Table of Contents

• What is Ansible?
• How Does Ansible Work?
• Ansible's Architecture
  • Plugins
  • Modules
  • Inventories
  • Playbook
• Benefits of Using Ansible
• Why is Ansible so important?
• How to Install and Configure Ansible on Ubuntu
• Conclusion
• References

What is Ansible?

Ansible is a tool that generates written instructions for automating IT professionals' work throughout the entire system infrastructure.

It's designed particularly for IT professionals who use it for application deployment, configuration management, intra-service orchestration, and practically anything else a systems administrator does on a weekly or daily basis.

Ansible is simple to install because it doesn't require any agent software or other security infrastructure.

While Ansible is at the cutting edge of automation, systems administration, and DevOps, it's also valuable as a tool for devs to use in their daily work.

Ansible allows you to set up not just one machine but a complete network of them all at once, and it doesn't require any programming knowledge.

How Does Ansible Work?

Ansible connects to nodes on a network (clients, servers, etc.) and then send a little program called an Ansible module to each node.

It then runs these modules through SSH and deletes them once they're done.

Your Ansible control node must have login access to the managed nodes for this interaction to work.

The most frequent method of authentication is SSH keys, but alternative methods are also allowed.

If you want to see how to install and start using Ansible, we'll cover that below.

Ansible's Architecture

Now let's take a look at Ansible's architecture and how it manages operations.

Ansible Plugins

Plugins are supplementary pieces of code that enhance functionality, and you've probably used them in many other tools and platforms. You can use Ansible's built-in plugins or create your own.

Examples are:

• Action Plugins
• Become Plugins
• Cache Plugins
• Callback Plugins
• Cliconf Plugins
• Connection Plugins
• HTTP API Plugins
• Inventory Plugins
• Lookup Plugins
• Netconf Plugins
• Tests

Ansible Modules

Modules are short programs that Ansible distributes to all nodes or remote hosts from a central control workstation. Modules control things like services and packages and can be executed via playbooks.

Ansible runs all of the modules needed to install updates or complete whatever operation is required and then removes them after they're done.

Ansible Inventories

Ansible uses an inventory file to track which hosts are part of your infrastructure and then accesses them to perform commands and playbooks.

Ansible works in parallel with various systems in your infrastructure. It accomplishes this by picking methods mentioned in Ansible's inventory file, which is saved in the host location by default.

Once the inventory is registered, you can use a simple text file to assign variables to any of the hosts, and you may retrieve inventory from a variety of sources.

Ansible Playbook

IT professionals can use Ansible playbooks to program applications, services, server nodes, and other devices without starting from scratch. Ansible playbooks, along with the conditions, variables, and tasks included within them, can be stored, shared, and reused forever.

Ansible playbooks function similarly to task manuals. They're simple YAML files, a human-readable data serialization language.

Playbooks are at the heart of what makes Ansible so popular. They specify activities that can be completed quickly without requiring the user to know or remember any specific syntax.

Benefits of Using Ansible

• Ansible is quick and easy to use, as it runs all of its operations over SSH and doesn't require the installation of any agents.
• Ansible is a free, open-source tool, and it's straightforward to set up and use: Ansible's playbooks don't require any special coding knowledge.
• Ansible can be used to perform simple tasks such as ensuring that a service is operating or rebooting from the command line without the need for configuration files.

In a more extensive or more uniform system, Ansible may be a better fit. It also provides a set of modules for managing various methods and cloud infrastructure.

Why is Ansible so important?

Modernization and digital transformation require automation that's both necessary and purposeful. We need a new management solution in today's dynamic contexts to increase speed, scale, and stability throughout IT infrastructure.

Technology is our most potent instrument for product improvement. Previously, accomplishing this required a significant amount of manual labor and intricate coordination. But today, Ansible - a simple yet powerful IT automation engine used by thousands of enterprises to simplify their setups and speed DevOps operations - is available.

How to Install Ansible on Ubuntu

Run the following commands to configure the PPA on your machine and install Ansible:

