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

61–70 of 132 posts

Re: Docker in Production: A retort

#61

Post by user5994461 »

jfoutz wrote: post #52
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'…

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

Re: Docker in Production: A retort

#62

Post by [deleted] »

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…

[deleted]

Re: Docker in Production: A retort

#63

Post by teabee89 »

shykes wrote: post #45

Docker founder here. I keep reading articles stating that "the Docker API changes with every release", but the assertion is never backed by any specific examples. Has anyone here encountered an actual breaking change? If so, I would appreciate you sharing the specifics so we can fix it. Docker is by no means perfect: - I remember that in 1.10 the switch to content-addressed registries meant that older clients could n…

Maintainer here,

After verifying, I have to rectify your second point: 1.12 DOES NOT BREAK older clients.

To add more information, the issue was present for Docker clients with version 1.9 and older talking to THEN Docker master. Thankfully it was seen before 1.11 was released, and thus we decided to stay on Go 1.5 for Docker 1.11 for this reason.

For 1.12, we added a workaround for this issue, allowing us to upgrade to Go 1.6.

UPDATE: Docker 1.10 was built with Go 1.5 so this issue was not present with a Docker 1.9 client talking to a 1.10 daemon either.

Re: Docker in Production: A retort

#64

Post by web007 »

shykes wrote: post #45

Docker founder here. I keep reading articles stating that "the Docker API changes with every release", but the assertion is never backed by any specific examples. Has anyone here encountered an actual breaking change? If so, I would appreciate you sharing the specifics so we can fix it. Docker is by no means perfect: - I remember that in 1.10 the switch to content-addressed registries meant that older clients could n…

You're missing the fact that docker clients complain about the API version if they're different from the server - regardless of actual compatibility problems.

http://stackoverflow.com/questions/37617400/ sums it up. There's a magic (afaik undocumented) env var DOCKER_APIVERSION you can set for compatibility, but nobody can find it.

If you can't mix even minor versions then yes, it's a problem. I can't run X in prod and anything other than X in dev of I'm working with the same toolset.

Re: Docker in Production: A retort

#65

Post by yawz »

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…

Agreed! So far I've used Docker only on Dev systems. I'm still waiting to be convinced that there's sufficiently higher productivity and value to be had by introducing it to Prod.

Re: Docker in Production: A retort

#66

Post by erikgrinaker »

lobster_johnson wrote: post #55

Re ECR (the EC2 Container Registry), it has one downside that the author doesn't mention, which also applies to Google's own registry. A Docker registry has own authentication system. So does AWS (and GCloud). So what you end up is one wrapping the other: To access the ECR, you have to run an AWS command to get a token to put into "docker login". Google has "gcloud docker login" for the same purposes. Both produce te…

At least with Google's GCR, this is no longer the case. They have a Docker credentials helper [1] which transparently handles authentication for regular interactive use, and service accounts with permanent keys [2] for use with CI servers etc. I find both of these to be fairly straightforward to use.

[1] https://github.com/GoogleCloudPlatform/docker-credential-gcr

[2] https://cloud.google.com/container-registry/docs/advanced-au...

Re: Docker in Production: A retort

#67

Post by [deleted] »

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…

[deleted]

Re: Docker in Production: A retort

#68

Post by yawz »

"The internet has been a wash with a well written article about ..."

Typo: a wash => awash

I know! The content is more important than the quality of the writing, but it's a little surprising to see such a mistake jumping at the reader at the start of an article. We should go back to the first days of the Internet where "updates" were possible. :) I would have loved to suggest an update quickly.

Re: Docker in Production: A retort

#69

Post by user5994461 »

girvo wrote: post #58

As an example of Docker in production: Expedia are moving lots of their legacy infrastructure into Docker containers. My third-party contracting team that works on projects for Expedia (we're brought in so the rules and bureaucracy don't apply to use, allowing us to rapidly iterate and experiment in ways the core teams can't) have been using Docker end-to-end (local development through to autoscaled production deploy…

Short version: Nope :p

Long version: I met the DevOps guy who [I believe] is responsible for pushing Docker at Expedia and we've had long conversations about it.

They were lucky to have had a particular environment and a specific version that worked, and got it pinned down and frozen very early.

I suppose you are on the dev side and not aware of all that. (Hell, maybe, you're not even in the same subsidiary of Expedia). I'm glad it all worked out for you as a dev, my devs are also happy with Docker. (We're probably used as an example of Docker success story at times).

In the end, there is no free lunch. There is dirty work done and more to be done. Some of which is invisible.

Re: Docker in Production: A retort

#70

Post by justincormack »

ben_jones wrote: post #7
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…

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…

* Docker encourages fully disposable infrastructure

Absolutely. You will get the most out of it like this. You can run pets, and treat containers VMs but I don't think you will get all the advantages.

* Docker containers can be more secure then traditional environments

Out of the box you get isolation from namespaces (not being able to see the host filesystem or network), resource limits via cgroups, a default seccomp profile that restricts some system calls that could be used in exploits, and more. You can set all these defaults yourself but the majorty of people do not. So there are definit benefits.

* Docker provides for indempotent environments agnostic of hardware concerns etc

Most applications do not talk directly to hardware, the default container does not directly present hardware interfaces, yes.

* Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better

It does help to have software to manage programs across multiple computers, for scaling and redundancy, yes.

Post reply on HN