The course is part of these learning paths
Getting Started With Ansible
Cloud platforms, on-prem servers, dozens of operating systems, more language and frameworks than you can count, and you have to manage it all!
These days even the "simple" application infrastructures have a lot of moving parts. Managing all of this stuff effectively takes some effort, and configuration management tools such as Ansible can help.
Ansible is an automation engine that can help with provisioning infrastructure, configuring operating systems, deploying applications, and much more.
The goal of this course is to teach you how to get started using Ansible for automation. By then end of this course you should be able to create playbooks to automate basic tasks. You won't know everything there is to know about Ansible, however you'll know enough of the basics to start using Ansible. You'll understand how Ansible manages inventory, how to create simple modules, how to create playbooks, how to deal with errors and more.
Understanding a tool such as Ansible has a lot of value to developers and operations engineers. Especially since it's agentless, because that means you can start managing hosts without needing to install an agent on them first. Well, assuming Python is installed. Developers can use Ansible to automate the creation of development environments that mirror production. And operations can use the same playbooks to automate the creation of staging and production environments. This level of consistency between environments tends to reduce bugs; especially those caused from environmental differences.
One of the features of Ansible that makes it so appealing is that it allows you to create modules with whatever language you want. Another appealing feature is the YAML based playbooks. The reason this is so appealing is that YAML tends to be a very simple format for expressing tasks. And that makes it easier to get started using it.
What You'll Learn
| Lecture | What you'll learn |
|---|---|
| Intro | What will be covered in this course |
| What is Ansible? | An introduction to Ansible |
| Concepts | An overview of the Ansible concepts |
| Installation | How to install Ansible |
| Inventory | How Ansible knows which servers to manage |
| Windows | How Ansible connects to Windows servers |
| Modules | What modules are and how to create one |
| Playbook | What playbooks are and how to create them |
| Handlers, Facts, Variables, and Templates | Handlers, Facts, Variables, and Templates |
| Roles | How to bundle functionality in a role |
| Errors and Debugging | How to deal with errors and how to use the debug module |
| Next Steps | How to keep learning |
If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.
Welcome back, in this lesson I'll cover some of Ansible's terms and concepts. Some of this may be difficult to understand until later in the course, because some of these concepts are so interconnected that no matter the order I explain it in, it still might be confusing at first. So if things are a bit confusing try and stick with it and it should start to make sense as you progress through the course.
I mentioned in a previous lesson that Ansible is an automation engine. Ansible allows you to run tasks on one or more servers, and there are two ways to run those tasks. You can use an ad-hoc command or you can run playbooks. Ad-hoc commands use the Ansible executable to run code on whichever servers you specify. The idea behind ad-hoc commands is that you can run one-off commands, which are things that you may only need to do once.
An example of an ad-hoc command is a command that would shut down a test server. Another example might be an ad-hoc command to restart a service. So they’re things that don't really require you to save them, because they aren't used often enough.
Here's an example of an ad-hoc command that restarts the Apache web server. It uses the Ansible executable and then it requires the hosts pattern, which is something I'll cover later in the course, and then any other options that you want to specify.
In this example lamp is the name of the group of servers that we're going to run this command on. The -m tells Ansible which module to run and then -a specifies a list of key value arguments. If this doesn't quite make sense yet don't worry it's going to start to make sense as I explain more about how Ansible works. So ad-hoc commands are just commands that you want to run once and forget about.
However, the real power with Ansible is the ability to run multiple tasks, and playbooks allow that to happen. Playbooks are a YAML file that contains plays. Now before I can explain plays I need to explain modules and tasks. At its core Ansible allows you to execute modules, which are wrappers around code designed for a specific purpose.
For example, the copy module allows you to copy a file from one location to another. The git module allows you to interact with a git repository, and the ping module allows you to ping servers. Now these are just three of the hundreds of modules that Ansible provides.
In the example of the ad-hoc command I showed the service module, which allows you to interact with services. When you call modules inside of a playbook you call them from a task. Tasks consist of a module and some metadata. The metadata includes things like the name of the task, notifications, settings for ignoring errors, etcetera. So a task is a wrapper around modules along with the metadata that Ansible uses to execute the modules in the way that you want to.
So now that I've explained modules and tasks I can explain plays. A play consists of a list of tasks to run, the hosts that the tasks should run on, any variables along with any additional settings, and all of that lives inside what Ansible calls a playbook.
A playbook can have multiple plays in it, and it can target multiple servers. Playbooks are going to be the way you'll interact with Ansible most of the time. So I'll be talking about them quite a lot throughout this course. Though for now this is going to wrap up this lesson.
In the next lesson we're going to talk about installing Ansible. So if you're ready to learn more than let's get started in the next lesson.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.