DryDock has multiple functions, the end goal of which is to setup and configure a cluster of Docker containers.


The master command will prepare and provide the command for a new Docker container under the given name based upon nekroze/drydock . This container is setup and ready to use DryDock to run a cluster of Docker containers in a Docker container (dind). This is designed to easily contain a DryDock cluster but is not required.

By default the master container will take over the host ports; 80, 443, for; HTTP, and HTTPS. This can be customized by providing the root specification a http_port and https_port respectively. If the specification describes any exposed ports for sub-containers the external ports for those will also be exposed through the master container.

Once a master container has been prepared DryDock will provide the user with the command required to run that specific cluster. It may be worth adding the docker --rm=true switch to the provided command. using this in an upstart script for example would mean that each boot or restart of the master container will be fresh from the original image that was created. If you wish to run it in the background immediately then the -d do that for you.


Setting up a DryDock master container is entirely optional.


The resulting master container runs in --privileged mode and retains all security concerns of such a Docker container.


This command will setup a few Docker containers, generate an ssl certificate, and must be run before running construct on a specification.

The following containers will be setup and run:

  1. skydns: Small dns server.
  2. skydock: Docker skydns registry.
  3. nginx: An nginx powered reverse proxy container.

The nginx container will have a volume mapped to the hosts /etc/nginx/sites-enabled directory for the matching nginx directory.


The main function for DryDock, construct, takes a YAML specification file and will create the required configuration files (supervisor, and nginx) before running and naming containers as defined in the specification.

Here is an example of a DryDock specification file that will construct with wordpress and gitlab available at and Finally the config describes a special root container that serves the root of the domain, in this case gets passed to the root sub-container running drupal.



  - name: blog
    base: skxskx/wordpress
        2222: 22
    http_port: 80
    volumes: [/var/lib/mysql]

  - name: lab
    base: crashsystems/gitlab-docker
        22: 22
    http_port: 80

  - name: root
    base: moul/drupal
        2221: 22
    http_port: 80

The YAML specification file consists of two main parts; cluster information, and container specification. Together these define a DryDock Specification which gets constructed into running Docker containers and accompanying configuration files!

All peristant data should be stored in /var/lib/{domain}/ where domain is the specifications domain


This command assumes that both Docker and supervisor are currently installed on the system.


This command is used almost identically to the construct and deconstruct command and will download all of the base images in the given specification. This can be useful for caching and or testing.


This is a supervisor for a DryDock container cluster and can be used to ensure sub-container uptime. The supervise command can be run without running prepare or even construct as it will maintain and construct containers as needed.


When using a master container, its default entrypoint command will be to supervise the given specification.


The deconstruct command is used the same way as the construct command, however it will remove any thing created by the corresponding construct command.