Update the repository:

sudo apt-get update

Install the software properties:

sudo apt-get install software-properties-common

And then install Ansible like this:

sudo apt-add-repository --yes --update ppa:ansible/ansible

Then run this:

sudo apt-get install ansible

You should have something similar to what is shown below:

Now that you have successfully installed Ansible, let's test if it's working by using the command below:

ansible --version

We'll use the command below to instruct Ansible to target all systems for the inventory host localhost, and we'll run the module ping from your local console (rather than ssh).

ansible all -i localhost, --connection=local -m ping

You should get a response similar to what you can see below:

How to modify the hosts that Ansible targets

We'll make changes to the host's file in /etc/ansible/hosts. This is the default file where Ansible searches for any defined hosts (and groups) where the given commands should be executed remotely.

sudo nano /etc/ansible/hosts

Add the lines below to the file and save the modifications:

[local]
localhost

Execute this command with your adjusted inventory file:

ansible all --connection=local -m ping

The response should look similar to what we have below:

How to configure a remote server

We deploy our Ansible test program to our remote server using a Digital Ocean droplet.

Use the command below to ssh into the server:

ssh username@IP_Address

Note: we have already configured an ssh key in our profile, which was selected when creating the droplet.

How to configure Ansible for a remote server

We will edit our hosts file in /etc/ansible/hosts using the command below:

sudo nano /etc/ansible/hosts

Add the lines below to the file and save the modifications:

[remote]
remote_test

[remote:vars]
ansible_host=IP_ADDRESS_OF_VIRTUAL_MACHINE
ansible_user=USERNAME

To see if Ansible can connect to your remote compute instance over SSH, let's type the following command:

ansible remote -m ping

We'll make an Ansible playbook using the command below, which is the typical way of telling Ansible which commands to run on the remote server and in what order. The playbook is written in .yml and follows a strict format.

In the official Ansible documentation, you can learn more about playbooks.

nano my-playbook.yml

Add the following code, which tells Ansible to install Docker in several steps:

---
- name: install docker
hosts: remote
become_method: sudo
become_user: root
vars: #local variables
docker_packages:
- apt-transport-https
- ca-certificates
- curl
- software-properties-common

tasks:
- name: Update apt packages
become: true #make sure you execute the task with sudo privileges
apt: #use apt module
update_cache: yes #equivalent of apt-get update

- name: Install packages needed for Docker
become: true
apt:
name: "{{ docker_packages }}" #uses our declared variable docker_packages
state: present #indicates the desired package state
force_apt_get: yes #forces to use apt-get

- name: Add official GPG key of Docker
shell: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

- name: Save the current Ubuntu release version into a variable
shell: lsb_release -cs
register: ubuntu_version #Output gets stored in this variable

- name: Set right Docker directory
become: true
shell: add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu {{ ubuntu_version.stdout }} stable"

- name: Update apt packages
become: true
apt:
update_cache: yes

- name: Install Docker
become: true
apt:
name: docker-ce
state: present
force_apt_get: yes

- name: Test Docker with hello world example
become: true
shell: docker run hello-world
register: hello_world_output

- name: Show output of hello word example
debug: #use debug module
msg: "Container Output: {{hello_world_output.stdout}}"

We can now execute it with the command below:

ansible-playbook my-playbook.yml -l remote

After that, we'll see some magic happen (it might take a while), and somewhere in the last debug message in our terminal, we should see "Hello from Docker!"

Conclusion

In this article, we had a detailed look into Ansible, its benefits, how it works and what it can do, its architecture, plugins, playbook, inventory, and how to configure and deploy Docker with Ansible on a remote server.

Thank you for reading!

Resources

Ansible docs Setting up Ansible Inventories Ansible installation

I'd love to connect with you on Twitter | LinkedIn | GitHub

If you already have experience with AWS, then you know how much of a pain it can be to work through web page after web page in the Amazon management console as you manually provision services. And even the AWS CLI - which is a huge step up - can add its own complexity and effort to the mix.

