Currently, Octopus deploys NuGet packages to destination machines, and handles all the orchestration around the deployment.
From an application packaging point of view, a NuGet package is similar to a Docker container image:
- To build a NuGet package, we take your code, compile it, and bundle the results into a package, and give it a version stamp.
- To build a Docker image, we take a Dockerfile, and run
docker build
, and it creates an image with a version stamp
From a deployment orchestation point of view, the two are also very similar:
- We want to build a NuGet package once, then deploy it many times (test, staging, prod, across many machines). The NuGet package contains everything we need to run the app (except the OS/runtimes) so we can have confidence that what we test is what we put in prod. After testing in test, we wouldn't want to recompile our code from scratch to deploy to prod.
- We want to build a Docker image once, then deploy it many times (test, staging, prod, across many hosts). The image contains everything to run the package, including the OS, so we are guaranteed that what we tested is what is going to prod. After testing in test, we wouldn't want to build a new image to deploy to prod.
So Docker support in Octopus would mean:
- In addition to "Deploy a NuGet package" steps, we have "Deploy a Docker image" steps
- In addition to NuGet feeds that provide packages, we have Docker registries
- When you create a release, as well as choosing the version of NuGet packages, you can choose the version of Docker images
- As you promote the release through test/staging/prod, as well as using the same NuGet packages, you'll use the same Docker images
- Docker hosts become machines that you manage in the Octopus environments tab
Some things we need to figure out:
- Image distribution. Do we expect all docker hosts to pull images directly from the registry, or will Octopus pull images and transfer them directly to the hosts?
- Configuration. Can we assume all configuration is built into the image or provided externally (when docker run is called) or will we need to modify images slightly?
I like your general approach.
Typically per-environment configuration is omitted from Docker images and instead provided at run-time through one of, or a combination of, environment variables, mapped volumes, and linked containers. I think Octopus should enable this approach.
Last time I looked at the Docker Registry protocol it was reasonably straight-forward and it may be sensible for the Octopus server to act as the default registry and let the Docker hosts pull the images that way... especially when images inherit from other images or only the last layers change.
As @serbrech mentioned, Mesos, Kubernetes, etc abstract the Docker host concept and I'm not sure how a Tentacle would fit here. Having the Octopus server act as a registry that a Mesos cluster could pull from would help. Perhaps Octopus could interact with a Mesos cluster or Docker Swarm as just another Deployment Target Type.
Octopus may not support all Docker cluster implementations but given that Mesos supports Windows it would probably be a good candidate.