<p>I am migrating an application from running in Docker (using <code>docker-compose up</code>) to Kubernetes.  We are still using <code>docker-compose.yml</code> for building the images.</p>
<p>I'm aware several of the config settings for the services are for build, and some are for runtime (<code>docker-compose up</code>). So, I'd like to remove those settings that won't be used in the Kubernetes environment.</p>
<p>I <em>think</em> 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 <code>environment</code> just says &quot;Add environment variables&quot;.</p>
<p>This is my list of runtime (<code>docker-compose up</code>) settings that I think would be safe to remove if I'm just building with docker-compose.</p>
<p>Validation of this list would be helpful, or a pointer to some documentation somewhere.</p>
<ul>
<li><code>container_name</code></li>
<li><code>restart</code></li>
<li><code>init</code></li>
<li><code>depends_on</code></li>
<li><code>environment</code></li>
<li><code>ports</code></li>
<li><code>expose</code>  (can put in Dockerfile?)</li>
<li><code>command</code></li>
<li><code>environment</code></li>
<li><code>volumes</code></li>
</ul>
<p>So, actually, all I would need is <code>image</code> and <code>build</code> for each service? Would that be right? Thanks.</p>

Steve Folly
<p><em>All</em> of those settings are run-time settings.  The only build-time settings are the things in the <code>build:</code> block and the <code>image:</code> name.</p>
<p>That having been said, a couple of these things can be specified in the Dockerfile.  The Dockerfile <code>EXPOSE</code>, <code>CMD</code>, and <code>ENV</code> directives provide defaults for the corresponding Compose settings.  If you have a useful default command, or an environment-variable setting that will <em>always</em> be the same no matter where you run the container (for example, path-related variables), set them in the Dockerfile.</p>
<p><code>expose:</code> 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 <code>container_name:</code>.  Most Compose applications do not need more than the <code>default</code> network and you can usually delete all of the <code>networks:</code> blocks in the <code>docker-compose.yml</code> file; Kubernetes does not support multiple segregated networks in any case.</p>
<p><code>restart:</code>, <code>environment:</code>, and <code>command:</code> have Kubernetes equivalents; see the <a href="https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/" rel="nofollow noreferrer">Pod</a> API reference.  Unlike Compose containers, Pods default to <code>restartPolicy: Always</code>.  Note that Kubernetes <code>command:</code> overrides the image's <code>ENTRYPOINT</code> and Kubernetes <code>args:</code> the <code>CMD</code>; the terminology is slightly different from Docker.  You can reasonably need <code>environment:</code> settings to point at things like database hostnames that will be different in Kubernetes.</p>
<p><code>depends_on:</code> 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 <a href="https://stackoverflow.com/questions/31746182/docker-compose-wait-for-container-x-before-starting-y">Docker Compose wait for container X before starting Y</a> you will need to manually ensure the dependency is available in Kubernetes, or tolerate it being unavailable.</p>
<p><code>init:</code> does not exist in Kubernetes either.  If you need an init process to be process 1 in your container, install something like <a href="https://github.com/krallin/tini" rel="nofollow noreferrer">tini</a> in your image.</p>
<p><code>volumes:</code> is the most complicated one here.  I've seen several uses for this:</p>
<ul>
<li>If <code>volumes:</code> injects a configuration file from the host system, put it in a <a href="https://kubernetes.io/docs/concepts/configuration/configmap/" rel="nofollow noreferrer">ConfigMap</a> and mount that in your Deployment spec.</li>
<li>If <code>volumes:</code> 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.</li>
<li>If <code>volumes:</code> hold persistent data like database data, run your container as a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a>; each replica will get its own PersistentVolumeClaim with cluster-managed storage.</li>
<li>If <code>volumes:</code> inject your application code or libraries, delete them; the code should be packaged in the image.</li>
</ul>
<p>There are tools like <a href="https://kompose.io/" rel="nofollow noreferrer">Kompose</a> that can attempt to convert a <code>docker-compose.yml</code> 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.</p>
