Hacker News Reader

Comment by rm999 | Hacker News Reader

Containers are designed to be non-persistent - if an instance of a container goes down you should be able to replace it with another instance with no loss in state. Most people want their databases to be persistent (unless it's just temporary local storage for your process), so containers are a bad idea here. What you want is some sort of external storage to store state. This also enables better horizontal scaling.

View on HN

I would say this might be a description of Docker or Docker containers specifically, but does not characterize Linux containers generally.

Linux container technology, by which I mean the Linux kernel APIs used by Kubernetes, CoreOS rkt, and Docker, do not have an opinion about whether the processes that run as containers are ephemeral or persistent. Containers can be just as persistent as the host they're running on.

For example, consider a Linux distribution using systemd. Systemd might launch regular processes upon system startup, and it might also launch containers where both types of processes are equally persistent on the parent host. See the documentation for systemd-nspawn [1] and machinectl [2]. The Arch Linux wiki has more details about how to use that distribution with nspawn [3]. Containers managed in this way are just like other system processes aside from being containerized.

[1] https://www.freedesktop.org/software/systemd/man/systemd-nsp...

[2] https://www.freedesktop.org/software/systemd/man/machinectl....

[3] https://wiki.archlinux.org/index.php/Systemd-nspawn

Docker allows you to specify mounting directories on the host system. If you wish to have persistence of the data - it's simply the matter of specifying that mounting option.

Sure, but that's not a database running in Docker, it's "external storage to store state". Which is the right way of doing things if you're ok with your data persisting on the server.

Reply on news.ycombinator.com