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.envcreates:-
lab-stop (via
docker stopcontainer 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:%pdocker-py
libselinux-python # For systems that have SELinux enabled such as Fedora, RHEL, and CentosIn 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>