Configuration

The dockership configuration is based on an INI-formatted config file.

Dockership will look at /etc/dockership/dockership.conf for this config file by default. The -config flag may be passed to the dockershipd or dockership binaries to use a custom config file location.

Syntax

The config file syntax is based on git-config, with minor changes.

The file consists of sections and variables. A section begins with the name of the section in square brackets and continues until the next section begins. Section names are not case sensitive. Only alphanumeric characters, - and . are allowed in section names. Each variable must belong to some section, which means that there must be a section header before the first setting of a variable.

Sections can be further divided into subsections. To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in the example below:

; Comment line
[section "subsection"]
name = value # Another comment
flag # implicit value for bool is true

Sections

Global

A miscellaneous of configuration variables used across the whole tool.

HTTP

Configuration of the web server from dockershipd. This section is only required by dockershipd

Since the authentication is based on a registered Github Application, you should create it at Github. The Authorization callback URL must be filled with http://<server-addr>/oauth2callback, this URL should be accessible by anyone.

Environment

An environment is a logical group of any number of Docker servers. Dockership supports multiple environments. Each Environment is defined as a section with subsection: [Environment "production"]

Project

Project section defines the configuration for every project to be deployed in the environments. The relation between repositories is one-to-one, so the repository should contain the Dockerfile and all the files needed to build the Docker image. The Project as Environment is defined as a section with subsection: [Project "disruptive-app"]

Example

Scenario

rest-service project

REST webservice in Python running under a uwsgi+nginx on port 8080

This repository requires the python package domain, so we want to detect if the rest-service has pending changes to be deployed when the domain has new commits, even when the rest-service repository does not have new commits.

frontend project

An AngularJS frontend running on a nginx server, with a reverse_proxy pointing to the port 8080 at rest-service container, in the path /rest.

We want to expose the port 80 at the host server.

Config file

[Global]
GithubToken = example-token

[Project "rest-service"]
Repository = git@github.com:company/rest-service.git
Environment = live
Environment = dev
File = /tmp/container.py
RelatedRepository = git@github.com:company/domain.git

[Project "frontend"]
Repository = git@github.com:company/angular-client.git
Environment = live
Environment = dev
Port = 0.0.0.0:80:80/tcp
Link = rest-service:backend

[Environment "live"]
DockerEndPoint = http://live-1.example.com
DockerEndPoint = http://live-2.example.com

[Environment "dev"]
DockerEndPoint = http://dev.example.com