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: Mon, 1 Jun 2020 01:27:59 +0200 [thread overview]
Message-ID: <CAJ3okZ3RKvUAoO1hasKXEfLAKp5KM6jNPFvx_ofiMytMZN8psw@mail.gmail.com> (raw)
In-Reply-To: <CAKjnHz1YTAFZGYJRc=usWVAJXP50BqU8EhGvkjPtUgyH3yxMpg@mail.gmail.com>
Dear Stephen,
On Sun, 31 May 2020 at 21:43, Stephen Scheck <singularsyntax@gmail.com> wrote:
> On Sun, May 31, 2020 at 2:51 PM zimoun <zimon.toutoune@gmail.com> wrote:
>>
>> Maybe the explosion of size would be slower. If you do, please report
>> here the number after say 12 generations; I am really interesting. ;-)
>
> Now I'm confused - in your reply to Vincent, it seemed that there were still problems
> with the GC removing dead store items even after you did an export/re-import with the
> entire image on a single Docker layer? Or did I misread it?
The export/import trick cut by half the size of "your guix-bootstrap"
image. So even I am not convince that it will fix the issue, I think
that my proposal is the correct thing to do to delete dead items in
the store. Basically, after the pull, you need to delete all the
other generations of /root/.config/guix/current (expected one) by
"guix pull -d", then to delete all the generations of
/root/.guix-profile with "guix package -d" and last garbage collect.
For sure, it will not delete the items coming from previous layer but
it will delete all the dead items of the current session. And "docker
export | docker import" could remove other items -- even if in the
case of "install/remove hello" it is not work cleanly, some items are
deleted.
Well, it is just to be complete with your approach.
>> 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?
>
> Well, Guix is interesting, and there aren't ready-made containers for it out there like there are for
> Ubuntu, Fedora, etc. if you have a need to do some task in that kind of environment, or just to play
> around, or see how the system is evolving. Also, I have been playing around with Guile lately and
> I thought Guix might be a better fit for that kind of work than other environments where Guile is
> largely neglected (Guix is *written* in Guile, after all). And I happened to be learning GitLab CI/CD
> around the same time, and it seemed like a good opportunity to experiment with both at once,
> so I thought, why not? :-) Which infrastructure - well, GitLab CI/CD, with fixed compute limits :-)
Yeah, "ready-made container" could be really cool! AFAIK, no one took
the time to implement and document. There are various attempts but
not always reported on help-guix or guix-devel. Well, the answer of
these 2 questions implies different strategies.
For example, I am running Guix on the top of Debian so I basically use
only the package manager. And I use this infrastructure to produce
Docker images containing apps running "guix pack -f docker -m
manifest.scm". Because I am interested in Reproducible Science, I
also use "guix time-machine -C channel.scm -- pack -f docker -m
manifest.scm". However, the Docker images contains only applications
(R or Python with bunch of packages) and the "user" cannot use these
images to extend them running "guix install foo"; because I want to
track reproducibility so the only way is to go by 'manifest.scm' and
'channel.scm' files.
Another example is the Dockerfile way. Based on any image (Alpine or
Debian), I build an image containing the Guix package manager --
roughly speaking as you are doing with your image 'guix-bootstrap'.
Then I use this image in 2 different ways: with a Dockerfile or
directly. In both cases, it always starts by "guix pull. And I never
chain the images -- I mean only 3 "layers" at maximum: 0-debian,
1-guix-fresh and 2-guix-lastest. Well, I have never run "guix gc"
inside a Docker image.
Last, I have never played with "guix system docker-image". But in the
context of GitlabCI, what I would try should be something like:
CONTAINER=`docker run --detach --privileged $OLD`
docker exec $CONTAINER guix pull
docker exec $CONTAINER guix system docker-image --root=/image.tar stuff.scm
docker cp $CONTAINER:$IMG $NEW
with maybe instead of "guix pull" this bazooka:
docker exec $CONTAINER guix install git
docker exec $CONTAINER git clone
docker exec $CONTAINER guix environment guix
docker exec $CONTAINER ./bootstrap && ./configure --localstatedir=/var/
docker exec $CONTAINER make -j
docker exec $CONTAINER ./pre-inst-env guix system docker-image
Well, use "guix system docker-image" inside a Docker image already
containing Guix; this avoid the layer issue, isn't it?
But as I said elsewhere, I am not really familiar with Docker so my
words are probable irrelevant.
All the best,
simon
next prev parent reply other threads:[~2020-05-31 23:28 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
2020-05-31 19:43 ` Stephen Scheck
2020-05-31 23:27 ` zimoun [this message]
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=CAJ3okZ3RKvUAoO1hasKXEfLAKp5KM6jNPFvx_ofiMytMZN8psw@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).