8 ms·

> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story. Sorry, but this is really a bad advice. We

by CSDude 10y ago

> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story. Sorry, but this is really a bad advice. We have ran and contine to run various databases inside Docker including MySQL, PostgRedis, Cassandra, Elastic Search, RethinkDB even HDFS with proper user rights and configuration. We can maintain the state just as fine. If your only problem is to move the data, all you have to do is stop, export, tar it, move to another server, just as you would do in a normal server. Docker is not a magic bullet to solve such kind of issues. Yes, Docker might have another problems, but just as you could not run someting with state inside Docker does not mean "thou shalt not run" , there are various ways to manage state. Host, IO can get crash regardless of Docker.

otterley 10y ago
What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't fix it." It's there to store data on behalf of the applications you write; it is not a thing to upgrade or migrate for its own sake unless there is a bug to quash or a new feature that your application will depend upon; and even then, migrations must be carefully planned to preserve availability for users. Docker and the like seem like a solution in search of a problem for this particular part of a typical service infrastructure. Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.
- kstenerud 10y ago
  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.
  - toomuchtodo 10y ago
    Unnecssesary complexity. A VM would've sufficed for what you described.
    - cs02rm0 10y ago
      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.
      - ascendantlogic 10y ago
        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.
        deleted 10y ago
        [deleted]
    - distracted_boy 10y ago
      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.
- CSDude 10y ago
  > 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.
  - xorcist 10y ago
    > 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.
    - CSDude 10y ago
      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.
  - otterley 10y ago
    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).
- fh973 10y ago
  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.
  - dozzie 10y ago
    And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?
    - fh973 10y ago
      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.
      - dozzie 10y ago
        > 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?
        CSDude 10y ago
        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.
- paulddraper 10y ago
  I update my database servers for the same reason I update my proxy servers: more features, security fixes, better performance, increased stability.
  - otterley 10y ago
    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?
    - paulddraper 10y ago
      The same as all my other software? Is this your first time working with it?
      - otterley 10y ago
        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.
        paulddraper 10y ago
        I didn't say exactly how frequently, just that it's the same with my database as other software.
        otterley 10y ago
        That's... not helpful at all.

by CSDude 10y ago

otterley 10y ago

What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't fix it." It's there to store data on behalf of the applications you write; it is not a thing to upgrade or migrate for its own sake unless there is a bug to quash or a new feature that your application will depend upon; and even then, migrations must be carefully planned to preserve availability for users. Docker and the like seem like a solution in search of a problem for this particular part of a typical service infrastructure. Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.

kstenerud 10y ago
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.
- toomuchtodo 10y ago
  Unnecssesary complexity. A VM would've sufficed for what you described.
  - cs02rm0 10y ago
    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.
    - ascendantlogic 10y ago
      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.
      - deleted 10y ago
        [deleted]
  - distracted_boy 10y ago
    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.
CSDude 10y ago
> 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.
- xorcist 10y ago
  > 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.
  - CSDude 10y ago
    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.
- otterley 10y ago
  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).
fh973 10y ago
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.
- dozzie 10y ago
  And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?
  - fh973 10y ago
    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.
    - dozzie 10y ago
      > 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?
      - CSDude 10y ago
        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.
paulddraper 10y ago
I update my database servers for the same reason I update my proxy servers: more features, security fixes, better performance, increased stability.
- otterley 10y ago
  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?
  - paulddraper 10y ago
    The same as all my other software? Is this your first time working with it?
    - otterley 10y ago
      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.
      - paulddraper 10y ago
        I didn't say exactly how frequently, just that it's the same with my database as other software.
        otterley 10y ago
        That's... not helpful at all.