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

81–90 of 132 posts

Re: Docker in Production: A retort

#81

Post by gerdesj »

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

It's great for development if it wasn't 4 to 5 times slower on Mac: https://www.reddit.com/r/docker/comments/59u1b8/why_is_docke...

(Having read the Reddit thread for a while)

Macs don't appear to have support for containers which is what Docker is. Well that is probably bollocks because they are *BSD based and I know that FreeBSD at least has a form of containerization and I seem to recall that the whole container thing was invented on a BSD - "jails".

So Docker can't run native on iStuff. You have to run it within a Linux VM. I gave up on Googling for "apple mac jail" 8)

The reason why Docker runs slowly on Macs is because it is running under emulation within a VM.

Unfortunately, Macs are not cool enough to run Docker, so there 8)

Cheers Jon

Re: Docker in Production: A retort

#82

Post by web007 »

teabee89 wrote: post #71
web007 wrote: post #64

Earlier quoted context omitted.

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

The issue you are referring to happens only if the docker client version is newer than the docker daemon version. In the case where the client is older than the daemon, it has always worked. Thanks for bringing this issue up though, because we are currently working on a fix. Here is the PR: https://github.com/docker/docker/pull/27745 As for DOCKER_API_VERSION, it is possibly not well documented, but it is indeed pres…

The client will nearly always be newer, so that message will almost always show up. You'll update your laptop tools regularly, and only bump your infrastructure occasionally.

How many versions has this been a problem? It's not thinking about things like this until (apparently) 11 days ago that give Docker haters such ammo. The UX of the entire ecosystem feels like an afterthought. Yes, it's been evolving rapidly, but that's no excuse for not having a good, unified user experience for what's there or what's coming next.

Re: Docker in Production: A retort

#83

Post by DrNemski »

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…

Hi There,

I created an account here so I could let you know I've clarified some points in my post to address your concerns.

Re: Docker in Production: A retort

#84

Post by DrNemski »

yawz wrote: post #68

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

My googling failed on this account on the correct grammatical term.

Re: Docker in Production: A retort

#85

Post by jsz0 »

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…

> seems to me like a crazy thing to try to use and depend on this thing/company

Always beware of perception bias or whatever the right term is for this. When docker was new it got tons of hype and people were talking about how great it was. Now it's no longer the hot new thing so it's just another tool many people are using quietly and successfully. It no longer warrants much positive discussion. The people using docker in production successfully don't feel compelled to write articles about it working for them.

I'd say the pros/cons of docker (or containers in general) are similar to the pros/cons of buying hand made vs. mass produced goods. The hand made goods will probably be higher quality but they take more time and skill to produce so they're more expensive. The mass produced goods will probably be lower quality but will work fine and at least offer consistent/reliable level of quality. They take less time and skill to produce so they'll also be less expensive. In the context of using Docker in production this translates to it being very good for solving 'off the shelf' types of problems quickly and reliably. It's essentially the software/systems version of an assembly line. If you don't need an assembly line then docker may be worthless or even a total waste of time. If you do need an assembly line it's the best option currently.

Re: Docker in Production: A retort

#86

Post by quickben »

fh973 wrote: post #26
otterley wrote: post #8

Earlier quoted context omitted.

What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't…

A good reason for running a database in a container is fault tolerance without setting up database replication. Put your database in a container, let it store its data on a network storage system (like a distributed file system). The container scheduler makes sure it gets rescheduled when the node goes down.

And then the NFS handle goes stale, and the fun begins.

Re: Docker in Production: A retort

#87

Post by quickben »

CSDude wrote: post #48
dozzie wrote: post #39

Earlier quoted context omitted.

> Less downtime and automatic recovery, I'd say. How? By magic dust sprinkled by Docker Inc? > When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would. You seem to forget that a) container's filesystem needs to be downloaded in the first place, and b) that VMs can work in a standby mode, not running the serv…

Its faster virtual machines, which do not have live migration for that specific use case. Just because you are doing it for years does not mean that it cannot be improved or have an alternative with its both downsides and upsides.

You do not want a 'downside' with any database. Especially when big money are involved, people are shown the door for far lesser issues than the ones that docker seems to have.

By the way, you still haven't answered his question.

Re: Docker in Production: A retort

#88

Post by fapjacks »

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.

Right. This "don't Dockerize databases" thing is truly just bizarre. It almost in a way seems intentionally antagonistic to make Docker seem less capable than it is. After all, who wants to use something that only works for some applications? And the fact of the matter is that Docker is just a fancy way to run a process. Bind-mounted host directory volumes are one of the most fundamental features available for Docker. The truth of the matter is that Docker can be a complex beast. And what ends up happening is that often people only understand a small part of Docker features they're using. And then they complain about problems with Docker when what they really need to do is go read the documentation. Not all problems with Docker are like this, of course, but the vast majority of complaints that I see (and I see a lot of them from being part of the open source community for over three years now) come from people that don't fully understand the features of Docker they're trying to use. Getting Docker going is dead simple, and people fall into the trap of thinking that's all there is, when Docker is a damn deep technical subject.

Re: Docker in Production: A retort

#89

Post by girvo »

user5994461 wrote: post #69
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 Expedi…

Sorry if I didn't explain it correctly!

We're an external team (completely seperate to Expedia) that is brought in to build certain products :)

And yeah, definitely. I spent a couple weeks debugging the ECS issues we had with the Wotif guys, which was fun, but none of the issues were insurmountable!

We were one of the first adopters for the new ECS deployment, and while some parts of it weren't fun (Splunk still drives me mental) for the most part it went smoothly: that's down to how good the ops team is, I think.

Our specific case was somewhat special, in that because we're outside of the rest of the infrastructure, and had extensive experience with Docker in production for other clients, our apps were basically ready to rock from the get-go. I think we were the first PHP deployment within the new ECS deployments!

Should send me an email, it's in my profile, would love to chat sometime!

Re: Docker in Production: A retort

#90

Post by fapjacks »

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.

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

Post reply on HN