Introduction to Ansible Transcripts
Chapter: Ansible Core Concepts
Lecture: Core Ansible Concepts Overview

Login or purchase this course to watch this video and the rest of the course contents.
0:00 Ansible has a set of terminology and core concepts
0:03 that are going to be crucial for you to learn and understand
0:06 because we're going to use them throughout the rest
0:08 of the videos in this course.
0:09 This video is designed to introduce you to those concepts
0:12 and show how they relate.
0:14 Then we'll explain in further depth
0:15 each of these concepts in turn.
0:17 If we think about how a configuration management tool
0:19 operates, there has to be some way for us to execute actions
0:23 against the servers that we want to configure.
0:25 With any configuration management tool
0:27 that tool contains some code, and it will expose a way
0:30 for you to use operations so you can execute your actions.
0:33 In Ansible's case, these are modules
0:36 and most modules contain a familiar name.
0:38 For example, if you're working with a Git source control
0:40 system, you're going to be working with a Git module.
0:43 If you're trying to bring services up and down
0:45 on a Linux system, you use the service module.
0:47 The database back ends like Postgres
0:49 or the in memory data store, Redis, likewise.
0:52 They have modules named after them.
0:53 There's a laundry list of hundreds of core modules
0:56 that come with Ansible, which we saw in the documentation.
0:59 And Ansible makes it easier for you to write your own
1:01 modules if for some reason what you're trying to do
1:03 is not covered by the existing modules.
1:05 So modules are our first core concept.
1:07 This is functionality that Ansible exposes to us
1:10 but we need some way to use that functionality.
1:13 We need a mechanism to specify the modules
1:15 that we're going to use.
1:16 Another way to put this is the modules are the code
1:19 that Ansible already has, and you need a way to write code
1:22 or some markup language that will let you
1:24 use that Ansible code. In this case, we have tasks.
1:27 A task is a specific implementation.
1:29 If we need to use the Git module where we will specify
1:32 a particular Git repository that we want to clone
1:35 or push our code to, we'll write a specific task
1:38 like restart the Nginx service.
1:40 We'll modify or recreate Postgres or Redis database
1:44 and we'll enable and disable rules on a firewall.
1:46 Tasks are the bridge from the Ansible code
1:49 that's contained in modules to what you are writing
1:51 to use Ansible for configuration management.
1:53 With any non-trivial configuration or deployment
1:56 we're probably going to have dozens, or hundreds
1:58 maybe thousands of tasks.
2:00 So we need some way to organize and group
2:02 these related tasks.
2:04 Ansible has two more core concepts here
2:06 that we're going to use, roles and playbooks.
2:08 Roles are a flexible way to express what tasks to apply
2:12 to one or more types of servers that we're working with.
2:14 Think about roles as either being horizontal
2:17 so they'd be cutting across every single server
2:19 that you'd have as a part of your deployment.
2:20 So if you have common security settings
2:22 you would specify your security settings as a role.
2:25 Or they can be verticals like a web server configuration
2:28 or a database back end.
2:29 Roles are one of the most flexible, conceptual ideas
2:32 so they often take the longest to wrap your head around.
2:34 And many roles are contained within a playbook
2:37 and we can have one or more playbooks.
2:38 Playbooks are the overarching way to organize
2:41 all of your tasks and all of your roles
2:43 so that Ansible can execute them.
2:45 While it is possible to run an ad hoc task with Ansible
2:48 most of the time you're going to use the Ansible
2:50 playbook command, which will combine many roles
2:53 and many tasks within each of those roles
2:55 to complete a deployment
2:56 or orchestrate your server configurations.
2:58 The big missing piece here is the specific servers
3:01 that we want to execute our playbook against.
3:03 You wouldn't put specific host names or IP addresses
3:06 in the playbooks because they wouldn't be reusable.
3:08 Instead we have a different concept to describe
3:11 which servers we want to run which roles on.
3:14 This core concept is known as the inventory.
3:16 The inventory maps the roles, such as a web server
3:19 or a database server, to IP addresses and host names
3:22 that you want to configure.
3:23 The separation between what needs to be accomplished
3:27 that is specified within your playbook
3:28 and where to run those configurations goes a long way
3:32 with making Ansible playbooks reusable.
3:34 And its also a huge help when you're trying to deploy
3:36 to a dev environment, a staging environment
3:38 a test environment, production environment.
3:41 You only need to change the inventory.
3:42 You don't need to change the playbook itself.
3:44 Finally, YAML, or confusingly known as
3:47 YAML ain't markup language, is how we write our collection
3:50 of tasks within the roles.
3:51 We can also write our inventory in YAML
3:53 although, as we'll see in a future video
3:55 we can either us an INI format or YAML
3:58 and I typically use the INI format.
4:00 But just know that YAML is how you're going
4:02 to write your tasks.
4:03 So these six core concepts, the modules, which is the code
4:06 that is a part of Ansible that we're going to execute.
4:08 The tasks which allows us to describe which modules
4:11 we want to use and how we're going to use them.
4:13 The roles, which allow us to group related tasks together
4:16 for purposes like setting up a web server
4:18 or a database server.
4:19 Playbooks are typically the overall unit
4:22 that we're going to be executing, and we have one or more
4:24 roles that we're going to execute as a part of our playbook.
4:26 The inventory describes where we are going to
4:29 execute our playbook against
4:30 and YAML, which is how we write our tasks
4:33 and is one way we can write our inventory files.
4:35 We've seen a little bit about
4:36 how these concepts interrelate.
4:38 If you're still really confused by what each one means
4:40 that's why we're going to dive into each one right now.