Live data from Hacker News

Ask HN: How do you use Docker in production?

news.ycombinator.com

41–50 of 157 posts

Re: Ask HN: How do you use Docker in production?

#41
We are running our app[1] in instances of Google Compute Engine. We installed Docker in those instances.

Our app is a bunch of microservices, some Rails Apps each one running with Puma as webserver, HAProxy, some other Rack app (for Websockets). We also use RabbitMQ and Redis.

All the components are running in their own containers (we have dozens of containers running to support this app).

We choose this path because in case of failures, just 1 service would be down meanwhile the whole system is nearly fully functional. Re-launching a container is very straightforward and is done quickly.

[1]: https://dockerize.it

Re: Ask HN: How do you use Docker in production?

#43
We use docker at stylight for deploying our frontend app (wildfly). We use the docker hub for storing images. When we do a release we basically push to the hub, pull on all upstreams and restart the containers with the new image. We have a base application image (containing java, wildfly etc.) which basically never changes so builds and distribution are super fast. We really like the fact that the containers are isolated! We ran into an issue the other day where we wanted to dump the heap of the JVM to debug some memory leak issue, this should be easier with 1.3!

Re: Ask HN: How do you use Docker in production?

#44

Here's the problems we're solving with Docker: * Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?" * Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying…

Very interesting. I'm curious, have you considered nixos?

Re: Ask HN: How do you use Docker in production?

#45
post #40

Most people seem to be using Docker with distro-based images, ie. start with ubuntu and then add their own app on top etc. Is anyone using more application-oriented images, ie. start with empty image and add just your application and its dependencies?

I'm doing this, but starting with the minimal 80MB debian:stable image and then using apt-get to grab my dependencies. The 80MB covers the dependencies for apt-get.

I believe the centos images are also minimal, but the ubuntu image starts out much larger.

Re: Ask HN: How do you use Docker in production?

#46

Here's the problems we're solving with Docker: * Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?" * Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying…

In typical virtualisation + config management you specify a base image and bunch of config files and commands.

In a Dockerfile you specify a base image and commands, may often invoke a config management tool.

How is using Docker more declarative?

Re: Ask HN: How do you use Docker in production?

#47

Here's the problems we're solving with Docker: * Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?" * Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying…

Great explanation. If possible, I'd love to see/know more about how the statistician training step was accomplished. I also work with many nontechnical folks and haven't found success getting training on docker to 'stick'.

Re: Ask HN: How do you use Docker in production?

#48
post #37

Earlier quoted context omitted.

how do you do restarts when you update the app ? I assume you have to take the app server out of the server pool (remove from load balancer or nginx) and shut it down, then docker pull your image. I'm doing deploys with ansible and its just too slow

Actually, we have Nginx configured with Health Check ( http://nginx.org/en/docs/http/load_balancing.html#nginx_load... ). Hence, it will automatically take a given appserver out of the pool when it stops responding. Once the node is back again, Nginx will automatically bring it back into rotation. Also, we actually use a volume/bind-mount to store the source code on the host machine (mounted read-only). That way we c…

How do you deal with connections that are in progress to the app server? If you just take it down, you're potentially throwing away active connections.

Re: Ask HN: How do you use Docker in production?

#49
At Pusher we use Docker for CI.

I've developed a little command-line tool (https://github.com/zimbatm/cide) that can run the same environment on the developer machine and Jenkins. It also makes the Jenkins configuration much easier since build dependencies are all sandboxed in different docker boxes. The tool is mainly for legacy apps and is able to export artefacts back to Jenkins instead of publishing Docker images.

Re: Ask HN: How do you use Docker in production?

#50
post #46

Here's the problems we're solving with Docker: * Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?" * Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying…

In typical virtualisation + config management you specify a base image and bunch of config files and commands. In a Dockerfile you specify a base image and commands, may often invoke a config management tool. How is using Docker more declarative?

If you take the steps for, say, AWS, of building a new AMI for every role you have, then it's pretty much the same.

(but in my experience with building AMI's, that process is way too slow compared to Docker)

Docker becomes closer to declarative when you build static Docker images for every role and rebuild for every change and re-deploy. Even more so when your deployment is based on a tool like Fleet that declaratively specifies your cluster layout.

The point is to avoid ever having situations where you say "install package foo on all webservers". Instead you say "replace all webservers with a bit-by-bit identical copy of image x".

The benefit is that you can have already tested a container that is 100% identical, and know that the deployed containers will be 100% identical, rather than hope the commands you pass to the config tool handles every failure scenario well enough.

Post reply on HN