What's the best practice to work with helmfile inside the container

[jizusun]

I really love the out-of-the-box docker images at https://quay.io/roboll/helmfile
And the Dockerfiles: https://github.com/roboll/helmfile/blob/master/Dockerfile.helm3

My approach is to mount my project folder (or only the helm chart folder) into the container (from my Makefile):

helmfile-install: 
  docker run --rm -it \
	-v $(PROJECT_ROOT_DIR):$(PROJECT_ROOT_DIR) \
	-w `pwd` \
	-v $$HOME/.kube:$$HOME/.kube \
	-e KUBECONFIG=$${KUBECONFIG} \
        quay.io/roboll/helmfile:helm3-v0.102.0 helmfile -f charts/helmfile.yaml apply

However, the user in the container is root, so after helmfile apply, i will get *.tgz with permissions user: root, group: root under the sub-folder. To work with it out of the container, i have to use sudo.

Is it better if we add a non-root user in the Dockerfile?
Like the following:

ARG username=user
RUN addgroup -g 1000 ${username} \
    && adduser -u 1000 -G ${username} -s /bin/sh -D ${username}
USER ${username}

I would like to create a pull request if any maintainer agree with me 😸
Thanks.

[mumoshu]

@jizusun Hey! I have never tried to use the helmfile image that way, but I've experimented a bit and came up with this working command:

docker run -it --rm -u "$(id -u):$(id -g)" -v "$(pwd):$(pwd)" -w "$(pwd)" quay.io/roboll/helmfile:v0.106.1 bash -c "echo foo > foo.txt"

So without modifying the image, it seems like docker run -u UID:GID helps altering the owner uid/gid.

Would this work for you, too?

[jizusun]

@jizusun Hey! I have never tried to use the helmfile image that way, but I've experimented a bit and came up with this working command:

docker run -it --rm -u "$(id -u):$(id -g)" -v "$(pwd):$(pwd)" -w "$(pwd)" quay.io/roboll/helmfile:v0.106.1 bash -c "echo foo > foo.txt"

So without modifying the image, it seems like docker run -u UID:GID helps altering the owner uid/gid.

Would this work for you, too?

Oh thank you @mumoshu ❤️

With the command you mentioned the file permission is not a problem any more.
but another critical problem still blocks me 💔

That is, with the new user, the helm plugins required are missing, because they were installed into somewhere in the root user folder.

➜  Code docker run -it --rm \
quay.io/roboll/helmfile:v0.106.1 \
bash -c "whoami; helm plugin list"

root
NAME            VERSION DESCRIPTION
diff            3.1.1   Preview helm upgrade changes as a diff
helm-git        0.6.0   Get non-packaged Charts directly from Git.
s3              0.9.2   The plugin allows to use s3 protocol to upload, fetch charts and to work with repositori...
secrets         2.0.2   This plugin provides secrets values encryption for Helm charts secure storing
tiller          0.9.3   Start a Tiller server locally, aka Tillerless Helm


➜  Code docker run -it --rm \
-u "$(id -u):$(id -g)" \
-v "$(pwd):$(pwd)" -w "$(pwd)" \
quay.io/roboll/helmfile:v0.106.1 \
bash -c "whoami; helm plugin list"

whoami: unknown uid 501
NAME    VERSION DESCRIPTION

Thus helm diff cannot be executed.

bash-5.0$ helmfile  -f 01-assistant-ui.yaml diff
Building dependency release=assistant-ui, chart=../../charts/assistant-ui
No requirements found in ../../charts/assistant-ui/charts.

Comparing release=assistant-ui, chart=../../charts/assistant-ui
in ./01-assistant-ui.yaml: failed processing release assistant-ui: helm exited with status 1:
  Error: unknown command "diff" for "helm"
  Run 'helm --help' for usage.

[mumoshu]

@jizusun Hey! Thanks - But I don't understand why that affects plugin installation.

I was assuming not, as the plugins would be installed under /root/.helm/plugins, and volume mounts won't affect that path?

[jizusun]

I was assuming not, as the plugins would be installed under /root/.helm/plugins, and volume mounts won't affect that path?

I guess, the volume mounts won't affect that path, but since we use -v "$(pwd):$(pwd)", and this user whoami: unknown uid 501 has no permission to /root/ folder

➜  Code git:(master) ✗ docker run -it --rm \
-u "$(id -u):$(id -g)" \
-v "$(pwd):$(pwd)" -w "$(pwd)" \
quay.io/roboll/helmfile:v0.106.1 \
bash -c 'ls -lah /root'
ls: can't open '/root': Permission denied
total 0

I mean we'd better use a non-root user in the Dockerfile.
Something like this:

https://github.com/jupyter/docker-stacks/blob/dc9744740e128ad7ca7c235d5f54791883c2ea69/base-notebook/Dockerfile#L12-L14

Do you agree?

[mumoshu]

@jizusun Thanks! That makes sense.

Regarding your suggestion, I don't disagree, but I'm not sure how it would work in practice.

If we used build args like https://github.com/jupyter/docker-stacks/blob/dc9744740e128ad7ca7c235d5f54791883c2ea69/base-notebook/Dockerfile#L12-L14, we can't customize it to match your actual UID at runtime(=what id -u returns).

So I have two options in my mind. (1) Make /root in the container readable from any user within the container or (2) Modify the dockerfile entrypoint to run chown /root (oh but this doesn't work as once we specify -u $(uid) the user that runs the entrypoint has no root priv in the container to successfully run chmod?

[jvergara-runbuggy]

Hey, you can look at the image created by Codefresh:
https://github.com/codefresh-contrib/cfstep-helmfile

[felipecrs]

If running as the user in the host is indeed needed, the best solution that I can think of is fixuid.