Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker in Production: A retort

patrobinson.github.io

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Docker in Production: A retort

#101

Post by XorNot »

digi_owl wrote: post #93
closeparen wrote: post #43

Earlier quoted context omitted.

>Having docker without orchestration is like having cars without roads. Docker's stated purpose is to be the "shipping container" abstraction for server-side code. Shipping containers are not much more exciting than any other kind of box (VM, jail, whatever) in isolation. Things get more interesting when every port has container-optimized cranes and there are thousands of container ships competing for your business.

Thinking about it i seem to recall that for a while all the hoopla was about VMs that could migrate between hardware to both better utilize existing hardware resources, and allow for more uptime. But then a while later all the buzz was containerization, with Docker as the poster boy. This, i suspect, in that rather than have the overhead of a VM and such, you could spin up a container instance over there, take it dow…

In my context it's because big data became a thing. Nobody wants to pay the virtualization IO overheads anymore.

That said, I've found myself swinging back towards preferring VMs - with docker-like infrastructure made available. The runv project (https://github.com/hyperhq/runv/) is an interesting and functional take on Docker-with-VMs since I spend way too much time wanting to do privileged things in containers.

Re: Docker in Production: A retort

#102

Post by mbesto »

adimitrov wrote: post #77
user5994461 wrote: post #32

Earlier quoted context omitted.

Author from the original article here. >>> * Docker encourages fully disposable infrastructure => I'd consider that incorrect and/or misleading Docker is meant to manage disposable (i.e. stateless) applications. They are expected to be killed/stopped/restarted at any time, no persistent state, no data. An application is either disposable OR not disposable by its design, docker doesn't change that. (For instance, don'…

> For instance, don't try to dockerize databases Host volume mappings. Problem solved. I've been using them for over a year, with all kinds of different databases, postgres, mysql, mongodb, in dev, ci, and production, never had a problem. It gives you a nice separation of what is and what isn't part of the application state, and makes backups a breeze.

Is this what you're referring to?

https://docs.docker.com/engine/tutorials/dockervolumes/

Re: Docker in Production: A retort

#103

Post by notliketherest »

girvo wrote: post #60
emeraldd wrote: post #22

Earlier quoted context omitted.

I can tell you one place I've found them very valuable: development systems. The longer I've been in the field, the more I've learned that polluting my dev box with globally installed tools makes life painful down the road. Docker provides a nice way (especially now that they have docker exec) to spin up environments, or set's of environments with tools/stacks and not touch the host. It's lighter than a bunch of vm i…

Completely agreed. My workplace adopted Docker for local development first, before using it anywhere else. Aside from the "volume mount wiping the `node_modules` folder that was installed in the image but doesn't exist in the host on first boot" problem, it's been an absolute dream. We had some issues with docker-compose for our use-cases, such as persistent database even when recreating every container from scratch,…

Assuming you're also running your db in dockrr, why didn't attaching docker volumes work for you for database persistence ?

Re: Docker in Production: A retort

#104

Post by swsieber »

roblabla wrote: post #75
emeraldd wrote: post #22

Earlier quoted context omitted.

I can tell you one place I've found them very valuable: development systems. The longer I've been in the field, the more I've learned that polluting my dev box with globally installed tools makes life painful down the road. Docker provides a nice way (especially now that they have docker exec) to spin up environments, or set's of environments with tools/stacks and not touch the host. It's lighter than a bunch of vm i…

I find using nix as a package manager to be a better solution. Write a nixfile that have all the tools you need for a script, and you're fixed. Docker is a slow, blunt tool for just containerizing dependencies IMO.

A slow, blunt, cross-platform tool. So while I agree, I don't think nix makes a good replacement for docker.

Re: Docker in Production: A retort

#105

Post by manojlds »

emeraldd wrote: post #22
carapace wrote: post #6

I've never used Docker, or containers, but I read about things like "Breaking changes and regressions ... a well documented problem with Docker" and "Can’t clean old images ... a well known issue" and it just seems to me like a crazy thing to try to use and depend on this thing/company. Bluntly put they seem like children. So nevermind a retort, what I would like to see is a sane, sensible "business value" cost/benef…

I can tell you one place I've found them very valuable: development systems. The longer I've been in the field, the more I've learned that polluting my dev box with globally installed tools makes life painful down the road. Docker provides a nice way (especially now that they have docker exec) to spin up environments, or set's of environments with tools/stacks and not touch the host. It's lighter than a bunch of vm i…

Also for CI in the same vein.

Re: Docker in Production: A retort

#106

Post by girvo »

notliketherest wrote: post #103
girvo wrote: post #60

Earlier quoted context omitted.

Completely agreed. My workplace adopted Docker for local development first, before using it anywhere else. Aside from the "volume mount wiping the `node_modules` folder that was installed in the image but doesn't exist in the host on first boot" problem, it's been an absolute dream. We had some issues with docker-compose for our use-cases, such as persistent database even when recreating every container from scratch,…

Assuming you're also running your db in dockrr, why didn't attaching docker volumes work for you for database persistence ?

Because docker-compose had a very bad habit of destroying and rebuilding the volume-only container, unfortunately! This was of course back when running Docker on macOS was somewhat painful, so mounting the DB data directory directly as a volume into your host would nearly always fail to work successfully due to screwy permissions errors (it's quite a bit better now with Docker for Mac)

So, some dodgy code and a JSON file later, and our team uses the `dup` CLI to run everything with exactly zero hitches thus-far, and we've been using (across it's two incarnations) for... 18 months now?

Re: Docker in Production: A retort

#108

Post by lobster_johnson »

user5994461 wrote: post #61
jfoutz wrote: post #52

Earlier quoted context omitted.

>>> * 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…

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.

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.

Re: Docker in Production: A retort

#109

Post by startling »

user5994461 wrote: post #32
ben_jones wrote: post #7

Earlier quoted context omitted.

As someone considering using Docker for production infrastructure I'd love to hear from a docker expert what their thoughts are on the following observations: * Docker encourages fully disposable infrastructure * Docker containers can be more secure then traditional environments * Docker provides for indempotent environments agnostic of hardware concerns etc * Container management software (Kubernetes, etc.) makes Do…

Author from the original article here. >>> * Docker encourages fully disposable infrastructure => I'd consider that incorrect and/or misleading Docker is meant to manage disposable (i.e. stateless) applications. They are expected to be killed/stopped/restarted at any time, no persistent state, no data. An application is either disposable OR not disposable by its design, docker doesn't change that. (For instance, don'…

> No. Just No. > Docker has nothing to do with security.

Docker can totally reduce the risk of in-container services being exploited. It has sane defaults, and makes it easy to distribute other restrictions with the application (seccomp profile, apparmor settings, etc).

Re: Docker in Production: A retort

#110

Post by lobster_johnson »

corv wrote: post #91

Docker seems very limited when it's unsuitable to run databases. I've never seen this limitation with other container solutions. What is it about Docker that makes it problematic?

Nothing. It's bad advice. Lots of companies run databases in containers.
Post reply on HN