5 ms·

Would love to hear thought from people who use it in production?

toomuchtodo 10y ago
Unless you're using it to compartmentalize CI jobs on Travis or Jenkins, don't use it in production (do use it in development for standing up local dev environments quickly). We do, and it's a wasted layer of abstraction. I predict the Docker fad will end in 2-3 years, fingers crossed.
- cgag 10y ago
  I think it's a pretty excellent layer of abstraction, as it was in the form of jails/zones. Even if we stuck to single node computing I think I think it'd be a powerful thing, but viewing a whole cluster of computers as a single compute resource is incredible. I think docker itself may fade but I view its popularity as jails finally catching on rather than a new bit of hype that's going to die down soon.
- jagermo 10y ago
  maybe not end, but scale down to realistic usage scenarios.
- eropple 10y ago
  > do use it in development for standing up local dev environments quickly You can do this, for sure, but, tbh, I'd still rather use Vagrant. I'm already provisioning things like my datastores using Chef (and not deploying those inside of Docker in production); I might as well repurpose the same code to build a dev environment. I do agree regarding using containers (I use rkt rather than Docker for a few reasons) for CI being a really good jumping-off point, though.
  - bdcravens 10y ago
    Vagrant is pretty heavy, but if you're already using Chef, makes sense. If you're deploying using Docker, then mirroring your environment in dev makes more sense. I've used both Vagrant and Docker for dev, and find Docker to be super fast and light. (though I've definitely run into some headaches with Docker Compose that I didn't see in using just Docker)
    - eropple 10y ago
      I think it's probably not worth worrying about "fast" when "slow" is "ten minutes once a week, maybe, if you're really destructive" and similarly worrying about "light" when you have 16GB of RAM and a quad-core processor; the heaviest dev environment/IDE I can find (IntelliJ and a couple hundred Chrome tabs) doesn't use eight of it. It comes off as super-premature optimization to me, and those optimizations that you would otherwise do in Docker (which are just building base images, whatever, Packer does this trivially) exist in a virtualized environment too. Running datastores in Docker is bonkers in the first place, which still leaves a significant place for an actual CM tool--so unless you are a particular strain of masochist, when you are replicating your local environment, you'll probably need it anyway.
      - bdcravens 10y ago
        > ten minutes once a week, maybe, if you're really destructive If you do a lot of active machine development, where you're iterating on that machine setup, it's an extremely slow process. Perhaps it would make sense to iterate in Docker, and then convert that process to Vagrant once you finish. > similarly worrying about "light" when you have 16GB of RAM and a quad-core processor It's a concern when you're launching many machines at once to develop against. Docker tends to only eat what it needs. Also, while I think everyone should have a 16GB machine, there's quite a few developers out there running 8 or 4GB machines.
        eropple 10y ago
        > Perhaps it would make sense to iterate in Docker, and then convert that process to Vagrant once you finish. I disagree; writing convergent Chef is easy. (Actually convergent Ansible isn't, but that's just one more reason not to use it!) So I just re-run on the same machine. When I'm confident, I nuke and rebuild to make sure that the first pass, and not just later passes, work fine. When I'm doing this for other people, they don't have to rebuild at all unless I have to break compatibility (which is rare, if ever). Using Docker for this means wasting time using Docker instead of doing what I'm actually going to send to production. In a cloud environment, I get so vanishingly close to nothing for using Docker that it makes little sense to use it in development, at all. (I've tried. It's a slower, clumsier experience that results in a duplication of effort even before you have to buy into the gong show of k8s or whatever you want to use in order to actually manage your disaster.) > It's a concern when you're launching many machines at once to develop against. My standard VM flight for my current project is eight machines. It uses four gigs of RAM, and that's mostly because I decided to be pretty generous with RAM usage (none of my services really need half a gig of RAM when running in a development environment; there isn't enough data in a dev environment even to fill the caches). If you are doing the "oh, we have a billionty microservices" thing, well, sure, you might stick yourself in a rough place, but in the overwhelming majority of situations you're also probably engaged in masturbatory exercises that don't help you ship and I think you have much bigger problems on your hands. As far as developers with unsuitable hardware go--meh. "My boss is too cheap, so I need to use the wrong tools" is, and thankfully for the foreseeable future will be, someone else's problem. And that someone else should quit. (I was being pretty conservative with 16GB of RAM and a quad-core; that's just my laptop, I have a workstation for serious work.)
- jacques_chester 10y ago
  > I predict the Docker fad will end in 2-3 years, fingers crossed. I work for what is, ostensibly, a competitor and I don't agree. Containers are here to stay. Docker will pretty much have a brand lock on that for a long time.
