Hacker News Reader

> Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.

What is your typical server infrastructure? We use bare machines and had kernel panics very rarely (only with experimental MACVLAN). We did not 'get away' with anything. We have been using Docker for over 2 years, and LXC much more and know how to handle mounted directories, it is not a rocket science. We used LXC, now Docker to provide quick isolated mini linux environments. They are just different type of Virtual Machines when you abstract it in your head, and do not expect it to do magical stuff like saving your data and send it to another host upon crash.

> Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager.

They are often outdated, we mostly get one of the latest builts, and in some cases Snapshot builds, where they are not available anywhere. So ability to run versioned instances of some software independently and isolated is a huge win for us. We do not want to distrub people using the old version. Yes it can be solved with VMs. We use our own bare metal servers. We do not like to "pay" to open VMs, so we turned to OpenStack. It is very complicated for our use case, we like to use bare metal on our own. But, we still need isolation, this is where containers; LXC and Docker came to help and saved us a burden.

> They are often outdated, we mostly get one of the latest builts, and in some cases Snapshot builds,

That's a very usual thing to say about databases. For critical and commercially supported things such as your relational databases, nobody runs snapshot builds. You run whatever builds your vendor supports, and for all those you mentioned (and most other vendors) that is going to be native packages.

Native packages are nothing more than packaged software with startup and maintaining scripts, (and tested) so as long as you can manage these, I really don't see I have to stick to what my vendor thinks best.

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 instability through frequent needless upgrades).

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 don't care a guy on the internet that is upset because I don't follow their "best" practice. I gave you my use cases, said that Its workinng well for almost 2 years and list the advantages, you still focus on your "best" cases. It works just fine as long as you know what you are doing, and I expect to hear more justifiable and technical explanations why this should not be done, rather than your feelings and biased best practices that does not translate into any verifiable points.

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.

And this is exactly why you should containerise your db's run environment with docker. Dependency management. You cannot control your host environment to the same degree you can control the docker environment, given the same amount of effort. If Oracle only supports RH6 and you use Ubuntu LTS on your host, you run it in a RH6 based container. Oh look, maybe even use the official one https://github.com/oracle/docker-images

If the DB vendor is supplying and supporting the images, then that's a different story, of course. The devil is in the details, and the presence of Docker support shouldn't be interpreted to suggest that other aspects of database administration shouldn't be followed.

At any rate, at least MySQL and its Percona variant have native packages for modern mainstream Linux distributions , so as a practical matter you shouldn't need to run them in a container: they've already worked out the dependencies for you. This means you don't need to bother with the overhead of Docker.

I update my database servers for the same reason I update my proxy servers: more features, security fixes, better performance, increased stability.

How frequently? And can you quantify those benefits relative to the risk and amount of work involved? How do you know it passes the cost/benefit ratio test?

The same as all my other software?

Is this your first time working with it?

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.

I'm still not sure I follow. If you're not setting up a DB that will have such heavy usage that it needs bare metal access, what's wrong with setting it up such that it stores data on a NAS, or via mounted volumes? Then when it comes time to upgrade due to a security issue, you can create a new container, spin it up, and if it barfs, relaunch the old one.

Unnecssesary complexity. A VM would've sufficed for what you described.

I find VMs are super slow for development purposes (I mean setup, starting up and shutting down rather than actual processing), where docker's made a massive difference. YMMV especially if you're not spinning up new projects frequently.

They might be a better solution in production, but I have a strong preference for production mimicking development.

Precisely the point. It's fine in dev but once you are running in prod and need rock solid stability the generally accepted dogma is that containerizing your DB is playing with fire. As you said, YMMV.

What is the "Unnecssesary complexity" in this scenario? You literally just run a command and you can spin up a new container with your data.

A good reason for running a database in a container is fault tolerance without setting up database replication.

Put your database in a container, let it store its data on a network storage system (like a distributed file system). The container scheduler makes sure it gets rescheduled when the node goes down.

And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?

Less downtime and automatic recovery, I'd say. 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.

> 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 service (database) when not needed. Starting a container seems to be much more fragile solution.

There are already well-developed mechanisms for things like that, and we (sysadmins) were using them for dozens years already.

The question still stands: what do containers do better than the mechanisms we had for a long time?

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 do not want a 'downside' with any database. Especially when big money are involved, people are shown the door for far lesser issues than the ones that docker seems to have.

By the way, you still haven't answered his question.

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.

And then the NFS handle goes stale, and the fun begins.