A lightweight Centos based Ansible Lab using Docker. Creates a Docker centos
container running systemd
and ssh
with a vagrant user and passwordless sudo.
Ideal for a Ansible container based lab fully configured with localhost to container networking. Not Ideal for Production.
You get:
-
A bastion host/jumpbox
-
An arbritrary number of centos/ssh containers
-
by default using user vagrant and vagrant insecure key
-
-
A lab directory containing your:
-
inventory file:
hosts
-
pre-configured
ansible.cfg
(inventory and ssh) -
ssh directory: with insecure vagrant key and 2 ssh.cfg files
-
-
ssh access is automatically created and supports:
-
direct, via port mapping, default setup via
ssh.cfg
-
via jumphost 1st docker container using
ssh-jumphost.cfg
-
-
docker utilities aliases automatically created
-
source utilities/docker_aliases.env
creates:-
lab-stop (via
docker stop
container names`) -
lab-destroy (via
docker rm container names
)
-
-
Define your lab in
lab_vars.yml
-
ansible-playbook lab_create.yml
-
That’s it
labs/
contains:
lab ├── ansible.cfg ├── hosts ├── ssh │ ├── insecure_private_key │ ├── ssh-jumpbox.cfg │ └── ssh.cfg └── utilities └── docker_aliases.env
All access assumes localhost is the control node and has the necessary ssh
key(s). By default it uses vagrant insecure key and connects via ssh/ssh.cfg
which automatically uses port mapping. i.e. all targets are access via
locahost:port.
If you prefer to use the first container as an ssh jumphost an alternative ssh
confiration files, ssh-jumphost.cfg
is automatically generated and can be
pointed to via ansible.cfg
Note
|
the bastion host does not have a copy of this key so all ssh access is
via
|
Note
|
The auto generated ssh.cfg uses ProxyJump in preference to ProxyCommand.
This is a much cleaner syntax but if you are running a version of ssh prior to
OpenSSH 7.3 :
* Seriously think about upgrading!
* Use ProxyCommand instead, something like…
|
ProxyCommand ssh vagrant@bastion -W %h:%p
docker-py
libselinux-python # For systems that have SELinux enabled such as Fedora, RHEL, and Centos
In order to run the playbook in a Python virtualenv in a system that has SELinux enabled,
the virtualenv must be created with the --system-site-packages
option to enable
access to the global site-packages directory where the libselinux-python
is installed.
Example:
$ virtualenv --system-site-packages <venv_name>
or, if using virtualenvwrapper
:
$ mkvirtualenv --system-site-packages <venv_name>