That's not to say that AWS itself doesn't address the problem with their own class of powerful orchestration tools, including CloudFormation and their Elastic Kubernetes Service (something I address at length in my "Using Docker on AWS" course at Pluralsight). But neither of those options lives quite so close to your existing infrastructure - or uses as familiar a way of operating - as Ansible.

If you're already using Ansible for your on-premises operations, plugging it into your AWS account can sometimes be the quickest and most painless way to migrate operations to the cloud.

Understanding the Ansible/AWS Advantage

My book "Manage AWS Resources Using Ansible" - from which this article is excerpted - is designed to quickly introduce you to applying Ansible's declarative approach to working with AWS resources. Being able to "declare" the precise configuration results you want and then produce them by getting Ansible to read a playbook is Ansible's magic wand. When properly planned, it's amazing how simple it can be to execute complex, layered AWS deployments.

Before we launch a simple "Hello World" Ansible playbook, let's first make sure you've got a properly-configured working environment through which Ansible can communicate with all its new friends in your AWS account.

Preparing a Local Environment

As you probably already know, Ansible is an orchestration tool that lets you write plain-text playbook files that declare the software profile and ideal state you'd like applied to a target server. Those servers - known as hosts - can be provisioned for just about any digital workload you can imagine, using just about any combination of application software, and running on just about any platform.

In the good old days, when a playbook was run against a physical server, Ansible would employ an existing SSH connection to securely login to the remote host and go about building your application. But that won't work for AWS workloads. You see, because the EC2 instances and other infrastructure you want to launch don't yet exist, there can be no "existing" SSH connections. Instead, Ansible will use Boto 3 - the software development kit (or SDK) used by AWS that allows Python code to communicate with the AWS API.

Using the AWS CLI to Connect Ansible

You don't have to know how all that works, but it has to be there so it can work. For that reason you're going to install the AWS command line interface (CLI). We won't be using the CLI itself for anything important, but installing it will give us all the dependencies we'll need. You can find out how to make this work on the latest version of whatever OS you're using from the AWS documentation page.

Working with the Python package manager, PIP, is a popular way to get all this done. Here's how you would install PIP itself and then the AWS CLI on an Ubuntu machine:

sudo apt update
sudo apt install python3-pip
pip3 install awscli

I should note that, as I write this, Python 2 is still alive...but only just. So there might sometimes still be separate Python 2 and Python 3 versions installed on your system. Since Python 2 will soon be fully deprecated, you probably won't have to worry about specifying python3 or pip3 with your commands: that should be automatic.

Once the CLI is installed, run aws configure and enter your AWS access key ID and secret access key.

aws configure
cat .aws/credentials

You can get keys from the Your Security Credentials page in the AWS Management Console. Here's how those keys will look (don't get any naughty ideas, these aren't valid):

AccessKeyId: AKIALNZTQW6H3EFBRLHQ
SecretAccessKey: f26B8touguUBELGpdyCyc9o0ZDzP2MEUWNC0JNwA

Just remember that a pair of keys issued to the root user of your AWS account provides full access to your entire AWS account. Anyone in possession of those credentials would be quickly able to run up six and even seven figure services charges, so be very careful how you use and store them. Ideally, you would be better off limiting your risk exposure by creating an admin user in the AWS Identify and Access Management (IAM) service with limited powers and using a key issued to that user.

At any rate, why am I doing this? The value of populating my AWS credentials file is that Ansible is smart enough to look for it and, if no other authentication keys are available in the system environment, it'll use these. You'll soon see how mighty convenient that will be. However, you should be aware of other ways to manage authentication for Ansible playbooks, like using ansible-vault or by creating and then invoking an aws_keys.yml file. But one thing you should definitely NOT do is hardcode the keys in your playbook files - especially if you plan to push them to an online repository like GitHub. I'll quickly test the CLI to make sure we can properly connect to AWS. This simple command will list any S3 buckets I happen to have within this account.

aws s3 ls

