drydock

WORK IN PROGRESS — ALPHA-RELEASE SOFTWARE SOME FEATURES REQUIRE DOCKER 1.8.0 OR NEWER

Automated Build Status

A ruby DSL to build your own docker images. Images are built based on instructions contained in your project's Drydockfile.

Why not Dockerfile?

Dockerfiles are great to start out with, but:

  1. They are static, which isn't necessarily a bad thing. I'm not opposed to a declarative approach to building images, but sometimes it may be limiting.
  2. They are less hackable, because docker build doesn't support plugins to expand its capabilities.
  3. More complicated build pipelines are hard to implement, or perhaps even impossible. For instance, being able to build multiple images, then combine them at the end, would be a nice option. Imagine building your ruby gem dependencies and node.js dependencies separately, before combining both images into your application's final image.
  4. Caching rules are fairly limiting. For instance, when your Gemfile changes, it would be nice to import a configurably-older image, import the new Gemfile, and re-run the build. On the other hand, it would be important to be able to limit the age of the cache.

Why Drydock?

Drydock interfaces directly with the Docker Remote API via the docker-api gem. It's not for every use case, but it provides great control over what and how an image is built.

Drydock supports plugins, either provided through ruby gems or ruby files included in your project being built by Drydock.

Drydockfiles are written in ruby.

Production Installation

Either (a) gem install dry-dock, or (b) add "dry-dock" to your project's Gemfile, and run bundle. Sorry, but the gem name drydock was already taken by a defunct gem, and I'm too lazy to contact them; the binary and name of the project, however, are both drydock.

In your project's root directory, you'll want to create a Drydockfile containing drydock functions. When you're ready, build an image using:

$ drydock

Alternatively, point drydock to a directory containing the Drydockfile, or to any file to treat it as the Drydockfile, e.g.:

$ drydock ~/source/miniproject # project directory expects a file named Drydockfile
$ drydock ~/source/miniproject/drydock-definition.rb # expects a drydock-definition.rb

Example Drydockfiles may be seen in examples/.

Development Installation

This is needed if you plan on hacking drydock:

$ git clone [email protected]:ripta/drydock.git
$ bundle

Drydockfile Syntax

As previously mentioned, Drydockfiles are ruby. The contents of Drydockfile are evaluated in the context of an instance of Drydock::Project; you can refer to the documentation for it for more in-depth information.

Because Drydockfiles are ruby, most constructs should work as-is: you can declare constants and refer to them later; call Kernel#abort to exit the program and stop the build; and write plugins to be called from within the Drydockfile.

It would help if you understand ruby and Dockerfiles before jumping in.

All instructions are evaluated in the order that they are seen; syntax errors or any logical errors might not be caught until execution arrives at that point.

For a complete and updated list of Drydockfile instructions, see the public API methods of the Drydock::Project class or head to the automatically-generated ruby docs.

Roadmap

  1. Customizable caching subsystem.
  2. Customizable caching rules.