Given my limited failed experience with playing with docker + postgres (and various volume stores including flocker) I have continued doubts about Uber's choices.
I suppose they are having success but I wonder at what cost.
Specifically the quote on [1]:
Finally, our decision ultimately came down to operational trust in the system we’d use, as it contains mission-critical trip data. Alternative solutions may be able to run reliably in theory, but whether we would have the operational knowledge to immediately execute their fullest capabilities factored in greatly to our decision to develop our own solution to our Uber use case. This is not only dependent on the technology we use, but also the experience with it that we had on the team.
And you know, I wouldn't argue too much at the thought of running MySQL out of a container. It does avoid a lot of basic issues around upgrades, versioning, stack split, etc. It's the act of treating it like all other containerized software which gets my panties in a twist.
Stateful systems can't be treated like stateless systems if you want to maintain anything resembling reasonable uptime and performance.
Docker does not replace puppet and they clearly wrote that they developed a System just for that.
5a) ignores MySQL's ability to make many runtime config changes without a restart
6) hard-codes master/slave relationships into the boot process (at least if I'm understanding the config json)
7) adds additional risk (noted as docker crashes) and client issues (noted as "userland proxy" comment)
8) requires additional ops overhead (noted as special care needed for masters)
---
But if you already run everything in docker and really want to get rid of puppet, then why not?
---
this article links to ansible but not puppet and is the only blog post tagged with either one; I think this really boils down to puppet vs $x