From: zimoun <zimon.toutoune@gmail.com>
To: Stephen Scheck <singularsyntax@gmail.com>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Guix Docker image inflation
Date: Sun, 31 May 2020 20:51:10 +0200 [thread overview]
Message-ID: <CAJ3okZ3i0UhXccHnL2mGbT3HP-2KHUdp=44BvbPeSyyVVjU4gg@mail.gmail.com> (raw)
In-Reply-To: <CAKjnHz0oBQN+n6sXxbFhZK-0H8qJe1=74O+CrVbJxD0h9WjGBg@mail.gmail.com>
Dear Stephen, again :-)
On Sun, 31 May 2020 at 20:30, Stephen Scheck <singularsyntax@gmail.com> wrote:
>> No, it is how Docker is designed. Maybe the terminology "layer" is
>> not the Docker one but when the images are chained, one cannot remove
>> the data of the previous layer of the total image.
>
> I'm not disagreeing with that, but IF any of the store files resulting from `guix pull`
> are ephemeral (i.e. intermediate build results not anchored to a profile) AND guix
> GC worked inside the container, my approach might still work - yes there would be
> image and layers growth but it might be small enough not to care between periodic image
> rebases. But I'm starting to doubt that, or at least it is difficult to quantify with the
> GC issues.
Currently, if I read correctly, your images are chained with something like,
--8<---------------cut here---------------start------------->8---
GUIX_PATH=/root/.config/guix/current/bin
$GUIX_PATH/guix pull --branch=$CI_COMMIT_REF_NAME--fallback
/root/.config/guix/current/bin/guix gc --delete-generations
/root/.config/guix/current/bin/guix gc --collect-garbage
/root/.config/guix/current/bin/guix gc --optimize
docker commit
--8<---------------cut here---------------end--------------->8---
and instead you should do something like
--8<---------------cut here---------------start------------->8---
GUIX_PATH=/root/.config/guix/current/bin
$GUIX_PATH/guix pull --branch=$CI_COMMIT_REF_NAME--fallback
/root/.config/guix/current/bin/guix pull -d
/root/.config/guix/current/bin/guix package -d
/root/.config/guix/current/bin/guix gc
docker commit
docker export | docker import
--8<---------------cut here---------------end--------------->8---
Maybe the explosion of size would be slower. If you do, please report
here the number after say 12 generations; I am really interesting. ;-)
>> Because if you run Guix outside an Docker container, you will not have
>> the issue. The main issue is how the Docker "filesystem" is designed.
>
> Actually, there might be another way around this, still avoiding the need for a custom Runner,
> for example mounting /var/guix and /gnu/store into the container instead of belonging to it. If
> done that way, layer accumulation wouldn't be an issue, and maybe GC between layers neither.
Yes, it is one solution.
All the question seems to be:
- what is the purpose of such Docker image? Which usage?
- what infrastructure do you have at hand to build the Docker images?
Thank you for raising all this Docker image production question. :-)
All the best,
simon
next prev parent reply other threads:[~2020-05-31 18:51 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
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 [this message]
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='CAJ3okZ3i0UhXccHnL2mGbT3HP-2KHUdp=44BvbPeSyyVVjU4gg@mail.gmail.com' \
--to=zimon.toutoune@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).