Microcontainers – Tiny, Portable Docker Containers
iron.io
iron.io
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...
Citation? From my perspective, most of the features you'd need to do that appeared around 2 years into Docker's life.
[0]: https://en.wikipedia.org/wiki/Docker_(software)#History
> About the author > Hey! I’m Marc, an eighteen years old software engineer located in Germany.
You're obviously quite knowledgeable and well spoken for such a young age, and presumably English isn't your first language either. I just wanted to say keep up the good work, you have a bright future ahead of you – kudos!
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.
I just sent you a private email.
In this case it doesn't make much difference (a couple of MB perhaps) but often you'll see people chaining all the commands and ending it with a cleanup in a single RUN like here: https://github.com/docker-library/ruby/blob/ccbf9e54f60ba245...
[1] https://github.com/iron-io/dockers/commit/71687edb849dcb9079... [2] https://github.com/iron-io/dockers/issues/22
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.
These differences can range from building requiring different options to the application having strange performance characteristics to random crashes (rare!).
In addition, people who write these modules typically test against an ubuntu or debian system, so those are much safer bets. Alpine makes no serious attempt to match packages with those, either in breadth nor version.
It really isn't feasible to unilaterally move people, and for compatibility reasons Docker does not often change tags in such a drastic way.
The official docker images are often offering alpine alternatives in different tags, which is not the same as "moving towards" as you remarked.
[1] http://git.musl-libc.org/cgit/musl/commit/?id=3d6e2e477ced37...
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.
When you get right down to it a window is a virtualization of a screen, a packet switching network is a virtualization of a fixed line, a process is a virtualization of a CPU, etc. (I can't remember who I'm quoting).
The direction this is all heading (VMs, containers, unikernels, etc.) feels like confirmation of this to me. A series of corrections aligning our OSes with more ideal/virtual abstractions.
[1]: https://github.com/iron-io/dockers/blob/master/base/Dockerfi...
Past experiments proved that it wasn't feasible to match one microservice request to one Docker instance. The size of each Docker required vertical scaling of the microservices per container, which was not ideal.
Good job Iron.io! Might trying playing with these at some point.
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 the top and proceed to add different applications (say 2MB each), you'll find the "node" portion is totally shared and only the diff, you copying in your application's files, is different. You'll only store a single copy of the 633MB node image + your two application image's diffs, for a total of 637MB.
That number is the same if you bundle the applications (vertically scale as you say it).
This is also sorta true across language runtimes too! With some creative diffing, I experimentally tested the difference between the ruby and nodejs images. It turns out there's just under 600MB in common. The ruby image has 116MB of data the node one doesn't, and the node one has ~40MB of data the ruby one doesn't.
Again, you'll end up using a very small amount of disk space.
These savings also apply to downloading images after the initial base layers are downloaded (e.g. docker pull ruby; docker pull node will only download roughly 750MB of data, even though that's two >600MB images).
In any case, it's strange that disk space on the order of a couple gigs is even a scaling concern at all; I'd imagine memory or your application's disk needs would far outweigh such concerns.
My main point, however, is that your discussion of one service per container vs multiple services per container being any different in terms of disk space is rubbish and utterly false.
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 working with at least 11 environments, ( which all have separate dependency requirements ).
Instead of trying to manage a very large pool of Dockers, I opted for a smaller pool with several larger servers to scale the microservices vertically ( using tools like chroot to help try to isolate each service per silo ).
My main issue with using Docker for this was the bulk of the containers. Startup time, RAM consumption, and the size of the images were all causing me issues.
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.
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.
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).
Thanks for the information.
[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
Faster is objective, and in most cases correct. Glibc has a lot mor optimization over the years. Better is subjective and completely depends on your use case:
http://www.etalabs.net/compare_libcs.html
Similar point to systemd, it is kind of misleading to say that it's faster, it is parallel and event driven, which definitely makes it's end to end time shorter on parallel hardware. And again better is subjective, it's so much more complex that it might not always be the right choice.
Also, why use systemd inside a container at all? There's just one process in there usually.
Besides that, for an application only the licenses of libraries that you link against are relevant.
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.
We ditched Heroku + S3 for dev/test/staging branches (if your app can be expressed in a docker-compose.yml file you can get a server up with the command `b3cmd server-scaffold`)
Many small tools for random workflows