| || || || |
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.
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
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.
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.
This stage of the Playbook can take several minutes to execute on first run.
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.
1 2 3 4 5
The Ansible module being used here is the file module.
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.
1 2 3 4 5
The Ansible module being used here is the unarchive module.
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.
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.
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.
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
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
- Save the file as
git add main.yamlto add it to the Git staging area
git commit -am 'creating and Committing our primary playbook'to commit the file to our repository
- Push the code to GitLab.com: