Live data from Hacker News

Docker in Production: A retort

patrobinson.github.io

71–80 of 132 posts

Re: Docker in Production: A retort

#71
post #64
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 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 present in the documentation: https://docs.docker.com/engine/reference/commandline/cli/

Hopefully this was helpful.

Re: Docker in Production: A retort

#72

Earlier quoted context omitted.

The same as all my other software? Is this your first time working with it?

You didn't answer any of the questions expect the one about frequency. I'm left to assume that your usage is so irrelevant or your user base so small that you haven't needed to spend time thinking really hard about operational difficulties, SLAs, or calculating risk tolerance relative to value. Or gotten yourself into trouble yet which every DBA/SRE of a database of substantial size gets into eventually.

I didn't say exactly how frequently, just that it's the same with my database as other software.

Re: Docker in Production: A retort

#73
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…

Oh, hai there. I haven't gone 'whole hog' on Docker yet and subsequently tried to push for rolling it out in production for my team. I don't know how incorrect I am, but it seems like the Docker project is more interested in features rather than stability. Except, like you said, I don't have any specific examples to back that up. Maybe it's just community hive mind thought bleeding onto my decision making abilities?…

"but it seems like the Docker project is more interested in features rather than stability."

I think that is a fair dig but I think they are still exploring the limits of what it can do. They are following the path of release often and make changes and show your working really well - you get to see the code and can contribute yourself.

The thing is that you have to take all that into account when you are using their product. You need to take an Engineering approach to "production". Use Docker in the way that works for you. You state that you ended up using Arch instead of Windows or Mac - so fine, you have constructed a tool chain that works for you and welcome aboard! You see, Windows and Mac also do odd things every now and then but you don't get to see the workings.

You are clearly not daft - you use Arch. I run Arch (my wife's laptop), Gentoo (my laptop and a fair few mail proxies and Icinga instances and other things), a lot of Ubuntus and a slack handful of Kalis and a sprinkling of Debians, Centos and others.

You need to use engineering principles when going to production. Also you have to look at the price you paid to use Docker - it's a purely social one but one that is extremely important and may not involve money but cost you a fortune anyway. You need to decide if you want to pay that cost.

You are clearly someone who understands the open source methodology but I would suggest that you look a little deeper into the dev -> prod thing. There is no reason why dev = Docker => prod = Docker. That's something that only you can decide after careful testing.

Cheers Jon

Re: Docker in Production: A retort

#74
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…

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

Re: Docker in Production: A retort

#75
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…

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.

Re: Docker in Production: A retort

#76
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 think old school sysadmins care way more about system stability and new school devops guys are focused on cost and the speed of the development cycle. It really doesn't matter if you architect your systems properly that docker is unstable or your services crash as long as you have effective monitoring and self healing systems.

I'm both or rather I do things like this:

* Use modern tools to spin up a dev env * Determine how to monitor and maintain dev and deploy * Test dev env * Determine, based on dev and a deep risk assessment how prod will look * Create prod env * Determine how to monitor and maintain prod env and deploy (based on your test) * Test new prod env * Open up prod env to end users

It's not bloody rocket science - it's Engineering and the steps above hide loads of steps and feedback loops such as a safe upgrade method eg snapshot/clone VM, test, release.

If your product is important to you then you take it seriously and treat it right!

Cheers Jon

PS Did I mention documentation?

Re: Docker in Production: A retort

#77

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

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

Re: Docker in Production: A retort

#78

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

> don't try to dockerize databases

Why ever not? There no less reason to do so in a container - and all the usual benefits still apply.

Re: Docker in Production: A retort

#79

I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'.... That says all you need to know about the trustworthiness of Docker. EVEN DOCKER PROPONENTS caution against using it in 'important' apps.... What apps are people investing time in that aren't 'important'? Is there a coffee machine that is ok to use for a docker app somewhere?

I interpret that as don't use X (in this case Docker) with your most essential services. Initially. Get your teeth cut, make some mistakes, establish routines, etc with your internal apps, your low traffic services, etc. Be patient, then once comfortable and confident your start to roll it out to your core, heavily integrated services in production.

Having just come off a year at large(very large) government department that have 100s of core services running in Docker in production, I think the tech is ready, but not sure if every company is ready.

Re: Docker in Production: A retort

#80
post #74

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

Still feels several times faster than using an option like Vagrant. (haven't found a container that didn't cold start in less than 5 seconds; 3+ minutes for common Vagrant setup is pretty common)
Post reply on HN