31–40 of 68 posts
how are you guys using docker btw? I keep hearing about it, I like it but have almost to no reason to use it.
> 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…
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…
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.
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.
how are you guys using docker btw? I keep hearing about it, I like it but have almost to no reason to use it.
Amongst other things I use it to run Skype on my Linux laptop, cos I don't trust Microsoft. https://github.com/sameersbn/docker-skype
I have to say I love the work iron.io does. Their "iron worker"[1] service is awesome (think Amazon Lambda for pretty much any common language). [1] http://www.iron.io/worker/
Interesting. How long does it take an "iron worker" to start code execution after a webhook (latency)?
how are you guys using docker btw? I keep hearing about it, I like it but have almost to no reason to use it.
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
While it's nice to have small on-disk containers for some applications (e.g. deployment pipelines/CI), for production, I've found that Alpine doesn't save you much in RAM. I'd love to see this become something people look at as well when evaluating base images. To me at least, this was a far more important constraint when running Docker in production.
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…
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.
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.
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…