Deploy a Docker image with bash

[dave08]

When using the cue docker image in CI system like Argo Workflows, often one needs to run multiple cue commands (or possibly certain bash commands). One example would be processing files after importing some yaml files and using them with existing cue files for validation and generation of new results that need to be outputted to say, yaml. One could always use _tool.cue for this, but sometimes it's easier just to do that in bash (and there might be some features that _tool.cue wouldn't be able to handle and that the command line cue could?).

[mvdan]

One option would be to do a Docker image flavor on top of either Alpine or Debian, which are relatively common, and which often include common tools like a shell and git.

Alternatively, we could do our second Docker image flavor on top of a Go docker image, either their debian or alpine ones, which would give us a shell as well as Go for the sake of cue get go. This would significantly increase the size, though.

[b4nst]

What about calling this image debug? Other projects (like kaniko for example) are doing that for CI images

[dave08]

I think it's more than enough to base it on busybox... I got a 9MB image from this:

FROM cuelang/cue:0.7.1 AS cue

FROM busybox:1.36.1

COPY --from=cue /usr/bin/cue /usr/bin/cue

ENTRYPOINT [ "sh", "-c" ]

And it's not really debug... maybe cuelang/cue:0.7.1-busybox like lots of projects that use tags like that for -alpine?

[b4nst]

I don't really understand what you mean by

it's not really debug...

This is literally what Kaniko debug is based on...

[dave08]

@b4nst I think Kaniko is not really an example, since their use case for such an image is really for debugging purposes... you don't run a bunch of commands in one session, but rather one command that builds the image. Whereas in cue, there could be a bunch of use cases that require running many commands or using bash's globbing features, etc... so it's not really "debug" but rather just like have an image based on busybox instead of alpine.

I would even consider making the main image derive from busybox, since it's relatively cheap in space and provides more than distroless can do.

Recently I had another need for this when I was debugging a pipeline in Argo Workflows, I wanted to get into the cue process in the Pod to try out some commands and there wasn't any shell in distroless to log into...

Even Google Jib stopped using distroless for their base image, maybe since there was enough problems like this...

[b4nst]

I see now, thanks for the precision! I thought the use case was only to run a single CUE cmd but being able to debug them / have more metrics logs. I think this one still fall under that case:

I wanted to get into the cue process in the Pod to try out some commands and there wasn't any shell in distroless to log into...

Since CUE provides the execution part through CUE custom cmd I personally don't use bash's globbing and such anymore. However I get your point, and in that situation yeah I agree it should not be called debug. Sorry for the confusion!