A collection of curated dockefiles used to develop great software at the IT'IS Foundation

During our development workflow we use a great variety of thirdparty software tools (e.g. compilers, debuggers, package managers, ...) or services (e.g. CI services, artifacts repositories, monitoring services, ...) . Each of these have a very specific setup and version which is tuned to our needs at that point in time. Encapsulating all these tools in containers allows us to snapshot the tool/service and using it anytime without having to deal with tedious installation following some wiki step-by-step instructions.

This repo keeps a curated list of dockerfiles that are continuously deployed into our public itis-dockerhub repo.

$ docker run -it itisfoundation/pip-kit --help

$ make help
all – Builds all images
build – Builds all images
clean – Cleans all unversioned files in project
help – Display all callable targets

Here some of the guidelines we have collected so far:

1. Every container MUST be defined on its own folder and in a Dockerfile

   1. Dockerfiles SHALL be written following best practices

2. Every image MUST include some of the labels defined in label-schema.org

3. One of the image names MUST be formatted as itisfoundation/${folder-name}:${tag}

4. Every image MUST build from make build (see docker-compose)

5. Containers SHALL not address many applications at once

   1. One application per container is the prefered setup. E.g. the cookiecutter containers runs the application with the same name

   2. If this is not the case, they SHALL be refered as toolkits. For instance, pip-kit is a container with several python package management tools that can run with many applications, namely pip-sync, pip-compile, pipdeptree and pipreqs

6. Containers with mounted volumes MUST run using the same uid:gid as the mounted volume.

7. Configuration information SHALL be passed into the container as environment variables prefixed with the name of the container.

8. The "payload" of the container SHALL be run with 'exec' at the end of the entrypoint.sh script to make sure signals get passed properly.

9. If the "payload" has no explicit internal signal handling add tini as an init replacement (same effect as when running the docker with --init) https://github.com/krallin/tini