Flockport supports LXC so both aufs and overlayfs are available for use but not enforced. Flockport let's you launch containers in a layer so its used at run time if required but not to build containers.
Layers are interesting but they are still maturing and have hard to detect bugs and incompatibilities [1]. The more layers the worse it becomes so they can add management overhead. Containers and layers are separate technologies so its useful to leave it as a choice.
The benefits have also often been oversold. For instance reuse, all container platforms provide a library of base OS images. These can simply to used as required instead of trying to use layers. How many upper layers are there going to be on top the base OS that can be reused? This sounds good as an idea but often does not pan out, usually its just the base OS or base OS plus dev environment being reused so why use layers?
And If there are updates to any of the lower layers for instance security or version updates usually the container needs to be rebuilt so again you are not benefiting from using layers to build containers.
Using it at run time like you would run a copy of a container to keep the original intact still makes sense, but using it to build containers adds a lot of complexity and management overhead.
> This sounds good as an idea but often does not pan out, usually its just the base OS or base OS plus dev environment being reused so why use layers?
When the build process is predictable or plannable in advance, this can turn out well. I'm familiar with buildpacks in this respect -- the basic order of operations and layout of the filesystem is the same for all software that passed through a buildpack.
> And If there are updates to any of the lower layers for instance security or version updates usually the container needs to be rebuilt so again you are not benefiting from using layers to build containers.
Layer rebasing will change this pretty dramatically. From "I need to rebuild and roll all my apps" to rebasing the image on new layers in seconds and rolling them out across a fleet in seconds to minutes.
While those are true in some cases, in others layers slow down the build process and increase the total download size. It really depends on what is being built and how it is distributed if layers have an advantage, make no difference, or are at a disadvantage.
I wish the industry had settled on binary diffs (xdelta3 works well) over squashfs for distribution and storage instead of this overwrought layering paradigm.
But then you have to unpack it, don't you? Like, diffs are great for downloading images, but once you've downloaded and want to run it, you still have to construct the final filesystem.
SquashFS is mountable directly as read-only. You can use Overlay just like Docker does to create a read-write layer on top. This combination of SquashFS+Overlay -- plus Xdelta3 for distribution -- has worked extremely well for the internal project I use it for.
1. If user's machine already has some of the layers for other images, no need to download them
2. Updating an app becomes an actual update to the so layer, reusing the underlying infrastructure layers
3. Layering enable hosting commonly used layers on faster CDNs, making downloads faster.
I hope layering is in your roadmap