On Wed, Aug 7, 2019 at 5:26 PM Colin Walters <walters@verbum.org> wrote:


On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
> If you want small images, just use buildah.

Dockerfile-based multi-stage builds are significantly more popular than this and should really be mentioned first.

I'm not saying `buildah` is bad, but...what you're talking about here also encourages using the host as a build root which has various negatives.

And I think the main conversation to have is whether we should introduce something more like
https://github.com/GoogleContainerTools/distroless
that basically just has:

 - glibc
 - ca-certificates
 
Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's it.
(While people often say both Rust and golang are statically linked, that's true
 of the language code, but by default  Rust links to glibc, Go does not, and I
 think what Rust does is better and should be encouraged, so we want a libc
 in this "ultramin" container)

Wow, a model like _distroless_ is exactly what I think we need in and from Fedora to enable making those minimal, purpose-built and service-specific containers.

I was thinking of a concept that has rpm-ostree compose a set of packages to a root dir, and put that in a container with Buildah.
Not sure how feasible it would be to add that functionality (as opposed to simply using dnf for this), but I'm thinking it would be super neat to have a coreos-assembler that also does container composes from an ostree manifest, in the same way it assembles OS images in different formats for different platforms.

I'd also like to link to Adam's super informational page here: https://asamalik.fedorapeople.org/container-randomness/report-f31.html
It would be great if we could include infos about the package sets of our ostree-based composes in there as well (FCOS, Silverblue and IoT). Also note that our container scratch build size has gone up dramatically in F31 (I don't know why, yet).

cc'ing Ben Breard and Sanja Bonic for their general interest in the Minimization effort.