4 ms·

Docker in Production: How we did it wrong This is a typical case of blaming the tool. There are so many bad practices mentioned I don't know where to start. No

by moondev 10y ago

Docker in Production: How we did it wrong This is a typical case of blaming the tool. There are so many bad practices mentioned I don't know where to start. No orchestration... One container a host... Not using volumes correctly... Apt-get installing docker every time ci runs... Not using an optimized base os for containers... It's amazing what people will blame their problems on when they don't do their due dilligence with a new platform.

mschuster91 10y ago
> One container a host... As said in the post, this was a consequence of Docker failing them when running multiple containers on a host. > Not using an optimized base os for containers... On a server that might be possible, but I thought Docker's advantage was providing a reproducible system that can also be run on your dev machine? Sorry, if Docker doesn't run stable on my dev machine, no way I'm trying it.
- moondev 10y ago
  The topic is running containers in production. Why not use a base os designed for that?
  - mschuster91 10y ago
    Because the base OS needs to be something an admin can work comfortably on, esp. if the host is supposed to run other things besides docker (e.g. a database, you do not want to run mysql over a network if possible). And for this you need a "real" base OS, which will be either apt-flavor (debian/ubuntu) or rpm-flavor (rhel, sles), depending on the organization.
    - moondev 10y ago
      Why not run your database on a different machine then. Separation of concerns. Have a cluster a machines for containers so you can take advantage of it's strengths instead of trying to duct tape everything together on machine
      - mschuster91 10y ago
        > Why not run your database on a different machine then. Separation of concerns. While true in general, you always end up introducing latency (simply because it's on a different host) and possible packet losses/retransmits (e.g. when the switch buffer memory overruns). Given the "hft" in the blog name (high-speed financial transactions), both can equal losses of money.

by moondev 10y ago

mschuster91 10y ago

> One container a host... As said in the post, this was a consequence of Docker failing them when running multiple containers on a host. > Not using an optimized base os for containers... On a server that might be possible, but I thought Docker's advantage was providing a reproducible system that can also be run on your dev machine? Sorry, if Docker doesn't run stable on my dev machine, no way I'm trying it.

moondev 10y ago
The topic is running containers in production. Why not use a base os designed for that?
- mschuster91 10y ago
  Because the base OS needs to be something an admin can work comfortably on, esp. if the host is supposed to run other things besides docker (e.g. a database, you do not want to run mysql over a network if possible). And for this you need a "real" base OS, which will be either apt-flavor (debian/ubuntu) or rpm-flavor (rhel, sles), depending on the organization.
  - moondev 10y ago
    Why not run your database on a different machine then. Separation of concerns. Have a cluster a machines for containers so you can take advantage of it's strengths instead of trying to duct tape everything together on machine
    - mschuster91 10y ago
      > Why not run your database on a different machine then. Separation of concerns. While true in general, you always end up introducing latency (simply because it's on a different host) and possible packet losses/retransmits (e.g. when the switch buffer memory overruns). Given the "hft" in the blog name (high-speed financial transactions), both can equal losses of money.