Ansible-container: a new step in the management of containers

Recently, Ansible developers have announced a new draft Ansible Container . The project intrigued us very much, and we decided to take a closer look at it.
Ansible has long become an indispensable tool in the creation, assembly, deployment of images of docker containers and docker containers themselves, thanks to the appropriate module .
Previously, to run docker containers with Ansible, the sshd container was needed, but in version 2.1, the Docker connection plugin was added to Ansible, thanks to which it became possible to launch playbooks not only on physical / virtual machines, but also inside the docker containers. the need to use sshd inside the docker container


')
Another of the reasons why developers began work on ansible-container is the Dockerfile format. Probably, many people know that Dockerfile is no more than a shell script with its own instructions. I don’t know about you, but personally I would prefer to describe the contents of the container in yaml-format, than to fence a wrapper from a shell script, which then not everyone can understand. Thus, we were given another cool opportunity - building a docker image using an ansible playbook!

Another nice bonus is the ability to orchestrate containers in docker-compose format.
It is also possible to upload and download images in the Docker registry (including private ones), and deploy applications in the Kubernetes cluster and in the OpenShift cloud.

Let's have a little acquaintance with ansible-container.
We will use CentOS 7 as the host machine.

Install Docker.

sudo tee /etc/yum.repos.d/docker.repo <<-'EOF' [dockerrepo] name=Docker Repository baseurl=https://yum.dockerproject.org/repo/main/centos/7/ enabled=1 gpgcheck=1 gpgkey=https://yum.dockerproject.org/gpg EOF 

 sudo yum install docker-engine 

Ansible installation.

The installation of ansible is beautifully described in the official documentation.

Let's connect the EPEL repository (there is the latest stable version of Ansible 2.1 available in it), install ansible, git and python-pip to manage the python packages.

 yum install epel-release yum install ansible git python-pip 

Install ansible-container
Everything is pretty simple here. So far, only the build from source is available, since the project is at the stage of early development and has not yet been laid out in the repository.

 git clone https://github.com/ansible/ansible-container.git cd ansible-container pip install --upgrade setuptools python ./setup.py install 

Customization

The IP address assigned to the host is NOT 127.0.0.1. It must be deleted from the Ansible build container.
By default, the docker daemon listens on a UNIX socket. To use Ansible Container, you need to move the daemon on a TCP socket.

 vi /etc/systemd/system/docker.service 

Change the line * ExecStart * IP-address to the current:

 [Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network.target docker.socket Requires=docker.socket [Service] Type=notify # the default is not to use systemd for cgroups because the delegate issues still # exists and systemd currently does not support the cgroup feature set required # for containers run by docker ExecStart=/usr/bin/docker daemon -H fd:// -H tcp://0.0.0.0:2375 MountFlags=slave LimitNOFILE=1048576 LimitNPROC=1048576 LimitCORE=infinity TimeoutStartSec=0 # set delegate yes so that systemd does not reset the cgroups of docker containers Delegate=yes [Install] WantedBy=multi-user.target 

It is also recommended to configure TLS for the docker daemon . In the test environment, we dropped this moment.

restart docker-daemon

 systemctl daemon-reload systemctl restart docker 

Do not forget to set the DOCKER_HOST variable to work with the docker daemon over a TCP socket.

 export DOCKER_HOST=tcp://0.0.0.0:2375 

After installing ansible and ansible-container, you need to create a new project.

 ansible-container init 

after that, we will create a directory "ansible" with three files inside

 ansible |-- container.yml |-- main.yml `-- requirements.txt 

The container.yml file is a description of the launch of the project, its containers and the applications inside them. The format is very similar to docker-compose v 1.

For example, we have a couple of spherical roles in a vacuum.

 ├── container.yml ├── main.yml ├── requirements.txt └── roles ├── dumb-init │ └── tasks │ └── main.yml ├── nginx │ ├── defaults │ │ └── main.yml │ ├── files │ │ └── nginx.repo │ ├── handlers │ │ └── main.yml │ ├── tasks │ │ └── main.yml │ └── templates │ └── nginx.conf ├── php-fpm │ ├── handlers │ │ └── main.yml │ ├── tasks │ │ └── main.yml │ ├── templates │ │ └── php.ini │ │ └── app.conf │ └── vars │ └── main.yml 

container.yml file

 version: "1" services: nginx: image: centos:7 ports: - "80:80" links: - php command: ['/usr/bin/dumb-init', '/usr/sbin/nginx', '-c', '/etc/nginx/nginx.conf' ] volumes: - /var/www:/usr/share/nginx/html php: image: centos:7 ports: - "9000:9000" command: ['/usr/bin/dumb-init', '/usr/sbin/php-fpm', '-y', '/etc/php-fpm.d/app.conf'] volumes: - /var/www:/usr/share/nginx/html 

The main.yml file is nothing more than an ansible playbook that describes the configuration of the docker containers. This scenario will be used to build docker images. We no longer need a bunch of folders and Dockerfiles. The assembly of all images can be described in a single file.

 - hosts: all gather_facts: false roles: - dumb-init - hosts: nginx roles: - nginx - hosts: php roles: - php-fpm 

Putting images with the team:

 ansible-container build 

And run the containers:

 ansible-container run 

Thus, in two teams we can build, run a full-fledged dokerezirovanny application, not bothering to write Dockerfile and not entering a bunch of parameters in the command line when launching docker-containers.

The project is still quite young, is at the stage of active development, but, in my opinion, it has great potential, although there are some other shortcomings. For example, I could not find how to run containers with the detach option (analogous to docker-compose up -d) or the ability to debug playbukov. And the assembly of images seemed to me too long, in contrast to the assembly of images by the traditional Dockerfile.

Thanks for attention. Successful automation!
Author: DevOps admin Southbridge - Victor Batuev.