dockerfiles

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

Why?

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.

Usage

Running tools

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

Developing

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

Guidelines

Here some of the guidelines we have collected so far:

Every container MUST be defined on its own folder and in a Dockerfile
1. Dockerfiles SHALL be written following best practices
Every image MUST include some of the labels defined in label-schema.org
One of the image names MUST be formatted as itisfoundation/${folder-name}:${tag}
Every image MUST build from make build (see docker-compose)
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
Containers SHALL run with a non-root user (see trick with entrypoint.sh)
All containers with mounted volumes MUST run using the same uid as the host.
... (add here your suggestion)

oetiker / dockerfiles