Docker in Production: A retort

Re:Docker in Production: A retort by jfoutz on Saturday November 05, 2016 @06:29PM (#12882277)

>>> * Docker encourages fully disposable infrastructure

I just want to tack on the upgrade rollback situation. A container looks a lot like a process from the host os point of view. You can bring up the new release and leave the old release running on the same machine without much difference in load. The load just shifts to the new container. With a VM approach, you kind of need both vm's for the whole upgrade window.

Depending on your orchestration, blue/green deployment is pretty straightforward.

[ Parent | on HN ]

Re:Docker in Production: A retort by user5994461 on Saturday November 05, 2016 @07:00PM (#12882388)

There can't be two containers running that listen on the same port. The rolling upgrade will need to kill the first container to start the new one.

I may suppose that you talk about [CPU] load, because you are running computations/processing applications and not webservices.

[ Parent | on HN ]

Re:Docker in Production: A retort by fapjacks on Saturday November 05, 2016 @10:44PM (#12883175)

Well, this is a problem that's been solved [0]. I've been using nginx-proxy for a couple of years now, in production, without any issues.

[0] https://github.com/jwilder/nginx-proxy

[ Parent | on HN ]

Re:Docker in Production: A retort by lobster_johnson on Sunday November 06, 2016 @01:59AM (#12883762)

Don't use static ports. Pick a random one and update the load balancer (Haproxy, Traefik, Nginx) to point to the new one. If the rollout fails, you can always roll back by pointing back the old one.

FWIW, Kubernetes solves this out of the box.

[ Parent | on HN ]