carlodepieri/docker-archlinux-ansible repository overview

⁠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⁠.

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
  

  Copy
  to

  /usr/lib/systemd/system/docker.service.d/override.conf
  

  Copy
  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 [email protected]: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