Hacker News Reader

Comment by sandGorgon | Hacker News Reader

The fact that we had a weird combination of python and libraries took us towards Docker. And we have never looked back.

For someone trying out building python deployment packages using deb, rpm, etc. I really recommend Docker.

They specifically called that out in the article with an entire section called "just use docker".

To be fair, what didn't work for Nylas might well not be an issue for others. There's definitely more than one way to skin a cat, especially in the Python world.

Seriously, their #1 reason for not using Docker amounts to "we couldn't be bothered to update our kernel." This reads to me more of an interesting story about how they chose to solve the problem rather than a serious recommendation of how things should be done.

I don't think that's a fair representation of why they don't want to update kernels and also completely downplays that there were three other points mentioned which all added non trivial overhead to getting stuff done now.

In an ideal world you build a system from the ground up, but rarely is that ever possible and the approach taken to iterate is far more valuable than your requested 'serious' recommendation.

Seriously, your #1 complaint about their reasons not to use Docker amounts to "I couldn't be bothered to read past the first dot point".

On the same vein as omni, the other reasons are "we don't want to learn a new technology, even though it was made exactly for this purpose" and "we don't want to learn how to install docker-registry."

if you have to choose between a kernel and docker, just choose docker. Python can't get their shit together deployment-wise, and docker is the one true route (tm) to python deployment happiness.

forget virtualenv; forget package dependencies on conflicting versions of libxml; forget coworkers that have 3 different conflicting versions of requests scattered through various services, and goddamnit I just want to run a dev build; forget coworkers that scribble droppings all over the filesystem, and assume certain services will never coexist on the same box

just use docker. It's going to go like this:

step 1: docker

step 2: happy

Ha. Wait until you need to run a build of shared Perl codebase against unit tests in all of the dependent codebases... but some of those codebases compile and run C (or C++) programs... and some of those codebases depend on conflicting versions of GCC!

"If we hit the bullseye, the rest of the dominos will fall like a house of cards... checkmate!" -- Zap Brannigan

> forget coworkers that scribble droppings all over the filesystem, and assume certain services will never coexist

I think this tends to be less of a problem than the desire to have a build artifact that can be reliably deployed to multiple servers, rather than having the "build" process and "deploy" process hopelessly intertwined with each other.

We love Docker where I work, but running it in production is a big challenge — there's no "just" using it. We build packages of Rails apps and dependencies quite happily. Sure, you have to make sure all dependencies are packaged too, but that's still easier than a full-on Docker roll-out.

Indeed, we actually use Docker to build packages. Blog post coming soon, maybe.

In a few months Cloud Foundry will natively support launching, placing, managing, wiring, routing, logging and servicing Dockerised application images.

In the meantime you can get a taste with Lattice[0].

[0] http://lattice.cf/

There was a whole paragraph in the article about why Docker didn't work for them.

they had 3 reasons:

one of which was just silly (kernel version -- are you living on that point release forever?)

one of which was valid (necessity to maintain method for distributing docker images), but probably dumb: you only get so many innovation points per company, and innovating on a problem docker just solves means you are supporting your in-house solution ad infinitum

and one of which definitely sounds painful (docker vs extant ansible playbooks)

The 3.2 kernel they mention is the standard kernel of Ubuntu 12.04. I have some docker machines of the same vintage, and it's as simple as installing a backported kernel from the official repos.

This being said, I'm using docker for packaging/deployment of a nodejs app on those machines, and I hate it. I'm about to strip it out and go for .debs. Docker brings a lot of baggage with it, and requires major restructuring of some infrastructure parts. As they say in the article, the changes required to bring docker in just to do packaging are way too heavy. And Docker also sucks for rollbacks, to be honest - their tagging system is downright terrible.

My advice is not to use Docker in a production environment unless you can articulate the specific pain points it will solve for you.

Agreed on the rollback part.

It is easy to pick the silliness of the kernel reason, but Docker is moving fast right now. They are still getting the basic building blocks in place, and the Docker in two years will look nothing like today's.

We use Docker quite a bit today, but it's immature and it shows. With Composer I feel the basic functionality is finally in place it needs time to mature.

So I think it's quite wise to wait. You don't need to chase every new technology. If you have a product to ship, focus on that instead and use whatever tools are proven to work.

    sudo apt-get install linux-generic-lts-quantal

Reply on news.ycombinator.com