(WORK IN PROGRESS)
A ruby DSL to build your own docker images. Images are built based on instructions
contained in your project’s
Why not Dockerfile?
Dockerfiles are great to start out with, but:
- 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.
- They are less hackable, because
docker builddoesn’t support plugins to expand its capabilities.
- 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.
- 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.
Drydock supports plugins, either provided through ruby gems or ruby files included in your project being built by Drydock.
Drydockfiles are written in ruby.
gem install drydock, or (b) add “drydock” to your project’s Gemfile,
In your project’s root directory, you’ll want to create a
drydock functions. When you’re ready, build an image using:
Alternatively, point drydock to a directory containing the
Drydockfile, or to any
file to treat it as the
$ drydock ~/source/miniproject # project directory expects a file named Drydockfile
$ drydock ~/source/miniproject/drydock-definition.rb # expects a drydock-definition.rb
Drydockfiles may be seen in
This is needed if you plan on hacking drydock:
$ git clone email@example.com:ripta/drydock.git
- Customizable caching subsystem.
- Derived docker images from a previous build step.
- Composable docker images.
- Customizable caching rules.