- bdcravens 10y ago
  > I predict the Docker fad will end in 2-3 years, fingers crossed. Containers are definitely here to stay. Google, Heroku, and others have been using them for years. Obviously Docker is just a subset, and it might fade, but I think it's pretty well established as a defacto standard.
  - toomuchtodo 10y ago
    Containers have been around for more than a decade as lxc. I'm saying Docker itself. It's hard to make money when you're running on an open standard that anyone can build tooling around.
- deleted 10y ago
  [deleted]
DigitalJack 10y ago
I use it in production by way of kubernetes. It's been great so far.
olalonde 10y ago
I used it in production with CoreOS and now Kubernetes. I almost never touch the Docker CLI and haven't tried Swarm. I think a lot of developers mistakenly think they can get to a production environment in a few Docker commands which is definitely not possible today.
- Twirrim 10y ago
  From an ops side, that's worrying. Yes, in an absolutely ideal world no one ever should touch a production environment, and ideally in every situation you find yourself having to touch a production system you should then be creating at the very least a backlog item to figure out how to avoid doing it in the future, but the reality is some kinds of troubleshooting are hard to do without having access. Generally the kinds of situations where you need that access are ones when you want access the quickest and easiest, i.e. the world is burning somehow.
  - lobster_johnson 10y ago
    OP wasn't talking about access, but about the effort needed to set up ("get to") a production environment. Of course Kubernetes/Docker gives you full access to your production environment.
TheHydroImpulse 10y ago
We're using Docker pretty extensively at Segment with over 1,200 containers running in production with ECS (total count, not uniqueness). We haven't touched Swarm and are staying a couple versions behind. With that said, we're pretty happy with the setup right now.
- NathanKP 10y ago
  Airtime is also using ECS to run docker containers in production. We ran into a few issues early on due to early adopter status, but the AWS team was very quick to add many features we needed. I have no complaints about ECS now, and in fact I'd say that ECS solves a lot of the problems that the author complains here. I'd say that Swarm is not production ready, but docker itself as an engine for running a container is fine. You just need to build your own orchestration layer, or use something like ECS. More details on Airtime's docker setup here: https://techblog.airtime.com/microservice-continuous-integration-made-easy-with-aws-ecs-10d470e31af0 https://techblog.airtime.com/microservice-continuous-integra...
  - hosh 10y ago
    Maybe things has changed since Apr 2015, but I found ECS pretty limited and K8S solving those limitations. One big issue was container-to-container addressing. It was not available last year when I put an ECS cluster into production. Has it been added since?
    - NathanKP 10y ago
      Direct container to container communication isn't the recommended pattern when using ECS. Instead you let ECS associate with either a legacy Elastic Load Balancer, or one of the new Application Load Balancers, which can direct requests to different classes of containers based on the request path, allowing you to take a set of containers of different types and meld their http resources together into one API on one domain. If one container needs to talk to another container of a certain type it just uses the load balancer, and the load balancer takes care of directing the request to the other container which may be on the same machine, or another machine, or maybe even in a different cluster. Obviously this forces you into a fully stateless design because the load balancer round robins all the requests across random containers, but its very fail proof, and gives you high resiliency.
ceocoder 10y ago
We use it via GKE in prod. Zero complaints so far.
knz 10y ago
I've posted about this before, but my work (non IT Department at a State Govt agency) has been using Docker in production for about a year. We are small by HN standards (~12 apps on 5 hosts that are a mix of API's, front ends, and several more complex GIS apps). Moving to Docker was a massive improvement for us in terms of deployment and development. Deploying with Docker is ridiculously easy (no more taking a node out of HAProxy for an update, rollbacks are painless, and we love that what you deploy is what you get - there is no question over what the container is actually doing since you define it in the Dockerfile). I can't remember the last time we had a bad deployment or even cared about making a change to production. It's that reliable. It's also been a massive improvement for QA and development because of the ability to standardize the container using the Dockerfile. We've been using CentOS for the production hosts and CentOS/OSX for developing on. There were a couple of minor issues when we started but the benefits outweighed the negatives then. It's been completely painless since Docker came out of beta. We have some containers that are deployed daily and others that run for months without being touched. I've never quite understood the negative attitude towards Docker. Perhaps we are too small to see many of the issues that people often complain about, but moving to Docker was a great decision in our office.
- cpitman 10y ago
  Are you installing docker out of the CentOS repositories, or from Docker Inc's repository? The CentOS version is based on the work Red Hat does to backport patches and create more production ready versions of Docker, so that might be why you are having a better experience.
  - knz 10y ago
    We are indeed using the CentOS repositories. The current version on our production servers is 1.10.3.

