unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: Stephen Scheck <singularsyntax@gmail.com>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Guix Docker image inflation
Date: Fri, 29 May 2020 16:30:56 -0700	[thread overview]
Message-ID: <87h7vyxqrz.fsf@gmail.com> (raw)
In-Reply-To: <CAKjnHz1X26QhPEWZfOmAbEmZHQA1qdU_Dq7U6kVXUqG7vCvuhw@mail.gmail.com> (Stephen Scheck's message of "Wed, 27 May 2020 15:41:49 -0400")

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

Stephen Scheck <singularsyntax@gmail.com> writes:

> Hello,
>
> As an exercise, I set up daily Guix System Docker image builds using GitLab
> and Docker Hub, here:
> https://hub.docker.com/repository/registry-1.docker.io/singularsyntax/guix/tags?page=1
>
> The build process works as follows: if an existing `latest` image does not
> exist for a given branch (master, 1.1.0, etc.), then bootstrap an image by
> running `guix system docker-image` inside an Alpine Linux Docker container
> with a fresh Guix installation. Using this image as a seed, `guix pull` is
> run for the desired branch, and the resulting image is committed to the
> Docker repository. If a "latest" image does exist, it is used instead as
> the base from which to run `guix pull`. Daily images are thus built
> incrementally from the previous day's build. For anybody curious about the
> process, the build script can be browsed here:
> https://gitlab.com/singularsyntax-docker-hub/guix/-/blob/master/.gitlab-ci.yml
>
> It works pretty well, except that I'm observing substantial image size
> inflation day-over-day, starting at ~197 MB from the seed image, now up to
> 1.71 GB eleven days later despite running `guix gc --delete-generations`,
> `guix gc --collect-garbage`, and `guix gc --optimize` after pulling prior
> to committing each new image.
>
> I'm wondering if there is some other Guix GC operation or option I'm
> missing, or any other suggestions which could stop this unsustainable image
> bloat from occurring. I really do doubt that the Guix System itself is
> growing this quickly.

Could it be that you are accumulating layers without bound?

https://developers.redhat.com/blog/2016/03/09/more-about-docker-images-size/

Since Docker images are built up of immutable layers, if you build your
image from an existing base image, I'm not sure that it's possible to
produce a new image that is smaller than the base image.  Basically,
even if you run "guix gc" to remove dead store items, they will still
exist on a prior layer, so the size of the new image won't decrease.
And since you're installing new things, the size will actually increase.
If you repeat this process by using the new image as an input for yet
another build, I think you will accumulate layers and storage space
without bound.

If this is what's happening, you might consider always building starting
from the same base image every time.  You could then update the base
image (e.g., by changing the FROM line of a Dockerfile, if that's what
you're using) periodically as new versions of it are released.  This
would probably allow you to avoid accumulating layers without bound.

FYI, Guix itself can build Docker images from scratch - no base image
required!  It can even build a Docker image of a full-blown Guix System
from scratch.  Sorry if you already knew that - I just wanted to point
it out in case you didn't!

See:

https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html
https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html

Hope that helps,

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2020-05-29 23:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 19:41 Guix Docker image inflation Stephen Scheck
2020-05-28 18:10 ` Leo Famulari
2020-05-29 16:19   ` Stephen Scheck
2020-05-29 17:08     ` Leo Famulari
2020-05-29 17:56       ` Stephen Scheck
2020-05-29 18:02         ` Leo Famulari
2020-05-29 18:21           ` Marius Bakke
2020-05-29 18:37             ` Leo Famulari
2020-05-29 18:44               ` zimoun
2020-05-29 21:24                 ` Stephen Scheck
2020-05-29 18:29           ` Stephen Scheck
2020-05-29 17:12     ` zimoun
2020-05-29 17:36       ` Stephen Scheck
2020-05-29 18:08 ` zimoun
2020-05-29 18:47   ` Stephen Scheck
2020-05-29 20:02     ` zimoun
2020-05-29 21:04       ` Stephen Scheck
2020-05-29 21:54         ` zimoun
2020-05-29 22:11           ` Stephen Scheck
2020-05-29 23:30 ` Chris Marusich [this message]
2020-05-29 23:55   ` zimoun
2020-05-30 17:13     ` Stephen Scheck
2020-05-31  9:37       ` zimoun
2020-05-31 18:30         ` Stephen Scheck
2020-05-31 18:51           ` zimoun
2020-05-31 19:43             ` Stephen Scheck
2020-05-31 23:27               ` zimoun
2020-05-31 21:04           ` Chris Marusich
2020-06-01  0:37             ` zimoun
2020-05-30 17:02   ` Stephen Scheck
2020-05-31  4:31     ` Chris Marusich
2020-05-31  9:08       ` zimoun
2020-05-31 17:50       ` Stephen Scheck
2020-05-31 18:33         ` zimoun
2020-05-31  8:24     ` zimoun
2020-05-31 10:50       ` Vincent Legoll
2020-05-31 17:58         ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7vyxqrz.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=help-guix@gnu.org \
    --cc=singularsyntax@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).