Docker Compose on K8s
Docker Compose is currently used by millions of developers and with over 650,000 Compose files on GitHub, Compose has been widely embraced by developers because it is a simple cloud and platform-agnostic way of defining multi-container based applications.
Problem statement
Today docker-compose is used on local development environments and in integration tests on physical Jenkins nodes. Moving almost everything to Kubernetes means that either we must make docker-compose work without hassle on the Kubernetes platform or agree upon another preferred way of working.
Important to take into consideration are:
-
Testability: Support for Ephemeral deploys.
-
Simplicity: Hide complex and technical implementation details for developers behind a simple to use api with a lot of sensible default values.
- Because developers should focus on business logic and not build and deploy scaffolding.
- Because with an api as an abstraction layer on top we can be flexible and replace underlying implementations like Jenkins, docker-compose and kubernetes without developers having to make a change.
-
Reproducibility: Make different environments as similar as possible to each other.
-
Delivery speed: Provide a smooth and quick process from code commit to production.
The idea to make all environments, including local dev environments, as similar as possible is very appealing. The reason for making all environments as similar as possible is to minimize bugs and minimize time spent in trouble shooting due to differences in environments.
Production, staging, QA environments all run on the Kubernetes platform, therefore, in order to be similar, local dev environment should also run on kubernetes.
This can be achieved by:
-
Running Kubernetes on docker-desktop or mini-kube or similar.
-
Extending local-dev environment to be developer laptop + Kubernetes namespace in “the cloud”.
Sadly, this approach will almost certainly be:
-
Heavy on resources, all developer laptops are not beasts.
-
Complex for the average developer, all developers should not have to know or care about kubernetes.
For numerous developers we should provide a solution where their dev environments are:
-
Lightweight
-
Simple to use (hide unwanted complexity)
Requirements (on the development environment)
First, let’s define the average developer as:
A fairly new frontend-developer who is great at javascript and React and has little knowledge or interest in backend-code, Kubernetes and deploy-pipelines.
The average developer should:
-
Be able to work offline
-
Not need deep knowledge in Kubernetes.
-
Be able to spin up (mock) auxiliary services like backend api/service and databases.
-
Not need a very powerful pc.
Options
-
Let the developers do what ever they want on their machines but do not try to reuse it. Accept that developer setup is very different from other environments.
-
Try to reuse docker-compose files created by developers to also run integration-tests in deploy and build pipelines.
-
Try to reuse docker-compose files created by developers to also run integration-tests in deploy and build pipelines and to deploy to different (ephemeral) environments.
-
Deprecate the use of docker-compose files for developers and introduce another lightweight format which under the hood can work well in offline mode on a developer machine and be the base for a production deploy.
-
Run Kubernetes locally on docker-desktop or mini-kube or similar.
-
Extend local-dev environment to be developer laptop + Kubernetes namespace in “the cloud”. More about this approach here:
Current state of Docker Compose in K8s
It’s possible to use different tools to convert docker-compose files to kube-configs.
How to convert and use your docker-compose files in K8s
| Project | Description | Note |
|---|---|---|
| Kompose | Translates docker-compose to kubectl configs | - |
| Blimp | Docker Compose, (and your dev environment) in the K8s cloud | - |
| Compose on Kubernetes | Deploy Docker Compose files onto a Kubernetes cluster | no progress this year (2020) |
| Docker App and CNAB | Build Cloud Native Application Bundles (CNAB) from docker-compose | - |
| Podman Compose | An implementation of docker-compose with Podman backend | - |
Kompose
Simplify your development process with Docker Compose and then deploy
your containers to a production cluster Convert your docker-compose.yaml
with one simple command kompose convert.
kompose is a convenience tool to go from local Docker development to managing your application with Kubernetes. Transformation of the Docker Compose format to Kubernetes resources manifest may not be exact, but it helps tremendously when first deploying an application on Kubernetes.
Blimp
Blimp is a drop-in replacement for Docker Compose that enables
development in the cloud. Laptop struggling to keep up? It’s time to
blimp up and get your Docker containers in the cloud.
Blimp is for developers working with containers that use Docker Compose to run their dependencies locally, even if they’re using Kubernetes in production. Blimp runs on Kubernetes in the backend; however, the interface it exposes to developers looks and feels like Docker Compose. As a result, it may be easier to start using for Developers that aren’t familiar with Kubernetes.
Blimp runs entirely in your own Kubernetes cluster. No requests are made to external Blimp servers.
Your containers are isolated in their own Kubernetes namespace.
Which one is the best?
- Recommendation is Kompose, but it is not the “silver bullet”.
Compose on Kubernetes
Compose on Kubernetes allows you to deploy Docker Compose files onto a Kubernetes cluster. https://github.com/docker/compose-on-kubernetes no progress this year (2020)
Docker App & CNAB
Build CNAP bundles from docker-compose.
https://www.docker.com/blog/docker-app-and-cnab/
Docker App
https://www.docker.com/products/docker-app Docker App is a way to define, package, execute, and manage distributed applications and coupled services as a single, immutable object.
CNAB
Cloud Native Application Bundles (CNAB) are a package format specification that describes a technology for bundling, installing, and managing distributed applications, that are by design, cloud agnostic. https://cnab.io/ https://github.com/cnabio/cnab-spec
The future of Docker Compose
docker-compose is no longer only a stand-alone tool, it has moved
inside docker. Instead of writing
docker-compose you write `docker compose.
By using docker context to switch context, it’s possible to use the
same docker compose up on Azure cloud or to create Amazon ec2
instances.
Docker has created a new open community to develop the Compose-Specification.
The intention is that the Compose-Specification/API can be used with
different backend technologies to describe (parts of) multiple
environments, switched between by using docker context.
docker compose contains things that developers care about. It does not
aim to be the whole description of production, just the developer-facing
pieces.
This is not ready for us to use, but it will be interesting to follow and see what happens here.