3 ms·

5) configuration and version drift is guaranteed since you have to restart databases to make any changes 5a) ignores MySQL's ability to make many runtime confi

5) configuration and version drift is guaranteed since you have to restart databases to make any changes 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

falcolas 10y ago
> But if you already run everything in docker and really want to get rid of puppet, then why not? 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.
merb 10y ago
> But if you already run everything in docker and really want to get rid of puppet, then why not? Docker does not replace puppet and they clearly wrote that they developed a System just for that.
agentgt 10y ago
I find it ironic that one of Uber's original impetus for migrating off Postgres (which I still have serious doubts about) was not being able to "trust" the system [1]. 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. [1]: https://eng.uber.com/schemaless-part-one/ https://eng.uber.com/schemaless-part-one/

falcolas 10y ago

> But if you already run everything in docker and really want to get rid of puppet, then why not? 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.

merb 10y ago

> But if you already run everything in docker and really want to get rid of puppet, then why not? Docker does not replace puppet and they clearly wrote that they developed a System just for that.

agentgt 10y ago

I find it ironic that one of Uber's original impetus for migrating off Postgres (which I still have serious doubts about) was not being able to "trust" the system [1]. 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. [1]: https://eng.uber.com/schemaless-part-one/ https://eng.uber.com/schemaless-part-one/