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 ?
Besides, do the two terms disposable-container and immutable-container mean the same ?
[1] https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/
[2] https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/
Besides, are the two terms disposable-container and immutable-container mean the same ?
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.
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.
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.
why are they considered so ephemeral?
A container is a process. A process is ephemeral. Containers are ephemeral. Containers are able to persist data separately though.
how can one run a containerized application in production
If your hangup with using containers in production can be rephrased "how can you run a containerized application in production with no state?", then I'd first say not all applications are stateful. A basic web server, or a great many well-designed micro services, for example.
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.