I enjoyed this blog post. Julia does a great job of distilling an idea down with examples.<p>I am fairly comfortable with Linux as a user for things like understanding processes, ports, key files and utilities, etc. The way I understand how to model abstractions like containers is to know the various OS primitives like cgroups, changing root, network isolation. Once one sees how those pieces come together to create the container abstraction, they can be mapped to the system calls provided by the OS. Usually they also have utilities bundled (like `chroot`) to interface with those primitives as an operator.
Hmm... how is Overlayfs and Unionfs different? From the explanation I can't find any differences...<p>Unionfs: A Stackable Unification File System[0]:<p>> This project builds a stackable unification file system, which can appear to merge the contents of several directories (branches), while keeping their physical content separate.<p>> Unionfs allows any mix of read-only and read-write branches, as well as insertion and deletion of branches anywhere in the fan-out.<p>> To maintain unix semantics, Unionfs handles elimination of duplicates, partial-error conditions, and more.<p>If it is the same thing (but maybe more maintained or has more features...) , can we implement something like trip[1][2] package manager on top of Overlayfs?<p>(Porg is a package manager where all files that are installed by make install is tracked and mounted on a Unionfs layer.)<p>[0] <a href="http://unionfs.filesystems.org" rel="nofollow">http://unionfs.filesystems.org</a><p>[1] <a href="https://github.com/grencez/trip" rel="nofollow">https://github.com/grencez/trip</a><p>[2] <a href="http://www.linuxfromscratch.org/hints/downloads/files/package_management_using_trip.txt" rel="nofollow">http://www.linuxfromscratch.org/hints/downloads/files/packag...</a>
I recently made a system that uses overlays to provide work spaces for a complex build process. However, there is significant overhead paid for unmounting an deleting the files in the overlay after all the work is done. I was thinking about changing the system such that I allocate a partition ahead of time, write all the overlays there, and on success just blow away the partition and with it the overlays. This is kind of a pain in the ass. Can anyone suggest a method for rapidly deleting all the data generated by using 100's of overlays? Maybe BtrFS snapshots would be better? What are the pros and cons? Thank you so much and I apologize for "anything" up front :)
I somehow feel compelled to point out that this idea of union/overlay FS layers has nothing to do with containers per se. But on the other hand is somehow critical for why containers got popular as that is the way to make the whole thing somehow efficient both in terms of hardware resources and developer time.
I wrote this script[1] a while ago which creates an overlay and chroots into the overlays workdir. It's pretty useful, with it, you can do something like<p>> overlay-here<p>> make install (or ./wierd-application or 'npm install' or whatever)<p>> exit<p>and all changes made to the filesystem in that shell is written to the upperdir instead. So for example in the above example, the upperdir would contain files such as upperdir/usr/bin/app and upperdir/usr/include/header.h.<p>It's useful when<p>* You want to create a deb/rpm/tgz package, but a makefile does not have support for DESTDIR<p>* An application writes configuration files somewhere, but you don't know where<p>* An application would pollute your filesystem by writing files in random places, and you want to keep this application local to "this directory"<p>* In general when you want to know "which files does this application write to" without resorting to strace<p>* or when you want to isolate writes, but not reads, that an application does<p>[1]: <a href="https://gist.github.com/dbeecham/183c122059f7ba288397e8c3320234d3" rel="nofollow">https://gist.github.com/dbeecham/183c122059f7ba288397e8c3320...</a>
There was a practice of using MergerFS/OverlayFS for pooling multiple drives (often by SnapRAID users), but what's still missing (to my knowledge) is some sort of a balancing layer, that could distribute writes.<p>I got this idea many years ago, when first personal cloud storages appeared and offered some limited space for free. I thought it would be nice if I could pool them and fill them taking their different capacities into account. And if I could also stripe and EC them for higher availability...<p>I still wonder if there's something that can do this and if there isn't I would like to know why, since it looks like a useful and obvious idea.
This is crucial tech to understand docker-style containers...<p>I used this to build custom iso images based on an existing iso file. The old method mounted the ISO image, rsync'd the entire contents, copied and updated some files, and then created a new image. This took quite a while and (temporarily) wasted a lot of disk space, and was initially sped up by copying the temp ISO to RAM disk, which also presented some challenges, and wasn't as fast as the eventual solution, using aufs on top of the ISO mount to patch the image. Worked like a charm and sped up the ISO building considerably :)
Great article and nice style distilling all this into a bite size chunks.<p>Is it me or just the title is a little bit inaccurate in the sense that there's more to "How containers work?" than overlays, e.g. it made me think that it covers more than it actually does, e.g. cgroups, namespaces, etc...<p>Anyone knows of a more in depth coverage of containers building block type of article that allows one to build a rudimentary container from scratch to appreciate what goes into building one ?
OverlayFS is pretty useful for day to day things like union folders for your media collection spanning across different hard drives.
It does have a few quirks like inotify not working properly, so changes need to be watched for on the underlying fs.
A lot of utility in Docker comes from incremental (cached) builds based on overlay but in fact you can get it from any CoW system such as LVM/ZFS/BtrFS snapshots.
When working with containers also consider hardware abstractions like virtual machines. Startup time can be optimez from minutes down to milliseconds. And also consider statically linked binaries if all you want is to solve the dll hell.
s/o to unionfs for plan9 by kvik: <a href="http://code.a-b.xyz/unionfs" rel="nofollow">http://code.a-b.xyz/unionfs</a><p>Userspace implementation of union directories with control of which half of the union made gets precedence for certain operations such as file creation, etc.