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

Talk Python's Mastodon Michael Kennedy's Mastodon