Docker seems very limited when it's unsuitable to run databases.
I've never seen this limitation with other container solutions. What is it about Docker that makes it problematic?
Docker in Production: A retort
91–100 of 132 posts
Re: Docker in Production: A retort
#92Earlier quoted context omitted.
I can't imagine what your use case is that requires running bleeding edge database servers in production and that cannot be managed via native OS packaging. Would you please enlighten us? Otherwise it really sounds like you're using a non-best practice (running a DB in a container) to paper over another non-best practice (treating your DB as a non-sacrosanct piece of infrastructure by introducing intentional instabil…
I really don't understand why you insist. You keep saying "best-practice" like it is a law, but the truth is there is no such thing is best. It fits our cases, worked well, continues to work well. Did I say it cannot be managed with traditional package managers? No. But I do not like upstart nor systemd, and I like the simplicty I get from Docker, and ability to replicate the almost same environment easily. I really…
[deleted]
Re: Docker in Production: A retort
#93Earlier quoted context omitted.
Author from the original article here. >>> * Docker encourages fully disposable infrastructure => I'd consider that incorrect and/or misleading Docker is meant to manage disposable (i.e. stateless) applications. They are expected to be killed/stopped/restarted at any time, no persistent state, no data. An application is either disposable OR not disposable by its design, docker doesn't change that. (For instance, don'…
>Having docker without orchestration is like having cars without roads. Docker's stated purpose is to be the "shipping container" abstraction for server-side code. Shipping containers are not much more exciting than any other kind of box (VM, jail, whatever) in isolation. Things get more interesting when every port has container-optimized cranes and there are thousands of container ships competing for your business.
Thinking about it i seem to recall that for a while all the hoopla was about VMs that could migrate between hardware to both better utilize existing hardware resources, and allow for more uptime.
But then a while later all the buzz was containerization, with Docker as the poster boy. This, i suspect, in that rather than have the overhead of a VM and such, you could spin up a container instance over there, take it down over here, and achieve much the same result. This in particular if the content of your VM or container was talking to a storage backend anyways.
Re: Docker in Production: A retort
#94Earlier quoted context omitted.
I can't imagine what your use case is that requires running bleeding edge database servers in production and that cannot be managed via native OS packaging. Would you please enlighten us? Otherwise it really sounds like you're using a non-best practice (running a DB in a container) to paper over another non-best practice (treating your DB as a non-sacrosanct piece of infrastructure by introducing intentional instabil…
I really don't understand why you insist. You keep saying "best-practice" like it is a law, but the truth is there is no such thing is best. It fits our cases, worked well, continues to work well. Did I say it cannot be managed with traditional package managers? No. But I do not like upstart nor systemd, and I like the simplicty I get from Docker, and ability to replicate the almost same environment easily. I really…
Well, for one, because many database vendors won't provide support unless you're using the bits they've precompiled for you. If you think you'll never need outside help for the lifetime of your organization, then more power to you.
Another reason is that you're introducing an unnecessary dependency/component that can introduce potential instability. Common sense (since you seem to be offended by the term "best practice") and experience suggests that you should eliminate as many sources of potential instability as possible to increase the overall availability of a service or component.
Re: Docker in Production: A retort
#95Earlier quoted context omitted.
You didn't answer any of the questions expect the one about frequency. I'm left to assume that your usage is so irrelevant or your user base so small that you haven't needed to spend time thinking really hard about operational difficulties, SLAs, or calculating risk tolerance relative to value. Or gotten yourself into trouble yet which every DBA/SRE of a database of substantial size gets into eventually.
I didn't say exactly how frequently, just that it's the same with my database as other software.
That's... not helpful at all.
Re: Docker in Production: A retort
#96Earlier quoted context omitted.
It's great for development if it wasn't 4 to 5 times slower on Mac: https://www.reddit.com/r/docker/comments/59u1b8/why_is_docke...
(Having read the Reddit thread for a while) Macs don't appear to have support for containers which is what Docker is . Well that is probably bollocks because they are *BSD based and I know that FreeBSD at least has a form of containerization and I seem to recall that the whole container thing was invented on a BSD - "jails". So Docker can't run native on iStuff. You have to run it within a Linux VM. I gave up on Goog…
XNU (the macOS kernel) may have BSD origins, but it doesn't have features like cgroups and process namespacing that the Linux kernel provides and the Docker runtime relies on.
Re: Docker in Production: A retort
#97Earlier quoted context omitted.
> Less downtime and automatic recovery, I'd say. How? By magic dust sprinkled by Docker Inc? > When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would. You seem to forget that a) container's filesystem needs to be downloaded in the first place, and b) that VMs can work in a standby mode, not running the serv…
Its faster virtual machines, which do not have live migration for that specific use case. Just because you are doing it for years does not mean that it cannot be improved or have an alternative with its both downsides and upsides.
You're praising a feature that is an anti-pattern for database administration. If you're migrating data around and upgrading and restarting your production database without adequate business justification, you're asking for trouble.
Re: Docker in Production: A retort
#98Earlier quoted context omitted.
> Less downtime and automatic recovery, I'd say. How? By magic dust sprinkled by Docker Inc? > When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would. You seem to forget that a) container's filesystem needs to be downloaded in the first place, and b) that VMs can work in a standby mode, not running the serv…
Its faster virtual machines, which do not have live migration for that specific use case. Just because you are doing it for years does not mean that it cannot be improved or have an alternative with its both downsides and upsides.
[deleted]
Re: Docker in Production: A retort
#99Re: Docker in Production: A retort
#100Previous article: "This is nowhere near ready for those who just want to get the job done." This article: "It'll be better in the future, you'll see!" The former is verifiable, the latter is a hypothesis.
No what I was saying was its ready for today in certain use cases. But only if you look at it as a long term transition and not a short term project