Docker Archlinux for testing Ansible playbooks

An updated, systemd-enabled Archlinux docker image (based on my docker-archlinux-systemd)
useful for testing Ansible playbook.

Images are built by GitHub CI, tagged and pushed to DockerHub at least once a month.

Available tags

Arch is a rolling release distribution. This means that the available tags
are nothing more than arbitrary snapshots of the distro at that particular time.

Beware when using tags in automated testing environments: while usually a good
practice, keep in mind that in reality Arch is changing daily and that a system
test with a pinned environment could become useless quickly. A more in-depth
discussion on this can be found here.

Usage: testing with Molecule

A working Docker installation is needed.
Images on Docker Hub gets automatically built at least once a month by GitHub Actions.

A working molecule installation is also needed.

Running molecule init scenario --driver-name docker will quick-start a project.
Now edit the 'platforms' section inside the file molecule/default/molecule.yml.

platforms:
  - name: cdp-arch-ansible
    image: carlodepieri/docker-archlinux-ansible:latest
    command: ${MOLECULE_DOCKER_COMMAND:-""}
    privileged: true
    pre_build_image: true
    # see "Problems with ulimits and makepkg" section below 
    ulimits:
      - nofile:65535:65535
provisioner:
  name: ansible
  inventory:
    host_vars:
      # setting for the platform instance named 'cdp-arch-ansible'
      # see "Problems with ulimits and makepkg" section below 
      cdp-arch-ansible:
        ansible_user: ansible

This will make molecule pull the image from Dockerhub and start the container in a way that

supports systemd and Ansible.
uses non-privileged, passwordless sudoer ansible user (to allow to build AUR packages)
uses lower nofiles ulimit value (to avoid problems with AUR package
builds taking too long).

For more information about last two points see Problems with ulimits and makepkg.

Important: the privileged flag is necessary to make systemd behave,
but make sure to understand the security concerns involved.

After the container has been created (for example by molecule converge),
a shell to inspect the container can be obtained with:

docker exec -it cdp-arch-ansible env TERM=xterm bash

Problems with ulimits and makepkg

AUR packages are installed via
makepkg which uses
fakeroot to allow to
build packages as a normal user with root permissions. makepkg
itself cannot run under root and that is why we need a non-privileged user
(which we call ansible) inside Docker container to be able to install
AUR packages inside that container. In case of Docker container
controlled by Molecule (via Molecule Docker driver) we need to add the
following section to ./molecule/default/molecule.yml:

provisioner:
  name: ansible
  inventory:
    host_vars:
      # setting for the platform instance named 'cdp-arch-ansible'
      # see "Problems with ulimits and makepkg" section below 
      cdp-arch-ansible:
        ansible_user: ansible

Moreover, fakeroot is known to be extremely slow when nofile
ulimit is set to a
high value (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920913).
This results in AUR package installation taking too long (sometimes -
hours).

Ulimits for Docker containers can be set in one the following ways:

system-wide (see https://wiki.archlinux.org/title/Limits.conf)
just for Docker service (see
https://bbs.archlinux.org/viewtopic.php?id=283460) by adding something
like
```
[Service]
LimitNOFILE=1048576
```
to
```
/usr/lib/systemd/system/docker.service.d/override.conf
```
on ArchLinux

by specifying --ulimit option for docker build and docker run:

docker run --rm --ulimit nofile=65536:65536 rabbitmq:3.6.6-management

in Molecule with Docker driver we can configure Molecule
to pass specific value of nofile ulimit to Docker using the follwing
syntax:

platforms:
  - name: cdp-arch-ansible
    ...
    ulimits:
      - nofile:65535:65535

Consequently, if we want Molecule
to test an Ansbile role or a playbook that installs AUR packages we need
all of the following:

Pre-built Docker image with non-privileded user inside that container
Molecule contigured to
- use that non-privileged Ansible (instead of using root)
- use lower values of nofiles ulimit.

Devs: building the image from GitHub

Clone the repo first with:

git clone git@github.com:CarloDePieri/docker-archlinux-ansible.git

Building the image from source

A working Docker installation is needed.
Then run:

docker build -t carlodepieri/docker-archlinux-ansible .

or, for convenience:

make

This will build the image. The command docker images can then be used to verify a
successful build.

Creating a new container

Run:

docker run --name=cdp-arch-ansible --detach --privileged --volume=`pwd`:/etc/ansible/roles/role_under_test:ro carlodepieri/docker-archlinux-ansible

or, for convenience:

make run-container

This should start the container, which can should be then visible in docker ps.
It will also bind the current working directory inside the container, which can
be handy to quickly test a playbook (like the included test.yml).

Support for manual cgroup binding

If manual cgroup volume mounting is needed and the docker-archlinux-systemd
image has been built as explained here,
this image must be build as described above but then, for running the
container, launch:

docker run --name=cdp-arch-ansible --detach --privileged --volume=/sys/fs/cgroup:/sys/fs/cgroup:ro --volume=`pwd`:/etc/ansible/roles/role_under_test:ro carlodepieri/docker-archlinux-ansible

or, for convenience:

make run-container-volume

Testing the container

Run:

docker exec -i cdp-arch-ansible env TERM=xterm ansible-playbook /etc/ansible/roles/role_under_test/test.yml --syntax-check

or, for convenience:

make test

Connecting to the container

Run:

docker exec -it cdp-arch-ansible env TERM=xterm bash

or, for convenience:

make shell

Testing the CI loop

Act can be used to execute locally the GitHub
Actions loop. Keep in mind that this will use Act’s
full image,
which is really heavy (>18GB).

To execute a ‘push on a testing branch’ event (which also triggers when pulling
into master), run:

make act-dev

To execute a ‘push on master’ event (which triggers also on scheduled cronjobs),
with the relative DockerHub deploy:

make act-prod

To access the act containers:

make act-dev-shell
# or
make act-prod-shell-ci
# or
make act-prod-shell-deploy

To quickly delete them the act containers:

make act-dev-clean
# or
make act-prod-clean

Do note that the included CI loop will clear the containers used but NOT the
image (to save from repetitive builds). This can be forced by running:

make clean-image