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

11–20 of 68 posts

Re: Microcontainers – Tiny, Portable Docker Containers

#11

Post by _query »

> Docker enables you to package up your application along with all of the application’s dependencies into a nice self-contained image. You can then use use that image to run your application in containers.

Actually docker was created to enable easy scaling of web applications. If you want to package your application up take a look at some modern package managers. By using a modern package manager like nix you can work around the issues of containers while still keeping the "it just works" advantage of containers.

This does not mean that containers are bad, it's just that using a good package manager is usually a simpler solution.

Take a look at my blog post if you want to read more on this: http://www.mpscholten.de/docker/2016/01/27/you-are-most-like...

Re: Microcontainers – Tiny, Portable Docker Containers

#12

Post by AstroJetson »

lox wrote: post #3

Do we really need to brand using smaller containers as microcontainers? Why not submit these as pull requests to the official docker images rather than introducing more fragmentation? Also worth noting that the official docker images are moving towards alpine. Of course if you have ruby or node apps your biggest space hog is still going to be your packages.

I agree, they are still docker images, they have less stuff inside. I didn't know about Alpine, so I'm going to start down that path. Working on Lua based applications, hoping to see if Alpine will work.

Re: Microcontainers – Tiny, Portable Docker Containers

#13

Post by lucaspiller »

_Marak_ wrote: post #8
TheDong wrote: post #4

Earlier quoted context omitted.

... Why? The scalability difference (in terms of disk space) between having multiple services per container and many containers is, in practice, zero. That's because of layered filesystems and most of the language runtimes and other images pulling from a small set of base images. For example, if you have two node applications, the base "nodejs" image is 633MB in size. If both of your applications have "FROM node" at…

I would assume the smaller images would also result in a smaller memory footprint for running the images and a general reduction in time of starting images. You seem to know a lot of about Docker, is that a wrong assumption? The scale which I'm discussing is in the order of at least several hundred docker images per second. Previous attempts at making this work involved keep a warm elastic pool of Dockers. I'm workin…

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.

Re: Microcontainers – Tiny, Portable Docker Containers

#14

Post by lisivka »

_Marak_ wrote: post #8
TheDong wrote: post #4

Earlier quoted context omitted.

... Why? The scalability difference (in terms of disk space) between having multiple services per container and many containers is, in practice, zero. That's because of layered filesystems and most of the language runtimes and other images pulling from a small set of base images. For example, if you have two node applications, the base "nodejs" image is 633MB in size. If both of your applications have "FROM node" at…

I would assume the smaller images would also result in a smaller memory footprint for running the images and a general reduction in time of starting images. You seem to know a lot of about Docker, is that a wrong assumption? The scale which I'm discussing is in the order of at least several hundred docker images per second. Previous attempts at making this work involved keep a warm elastic pool of Dockers. I'm workin…

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 when only static files are changed).

Re: Microcontainers – Tiny, Portable Docker Containers

#15

Post by pea »

_query wrote: post #11

> Docker enables you to package up your application along with all of the application’s dependencies into a nice self-contained image. You can then use use that image to run your application in containers. Actually docker was created to enable easy scaling of web applications. If you want to package your application up take a look at some modern package managers. By using a modern package manager like nix you can wor…

Yes, layering is somewhat of a hack to get around the fact that most OS package managers are mutable. IMO nix / guix have a much better approach here.

Re: Microcontainers – Tiny, Portable Docker Containers

#16

Post by cdnsteve »

lox wrote: post #3

Do we really need to brand using smaller containers as microcontainers? Why not submit these as pull requests to the official docker images rather than introducing more fragmentation? Also worth noting that the official docker images are moving towards alpine. Of course if you have ruby or node apps your biggest space hog is still going to be your packages.

Agreed. Docker was suppose to inherently be about small containers. Vendors just choose to use the largest Linux base image out there.

Re: Microcontainers – Tiny, Portable Docker Containers

#17

Post by _Marak_ »

lisivka wrote: post #14
_Marak_ wrote: post #8

Earlier quoted context omitted.

I would assume the smaller images would also result in a smaller memory footprint for running the images and a general reduction in time of starting images. You seem to know a lot of about Docker, is that a wrong assumption? The scale which I'm discussing is in the order of at least several hundred docker images per second. Previous attempts at making this work involved keep a warm elastic pool of Dockers. I'm workin…

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.

Re: Microcontainers – Tiny, Portable Docker Containers

#18

Post by sandGorgon »

lisivka wrote: post #14
_Marak_ wrote: post #8

Earlier quoted context omitted.

I would assume the smaller images would also result in a smaller memory footprint for running the images and a general reduction in time of starting images. You seem to know a lot of about Docker, is that a wrong assumption? The scale which I'm discussing is in the order of at least several hundred docker images per second. Previous attempts at making this work involved keep a warm elastic pool of Dockers. I'm workin…

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…

whoa - you have a container with working systemd ? I thought that was an unfixed bug - https://github.com/docker/docker/pull/5773 and https://github.com/docker/docker/issues/3629

Re: Microcontainers – Tiny, Portable Docker Containers

#20

Post by lisivka »

sandGorgon wrote: post #18
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…

whoa - you have a container with working systemd ? I thought that was an unfixed bug - https://github.com/docker/docker/pull/5773 and https://github.com/docker/docker/issues/3629

Yep. It have some quirks (hard to shutdown properly), but it works.

    [vlisivka@apollo5 docker-centos7-systemd-unpriv]$ ./enter.sh
    [root@e3c3dd7539ad /]# ps ax
    PID TTY      STAT   TIME COMMAND
        1 ?        Ss     0:00 /usr/lib/systemd/systemd
       71 ?        Ss     0:00 /usr/lib/systemd/systemd-journald
       74 ?        Ss     0:00 bash
       92 ?        R+     0:00 ps ax
https://github.com/vlisivka/docker-centos7-systemd-unpriv
Post reply on HN