The main.yaml File¶
| Filename | Location | Group | Project/Repository |
|---|---|---|---|
main.yaml | ./main.yaml | configuration | ansible |
Why?¶
A Playbook is a set of instructions. We use these instructions to describe the state, the configuration, we want Ansible to manage for us. Our Playbook is very simple at this point in time.
We combine our Playbook with the inventory we've created and we can begin to configure our fixed systems.
Breakdown¶
What we're doing in our Playbook is the following:
- Get the system's packages up to date
- Install the packages we need
- Set up the
ubuntuuser's home directory for our application - Upload our application
- Configure
systemdto manage our application as a service - Start the service
Let's go through each part of the steps above and highlight anything worth mentioning.
This should act as a good introduction to Ansible as well as explaining our goals.
Step 1¶
1 2 3 4 5 | |
The Ansible module being used here is the apt module.
We're using the additional, optional property update_cache and setting it to yes so that apt, on the remote host, will update the local cache of its packages before attempting to install anything.
Note
This stage of the Playbook can take several minutes to execute on first run.
Step 2¶
1 2 3 4 5 6 | |
The Ansible module being used here is the apt module, again.
Notice the use of loop: to create a list that the module will use to install multiple packages. This saves having to call the apt for each package we want.
Step 3¶
1 2 3 4 5 | |
The Ansible module being used here is the file module.
We're using state: directory to make the module create a directory for us and not a file.
We're also using the become: no meta property (it's a meta property because it's telling Ansible to behave in a particular way, not the file module.) We want Ansible to create the directory as the normal user we've used to connect to the system. If don't do this the directory will be owned by the root user but will exist inside of the normal user's home directory and be inaccessible.
Step 4¶
1 2 3 4 5 | |
The Ansible module being used here is the unarchive module.
We're using become: no here again for the same reason as above: ownership and permissions.
This module uses the unzip binary to extract our application. That's why we needed to install the unzip utility in the step above.
Step 5¶
1 2 3 4 | |
The Ansible module being used here is the copy module.
Here we're copying a local file, ./files/httpcats.systemd.service, to the remote system so we can get systemd to manage our application for us.
Step 6¶
1 2 3 4 5 | |
The Ansible module being used here is the systemd module.
And finally we're using the systemd module to start and manage our application as a service for us.
The daemon_reload: yes property on the module tells systemd to reload its own daemon as we've made changes to the systemd configurations on disk (when we used copy above.)
The Solution¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | |
Committing the Code¶
- Set your working directory to the
configuration/ansiblerepository - Save the file as
main.yamland usegit add main.yamlto add it to the Git staging area - Use
git commit -am 'creating and Committing our primary playbook'to commit the file to our repository - Push the code to GitLab.com:
git push