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?
It's clear how it aligns with nuget. and that shows how easily it will be to use octopus and do business as usual, or as before, with nuget.
However, I am a bit skeptical in the need for something like octopus, when you enter the Container world.
When we deploy nuget packages, we need to unzip, we need to put it in a folder, and archive them, etc...
But all this is gone with containers, because the container host manages this. when talking about clusters, mesos, or swarm manages what runs where. tagging of hosts, the roles and the hosts affinities, are also things cluster management software handles (swarm or mesos).
How is Octopus going to integrate with this? I think that this is important to figure out.
I don't think it is enough to map container <--> nuget. If it stops there, then the user is missing out on some of the real value of containers.