This talk was an introduction to the Dockerfile format and to Ansible container’s tool and then a comparison of both. It was hold by Tomas Tomecek from Red Hat’s containerization team.
It’s a file with no formal specification describing a recipe to create a Docker image using a sequence of instructions with arguments.
It starts with a
FROM instruction that sets a base image to build your image from, then you prepare the container’s internals and setup your app, and it ends with a
CMD instruction executing a shell line to run your app.
Best practices encourage you to set arguments that are subject to change, such as a mounted configuration directory, at the end of your file so that Docker only has to partially rebuild the image each time you want to test it.
The Docker Hub is a public registry hosting images and available to anyone, however more than 60% of these images are out of date, so you should check the linked github repository before you download anything.
You can orchestrate applications run in different containers through Docker Compose with another configuration file written in YAML.
Since it’s Docker’s default image building specification file, the dockerfile has a very wide usage and a good documentation and the Docker Hub is well furnished. It is also an actively developed project and relatively easy to get started with.
However the Dockerfile can’t easily be parsed since it doesn’t have formal specifications, and instructions can get really complex (see Go’s dockerfile for example) even if it is just essentially a shell script with metadatas. Images on the Docker Hub have to be carefully selected and the technology in itself is specific to Docker containers and Kubernetes.
Ansible is an OpenSource automation platform aquired by Red Hat in 2015 that has been packaging it with its’ releases since. It runs on a Linux server without any daemons, manages its servers using instruction files written in YAML and parsed using Python, and has an ecosystem rich of hundreds of modules to use.
Technical terms for Ansible include:
- Task: a command to execute
- Playbook: a group of tasks
- Play: the execution of a Playbook
- Role: a way to export playbooks and re-use them (like a Node.js module)
The Ansible Container tool allows you to build Docker images using only Ansible playbooks, thus getting rid of the Dockerfile format. It’s a year and a half old project on Github with close to a thousand commits and a small team of continuous developpers.
The tool gets installed using pip:
sudo pip install ansible-container
and comes with five basic actions:
ansible-container initto initialize an empty container project
ansible-container installsto download and install necessary ansible roles
ansible-container buildto create the Docker images from your playbook
ansible-container runto launch the containers
ansible-container deployto push the images to any registry and generates a playbook to deploy the project
In an initialized container project you will find:
container.ymlfile, an equivalent of
docker-compose.ymlthat will define services, the roles that describe them and intercommunication parameters (ports to expose, …)
a set of ansible roles containing:
- playbooks to prepare the containers
- metadatas describing the container’s base image, environment variables and command to run
And if you have existing docker compose or simple Dockerfile projects, you can convert them using
ansible-container import <directory>. The tool will parse the existing Docker configuration and generate the corresponding ansible container project with roles and
You can find a very complete demo on Github.
Using Ansible Container’s tool, you get to include your containers into your existing Ansible architecture and benefit from the huge ecosystem of existing roles.
However, due to Ansible’s way of describing tasks, some Dockerfile instructions can be very complex to convert, and you might have some learning to do.
With its container module close to a 1.0 release, Ansible offers a real alternative to Dockerfile and its complexity, and removes a tool that might be unnecessary if you are using Ansible to handle your architecture.
However if you are not already using Ansible, you might be better off with keeping your existing Dockerfile, you should use the tool that suits you best.