Problem Solving: Building Docker Containers Using Ansible.

5 min readJan 8, 2021

In this lab i’ll take you through the process of creating Docker containers using Ansible playbooks and the troubleshooting I used to solve the errors which occurred along the way.

In this lab, I was eventually successful in building Docker containers using Ansible. However, there were several errors along the way and required some DevOps surgery to get this playbook to run properly. Let me explain…

For this project I used an Amazon Linux 2 server inside a virtual environment.

What Is a Virtual Environment? At its core, the main purpose of Python virtual environments is to create an isolated environment for Python projects. This means that each project can have its own dependencies, regardless of what dependencies every other project has.

I then ssh’d into my EC2 server and created a working directory. Then decided to use root for this lab, but it’s not mandatory. I then created my virtual environment and built my playbook for launching Docker containers.

1. ssh cloud_user@YOUR-PUBLIC-IP-ADDRESS-HERE
2. mkdir ansible
3. sudo su

Here’s how to create for MacOs or Linux, if you have Windows the steps are located at this resource. → https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/

1. python3 -m pip install --user virtualenv
2. python3 -m venv env
3. source env/bin/activate

This playbook below was the original playbook I was trying to run with a hosts file containing “localhost” and then the command “ansible-playbook -i localhosts, playbook.yaml” to run. However it was very unsuccessful….

This fatal error code kept popping up after numerous random troubleshooting.

Here is a closer look at the error, which appears to be a python or docker error.

It seemed I had one of the following problems happening.

Docker module from pypi is not installed. Some package managers, including pip, use PyPI as the default source for packages and their dependencies.
Ansible is using the wrong python interpreter. Maybe 2.7?

After doing some research I realized “docker — version” is for the CLI tool for the docker engine. However pip seemed to be acting funny because I couldn’t install anything by “pip” for some reason. For example “pip install docker” was unresponsive.

$pip — version returns python version 3.7

I took a deeper look at the site packages and used the command ls -la /home/cloud_user/ansible/env/lib/python3.7/site-packages.

Then ls -la without the site packages.

Now pip was finally responding, and allowing me to install docker properly.

Then I checked the version of ansible and the location of python.

While you can write Ansible modules in any language, most Ansible modules are written in Python, including the ones central to letting Ansible work. By default, Ansible assumes it can find a /usr/bin/python on your remote system that is either Python2, version 2.6 or higher or Python3, 3.5 or higher.

Then the fun part began. I edited the cfg file, which I got from running ($which python) and edited it at vim /etc/ansible/ansible.cfg.

However, running the playbook again, I was still getting the same error…

The purple warning is showing me I am using the system python at /usr/bin/python but that isn’t my virtual env python where the modules are. It is also python 2.7 not 3.7. I needed to make sure ansible used the correct interpreter. So I put the correct path into my hosts file instead and changed the inventory command to “hosts” instead of “localhost,”.

This at least got rid of the python error I had been constantly getting.

The good news was it seemed like I had the right module installed and ansible was using the correct python interpreter, but now I had a new error to deal with. This time it was a docker issue. After running $docker ls I realized the Docker Daemon was not running and I needed to start it to have a chance.

$ systemctl start docker to start the docker daemon

I ran the playbook again. This time I had more success than before! However now I had yet another error. This time it wasn’t so bad it seemed to be a syntax error with one of the postgres Docker image in the playbook.

I am now using docker but it is returning an HTP 400 so that means it is our fault(client side). I had to make sure if postgres 10.4 was a valid image. Docker traditionally likes images to be tagged (image:tag) so I changed the syntax to postgres:10.4 instead. The playbook.yaml then looked like the one below.

The Winning Playbook: