cachedout/barnacle

Dockerfiles to easily create environments for developing and testing SaltStack on various platforms.

barnacle

Docker files for SaltStack

Note: It is strongly recommended that the default storage engine for Docker not be set to use the loopback/devicemapper. This will result in very slow builds and poor performance. Choose overlay or overlay2 if possible.

TL;DR (Lazy version)

For the impatient, images are available on Docker Hub.

To pull images: docker pull cachedout/barnacle

To use them, replace the name of the containers in the examples below with the path to the image tag. For example, replace instances of salt-arch with cachedout/barnacle:arch.

Installation

The following steps will walk you through building and running a Docker image for Arch Linux.

To build and test another OS, simply change the OS identifier where appropriate.

If you are running Docker for Mac, the sudos below are not necessary.

NOTE: This guide assumes that one's local salt development directory is in ~/devel/salt. If this is not the case, adjust the paths below accordingly.

To build an image, change to an image directory and type: sudo docker build -t salt-arch ..

This will download a base image and apply the necessary layers to ensure it has all the layer necessary to develop Salt with, including all of the development deps.

After the container is built, you can shell into it and have a look around:

sudo /usr/bin/docker run --rm -itv ~/devel/salt/:/testing salt-arch /bin/bash

Your local Salt development directory will be mounted into /testing. Any change you make locally will be immediatley reflected there and vice-versa.

You can of course run the tests if you like: python2 /testing/tests/runtests.py

Running the tests and then exiting

There is no need to create a shell just to run a test. You can do this with one command:

sudo /usr/bin/docker run --rm -itv ~/devel/salt:/testing salt-arch python2 /testing/tests/runtests.py

Again, this will operate on your local checkout of the Salt repo so you can quickly make changes and then immediatley see how they will work on any given platform.

Run a container using systemd

NOTE: currently only supported for the following images: cent7, fedora26, fedora27, ubuntu16, debian9

To start a container using systemd you need three things:

1. /{run,tmp} mounted as tmpfs
2. The container needs read-only access to your cgroups
3. You need to specify the path to the systemd binary as the command or entrypoint for the container.

For example:

docker run --detach --name container_name --tmpfs /tmp --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v ~/devel/salt:/testing cent7 /usr/lib/systemd/systemd

This will launch the container running systemd and detach from it.

To get a shell, evoke it with a tty in interactive mode.

docker exec -it container_name /bin/bash

Fortunately, both starting a container under systemd and evoking an interactive shell are supported via the .zsh aliases described in the section below.

Using .zsh aliases

This repo includes a docker_salt.zsh file. It makes running things even easier. Importing it into your shell is an exercise for the reader. ;] It understands if you are running Docker for Mac and does not sudo for the docker commands.

To run a single test:

cts arch integration.modules.beacons <-- Runs the beacons tests in an Arch container

cshell arch <-- Gives you a shell in an Arch container

cexec arch <-- Gives you a shell in an already running Arch container (use after cshell)

cbuild -a <-- Builds all OSs in the repo

cbuild -o <OS> <-- Builds a specific OS in the repo

csalt ubuntu14 state.sls test <-- Run a salt command

csalt-call ubuntu14 state.sls test <-- Run a salt-call command

cstart-systemd container_name cent7 <-- Start container_name under systemd using image salt-cent7

cssh container_name <-- SSH into container_name

cdshel <-- evoke an interactive shell in a detached container (defaults to bash)

Using Barnacle Python Module

Installing and Setup Barnacle Python Module

git clone https://github.com/cachedout/barnacle.git
cd barnacle
pip install -e .

Add configurations to file: /etc/barnacle.conf

salt_dir: /home/ch3ll/git/salt/
barnacle_dir: /home/ch3ll/git/barnacle/

salt_dir is the location to your locally cloned git repo of salt. The barnacle python module will use this directory to run salt from within the container

barnacle_dir is the location where you cloned the barnacle directory. The barnacle python module will use this directory when building docker images. It searches this directory for any dockerfiles and builds from those files.

Barnacle Commands

barnacle-build

Builds dockerimages from dockerfiles. Will create images with the name salt + the os.

barnacle-build -o <os> <-- builds a specific os barnacle-build -a <-- builds all OSs in the specified barnacle directory

barnacle-shell

Starts and shells into a container

barnacle-shell -o <os> <-- starts and shells into specific os container

barnacle-test

Starts a container and runs a test using salt's test runner.

barnacle-test -o <os> -t <salt-test> <-- starts a specific os container and runs specified salt test.

NOTE: when using <os> in any of these barnacle commands, you need to use the name of the directory where the Dockerfile exists. For example if you want to build centos7 you would use cent7 because that is the name of the directory in barnacle for that os.

barnacle's Issues

psutil install fails on debian8 build

When running a docker build -t salt-debian8 . command, the build exits because psutil can't be installed:

  Running setup.py install for psutil: started
    Running setup.py install for psutil: finished with status 'error'
    Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-xEsNOj/psutil/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-B2tkIC-record/install-record.txt --single-version-externally-managed --compile:
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/psutil
    copying psutil/_pslinux.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_pssunos.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_psbsd.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_common.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/__init__.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_pswindows.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_psosx.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_psposix.py -> build/lib.linux-x86_64-2.7/psutil
    copying psutil/_compat.py -> build/lib.linux-x86_64-2.7/psutil
    creating build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_linux.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_process.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/__init__.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_bsd.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_misc.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_system.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_windows.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/runner.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_posix.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_sunos.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_osx.py -> build/lib.linux-x86_64-2.7/psutil/tests
    copying psutil/tests/test_memory_leaks.py -> build/lib.linux-x86_64-2.7/psutil/tests
    running build_ext
    building 'psutil._psutil_linux' extension
    creating build/temp.linux-x86_64-2.7
    creating build/temp.linux-x86_64-2.7/psutil
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPSUTIL_VERSION=431 -I/usr/include/python2.7 -c psutil/_psutil_linux.c -o build/temp.linux-x86_64-2.7/psutil/_psutil_linux.o
    psutil/_psutil_linux.c:12:20: fatal error: Python.h: No such file or directory
     #include <Python.h>
                        ^
    compilation terminated.
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

    ----------------------------------------
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-xEsNOj/psutil/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-B2tkIC-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-xEsNOj/psutil/
INFO[0009] The command [/bin/sh -c pip install -r /dev_python27.txt] returned a non-zero code: 1

Debian 8 Build is actually Ubuntu 16

As seen in the Dockerfile for the debina8 directory:

barnacle/debian8/Dockerfile

Line 1 in bb26a57

FROM ubuntu:16.04

Add flag to preserve test run

There should be a flag that one can pass to the cts func which both removes the --rm flag from the docker run command and sets --no-clean on the test runner.

Update images published to docker hub

These images are out-of-date:

https://hub.docker.com/r/cachedout/barnacle/tags/

Add nox to requirements.txt

Upstream recommends using nox to run tests:

• https://docs.saltstack.com/en/master/topics/tutorials/writing_tests.html#running-the-test-suite
• https://docs.saltstack.com/en/master/topics/development/tests/index.html#running-the-tests