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

Docker: The good parts

blog.shrikrishnaholla.in

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Docker: The good parts

#41

Post by 1stop »

shrikrishna wrote: post #7
yachtintransit wrote: post #5

cute headline :) ( at least I think so as a node JavaScript developer ) . all fun aside, I love docker ( and previously vagrant ) as an on demand mobile back end for native iOS and android Dev. it works isolate, disconnected , and can be deployed when I need to stage for reviews . its great !

I am a node js developer as well. That's where I got the idea! :D

Except that Douglas Crockford was talking about Javascript which (at the time that book was published, and perhaps even now) was viewed as a steaming pile of crap. So he wrote a book that highlighted "the good".

Docker is a pretty modern piece of tech, that has very little wrong with it, and seems to work exactly as designed. So you are kind of shoe horning the reference...

Re: Docker: The good parts

#42

Post by shrikrishna »

1stop wrote: post #41
shrikrishna wrote: post #7

Earlier quoted context omitted.

I am a node js developer as well. That's where I got the idea! :D

Except that Douglas Crockford was talking about Javascript which (at the time that book was published, and perhaps even now) was viewed as a steaming pile of crap. So he wrote a book that highlighted "the good". Docker is a pretty modern piece of tech, that has very little wrong with it, and seems to work exactly as designed. So you are kind of shoe horning the reference...

Docker has kinks in its armour as well. There are some pretty irritating issues like #643 and #1171. Anyway, the naming wasn't done with that intention. I agree that the context just isn't the same.

Re: Docker: The good parts

#43

Post by king_magic »

1stop wrote: post #41
shrikrishna wrote: post #7

Earlier quoted context omitted.

I am a node js developer as well. That's where I got the idea! :D

Except that Douglas Crockford was talking about Javascript which (at the time that book was published, and perhaps even now) was viewed as a steaming pile of crap. So he wrote a book that highlighted "the good". Docker is a pretty modern piece of tech, that has very little wrong with it, and seems to work exactly as designed. So you are kind of shoe horning the reference...

While I think the bad parts of Javascript are far more bad than the bad parts of Docker, I think it's fair to call out the good parts of Docker in such a way that the reader walks away and starts thinking "well, okay, but I'm guessing there are some bad parts too - now what are they?".

I'm a pretty smart person; I've poured over the Docker documentation, run through the interactive tutorial twice now, and I still don't have a great sense of 1) what it really is for, 2) how to really use it, or 3) how to handle slightly-non trivial use cases.

For #3, reading through a few examples online of how to get MySQL or Redis up and running in a container... honestly makes my head hurt. And those represent just one or two parts of the system I'm thinking could some day run on Docker - I don't have the time or patience right now to figure out how to get Nginx, Node.js, Redis, MySQL, RabbitMQ, and a few other things here or there - stitched together into a dockerfile.

If I had to make a guess at what the "bad parts" of Docker are, it's that it's complex and not all that understandable - yet. Maybe there aren't that many things that are technically wrong with it, but at this point, it's pretty painful to wrap one's mind around (IMO), and at least I personally think thats a "bad" part.

Docker feels like one of those things that is going to be indispensable and incredibly useful in a year or two. I'm certainly keeping my eye on it, but I'm staying away from the diving board for now.

Re: Docker: The good parts

#44

Post by viraptor »

pgeorgi wrote: post #37
mateuszf wrote: post #33

Earlier quoted context omitted.

Or using a package manager which allows to specify exact versions of the artifacts, like npm or maven.

or apt-get...

For that to work you'd have to have your own repository with all the packages you install. Old specific versions will not be preserved in the upstream repos if a new package is released.

Re: Docker: The good parts

#45

Post by shrikrishna »

1stop wrote: post #39
IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

If run in the same machine, I think it will install the same version every time... won't docker cache the change and just play it back?

not if there is a non-cacheable command like "apt-get update". And if the subsequent command is something like "apt-get nodejs", then potentially two builds can have two different versions

Re: Docker: The good parts

#46

Post by saintfiends »

This maybe slightly OT, but could someone explain what etcd does?. CoreOS hosts containers and an etcd instance run on host (master) and on each container. Is that it?

Let's say I'm on on a VPS and I'm running multiple instances of CoreOS each hosting multiple containers. Can etcd be used in this case?

Re: Docker: The good parts

#47

Post by saintfiends »

This maybe slightly OT, but could someone explain what etcd does?. CoreOS hosts containers and an etcd instance run on host (master) and on each container. Is that it?

Let's say I'm on on a VPS and I'm running multiple instances of CoreOS each hosting multiple containers. Can etcd be used in this case?

Re: Docker: The good parts

#48

Post by justincormack »

shrikrishna wrote: post #42
1stop wrote: post #41

Earlier quoted context omitted.

Except that Douglas Crockford was talking about Javascript which (at the time that book was published, and perhaps even now) was viewed as a steaming pile of crap. So he wrote a book that highlighted "the good". Docker is a pretty modern piece of tech, that has very little wrong with it, and seems to work exactly as designed. So you are kind of shoe horning the reference...

Docker has kinks in its armour as well. There are some pretty irritating issues like #643 and #1171. Anyway, the naming wasn't done with that intention. I agree that the context just isn't the same.

Those are not really Docker issues they are upstream Linux issues. 42 layers of aufs is probably a sane limit, the NFS one looks at a glance like an obscure NFS bug...

Re: Docker: The good parts

#49

Post by shrikrishna »

skrebbel wrote: post #14

Complete off topic nitpick, but reading this font made my head hurt. I didn't manage to read till the bottom, even though I'm interested. Could I suggest a font that has the same x-height for each character?

Changed the theme to CleanPress. Hope it resolves the issue

Re: Docker: The good parts

#50

Post by heavenlyhash »

IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

I've been doing a lot of research lately into more deterministic dependency management and reproducible builds by leveraging hashes via git.

You might be interested in MDM[1], which is a general-purpose dependency manager for binary blobs.

Specifically for container images, you also might be interested in hroot[2] -- it separates the concept of the image and transport out from the containerization system.

I agree wholeheartedly that it's the image permanence that's the interesting part about containers right now. In the last 24 hours I actually had an experience where a docker setup full of apt-get's failed to reproduce an image (new deps were added upstream that broke the system). Fortunately with hroot, I had the exact filesystems I had previously produced in a permanent, transportable system, and all covered by a hash so my production system could fetch exactly the correct version. I could have done this all manually with tars, but that's a pain for nontrivial use cases, and I could have done it with a docker registry, but I'm too much of a security nut to use the public one, and I already have git infrastructure set up, so it's actually easier to use that than try to spin up a private docker registry and secure it, etc.

[1] http://github.com/polydawn/mdm [2] http://github.com/polydawn/hroot

Post reply on HN