Unless you're using it to compartmentalize CI jobs on Travis or Jenkins, don't use it in production (do use it in development for standing up local dev environments quickly). We do, and it's a wasted layer of abstraction. I predict the Docker fad will end in 2-3 years, fingers crossed.

cgag 10y ago
I think it's a pretty excellent layer of abstraction, as it was in the form of jails/zones. Even if we stuck to single node computing I think I think it'd be a powerful thing, but viewing a whole cluster of computers as a single compute resource is incredible. I think docker itself may fade but I view its popularity as jails finally catching on rather than a new bit of hype that's going to die down soon.
jagermo 10y ago
maybe not end, but scale down to realistic usage scenarios.
eropple 10y ago
> do use it in development for standing up local dev environments quickly You can do this, for sure, but, tbh, I'd still rather use Vagrant. I'm already provisioning things like my datastores using Chef (and not deploying those inside of Docker in production); I might as well repurpose the same code to build a dev environment. I do agree regarding using containers (I use rkt rather than Docker for a few reasons) for CI being a really good jumping-off point, though.
- bdcravens 10y ago
  Vagrant is pretty heavy, but if you're already using Chef, makes sense. If you're deploying using Docker, then mirroring your environment in dev makes more sense. I've used both Vagrant and Docker for dev, and find Docker to be super fast and light. (though I've definitely run into some headaches with Docker Compose that I didn't see in using just Docker)
  - eropple 10y ago
    I think it's probably not worth worrying about "fast" when "slow" is "ten minutes once a week, maybe, if you're really destructive" and similarly worrying about "light" when you have 16GB of RAM and a quad-core processor; the heaviest dev environment/IDE I can find (IntelliJ and a couple hundred Chrome tabs) doesn't use eight of it. It comes off as super-premature optimization to me, and those optimizations that you would otherwise do in Docker (which are just building base images, whatever, Packer does this trivially) exist in a virtualized environment too. Running datastores in Docker is bonkers in the first place, which still leaves a significant place for an actual CM tool--so unless you are a particular strain of masochist, when you are replicating your local environment, you'll probably need it anyway.
    - bdcravens 10y ago
      > ten minutes once a week, maybe, if you're really destructive If you do a lot of active machine development, where you're iterating on that machine setup, it's an extremely slow process. Perhaps it would make sense to iterate in Docker, and then convert that process to Vagrant once you finish. > similarly worrying about "light" when you have 16GB of RAM and a quad-core processor It's a concern when you're launching many machines at once to develop against. Docker tends to only eat what it needs. Also, while I think everyone should have a 16GB machine, there's quite a few developers out there running 8 or 4GB machines.
      - eropple 10y ago
        > Perhaps it would make sense to iterate in Docker, and then convert that process to Vagrant once you finish. I disagree; writing convergent Chef is easy. (Actually convergent Ansible isn't, but that's just one more reason not to use it!) So I just re-run on the same machine. When I'm confident, I nuke and rebuild to make sure that the first pass, and not just later passes, work fine. When I'm doing this for other people, they don't have to rebuild at all unless I have to break compatibility (which is rare, if ever). Using Docker for this means wasting time using Docker instead of doing what I'm actually going to send to production. In a cloud environment, I get so vanishingly close to nothing for using Docker that it makes little sense to use it in development, at all. (I've tried. It's a slower, clumsier experience that results in a duplication of effort even before you have to buy into the gong show of k8s or whatever you want to use in order to actually manage your disaster.) > It's a concern when you're launching many machines at once to develop against. My standard VM flight for my current project is eight machines. It uses four gigs of RAM, and that's mostly because I decided to be pretty generous with RAM usage (none of my services really need half a gig of RAM when running in a development environment; there isn't enough data in a dev environment even to fill the caches). If you are doing the "oh, we have a billionty microservices" thing, well, sure, you might stick yourself in a rough place, but in the overwhelming majority of situations you're also probably engaged in masturbatory exercises that don't help you ship and I think you have much bigger problems on your hands. As far as developers with unsuitable hardware go--meh. "My boss is too cheap, so I need to use the wrong tools" is, and thankfully for the foreseeable future will be, someone else's problem. And that someone else should quit. (I was being pretty conservative with 16GB of RAM and a quad-core; that's just my laptop, I have a workstation for serious work.)
