Back in December, we laid out a roadmap for container orchestration. Then the dust settled from the Docker spinoff. What we now know is that Docker Apps is an inactive project. tldr; It's not a big deal for our customers and they are going to automagically get something better very soon:
Some Context
Docker Apps were important to us for one main reason: It was an upstream open standard. However, as development of Docker Apps progressed, things weren't so great anyway:
- It was, surprisingly, not well integrated with docker-compose
- It was incredibly difficult to integrate with multi-arch containers.
- It didn't really solve the most common thing most people want when distributing docker-compose type things: Inability to bind mount local files into the container (eg custom nginx.conf).
In some ways we were making the best of a bad situation and hoping we could eventually grind things out upstream (i.e. spend months begging for improvements via code reviews and crying ourselves to sleep).
What Now?
The good news is that we were so early on docker app, that we aren't even using it well. We can keep going how we are and nobody is affected. The other good news: Docker is committed to docker-compose.
The bad news is that nobody seems to care about single node container orchestration. If the answer isn't Kubernetes, then nobody is listening ... except for Foundries.io. We care and have opinions. docker-compose is great. Having an immutable way to distribute compose applications is both important and easy to do. Our approach is what we call "Compose Bundles".
Compose Bundles
Quick background: A docker registry (eg hub.foundries.io or hub.docker.io) is a simple content addressable system. You just upload "Blobs" which can be anything and are referenced by their SHA-256 hash.
A Compose Bundle is simply a compressed tarball including:
docker-compose.yml - At "publish" time we take the docker-compose.yml file and pin each service container image to its immutable SHA-256 hash at the time. This makes it reproducible and TUF friendly.
Optional support files - Like an "nginx.conf" file that docker compose might bind mount inside one of its services.
We plan to refine a version of compose-ref to automatically do this for our factory users. We also have a simple change we plan to carry in the LMP for docker-compose to consume these bundles.
Migration to Bundles
Our build scripts will know how to convert existing .dockerap content into this new world. This means you won't have to do anything. For a period of time, your LmP build Targets will include a reference to the Docker App and this new Compose Bundle. This will allow Aktualizr-lite to update/rollback between these two styles.
Aktualizr-lite will need to include package manager support for this new bundle. It will probably carry the unfortunate name of "docker-apps" so that we don't affect existing devices. We've already done this once when preparing for the 1.0 version of Docker App that never was.
Once a fleet is converted (or if you don't have anything to convert), users can ditch the .dockerapp files (once their fleet is ready) and start working directly with docker-compose files like we are all used to.
FAQ
Q: I don’t like this.
A: That’s not a question. We've been surprised how little people have cared about the plumbing of Docker Apps. They just produce the .dockerapp file once and move on. The "download" step during an update is important ... if things are inefficient. However, this will be more efficient than what we were doing with Docker App Bundles.
Q: This doesn't look "upstreamable".
A: That's not a question. It might not be. However, we've intentionally made these changes to be as small as possible so that they might. The world does need something like this. If it doesn't go upstream? That's fine - it's not much code.
Q: What about k3s??
A: We aren't encountering embedded product makers that need this. Plus, it has its own baggage. It's orthogonal to this "publishing" problem we are trying to address here.
Q: Why do you hate Kubernetes?
A: We don't. We gambled our entire company's backend infrastructure on GKE 2.5 years ago. I love it for that. Not for this.