Having followed the history of Docker since its LXC roots and it decided to write its own LibContainer library the only thing I want to point out is:
> It's not correct to say Docker was designed "not" to do persistent data.
Actually...looking at a lot of things "missing from" or "difficult in" Docker can more or less be traced back to Docker's overriding philosophy of container runtimes. Things like not having an init process and optimizing user experience around single "Run" commands.
Having relatively recently done a container retrospective, following the path of:
I can't help but feel as if some of the "limitations" of Docker were more or less designed.
I'm not saying it's a bad thing, being a Python enthusiast I see value in simplicity/having only one way of doing things...but I just wanted to point out that where you draw the line for what is considered "designed" starts to get blurry in areas of Docker's chosen implementation.
Don't forget that DotCloud/Docker was originally basically a clone of Heroku, where "12 factor" dictated that all persistent data was stored in (non-containerized) Postgres.
That's incorrect. Dotcloud ran both stateless and stateful services on the same container fabric, unlike Heroku and every other PaaS. Specifically you could run a managed containerized postgres, mysql, mongodb, redis, rabbitmq, and custom stateful tcp services. Docker was a result of that design.
Docker was specifically designed to NOT impose a model of ephemeral containers. For example, by default 'docker run' preserves all data.
We use https://github.com/l3nz/whaleware for persistent, database-oriented workload with persistent data. We used to keep persistent data on a data volume, but now mount a native directory instead (2x faster).
Might not be the True And Approved Docker Way, but who cares? it works well, and has been in production for a number of years now. No data loss ever.
> It's not correct to say Docker was designed "not" to do persistent data.
Actually...looking at a lot of things "missing from" or "difficult in" Docker can more or less be traced back to Docker's overriding philosophy of container runtimes. Things like not having an init process and optimizing user experience around single "Run" commands.
Having relatively recently done a container retrospective, following the path of:
OpenVZ -> LXC -> Docker -> now (CoreOS, Rancher, LXD, Mesos, etc.)
I can't help but feel as if some of the "limitations" of Docker were more or less designed.
I'm not saying it's a bad thing, being a Python enthusiast I see value in simplicity/having only one way of doing things...but I just wanted to point out that where you draw the line for what is considered "designed" starts to get blurry in areas of Docker's chosen implementation.