Ansible: Provisioning and Config Management
Key Points
- Developers often push code many times a day, yet many Ops teams still rely on manual processes for infrastructure automation.
- Ansible, an open‑source tool from Red Hat, enables “infrastructure as code” and helps solve the major challenges of provisioning, configuration, and (implicitly) orchestration.
- In the provisioning stage, Ansible creates the underlying resources (e.g., a VPC and virtual machines) and defines an **inventory** of hosts, which can be further organized into patterns such as “web” and “db”.
- The primary use case most users adopt first is **configuration management**, where Ansible declaratively ensures OS patches, services, and software are installed and running on the defined hosts.
- Although marketed as declarative—specifying *what* you want—Ansible’s execution model involves procedural tasks underneath, allowing both styles of automation.
Sections
- Introducing Ansible for Infrastructure Automation - The speaker explains how Ansible automates provisioning and inventory management, bringing infrastructure-as-code to operations teams.
- Creating an Ansible Playbook for VM Patching - The speaker outlines building a YAML‑based Ansible playbook that defines a play (with a name, target hosts, and tasks) to execute security patches and other installations across all virtual machines.
- Ansible Agent-less Execution and AWX - The speaker explains how Ansible runs without agents using SSH, suggests using AWX/Ansible Tower for secure, centralized playbook execution, and introduces the concept of idempotence.
- Ansible: Declarative, Agentless App Deployment - The speaker explains how Ansible’s declarative, agent‑free and idempotent design, supported by community modules, enables reliable infrastructure automation and can also be used to deploy web applications to virtual machines.
Full Transcript
# Ansible: Provisioning and Config Management **Source:** [https://www.youtube.com/watch?v=fHO1X93e4WA](https://www.youtube.com/watch?v=fHO1X93e4WA) **Duration:** 00:11:04 ## Summary - Developers often push code many times a day, yet many Ops teams still rely on manual processes for infrastructure automation. - Ansible, an open‑source tool from Red Hat, enables “infrastructure as code” and helps solve the major challenges of provisioning, configuration, and (implicitly) orchestration. - In the provisioning stage, Ansible creates the underlying resources (e.g., a VPC and virtual machines) and defines an **inventory** of hosts, which can be further organized into patterns such as “web” and “db”. - The primary use case most users adopt first is **configuration management**, where Ansible declaratively ensures OS patches, services, and software are installed and running on the defined hosts. - Although marketed as declarative—specifying *what* you want—Ansible’s execution model involves procedural tasks underneath, allowing both styles of automation. ## Sections - [00:00:00](https://www.youtube.com/watch?v=fHO1X93e4WA&t=0s) **Introducing Ansible for Infrastructure Automation** - The speaker explains how Ansible automates provisioning and inventory management, bringing infrastructure-as-code to operations teams. - [00:03:19](https://www.youtube.com/watch?v=fHO1X93e4WA&t=199s) **Creating an Ansible Playbook for VM Patching** - The speaker outlines building a YAML‑based Ansible playbook that defines a play (with a name, target hosts, and tasks) to execute security patches and other installations across all virtual machines. - [00:06:28](https://www.youtube.com/watch?v=fHO1X93e4WA&t=388s) **Ansible Agent-less Execution and AWX** - The speaker explains how Ansible runs without agents using SSH, suggests using AWX/Ansible Tower for secure, centralized playbook execution, and introduces the concept of idempotence. - [00:09:59](https://www.youtube.com/watch?v=fHO1X93e4WA&t=599s) **Ansible: Declarative, Agentless App Deployment** - The speaker explains how Ansible’s declarative, agent‑free and idempotent design, supported by community modules, enables reliable infrastructure automation and can also be used to deploy web applications to virtual machines. ## Full Transcript
As a developer I quickly got into the habit of pushing to GitHub multiple times a day.
So, it surprises me when I hear that Operations teams are tackling their infrastructure automation
with a lot of manual processes. Hey everyone, my name is Sai Vennam, and today I want to talk about
Ansible. Ansible is an open source infrastructure automation tool, initially developed by Red Hat
and enables you to tackle kind of all of the major challenges that come with infrastructure.
It enables you to do so with code, or in other terms infrastructure as code.
Now Ansible has three major kind of uses and I'll start with the first one because this is generally
the one that people tend to gravitate to when they hear infrastructure automation, and that's
the provisioning use case. So the first step of kind of any infrastructure story, you've got to
have some infrastructure in the first place. So, let's say that using Ansible we've already spun
up some environment, let's say it's a VPC and my favorite cloud provider, and within this VPC I've
got three virtual machines. So, we'll say we've got one, two, and then a third one as well. Now
these set of virtual machines are going to essentially be our set of hosts. In the Ansible
world, we're going to call this an inventory. So, it's basically the set of hosts that Ansible can
work against. So, what we're going to call this is an inventory. Now within this inventory we can
actually create even more sub categorizations and Ansible calls this patterns. So, let's say these
virtual machines have different, you know, underlying tasks and use cases and services
that they're going to be running. So, these first two virtual machines will call them web
because they're going to be used for web servers, and then this last one
we're going to call this DB because we're going to run MySql database on it. So, there we go we've
got our infrastructure we've got that provision kind of step already done, and I want to jump to
the second thing that Ansible is really good at it's config management. And actually I'd say this
is kind of the main use case that most people think about when they first start to use Ansible,
and this kind of refers to the ability to configure your actual infrastructure. So a
simple example would be something like operating system patches, or maybe making sure a certain
service is running, maybe installing some service onto a virtual machine. So in our use case today,
let's focus on that, let's focus on how we can do config management with these virtual machines.
Now one of the key tenets of Ansible is that it's declarative. Now out there there's kind of
the notion that Ansible can be both declarative as well as procedural or imperative, and the idea is
that, you know with Ansible you declare what you want instead of focusing on how it gets there.
But in essence it can also be considered procedural because the underlying tasks that run
are procedural in nature, but as a user of Ansible you're taking advantage of the declarative aspect
of it meaning you define what you want rather than how to get to whatever it is that you need.
Now today, what we want is to be able to run some tasks against those VMs. Let's say we want to run
some OS patches and then install a programming language, and then install MySQL. So, what we'll
need is a playbook. So that's what we'll start with first, we'll create an Ansible playbook
and as the name indicates a playbook is going to be a book of tasks or a set of of plays rather.
Now our first play we want to run this against all of our hosts and we want to just run a security
patch, we want to make sure they're all running the same version of the same operating system. So,
that will be our first play. So a play is going to be kind of consisting of three main things,
you need a name for that play, you need the host that it's going to run against, and you need the
actual tasks that will run. Now in this particular play, let's say that we've got the hosts set to
all because we want to run this against all the hosts. And as far as the tasks
we'll define some set of tasks like security patching and that kind of thing.
Now key thing that I want to mention here, Ansible takes takes advantage of YAML to do its kind of
declarative nature of being able to declare what you want. So this would this is obviously not
a valid YAML but in the real world you know when working with Ansible this would be in YAML format.
So that'll be our first play running against all of the hosts in our inventory.
Now let's let's create some more plays here. Let's create a play that runs directly against the hosts
for our web servers. So we call that web, right. And this is going to have a set of tasks,
maybe we need to do something like install Go and install Python, maybe install some other services
that are specific to our web servers. And finally we'll create one more play in this playbook,
and for this one we'll set the host to be our DB, and then for instead of tasks let's talk
about something called roles. Ansible has a concept of roles which basically enable you to
group together actions that you run multiple times. So instead of having to define all of
the tasks every single time you can just define the roles and that will take advantage of you
know the underlying modules and tasks that need to be run. By the way, a playbook is one way of
grouping together a set of tasks that you need to run, it's a declarative way of doing it,
but if you really want to keep things procedural imperative you can actually run
one-off tasks by themselves and do so in a in an imperative way or a procedural way, but this is
kind of the way you would do a fully declarative approach to automate a set of tasks against you
know the set of hosts in your inventory. So, this is our playbook and we want to execute this now.
That's going to bring me to my second tenet of Ansible and that's the fact that it's agent-less.
Now Ansible is agent-less in in the sense that like a lot of other infrastructure automation
tools, unlike a lot of other infrastructure automations, you don't actually need to install an
agent on the VMs that were provisioned. So, Ansible is able to take advantage of SSH
to actually directly go into those VMs and run the tasks that it needs to. So, let's
see what that looks like right. So we take our playbook and as a user we'll execute Ansible, and
Ansible can execute you know and most unix-like environments, so we'll execute our playbook and
it'll run against our virtual machines and there we go, we're happy. But here's one thing to think
about. Now chances are we wouldn't be running Ansible on our local machine, right. At the
end of the day it has to store SSH keys and a lot of kind of other secure configuration and
you're not really trying to run automation off your local machine. So there's a capability out
there called AWX, or Ansible tower, which is the downstream project of the open source AWX,
and that's basically a graphical interface and set of APIs that enable you to run Ansible and
operationalize it across your organization. So whether you're using Ansible, or Ansible Tower, a
user will come in execute that playbook and there we go, we'll have our config management executed.
Now the third aspect that I want to talk about with Ansible is the fact that it's idempotent.
Now what exactly does that mean? So idempotent refers to an operation that can be
run multiple times without changing beyond the initial application. In other terms, the first
time I run this operation it should recognize that the security patches need to be installed,
the services need to be installed, the Python and Go and MySQL, or whatever needs to be installed
has to be done. The second time I execute that same playbook it's going to recognize it's already
done it and it's going to say hey nothing needs to be done. But let's say I come back my second
day and I say oh we need to actually update the operating system version from you know 1.0 to 1.1,
and we run this same playbook and Ansible, or Ansible Tower,
and then recognize it and says hey that operating system has changed but nothing else did it's going
to execute the only action needs to to kind of resolve that difference. Now one thing to consider
all of these tasks have underlying modules that power them and you want to make sure make sure
that the modules themselves are programmed in a way that's idempotent. And this is important
and it kind of brings me to my last point here is that Ansible is community driven.
That means that if I'm trying to do these things in a playbook that I kind of outline today
chances are someone out there has already developed the playbooks, the modules, the tasks,
that I need to actually do those operations. Those are basically published as collections in what's
called Ansible Galaxy, which is a repository where developers can kind of contribute their Ansible
kind of modules, or playbooks, or tasks whatever they might have created in the ecosystem. That's
one of the great things about Ansible is that it's so community driven that chances are whatever I'll
need to do I'll be able to find in that galaxy, Ansible Galaxy. The one kind of disclaimer I'll
say, make sure run these operations locally, make sure they're item potent, make sure
that you know executing them multiple times responds in a way that's kind of predictable.
So all that being said, we've kind of talked about how Ansible is a declarative language,
it doesn't require an agent to be able to execute in these kind of end environments
in these virtual machines. It's idempotent based on the modules that you're using to enable you to
avoid things like config drift by making sure that any changes that you make should be done
in your infrastructure automation story, whether it's playbooks, or roles, or modules.
And then finally, you know you can rest easy knowing that chances are whatever you need to
automate is available in the community. Now the third use case I mentioned, there are
three things that you can do with Ansible, it's going to be app deployment. Now I'm not going to
go into too much detail here today about the app deployment use case, but the fact is you can use
Ansible to then take it a step further and deploy your actual web applications and workloads into
the virtual machines, it's also a capability available by Ansible. I hope this was helpful.
If you like this video or have any comments, be sure to drop a like or comment below.
Stay tuned and follow us for more videos like this in the future. Thank you.