[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Experiment in generating multi-layer Docker images with guix pack

From: Ludovic Courtès
Subject: Re: Experiment in generating multi-layer Docker images with guix pack
Date: Sun, 29 Mar 2020 16:50:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Chris,

Christopher Baines <address@hidden> skribis:


>> I think a layering algorithm like Graham Christensen’s above requires
>> knowledge of the reference graph, meaning that layering can only be
>> computed on the build side, using #:references-graphs.  In that case, it
>> could be that you can’t have a host-side <docker-image-layer> record.
> As I understand it, you only have to do the computation on the build
> side if you're restricted to doing a single set of builds. If you first
> build the store items you want to put in the image, then look at there
> references and compute the derivation for building the image, then you
> could do this kind of computation on the client side.
> But yeah, this is important to work out, as how image generation should
> work, and what behaviours we want should define the structure of the
> code.
> I went with records to represent layers partially because I'm familiar
> with it, but also because it allows for easier manipulation of layers on
> the client side. Representing different layers as different derivations
> also allows them to potentially be built in parallel, although I'm not
> sure how beneficial this might be.

That’s a good point, it could help.  We could also use a “dynamic
dependency” like for grafts so we can compute things on the host side
anyway (tempting, but we should probably not start using that

> Related to this, at the moment Docker V1 images can be generated, it
> would be good in the future to also support Docker V2 images and OCI
> images. All three container formats use a layered approach to managing
> the files, but they are all different (as far as I'm aware).

Oh, I thought these formats were all the same.  I suppose it’d be enough
to support OCI, right?

> In my mind there are three architectural approaches:
>  - Image generation entirely on the build side
>    - The layers and the image are constructed through one derivation
>    - The code for building images is in a module available at build time
>    - Different approaches for layering are implemented in the module
>      available at build time, and parameters are passed in as
>      data/gexpressions
>  - Image generation entirely on the client side
>    - Each layer is a derivation, and the image is an additional
>      derivation that takes the layers as an input
>    - The code for building images is inside gexp compilers for the
>      record types representing the images and layers
>    - Different approaches for layering manipulate the layer records on
>      the client side
>  - Image generation can be done both build and client side
>    - Depending on the parameters, the layers and image can be a single
>      derivation, or one for each layer, and another for the image
>    - The code for building images is in a module available at build
>      time, and this is also used by gexp compilers
>    - Different approaches for layering have the option of either being
>      on the build side, or the client side
> What are peoples thoughts?

>From a pragmatic standpoint, perhaps we can first integrate what you
propose (option #2), and later adjust the code towards #1 or #3 as we
see fit.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]