From: "Ludovic Courtès" <ludo@gnu.org>
To: Giacomo Leidi <goodoldpaul@autistici.org>
Cc: 66160@debbugs.gnu.org
Subject: [bug#66160] [PATCH] gnu: Add oci-container-service-type.
Date: Sat, 14 Oct 2023 18:09:27 +0200 [thread overview]
Message-ID: <875y39fao8.fsf@gnu.org> (raw)
In-Reply-To: <8b8a0eed3b02cfd2edb94859da83032c96ee5616.1696619356.git.goodoldpaul@autistici.org> (Giacomo Leidi's message of "Fri, 6 Oct 2023 21:09:16 +0200")
Hi Giacomo,
Giacomo Leidi <goodoldpaul@autistici.org> skribis:
> * gnu/services/docker.scm (oci-container-configuration): New variable;
> (oci-container-shepherd-service): new variable;
> (oci-container-service-type): new variable.
> * doc/guix.texi: Document it.
We’re almost there! There’s a couple of things I overlooked before (my
apologies), so here we go:
> +@table @asis
> +@item @code{command} (default: @code{()}) (type: list-of-strings)
> +Overwrite the default command (@code{CMD}) of the image.
> +
> +@item @code{entrypoint} (default: @code{""}) (type: string)
> +Overwrite the default entrypoint (@code{ENTRYPOINT}) of the image.
Apparently this doesn’t match the docstring that’s in
‘define-configuration’.
Could you make sure the docstring is the canonical source? Then you can
use ‘generate-documentation’ to generate the bit that you’ll paste in
guix.texi (info "(guix) Complex Configurations").
> + (entrypoint
> + (string "")
> + "Overwrite the default ENTRYPOINT of the image.")
> + (environment
> + (list '())
> + "Set environment variables."
> + (sanitizer oci-sanitize-environment))
> + (image
> + (string)
> + "The image used to build the container.")
> + (name
> + (string "")
> + "Set a name for the spawned container.")
Please use ‘maybe-string’ in cases where it’s either the Docker default
(default ENTRYPOINT, default CMD, etc.) or some user-provided value.
I find it clearer or at least more conventional than using the empty
string to denote default values.
> +(define oci-container-configuration->options
> + (lambda (config)
> + (let ((entrypoint
> + (oci-container-configuration-entrypoint config))
> + (network
> + (oci-container-configuration-network config)))
> + (apply append
> + (filter (compose not unspecified?)
> + `(,(when (not (string-null? entrypoint))
> + (list "--entrypoint" entrypoint))
> + ,(append-map
> + (lambda (spec)
> + (list "--env" spec))
> + (oci-container-configuration-environment config))
> + ,(when (not (string-null? network))
> + (list "--network" network))
This would thus become:
`(,@(if entrypoint
`("--entrypoint" ,entrypoint)
'())
…)
> + #~(make-forkexec-constructor
> + ;; docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
> + (list #$docker-command
> + "run"
> + "--rm"
> + "--name" #$name
> + #$@(oci-container-configuration->options config)
> + #$(oci-container-configuration-image config)
> + #$@(oci-container-configuration-command config))
> + #:user "root"
> + #:group "root"))
Does ‘docker run’ necessarily need to run as root, or are there cases
where one might want to run it as non-root? (I expect the latter.)
> +(define oci-container-service-type
> + (service-type (name 'oci-container)
> + (extensions (list (service-extension profile-service-type
> + (lambda _ (list docker-cli)))
> + (service-extension shepherd-root-service-type
> + configs->shepherd-services)))
> + (default-value '())
I wonder if it should take a list of configs and be extensible, or
simply take a single config. Users would write:
(service oci-container-service-type
(oci-container-configuration …))
WDYT?
Last thing: there’s no system test (something we normally require), but
since I forgot about it before and I’m already asking for more than I
should :-) I propose to leave it for later.
Thanks!
Ludo’.
next prev parent reply other threads:[~2023-10-14 16:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 20:32 [bug#66160] [PATCH] gnu: Add oci-container-service-type paul via Guix-patches via
2023-09-22 20:34 ` Giacomo Leidi via Guix-patches via
2023-10-05 14:30 ` Ludovic Courtès
2023-10-05 17:30 ` paul via Guix-patches via
2023-10-13 22:53 ` paul via Guix-patches via
2023-10-06 19:09 ` Giacomo Leidi via Guix-patches via
2023-10-14 16:09 ` Ludovic Courtès [this message]
2023-10-14 21:29 ` paul via Guix-patches via
2023-10-19 20:13 ` Ludovic Courtès
2023-10-19 21:16 ` paul via Guix-patches via
2023-10-24 15:41 ` Ludovic Courtès
2023-10-24 20:22 ` paul via Guix-patches via
2023-10-13 22:57 ` Giacomo Leidi via Guix-patches via
2023-10-14 21:36 ` Giacomo Leidi via Guix-patches via
2023-10-14 21:47 ` Giacomo Leidi via Guix-patches via
2023-10-24 20:59 ` [bug#66160] [PATCH v2] " Giacomo Leidi via Guix-patches via
2023-11-23 10:02 ` Ludovic Courtès
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=875y39fao8.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=66160@debbugs.gnu.org \
--cc=goodoldpaul@autistici.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).