4 ms·

> 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 us

by 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).
- CSDude 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - otterley 10y ago
    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.

by CSDude 10y ago

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).

CSDude 10y ago
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.
- deleted 10y ago
  [deleted]
- otterley 10y ago
  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.