[atomic-wg] Issue #290: Make fedora-minimal base image generally available

[Josh Berkus]

jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
A "minimal" build of the base container image exists, but isn't official or
generally available from the repository.  We need this minimal image for a few reasons:

* users care about container size from some use-cases (think super-micro-services and
serverless)
* arguably a more minimal container is easier to secure
* other linux distros offer some kind of small base image
* buildah, now in alpha, *really* benefits from a minimal base image

For this to succeed, we'd want the following base images as part of
registry.fedoraproject.org:

* fedora-minimal:25
* fedora-minimal:26
* fedora-minima:latest

Given that the minimal image will differ less per release version (since it has less
plubming), it would be perfectly acceptable to have a very short expiration window on
older release versions, or only supporting the current Fedora release.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Matthew Miller]

mattdm added a new comment to an issue you are following:
``
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.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
Theoretically, yes.  I'd let @maxamillion comment on whether that's practical.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Dusty Mabe]

dustymabe added a new comment to an issue you are following:
``
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](https://pagure.io/fedora-kickstarts/blob/f26/f/fedora-docker-base-minimal.ks)
[non-minimal
kickstart](https://pagure.io/fedora-kickstarts/blob/f26/f/fedora-docker-base.ks). Note
that both of these *include*
[docker-common.ks](https://pagure.io/fedora-kickstarts/blob/f26/f/fedora-docker-common.ks).

``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Matthew Miller]

mattdm added a new comment to an issue you are following:
``
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 `rm`s 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.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Dusty Mabe]

dustymabe added a new comment to an issue you are following:
``
cc @fkluknav
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Boyer]

jwboyer added a new comment to an issue you are following:
``
>  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?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Frantisek Kluknavsky]

fkluknav added a new comment to an issue you are following:
``
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. 
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
@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).
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Matthew Miller]

mattdm added a new comment to an issue you are following:
``
I still think we need a much, much more modular systemd package to address this, rather
than a fake one.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
@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.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
@mattdm yah, and we're not going to get one, because Lennart hates containers.  So
probably wasting time here.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
@fkluknav out of curiosity ... for Buildah specifically ... is it possible to exclude DNF
entirely?  How much space would that save?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Frantisek Kluknavsky]

fkluknav added a new comment to an issue you are following:
``
@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?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
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.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Frantisek Kluknavsky]

fkluknav added a new comment to an issue you are following:
``
>  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?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Josh Berkus]

jberkus added a new comment to an issue you are following:
``
@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?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
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.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Amel Hodzic]

ilmostro added a new comment to an issue you are following:
``
From the docker-docs
https://docs.docker.com/engine/userguide/eng-image/baseimages/#create-a-f...

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.

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-...
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Dusty Mabe]

dustymabe added a new comment to an issue you are following:
``
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.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Dusty Mabe]

The issue: `Make fedora-minimal base image generally available` of project: `atomic-wg`
has been assigned to `maxamillion` by dustymabe.

https://pagure.io/atomic-wg/issue/290

[Dusty Mabe]

dustymabe added a new comment to an issue you are following:
``
this is now in the registry at registry.fedoraproject.org/fedora-minimal - can we close
this? 
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290

[Dusty Mabe]

The status of the issue: `Make fedora-minimal base image generally available` of project:
`atomic-wg` has been updated to: Closed as Fixed by dustymabe.

https://pagure.io/atomic-wg/issue/290