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

Building Good Docker Images

jonathan.bergknoff.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Building Good Docker Images

#61

Post by drdaeman »

shykes wrote: post #56
WestCoastJustin wrote: post #42

Earlier quoted context omitted.

I thought there was a way to enter a namespace (googled this as I write the comment). Basically you have your shell and debug bits outside the container and make it appear as if it was inside it via nsenter [1]. I have not tested this, but will do that in a second. This might correct the situation you are thinking of. +--------------------+ | docker container | | w/ static bin | | [1] http://www.kevssite.com/2014/08/…

As of Docker 1.3 you can simply 'docker exec' :)

He is actually talking about the case where bash binary (or gdb or whatever you're going to exec) does not exist in container. So the hassle of loading bash from the parent, then moving the process into container's namespace with nsentry.

So, nope, docker exec just wouldn't work.

Re: Building Good Docker Images

#62

Post by masklinn »

mnarayan01 wrote: post #43
23david wrote: post #19

One additional tip for readability is to replace the && with set -e at the top of any RUN commands that combine more than one command. before: RUN curl -SLO "http://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.gz" \ && tar -xzf "node-v$NODE_VERSION-linux-x64.tar.gz" -C /usr/local --strip-components=1 \ && rm "node-v$NODE_VERSION-linux-x64.tar.gz" after: RUN set -e; \ curl -SLO "http://nodejs.org/d…

Why?

Because it's more readable? It tells you at the top that any failure will fail the whole thing, and you can avoid the prefix `&&` which reduces the effective indentation level and noise.

Re: Building Good Docker Images

#63

Post by YokoZar »

digisign wrote: post #31
pit wrote: post #4

"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.

Depends on which Debian I believe, but Ubuntu doesn't update their package versions beyond security fixes within a single distro version. So you'll generally want those fixes, unless they really broke something, which I'd guess would be somewhat rare.

Ubuntu also issues stable release updates (particularly to the latest LTS version) to fix regressions, major bugs, or occasionally update minor release versions. Some applications known to have good release procedures are also allowed updates (eg Firefox).

Re: Building Good Docker Images

#64

Post by driverdan »

> Pin package versions

This is true for any packages you use, not just Docker. For example, rails gems. If you don't pin them your app will break at some point on an update. Always manually update packages and test before deploying.

Re: Building Good Docker Images

#65

Post by mnarayan01 »

masklinn wrote: post #62
mnarayan01 wrote: post #43

Earlier quoted context omitted.

Why?

Because it's more readable? It tells you at the top that any failure will fail the whole thing, and you can avoid the prefix `&&` which reduces the effective indentation level and noise.

You can use the same spacing for the ampersands as used for the semicolons (i.e. at the end of the line).

That said, obviously there's going to be different preferences...I was more wondering if there was some semantic difference.

Re: Building Good Docker Images

#66

Post by masklinn »

mnarayan01 wrote: post #65
masklinn wrote: post #62

Earlier quoted context omitted.

Because it's more readable? It tells you at the top that any failure will fail the whole thing, and you can avoid the prefix `&&` which reduces the effective indentation level and noise.

You can use the same spacing for the ampersands as used for the semicolons (i.e. at the end of the line). That said, obviously there's going to be different preferences...I was more wondering if there was some semantic difference.

> You can use the same spacing for the ampersands as used for the semicolons (i.e. at the end of the line).

Then if the lines are long (as they are here) they get cut off and it's much harder to notice that they're there at all.

Re: Building Good Docker Images

#67

Post by zenlikethat »

jaswilder wrote: post #40
zenlikethat wrote: post #34

Earlier quoted context omitted.

Perhaps I'm missing something, but I don't see how [1] can be used to create "single binary containers with the minimal OS bits needed"? It is from https://registry.hub.docker.com/u/google/nodejs/dockerfile/ and uses the full Debian stack that you discuss including apt-get etc. I've heard whisperings on the wind of research being done with respect to monitoring what files a Docker container uses, and then removing ev…

I wrote https://github.com/jwilder/docker-squash to remove things that I know I don't need in the final image such as curl, wget, temp files, various packages, etc.. I've managed to get most images to basically the size of the base image + my app. This process is sort of the reverse of building a single binary and adding it to a minimal image. I like that approach but it's not always straightforward w/ some applicati…

Ah yes, I've played with docker-squash and like it, I wish there was a built-in docker solution for squashing layers (perhaps any contiguous string of instructions starting with ~ would be squashed into one layer?).

Mostly the problem I've run into is figuring out what to remove without b0rking the containerized app.

Re: Building Good Docker Images

#68

Post by shykes »

drdaeman wrote: post #61
shykes wrote: post #56

Earlier quoted context omitted.

As of Docker 1.3 you can simply 'docker exec' :)

He is actually talking about the case where bash binary (or gdb or whatever you're going to exec) does not exist in container. So the hassle of loading bash from the parent, then moving the process into container's namespace with nsentry. So, nope, docker exec just wouldn't work.

You're right, we're still missing dynamic volume mounts to do the same thing in Docker. My bad.

Re: Building Good Docker Images

#69

Post by pierreozoux »

jbergstroem wrote: post #39

I think this is a case where gentoo can really shine. Although tooling might not be there just yet, the linux meta distribution allows you to build a strict set of dependencies based on what you need and nothing else. There's already been pretty successful attempts at this, such as https://github.com/edannenberg/gentoo-bb (63mb custom nginx sound ok to you?) or https://github.com/wking/dockerfile . edit: To elaborate…

Thanks for the pointer. I've been thinking about this kind of scheme: - using a vanilla gentoo - install portage - emerge my package - at the end, do a diff of the filesystem to apply it to the vanilla gentoo.

And using docker filesytem feature for that. I'm still quiete new to Docker and don't know if it is easy to do.

But I'll have a look to gentoo-bb, I think it is exactly what I need!

Re: Building Good Docker Images

#70

Post by pit »

sp332 wrote: post #5
pit wrote: post #4

"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.

Why do an update if you prefer your packages to be pinned?

I hadn't even thought of pinning packages before I read the article; I'm kind of a sucker for apt-get update. I've been thinking a lot about Docker lately, and something in the back of my mind was like, "but what if you don't want the latest version of everything?"
Post reply on HN