FPM and Docker¶
Because fpm depends on so many underlying system tools, docker can alleviate the need to install them locally.
An end user may use a docker container in lieu of installing locally. And a developer can use docker to run the test suite.
Running FPM inside docker¶
First, build a container will all the dependencies:
Now, run it as you would the fpm command. Note that you will have to mount your source directly into the docker volume:
docker run -v $(pwd):/src fpm --help
As a full example:
mkdir /tmp/fpm-test mkdir /tmp/fpm-test/files touch /tmp/fpm-test/files/one touch /tmp/fpm-test/files/two docker run -v /tmp/fpm-test/files:/src -v /tmp/fpm-test:/out fpm -s dir -t tar -n example -p /out/out.tar . tar tf /tmp/fpm-test/out.tar
Depending on your needs, you will have to adjust the volume mounts and relative paths to fit your particular situation.
Running rpsec inside docker¶
The Makefile provides some targets for testing. They will build a docker container with the dependencies, and then invoked rspec inside it. The makefile uses a sentinel file to indicate that the docker image has been build, and can be reused.
How does this work¶
The Dockerfile makes heavy use of multistage builds. This allows the various output containers to build on the same earlier stages.
There are two
base images. A
minimal image, which contains
compiled dependencies and ruby. And an
everything image which brings
in scripting systems like
perl. These are split to
allow a smaller
minimal image in cases where building scripting
language packages are not needed.
The Dockerfile the argument
BASE_ENV to specify what base image to
use. This can be set to either
unspecified, it defaults to
We want to use the same set of base images for both the
testing, as well as the run time containerization. We do this by using
TARGET argument to select which container to build.
The makefile encodes this logic with two pattern rules.