Ansible Repository¶
This repository is a collection of playbooks, roles, plugins and inventories for multiple clients that PARAGON supports. It is build such that multiple clients could be installed on a single control host. However, by default the setup script installs the framework for an individual custumer so that those can use it for themselves too.
Installation¶
Before you can checkout the repositories from the server, you have to add your public SSH key to your user profile on the GitLab server. To do so, please go to https://gitlab.lakedrops.com/profile/keys and follow the instructions there. Please also note the link to instructions on how to generate it which also describes on how to prepare your local host to securly access the GitLab repositories.
Once that's been completed, proceed with these steps:
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 |
|
Patching¶
From time to time there might be problems with an Ansible core update and if there is no other way, i.e. modifying our Ansible playbooks and roles, then we may have to patch Ansible core and here is a list of availables patches and the information which of them needs to be applied to which Ansible version:
Patch File | Ansible Versions | Comments |
---|---|---|
none |
You can find the patches in the files/patches
sub-directory of this repository
and the Ansible core directory, that needs to be patched, depends on the operating
system and might be something like /usr/share/pyshared/ansible/
So, you may have to execute these steps:
1 2 |
|
Again, the directories depend on your local installation.
Configuration¶
The above installation configures Ansible such that everything is good to go
and you can call the ansible-script.py setup-local
script again at any time to grab updates
or restore settings if something got broken.
When using ansible-script.py setup-local
the first time there will be two new files being created
that you can use again in the future as shortcuts:
- /opt/ansible/update.sh which will update your installation by pulling all changed repositories and also running configuration of the current user
- /opt/ansible/config.sh which will just update the configuration for the current user
Important: if your remote username is different from your local username, you
should call those scripts (ansible-script.py setup-local
, update.sh
, config.sh
) with an
additional parameter --username=[REMOTE USER NAME]
. This will write that
username into the ~/.ansible.cfg
for future usage so as long as that name
remains the same, you no longer have to use that parameter again.
Additional settings make the usage of Ansible more convenient and we're describing them here with detailed descriptions.
Ansible configuration¶
You'll find a file .ansible.cfg
in your home directory after the setup from
above and there are certain additional settings that could be usefull:
Working with a vault for automatic sudo password input¶
When using Ansible with this repository you'll get asked for your remote sudo password every single time. If you want to avoid that, you can store that password in a vault so that Ansible grabs it from there automatically.
Warning: Only use that if you have full control over the Ansible control host because otherwise someone else could get access to your whole server farm.
- Create your vault password file
Create a file named
~/.ansible/vault.pwd
and edit that file so that it contains your local password for your Ansible vault. - Configure your vault password file
To make sure Ansible is going to utilize your password file, insert the line
vault_password_file = ~/.ansible/vault.pwd
into.ansible.cfg
in your home directory. - Create your vault
Use the command
ansible-vault create ~/.ansible/secrets
and include one lineansible_sudo_pass: YOURSUDOPASS
. This is using your default editor for the console but you can configure that likeexport $EDITOR=nano
to use the nano editor as an example. When saving the file, ansible-vault will encrypt that file with your vault password contained in the vault.pwd file. - (Optional) Edit your vault file later on
If you later want to edit your secrets, use
ansible-vault edit ~/.ansible/secrets
AWS EC2: Boto configuration¶
If you want to use the dynamic AWS EC2 inventory, you should provide your access
keys in a file /etc/boto.cfg
with the following content:
1 2 3 |
|
Note: The access key and secret key should be provided without the < brackets >.
In a multi-company environment the configuration file should provide different sections for each company that has hosts in AWS EC2:
1 2 3 4 5 6 7 |
|
Here you should replace COMPANY#
with the lower case name of the relevant company.
JiffyBox configuration¶
If you are using a JiffyBox inventory, you have to provide your API token in a
file /etc/jiffybox.cfg
with the following content:
1 2 |
|
Note: The api token should be provided without the < brackets >.
In a multi-company environment the configuration file should provide different sections for each company that has hosts in JiffyBox:
1 2 3 4 5 |
|
Here you should replace COMPANY#
with the lower case name of the relevant company.
Linode configuration¶
If you are using a Linode inventory, you have to provide your API key in a
file /etc/linode.cfg
with the following content:
1 2 |
|
Note: The api key should be provided without the < brackets >.
In a multi-company environment the configuration file should provide different sections for each company that has hosts in Linode:
1 2 3 4 5 |
|
Here you should replace COMPANY#
with the lower case name of the relevant company.
Creating shortcuts for the scripts¶
All the scripts in this repository are written in a way that they can be called from everywhere, you don't have to chdir into the repository directory first.
For better convenience, we recommend to create shortcuts in a directory which is part of your PATH environment variable. Examples:
1 2 3 4 |
|
Since version 1.2, the setup script is creating those links by default for you.
Preparing access to existing hosts¶
Ansible knows the hosts by name and the company specific naming convention should
be reflected on each local host that wants to use Ansible to manage them. You'll
find the hostnames in the file called inventory
(if you have a static
inventory) or for dynamic inventories this is an executibale file that you can
call and it will list the known hosts to your console.
You should make sure that your local host knows all your remote hosts by name
and their IP address. For this, add a new line for each of those hosts into your
/etc/hosts
file starting with the IP address followed by a space and the
hostname from the inventory file.
You can also run ansible-script.py hosts
and Ansible will update your
local hosts file automatically.
Next, and this is the final piece before you can start using Ansible to access
your hosts, make sure that you can access your hosts via SSH. This repository
is built with security at the forefront and therefore access is only available
through a PKI infrastructure. To configure your system for easy access, you
should have a file $HOME/.ssh/config
with some content similar to the
following:
1 2 3 4 5 6 |
|
The above setting applies to all hosts and the definition of the remote user name
is only neccessary if that remote username is different from your local one. Please
note that you should define the same username also in $HOME/.ansible.cfg
Where to go next?¶
The best place to continue reading is by heading over to the Wiki