On ma, 05 elo 2019, Clement Verna wrote:
On Sun, 4 Aug 2019 at 18:17, Peter Robinson <pbrobin...@gmail.com> wrote:
>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>> <zbys...@in.waw.pl> wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages (ones
>> > > that wouldn't appear in the images using the Fedora base image) has been
>> > > dragged in as dependencies. Some of them are even related to hardware.
(See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>
>
> I've regenerated it for f30 and f31:
https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!
Is there a plan to add some form of CI to monitor this? It would make
it easy to monitor ups/downs over time and pick up mistakes that bloat
deps by accident.
I started some effort in that sense last year, to have the Fedora CI
pipeline to trigger on container builds[0]. Unfortunately the CI
pipeline for containers is not working [1] and it seems that nobody
has cycles to try to fix it.
We could also get some inspiration from what the Docker Hub folks are
doing [2][3].
And finally I would love to sunset registry.fp.o and just use quay.io
as our main registry that would give us for CVE scanning for free
using Clair[4] (that would also be one less thing to care about on the
infra side), but here again there is some work to be done to make that
possible :-)
Do we have all the same containers in quay.io?
FreeIPA upstream is relying on Fedora toolbox and main Fedora containers
for its CI testing in Azure Pipelines. I cannot find Fedora toolbox in
quay.io/fedora/ project.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
