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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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-full...
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-lin... ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/290
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
The issue: `Make fedora-minimal base image generally available` of project: `atomic-wg` has been assigned to `maxamillion` by dustymabe.
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
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.
-
Amel Hodzic -
Daniel J Walsh
-
Dusty Mabe
-
Frantisek Kluknavsky
-
Josh Berkus
-
Josh Boyer
-
Matthew Miller