undefined | Better HN

0 pointscompsciphd5y ago0 comments

I agree, I don't fault them for taking the easy way, I do think it was wrong though. I created tools tools for converting debian packages into layers (in my research I stored these layers on a shared file system (either a multi-attach (in practice would need an fs that can have a single writer and multiple readers, which might simplify things) on a san or nfs.

But, debian packages aren't really made for this directly, as they have their pre/post install/remove scripts. My "hack" was to treat every package as an dpkg --unpack version (i.e. not configured) and then at image "build" time (i.e. each image is really a layer that is a manifest of dependent layers + data created at image build time), we would dpkg --configure --pending all the composed layers (with a bit of magic happening behind the scenes to make dpkg realize that the packages were unpacked but not configured yet).

This mostly worked well, but you could have some ordering issues. A bigger issue is because debian doesn't expect this to happen, it creates encryption at install time (say for ssh), not at first run time. So for example, if one created an ssh daemon image, any instance run from it would have the same key. not a great idea. Of course, its possible to engineer my way out of this (simple case would be to write tooling to recognize these cases and inject it into the created images), but it goes to why a direct conversion from debian packges into layer wasn't a silver bullet solution. I had the thought that perhaps an Ubuntu type approach would work, where some packages are wholesale imported from Debian into Unbutu without any changes but "important" packages ae modified to fit Ubuntu better could work.

As an aside, the 2 papers referenced above were my "job talk" for my post doc at IBM Research, and got me the job. I tried to get support to continue this line of work there, but that never happened (and then my manager left, and I was left working on unrelated cloud stuff for the last 1.5 years there). Of course, this is now important to IBM (see Red Hat purchase).

I wasn't approaching this from the pet/cattle metaphor, so I also gave my system the ability to upgrade instances in place by mark removeding layers as unlinked (i.e. ignored by readdir/lookup), and adding new layers. A big advantage here over traditional package management is that this made upgrades "atomic". For example, when you upgrade libc in the traditional package managed world, your system is temporarily "broken", in the sense that any executable that tries to run in between old libc removal and new libc installation will fail as its not on the file system. However, in the cattle world of containers, this is probably unnecessary complexity.

0 comments

2 comments · 1 top-level

ece5y ago· 1 in thread

The system you describe seems close to Jib [1] or Nixery [2], which are dependency-aware tools built on top of Docker. I think neither they nor the prototype you've described could be as distro/language-agnostic as Docker and ostree/flatpack are. Debian could offer something like Nixery, any distro could, but then it wouldn't be a cross-distro solution.

I personally like appimage, but I don't mind using flatpack because it is so similar to Docker and is also supported on most major distros. Distro repositories aren't going anywhere, and I think flatpack strikes the right balance for users and developers.

[1] https://github.com/GoogleContainerTools/jib

[2] https://github.com/google/nixery

compsciphdOP5y ago

yes, its not distribution agnostic, what I'd argue is that "docker style" containers (i.e. created out of a composed set of layers) would benefit from being constructed out of its own layer distribution instead of a package distribution. that the benefits one gets from building images in a way that leverages layers would be a big win.

simple examples:

1) we spend time ordering the layers we install in docker so as not to waste space if an earlier layer changes. in layer aware building, this isn't an issue.

2) if one does a run apt-get install XYZ, unless one nukes one's cache on every build (possibly ruining all efforts to not waste space if data comes out somewhat differently), one will not actually be getting the latest packages.

The primary benefit of leveraging an existing distribution is that you have all the software they have already built (and is built to work on them). Which I don't want to downplay the value of that. I understand why the decisions were made to leverage them, I just feel they come with a cost.

I'd also note that the prototype I described was basically finished being built 4 years prior to docker. we've learned a lot since then, but I think we've also forgotten a bit.

j / k navigate · click thread line to collapse