I am migrating an application from running in Docker (using docker-compose up) to Kubernetes. We are still using docker-compose.yml for building the images.

I'm aware several of the config settings for the services are for build, and some are for runtime (docker-compose up). So, I'd like to remove those settings that won't be used in the Kubernetes environment.

I think I'm finding the right ones to remove, but I couldn't seem to find a definitive list, or whether each setting is for build or runtime (e.g. the docker-compose documentation for environment just says "Add environment variables".

This is my list of runtime (docker-compose up) settings that I think would be safe to remove if I'm just building with docker-compose.

Validation of this list would be helpful, or a pointer to some documentation somewhere.

• container_name
• restart
• init
• depends_on
• environment
• ports
• expose (can put in Dockerfile?)
• command
• environment
• volumes

So, actually, all I would need is image and build for each service? Would that be right? Thanks.

CodePudding user response：

All of those settings are run-time settings. The only build-time settings are the things in the build: block and the image: name.

That having been said, a couple of these things can be specified in the Dockerfile. The Dockerfile EXPOSE, CMD, and ENV directives provide defaults for the corresponding Compose settings. If you have a useful default command, or an environment-variable setting that will always be the same no matter where you run the container (for example, path-related variables), set them in the Dockerfile.

expose: in a Compose file does pretty much nothing at all and it's always safe to remove it. You should not usually need to override container_name:. Most Compose applications do not need more than the default network and you can usually delete all of the networks: blocks in the docker-compose.yml file; Kubernetes does not support multiple segregated networks in any case.

restart:, environment:, and command: have Kubernetes equivalents; see the Pod API reference. Unlike Compose containers, Pods default to restartPolicy: Always. Note that Kubernetes command: overrides the image's ENTRYPOINT and Kubernetes args: the CMD; the terminology is slightly different from Docker. You can reasonably need environment: settings to point at things like database hostnames that will be different in Kubernetes.

depends_on: does not exist in any form in Kubernetes. In Compose its most important effect is to ensure that some other host name exists; in Kubernetes you get this effect by creating a related Service. In much the same way as Docker Compose wait for container X before starting Y you will need to manually ensure the dependency is available in Kubernetes, or tolerate it being unavailable.

init: does not exist in Kubernetes either. If you need an init process to be process 1 in your container, install something like tini in your image.

volumes: is the most complicated one here. I've seen several uses for this:

• If volumes: injects a configuration file from the host system, put it in a ConfigMap and mount that in your Deployment spec.
• If volumes: hold log files, consider reconfiguring your application to log to stdout instead. If you can't do this, you'll need to work with a DevOps engineer to figure out how to extract logs from your containers.
• If volumes: hold persistent data like database data, run your container as a StatefulSet; each replica will get its own PersistentVolumeClaim with cluster-managed storage.
• If volumes: inject your application code or libraries, delete them; the code should be packaged in the image.

There are tools like Kompose that can attempt to convert a docker-compose.yml file into Kubernetes manifests, but there are a lot of corner cases (like ConfigMaps for example) and I'd suggest using these as a starting point rather than assuming it will convert successfully.