From: Stephen Scheck <singularsyntax@gmail.com>
To: Leo Famulari <leo@famulari.name>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Guix Docker image inflation
Date: Fri, 29 May 2020 13:56:28 -0400 [thread overview]
Message-ID: <CAKjnHz1b1EUXszQtUVz9p8zWu+h0HtPfCzrOmrXO+eyhH+AvVw@mail.gmail.com> (raw)
In-Reply-To: <20200529170820.GA30828@jasmine.lan>
On Fri, May 29, 2020 at 1:08 PM Leo Famulari <leo@famulari.name> wrote:
> I'm still not quite sure what you are doing (or what Docker does) so
> please bear with me.
>
> > root@localhost /# du -h --max-depth=1 /gnu/store | egrep
> > "guix-system$|guix-packages-base$|guix-[0-9a-f]*-modules$"
> [...]
> > 191M
> /gnu/store/l3amdz5xyhflg5wdzlxr2685dq5glic2-guix-527ab3125-modules
> > 201M
> /gnu/store/5mhn1ynxvy7jihsknsnv3yspkkvc0r5s-guix-2e59ae238-modules
>
> If I understand correctly, you should not need both of these directories
> in a Guix VM image. The latter hashes are truncated guix.git commit
> hashes and a VM image would only be based on a single one.
>
Exactly, I agree (to the extent that I understand Guix).
I recommend looking into why all these directories are being copied into
> your images.
>
Whatever is in /gnu/store (as managed by Guix) goes into the image, nothing
more and nothing less.
>
> I figure you'd want to create each image with *only* the things
> corresponding to the Git commit it's based on, but it sounds like they
> are being created by copying the entire host image, which doesn't seem
> right.
>
> If the Docker images are being created by simply snapshotting the file
> system of a non-ephemeral Guix system, that's probably not the right way
> to do it. Is that what's going on?
>
Yes, as I said, the image is created from a file system snapshot, after Guix
is brought up to date via `guix pull` and those various Guix garbage
collection
operations are run. However, it's not quite "non-ephmeral" as each Guix
operation
is run as an atomic command inside the Docker container, with nothing else
running (except for guix-daemon, which has to always be running for Guix to
operate to the best of my understanding, and a couple other Guix System
daemons
which anyway would be equivalent to the situation to any Guix installation
running
outside of a Docker container).
How else would you suggest that it be done? It would be nice if `guix
system docker-image`
took `--branch` and `--commit` options to build a container from a
well-defined Guix check-in
state, but that doesn't seem to be the case. And in any case - too slow.
The point here is to
leverage daily incremental pulls to keep data transfer and build times down.
next prev parent reply other threads:[~2020-05-29 17:56 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 [this message]
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
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=CAKjnHz1b1EUXszQtUVz9p8zWu+h0HtPfCzrOmrXO+eyhH+AvVw@mail.gmail.com \
--to=singularsyntax@gmail.com \
--cc=help-guix@gnu.org \
--cc=leo@famulari.name \
/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).