jacques_chester 10y ago
> I predict the Docker fad will end in 2-3 years, fingers crossed. I work for what is, ostensibly, a competitor and I don't agree. Containers are here to stay. Docker will pretty much have a brand lock on that for a long time.
bdcravens 10y ago
> I predict the Docker fad will end in 2-3 years, fingers crossed. Containers are definitely here to stay. Google, Heroku, and others have been using them for years. Obviously Docker is just a subset, and it might fade, but I think it's pretty well established as a defacto standard.
- toomuchtodo 10y ago
  Containers have been around for more than a decade as lxc. I'm saying Docker itself. It's hard to make money when you're running on an open standard that anyone can build tooling around.
deleted 10y ago
[deleted]

DigitalJack 10y ago

I use it in production by way of kubernetes. It's been great so far.

olalonde 10y ago

I used it in production with CoreOS and now Kubernetes. I almost never touch the Docker CLI and haven't tried Swarm. I think a lot of developers mistakenly think they can get to a production environment in a few Docker commands which is definitely not possible today.

Twirrim 10y ago
From an ops side, that's worrying. Yes, in an absolutely ideal world no one ever should touch a production environment, and ideally in every situation you find yourself having to touch a production system you should then be creating at the very least a backlog item to figure out how to avoid doing it in the future, but the reality is some kinds of troubleshooting are hard to do without having access. Generally the kinds of situations where you need that access are ones when you want access the quickest and easiest, i.e. the world is burning somehow.
- lobster_johnson 10y ago
  OP wasn't talking about access, but about the effort needed to set up ("get to") a production environment. Of course Kubernetes/Docker gives you full access to your production environment.

TheHydroImpulse 10y ago

We're using Docker pretty extensively at Segment with over 1,200 containers running in production with ECS (total count, not uniqueness). We haven't touched Swarm and are staying a couple versions behind. With that said, we're pretty happy with the setup right now.

NathanKP 10y ago
Airtime is also using ECS to run docker containers in production. We ran into a few issues early on due to early adopter status, but the AWS team was very quick to add many features we needed. I have no complaints about ECS now, and in fact I'd say that ECS solves a lot of the problems that the author complains here. I'd say that Swarm is not production ready, but docker itself as an engine for running a container is fine. You just need to build your own orchestration layer, or use something like ECS. More details on Airtime's docker setup here: https://techblog.airtime.com/microservice-continuous-integration-made-easy-with-aws-ecs-10d470e31af0 https://techblog.airtime.com/microservice-continuous-integra...
- hosh 10y ago
  Maybe things has changed since Apr 2015, but I found ECS pretty limited and K8S solving those limitations. One big issue was container-to-container addressing. It was not available last year when I put an ECS cluster into production. Has it been added since?
  - NathanKP 10y ago
    Direct container to container communication isn't the recommended pattern when using ECS. Instead you let ECS associate with either a legacy Elastic Load Balancer, or one of the new Application Load Balancers, which can direct requests to different classes of containers based on the request path, allowing you to take a set of containers of different types and meld their http resources together into one API on one domain. If one container needs to talk to another container of a certain type it just uses the load balancer, and the load balancer takes care of directing the request to the other container which may be on the same machine, or another machine, or maybe even in a different cluster. Obviously this forces you into a fully stateless design because the load balancer round robins all the requests across random containers, but its very fail proof, and gives you high resiliency.

ceocoder 10y ago

We use it via GKE in prod. Zero complaints so far.

knz 10y ago

I've posted about this before, but my work (non IT Department at a State Govt agency) has been using Docker in production for about a year. We are small by HN standards (~12 apps on 5 hosts that are a mix of API's, front ends, and several more complex GIS apps). Moving to Docker was a massive improvement for us in terms of deployment and development. Deploying with Docker is ridiculously easy (no more taking a node out of HAProxy for an update, rollbacks are painless, and we love that what you deploy is what you get - there is no question over what the container is actually doing since you define it in the Dockerfile). I can't remember the last time we had a bad deployment or even cared about making a change to production. It's that reliable. It's also been a massive improvement for QA and development because of the ability to standardize the container using the Dockerfile. We've been using CentOS for the production hosts and CentOS/OSX for developing on. There were a couple of minor issues when we started but the benefits outweighed the negatives then. It's been completely painless since Docker came out of beta. We have some containers that are deployed daily and others that run for months without being touched. I've never quite understood the negative attitude towards Docker. Perhaps we are too small to see many of the issues that people often complain about, but moving to Docker was a great decision in our office.

cpitman 10y ago
Are you installing docker out of the CentOS repositories, or from Docker Inc's repository? The CentOS version is based on the work Red Hat does to backport patches and create more production ready versions of Docker, so that might be why you are having a better experience.
- knz 10y ago
  We are indeed using the CentOS repositories. The current version on our production servers is 1.10.3.