Is it possible to make the minimal image the base of the regular image? That seems ideal from a testing perspective (not to mention explosion of streams).

I've had in the back of my mind for a while the idea of fedora-minimal and fedora (regular) like that, and then maybe a fedora-batteries image above that, which includes packages not in the fedora image but common to some threshold of our official layered images.

Theoretically, yes. I'd let @maxamillion comment on whether that's practical.

theoretically yes, but we do some stuff to the minimal image to reduce the image size that we'd then have to undo. I don't think it really makes sense. You can see for yourself: minimal kickstart non-minimal kickstart. Note that both of these include docker-common.ks.

That's less than I expected, really. :)

(And some of it really random. From coreutils, we loose pinky but not base32 (which isn't in EL7 and I'd never heard of... but that's another story.)

I'd really love to see a bug associated with each one of those rms in %post. It seems like we could solve most of it with better packaging over time, and then get to the point where we could do the additive thing.

cc @fkluknav

buildah, now in alpha, really benefits from a minimal base image

Is there a link to an article or something that explains why buildah benefits from a minimal base image?

The removed stuff is either:
- Explicitly requested to be removed by a Red Hat customer without much explanation. That is not very applicable to Fedora.
- Random stuff I deemed to be relatively safe to remove to meet an arbitrary size limit.

A big and necessary part of the image is glibc. I failed to persuade maintainers that image size matters and that they should seriously think about cutting large portions out.
Second is systemd. Experiments with various fake pseudo systemds not go well.

@fkluknav systemd is a big one, how many MB is that with dependencies? I thought we had a stub systemd which was kinda working ... it's particularly troubling to users to have systemd in the image when they don't want to use it (note that we're also going the opposite way with the fedora-init image).

I still think we need a much, much more modular systemd package to address this, rather than a fake one.

@jwboyer not yet, there's one currently being drafted, and one of the reasons we haven't published it is because fedora-minimal isn't usable in a Dockerfile.

Let me sum up: Buildah builds containers in the LXC fashion, installing from the host system into an alternate rootdir. This means that containers can theoretically be much smaller than Docker Build, because build & install tools (gcc, git, dnf) don't need to be included in the image. However, if the base image is already 199MB, excluding 40MB of build tools doesn't really make a difference. Therefore, we want Fedora Minimal to be available for Buildah, where 40MB of not-needed tools would make a huge difference.

@mattdm yah, and we're not going to get one, because Lennart hates containers. So probably wasting time here.

@fkluknav out of curiosity ... for Buildah specifically ... is it possible to exclude DNF entirely? How much space would that save?

@jberkus please, correct me if I am wrong/misguided/deluded. Once you move build tools out of the base image, why would you want a base image? Some configuration for convenience? Mask a few systemd units (without actually having systemd yet), create tmpfiles, import gpg keys, label the image "fedora features first freedom friends" for advertisement? What else? I guess the saved space would be almost 100%. Do we want a base image for that at all?

Because you can't run a container without a base image. You still need a stripped-down userspace with glibc, if nothing else.

The point of the container is as a unit of delivery, not as a work environment. That is, I'm building the contianer in order to deploy it to a cloud, not so that I can use it to build other things. I don't need DNF in the container, I need DNF inorder to install things into the container. Once those things are installed, I don't want DNF in the container. Same with gcc, make, git, etc.

Is this getting close to unikernels? Yep. And that's a good thing. We need to stop thinking of containers like they're VMs. They are not. Containers are statically linked binaries, and just like th statically linked binaries of yore, it's critically important to reduce our dependencies.

For those of you reading this, with a tool like buildah you can create and update these types of containers. One of my main goals with getting buildah done, was to simplify the building of container images. Part of doing this is to make it easier to use tools external to the container image to build and update the container image.

ctr=$(buildah from scratch)
mnt=$(buildah mount $ctr)
dnf install --installroot $mnt MYPACKAGES
make install --dest $mnt
buildah umount $mnt
buildah config --entrypoint=/usr/bin/MYPACKAGE $ctr
buildah commit $ctr MYPACKAGEIMAGE
buildah rm $ctr
buildah push MYPACKAGEIMAGE REMOTEREGISTRY/MYPACKAGEIMAGE

Later you want to update image

ctr=$(buildah from MYPACKAGEIMAGE)
mnt=$(buildah mount $ctr)
dnf update --installroot $mnt MYPACKAGES
buildah umount $mnt
buildah commit $ctr MYPACKAGEIMAGE
buildah rm $ctr
buildah push MYPACKAGEIMAGE REMOTEREGISTRY/MYPACKAGEIMAGE

Bottom line you end up with a minimal container image containing only the content required to run the image. Buildah can run in the traditional "docker" mode where processes run within the container userspace, but then you end up with the extra packages.

Because you can't run a container without a base image. You still need a stripped-down userspace with glibc, if nothing else.
The point of the container is as a unit of delivery, not as a work environment. That is, I'm building the contianer in order to deploy it to a cloud, not so that I can use it to build other things. I don't need DNF in the container, I need DNF inorder to install things into the container. Once those things are installed, I don't want DNF in the container. Same with gcc, make, git, etc.
Is this getting close to unikernels? Yep. And that's a good thing. We need to stop thinking of containers like they're VMs. They are not. Containers are statically linked binaries, and just like th statically linked binaries of yore, it's critically important to reduce our dependencies.

@jberkus : I agree fully with last 2 paragraphs but still do not get the first. Why do you need to build an image using a container? Even if you want to do that, because it is cool to do everything in containers, you still do not need a "base" image. Just make a tarball from scratch by any means you want - for example with buildah like in the previous post from dwalsh. As I understand it, the concept of a base image comes from the concept of containers as work environment - the very thing you want to avoid. Where is my understanding wrong?

@fkluknav all of the buildah documentation so far has worked with base images, I assumed that a base image was required.

Apparently, according to @dwalsh, a base image is NOT required? Or we already have a base image called "scratch" which has just glibc and nothing else?

scratch is not a "base" image, it is just a special name that tells buildah to create a layer with nothing in it. Dockerfile has the same concept.

From the docker-docs
https://docs.docker.com/engine/userguide/eng-image/baseimages/#create-a-full-image-using-tar

A parent image is the image that your image is based on. It refers to the contents of the FROM directive in the Dockerfile. Each subsequent declaration in the Dockerfile modifies this parent image. Most Dockerfiles start from a parent image, rather than a base image. However, the terms are sometimes used interchangeably.

A base image either has no FROM line in its Dockerfile, or has FROM scratch

Given that docker is native to Linux, we should safely assume that the "host" OS is Linux or
that users can build containers within a Linux VM or parent image.

Furthermore, if that Linux distro is RPM-based, the approach outlined at
https://github.com/moby/moby/blob/master/contrib/mkimage-yum.sh can be used
to build an RPM-based container without a Parent Image or the buildah tool.

In other scenarios, such as on non-rpm-based distro hosts/systems, the Parent image
might be relevant/necessary.

As for systemd, that shouldn't be needed/used within the container.
There's a redhat blog post that can also be referenced to get a better idea
of the end-result:
http://rhelblog.redhat.com/2017/03/13/introducing-the-red-hat-enterprise-linux-atomic-base-image/

Discussed at the atomic working group meeting today.

Most of the discussion in this ticket is unrelated to the original ask. Putting the container minimal image in the registry was something we were planning to do anyway. Adam will make it happen and will update this ticket when he has done so.

this is now in the registry at registry.fedoraproject.org/fedora-minimal - can we close this?

Is there a registry.fedoraproject.org/fedora-minimal:rawhide -- it doesn't look like there is