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

Microcontainers – Tiny, Portable Docker Containers

iron.io

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Microcontainers – Tiny, Portable Docker Containers

#61

Post by cyphar »

BenjaminCoe wrote: post #41

I believe Alpine is GPL licensed. Curious what companies are using Alpine? What ramifications does this have on the licensing of a micro service running in Alpine.

You can't use the GPL for an entire distribution. You could argue that it's possible to only package GPL-compatible software and sublicense all of it under the GPL. This is impractical because of MPL and LGPL libraries. But even then the distribution isn't under the GPL, so you could inject an "MIT version" of musl and other non-GPL versions of the rest of the software.

tl;dr: That's not how licenses work.

There have been some interesting questions about packaging Ubuntu and their terms of use. I always found their terms of use odd, because they are basically reinstating trademark law inside a software license.

Re: Microcontainers – Tiny, Portable Docker Containers

#62

Post by cyphar »

davexunit wrote: post #33
lucaspiller wrote: post #13

Earlier quoted context omitted.

Docker isn't a VM, so the memory usage should be pretty much on par with chroot. The only difference is shared libraries will need to be duplicated in each container (as nothing is shared) and loaded into memory multiple times, but that should be on the order of a few megabytes.

The duplication is worse than that. It's a data structure problem. Docker deals in opaque disk images, a linear, order-dependent sequence of them. The data structure is built this way because Docker has no knowledge of what the dependency graph of an application really is. This greatly limits the space/bandwidth efficiency Docker can ever hope to have. Cache hits are just too infrequent. So how do we improve? Functio…

> The duplication is worse than that. It's a data structure problem. Docker deals in opaque disk images, a linear, order-dependent sequence of them. The data structure is built this way because Docker has no knowledge of what the dependency graph of an application really is. This greatly limits the space/bandwidth efficiency Docker can ever hope to have. Cache hits are just too infrequent.

This is only true when you're building your images. Distributing them doesn't have this problem. And the new content-addressability stuff means that you can get reproducible graphs (read: more dedup).

> So how do we improve? Functional package and configuration management, such as with GNU Guix. In Guix, a package describes its full dependency graph precisely, as does a full-system configuration. Because this is a graph, and because order doesn't matter (thanks to being functional and declarative), packages or systems that conceptually share branches really do share those branches on disk. The consequence of this design, in the context of containers, is that shared dependencies amongst containers running on the same host are deduplicated system-wide. This graph has the nice feature of being inspectable, unlike Docker where it is opaque, and allows for maximum cache hits.

For what it's worth, I would actually like to see proper dependency graph support with Docker. I don't think it'll happen with the current state of Docker, but if we made a fork it might be practical. At SUSE, we're working on doing rebuilds when images change with Portus (which is free software). But there is a more general problem of keeping libraries up to date without rebuilding all of your software when using containers. I was working on a side-project called "docker rebase" (code is on my GitHub) that would allow you to rebase these opaque layers without having to rebuild each one. I'm probably going to keep working on it at some point.

Re: Microcontainers – Tiny, Portable Docker Containers

#63

Post by cyphar »

_Marak_ wrote: post #17
lisivka wrote: post #14

Earlier quoted context omitted.

Your assumptions are wrong. Glibc is faster (and better) than musl. Systemd is faster (and better) than SYSV init scripts. Moreover, for example, I can update my running containers based on Fedora 23 without restarting container, by issuing "dnf update", which will download updated package from local server, which is much faster that to build container, publish it to hub, download it back, restart container (even whe…

So the overhead of using Docker is still to great. Thanks for the information.

Docker has very little overhead (apart from all of the setup required to start a container). In principle it has no overhead, but Linux memory accounting has implicit memory overhead (this is a kernel issue, not a Docker issue).

Re: Microcontainers – Tiny, Portable Docker Containers

#64

Post by cyphar »

jorgecurio wrote: post #19

how are you guys using docker btw? I keep hearing about it, I like it but have almost to no reason to use it.

You can use it to run desktop apps if you're as anal as me about having a clean host machine. I also use it to run all of my small services (my website, IRC bouncer, etc).

Re: Microcontainers – Tiny, Portable Docker Containers

#65

Post by TheDong »

cyphar wrote: post #57
TheDong wrote: post #5

Earlier quoted context omitted.

There's also a very good reason to not move some things to alpine, including ruby and node applications. A significant number of ruby and nodejs apps depend on some c/c++ code hidden away in this module or that gem. Any time you're compiling c/c++ code, you run into a chance of musl vs libc causing differences. These differences can range from building requiring different options to the application having strange per…

One solution would be to have a "build" image that produces your binary or set of packages you need and then a "service" image that actually runs it.

In general, I agree with this, but it specifically doesn't help with issues where glibc vs musl matters.

Either your build image's libc (musl in this case) is statically linked in and you have the aforementioned issues, or it's not statically linked and your binary won't run. Most things compiled within an ubuntu container won't run in an alpine one; you specifically have to go out of your way to make that so.

Re: Microcontainers – Tiny, Portable Docker Containers

#66

Post by wcummings »

_query wrote: post #54
wcummings wrote: post #26

Earlier quoted context omitted.

Surprised he advertises his age, I started working around that age and pretty deliberately avoided age as a topic of discussion. Age is something best left unmentioned in a professional context.

Thanks for the advice. I've thought about it a little bit and decided to remove it with my next update to the web page.

You don't have to, but it will help avoid a lot of snark as well as well-intentioned but annoying jokes (like the babel dev described), not to mention less visible discrimination like being passed over for promotions, being given worse projects and so on.

There are also programmers whose pride is damaged by doing the same work as someone much younger than themselves.

Remember (at least in the US) age is a protected category and you can't be asked about it during an interview, so if you're careful about how you write your resume no one really has to know exactly how old you are.

Good luck.

Re: Microcontainers – Tiny, Portable Docker Containers

#67

Post by grkvlt »

tmd wrote: post #28

Docker storage engines remember all the layers by storing incremental differences so it makes little sense to have a layer that only removes things (like the last RUN in https://github.com/iron-io/dockers/blob/master/ruby/Dockerfi... ). You can see with `docker history ` that this layer has 0 bytes and you can access anything that it removes by using the parent image (`docker run -it 88ae7e32865f ls /var/cache/apk`).…

Heh, looks like the author fixed this [1] and it now uses the technique you suggest, based on issue #22 [2] which restates the same thing as your comment, basically chaining everything together with `&&` in a single `RUN` entry.

[1] https://github.com/iron-io/dockers/commit/71687edb849dcb9079... [2] https://github.com/iron-io/dockers/issues/22

Re: Microcontainers – Tiny, Portable Docker Containers

#68

Post by mstade »

_query wrote: post #54
wcummings wrote: post #26

Earlier quoted context omitted.

Surprised he advertises his age, I started working around that age and pretty deliberately avoided age as a topic of discussion. Age is something best left unmentioned in a professional context.

Thanks for the advice. I've thought about it a little bit and decided to remove it with my next update to the web page.

I'd love to say it's not sage advice, but it is. Unfortunately, once people know your age they will – consciously or subconsciously – treat you differently. I rather quickly opted to never disclosing my age in any context, unless it is absolutely necessary (it almost never is.) It's just easier that way, leads to less discrimination. Unlike skin color or other highly visual traits, it's one aspect of your person you can hide without any significantly negative consequence.
Post reply on HN