<p>I read in many books and documentations[1][2] that a docker-container or a pod are considered to be disposable and have a short lifetime. why are they considered so ephemeral?  In such case how can one run a containerized  application in production ?</p>

<p>Besides, do the two terms disposable-container and immutable-container mean the same ?</p>

<p>[1] <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/</a> <br>
[2] <a href="https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/" rel="nofollow noreferrer">https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/</a></p>

<blockquote>
  <p>Besides, are the two terms disposable-container and immutable-container mean the same ?</p>
</blockquote>

<p>Immutable means once it's created, it cannot be changed. Disposable, in the context of your question, means it can be destroyed and replaced with little consequence. </p>

<p>These things are not the same, but they operate together in a typical containerized application. You will be running an immutable container, and when you want to change the behavior of the container you would replace it with a new container instead of trying to change the existing container. </p>

<p>This is different than something like a VM, where you would deploy code updates and reload the service or similar if you wanted to change the behavior of your app.</p>

<blockquote>
  <p>why are they considered so ephemeral?</p>
</blockquote>

<p>A container is a process. A process is ephemeral. Containers are ephemeral.
<a href="https://docs.docker.com/engine/admin/volumes/volumes/" rel="nofollow noreferrer">Containers are able to persist data separately though</a>. </p>

<blockquote>
  <p>how can one run a containerized application in production</p>
</blockquote>

<p>If your hangup with using containers in production can be rephrased "how can you run a containerized application in production <em>with no state</em>?", then I'd first say not all applications are stateful. A basic web server, or a great many well-designed micro services, for example.</p>

<p>For stateful applications, nothing stops you from using a common database to back your containerized applications. You can also use volumes, as described above. You could combine the two and run a containerized database, using volumes underneath the database container. State isn't really a problem.</p>
