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.