Agentless configuration management tool.
This directory contains a development environment for Ansible Playbooks using Docker Compose. (Not intended for Ansible developing)
It defines one container with Ansible and another one with the target machine.
ansible: Alpine with Python 2.7. Ansible is installed via
git, the configuration in
etc/is mounted on
/etc/ansible/, and the
ansible/directory is mounted on
/opt/ansible. It also contains a private key to connect to the target machines
target: Ubuntu Xenial with ssh server to test Ansible playbooks. Python is installed, as it's needed by Ansible to run (this would be a problem in embedded systems). It contains a public key to allow passwordless logins from Ansible container.
dev up -d
to start the target machine and the network, then run an ansible command against it:
dev run ansible target -m ping
There's a key pair without passphrase to avoid password prompts. The public key is copied to
target when the image is created, but the ansible private key is mounted on the container. If want to change it, just generate another key pair and substitute the current pair.
WARNING: It uses
rootto connect, so it should't be used in production.
To discard all changes done on
target, just destroy the environment and start it again (
restart only stops and restarts the containers, so the volumes are preserved):
dev down dev up -d
There are some examples in the playbooks directory. As an exercise, I'm going to write a playbook to install PostgreSQL 9.x.
The process to install PostgreSQL can be summarized as:
- Add repository
- Authenticate repository
- Install packages
- Setup configuration files
- Setup users
These are going to be the tasks in the YML file. I've started with a simple playbook, but it's better organized as a role, so I have developed just the role.
- version: We can pass the version setting the variables in the command line:
ansible-playbook playbooks/psql.yml -e "version=9.4". Defaults to 9.6.
- datapath: It's created based on
- configpath: It's created based on
They are pretty self explanatory
- Add repo, takes in account the distro.
- Authenticate repo.
- Install packages, will use the appropiate version of
- Setup, uses some templating. It can be hard to be consistent between versions. Here they solved it using different templates for each version.
- Add admin user. This is tricky. Usage of
psycopg2to be installed on the target host, which is far from ideal. Other option is to create the user using a crafted query via
psqlbinary, which is also crappy, so I've taken the option of installing
python-psycopg2system package, as it's the cleanest way.
There are templates for:
There are no dependecies with other roles, nor Galaxy stuff
First, we create a group in runtime to select only the Debian family, then apply the role to that group.