We're now ready to install ansible. I'll go with pip3 for that. I could use the regular Ubuntu apt repository just as easily, but it will most likely install a slightly older version. Depending on your network connection, that'll take a minute or two, but I'll skip most of that.

$ pip3 install ansible

I'll confirm that it's properly installed by running ansible --version. This shows us the version that was built, that configured Ansible modules will, by default, be saved in either one of these two locations in the file system, that other modules would be available here and - most importantly - that the Ansible executable is located within the /local/bin/ directory beneath my user's home directory. My user here, by the way, is called ubuntu. You can also see that we're using a nice, up-to-date version of Python 3.

$ ansible --version
ansible 2.8.5
  config file = None
  configured module search path = 
    ['/home/ubuntu/.ansible/plugins/modules', 
    '/usr/share/ansible/plugins/modules']
  ansible python module location = 
    /home/ubuntu/.local/lib/python3.6/site-packages/ansible
  executable location = /home/ubuntu/.local/bin/ansible
  python version = 3.6.8 (default, Aug 20 2019, 17:12:48) [GCC 8.3.0]

One more step. As I mentioned earlier, Ansible will connect to AWS using the boto SDK. So we'll need to install the boto and boto 3 packages. I'll go with PIP for this one, too.

$ pip3 install boto boto3

Once that one has been brought on board, we'll be ready to get some real stuff done. That'll begin in the next section.

Testing Ansible with a Simple Playbook

This is going to be very simple proof of concept demo. I'll create a couple of files, walk you through the syntax, and then fire it up. First off, I'll use any plain text editor to create a hosts file. Normally, the hosts file tells Ansible where it can find the remote servers you want to provision. But since, in the case of AWS, the resources that will be our hosts don't yet exist, we'll simply point Ansible to localhost and boto will handle connections behind the scenes. Here's what the contents of that file will look like:

[local]
localhost

Next, I'll create a playbook file that I'll call test-ansible.yml. The yml extension, of course, indicates that this file must be formatted using YAML markup language syntax. As you can see from the file text I've pasted just below, that'll begin with three dashes marking the start of the file and then an indented dash introducing a set of definitions. The value of "hosts" could be one or more remote computers but, as I've said, we'll leave that up to the local system to figure out. The same goes for our connection.

The next section includes the tasks we want Ansible to perform. This one will use the aws_s3 module to create a new bucket on Amazon's S3 Simple Storage Service in the us-east-1 region. I have to give it this ugly name because S3 buckets require globally unique names - if a name you choose clashes with any one of the countless millions of names already out there, the operation will fail.

---
  - name: Test s3
    hosts: local
    connection: local

    tasks:
      - name: Create new bucket
        aws_s3:
          bucket: testme817275b
          mode: create
          region: us-east-1

I run the playbook by calling the ansible-playbook command using -i to specify the hosts file, and then pointing to the test.yml file. Ansible should give us some feedback in just a moment or two. If we're successful, you'll see "0" as the value of "failed" and at least "1" as the value of "ok".

$ ansible-playbook -i hosts test-ansible.yml
PLAY [Test s3] ******************************************************

TASK [Create new bucket] ********************************************

changed: [localhost]

PLAY RECAP **********************************************************
localhost: ok=1    changed=1    unreachable=0    failed=0   skipped=0
    rescued=0    ignored=0

If I check my list of buckets once more, I should - and do - see the new one:

$ aws s3 ls
2018-12-30 15:19:24 elasticbeanstalk-us-east-1-297972716276
2018-10-12 04:09:37 mysite548.com
2019-09-24 15:53:26 testme817275b

That's a very brief intro to setting up an Ansible environment. We saw how using Ansible with Amazon's automatically provisioned resources is going to work differently than it would with traditional Ansible hosts. You're going to require a different set of authentication and inventory control tools. We walked through the process of setting up an Ansible environment and connecting it to AWS, and then running a simple playbook. Short and sweet.

This article comes from my book "Manage AWS Resources Using Ansible". There's more technology goodness - in the form of books, courses, and articles - available on my website, bootstrap-it.com.