0

I'm new to docker and I'm reading a book which says:

Docker can't safely replaced an unhealthy container. Docker could remove that container and start a new one from the same setup, but maybe your app writes data inside the container, so that would mean downtime and a loss of data. Docker can’t be sure that taking action to fix the unhealthy container won’t make the situation worse, so it broadcasts that the container is unhealthy but leaves it running

I'm a little bit confused here, container orchestration tool like Kubernetes can replace unhealthy container with new container, so in this case, there will be a loss of data, because the old container hasn't finished writting, isn't it? obviously the new container can't take over the writing job from the old container, a loss of data issue still happen.

Philip Kendall
  • 24,083
slowjams
  • 127

2 Answers2

1

I don't know what book you are reading but I would guess that the author is saying that docker can't assume that it's safe to remove a running container. That is something you would normally manage in an orchestration system like Kubernetes. You can configure that behavior based on the signal that there as a problem. But the responsibility is on you to determine whether that is OK.

In the case where have control over the behavior of the application running in the container, it's a good idea to design your application to be able to exit cleanly in such a situation. It's not required however and that may not be possible or practical.

JimmyJames
  • 27,287
0

The book is correct but perhaps confusing.

Docker is, among other things, a general-purpose tool for running containers. It makes few assumptions about how the software within the container is going to work. In particular, Docker containers are persistent by default. Docker cannot safely throw away the container's file system with any data that might have been written there and start a new container. While unusual, it is possible to use a Docker container as a persistent virtual machine.

Kubernetes has more flexibility because it imposes clear conventions on how the system works. Pods are stateless unless they are part of a StatefulSet, and even then the state must be written to a persistent volume claim and can't just be left anywhere in the container's file system. This is not necessarily “safe”, but if this approach leads to data loss then the application was not fit to be deployed on k8s.

The other aspect here is that neither Kubernetes nor Docker restart containers at will. But these tools can be configured with restart policies or update strategies that are appropriate for the software running within.

amon
  • 134,135