The content of theprod.yml⁶²Ansible playbook is as follows.
1 - hosts: prod
Just by reading the playbook one should be able to understand what’s it about. It is running on hosts called prod as the user vagrant and executes commands as sudo. At the bottom is the list of roles that, in our case, consists of only two; common and docker. Role is a set of tasks that we usually organize around one functionality, product, type of operations, and so on. The Ansible playbook organization is based on tasks that are grouped into roles that can be combined into playbooks.
Before we take a look at it, let us discuss what are the objectives of the docker role. We want to make sure that the Docker Debian repository is present and that the latest docker-engine package is installed. Later on, we’ll need thedocker-py⁶³ (Python API client for Docker) that can be installed withpip⁶⁴ so we’re making sure that both are present in our system. Next, we need the standard Docker configuration to be replaced with our file located in the files directory. Docker configurations require Docker service to be restarted, so we have to do just that every time there is a change to the files/docker file. Finally, we’re making sure that the user vagrant is added to the group docker and, therefore, able to run Docker commands.
Let us take a look at the roles/docker directory that defines the role we’re using. It consists of two sub-directories, files, and tasks. Tasks are the heart of any role and, by default, requires them to be defined in the main.yml file.
The content of theroles/docker/tasks/main.yml⁶⁵file is as follows.
⁶²https://github.com/vfarcic/ms-lifecycle/blob/master/ansible/prod.yml
⁶³https://github.com/docker/docker-py
⁶⁴https://pypi.python.org/pypi/pip
⁶⁵https://github.com/vfarcic/ms-lifecycle/blob/master/ansible/roles/docker/tasks/main.yml
1 - include: debian.yml
2 when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu' 3
4 - include: centos.yml
5 when: ansible_distribution == 'CentOS' or ansible_distribution == 'Red Hat Ent\
6 erprise Linux'
Since we’ll be running Docker on both Debian (Ubuntu) and CentOS or Red Hat, roles are split into debian.yml and centos.yml files. Right now, we’ll be using Ubuntu so let’s take a look at the roles/docker/tasks/debian.yml⁶⁶role.
1 - name: Debian add Docker repository and update apt cache 2 apt_repository:
3 repo: deb https://apt.dockerproject.org/repo ubuntu-{{ debian_version }} main 4 update_cache: yes
5 state: present 6 tags: [docker]
7
8 - name: Debian Docker is present 9 apt:
15 - name: Debian python-pip is present 16 apt: name=python-pip state=present 17 tags: [docker]
18
19 - name: Debian docker-py is present
20 pip: name=docker-py version=0.4.0 state=present 21 tags: [docker]
22
23 - name: Debian files are present 24 template:
30 - name: Debian Daemon is reloaded
⁶⁶https://github.com/vfarcic/ms-lifecycle/blob/master/ansible/roles/docker/tasks/debian.yml
31 command: systemctl daemon-reload
32 when: copy_result|changed and is_systemd is defined 33 tags: [docker]
34
35 - name: vagrant user is added to the docker group 36 user:
42 - name: Debian Docker service is restarted 43 service:
44 name: docker 45 state: restarted
46 when: copy_result|changed or user_result|changed 47 tags: [docker]
If this would be a different framework or a tool, I would pass through each of the tasks and explain them one by one, and you would be very grateful for acquiring more pieces of wisdom. However, I do not think there is a reason to do that. Ansible is very straightforward. Assuming that you have a basic Linux knowledge, I bet you can understand each of the tasks without any further explanation.
In case I was wrong, and you do need an explanation, please look for the module in question in the All Modules⁶⁷section of the Ansible documentation. For example, if you’d like to know what the second task does, you’d open theapt module⁶⁸. The only important thing to know for now is how the indentation works. YAML is based on key: value, parent/child structure. For example, the last task has name and state keys that are children of the service that, in turn, is one of the Ansible modules.
There is one more thing we used with our prod.yml playbook. The command we executed had the-i hosts/prodargument that we used to specify the inventory file with the list of hosts the playbook should run on. Thehosts/prod⁶⁹inventory is quite big since it is used throughout the whole book. At the moment, we are interested only in the prod section since that is the value of the hosts argument we specified in the playbook.
If we’d like to apply the same configuration to more than one server all we’d have to do is add another IP.
We’ll see more complex examples later on. I intentionally said more complex since nothing is truly complicated in Ansible but, depending on some tasks and their interdependency, some roles can be more or less complex. I hope that the playbook we just run gave you an approximation of the type of the tool Ansible is and I hope you liked it. We’ll rely on it for all the configuration management tasks and more.
You might have noticed that we never entered the prod environment but run everything remotely from the cd server. The same practice will continue throughout the book. With Ansible and few other tools we’ll get introduced to, later on, there is no need to ssh into servers and do manual tasks.
In my opinion, our knowledge and creativity should be used for coding and everything else should be automatic; testing, building, deployment, scaling, logging, monitoring, and so on. That is one of the takeaways of this book. The key to success is massive automation that frees us to do exciting and more productive tasks.
As before, we’ll end this chapter by destroying all the VMs. The next chapter will create those we need.
1 exit 2
3 vagrant destroy -f
With the first production server up and running (at the moment only with Ubuntu OS, Docker, and Docker Compose) we can continue working on the basic implementation of the deployment pipeline.