Docker patterns when using gomplate?

[JeffSpies]

Hi - huge fan of gomplate here, but I'm trying to integrate it with a docker/docker-compose setup and am running into issues. I know this is more of a Docker issue, so feel free to close as off-topic, but I'm wondering if you have recommendations for usage patterns.

EDIT: while creating a reproducible example repo, I discovered that what I'm doing below by adding --user to the docker run with gomplate did in fact work correctly without permission issues when the output folder on my host (build/) didn't have a .gitkeep in it. Not sure what's going on here, but there may be a follow-up--I suspect there's a permission check in go or gomplate that saw a root-owned .gitkeep (shouldn't have been the case, but maybe) or maybe an editor-locked .gitkeep file and thought the whole directory couldn't be written to. I'll update if I find the answer.

I have a straightforward docker-compose setup with postgres and nginx. I'm using gomplate from docker via the CLI to do some more advanced templating in an nginx config file than normal:

docker run \
		--env-file $(ENV_FILEPATH) \
		-v $(PWD)/$(TEMPLATES_DIR):/input \
		-v $(PWD)/$(BUILD_DIR):/output \
		hairyhenderson/gomplate: \
		--input-dir /input \
		--output-dir /output

but this writes out /output as root, meaning my build directory on the host machine is written to as root. So I tried passing --user to the command line with my UID and GID, but then gomplate complains that it can't write to /output (because of course, in the container, the user that owns / is root). Tried playing with the alpine tagged container as well--no dice.

I suppose I can write my own docker file for nginx, add gomplate, etc., but that doesn't seem ideal--trying to keep this tight for future maintainers. Same thing for gomplate--adding the user/group properly in a dockerfile, etc.

I'm going to install gomplate locally for now to avoid the issue entirely, but I wonder if you have pattern recommendations or, perhaps, we can think building some of this permission wrangling into the gomplate template so it can more easily be dropped into workflows (unless of course I'm missing something, which is very likely possible).

Again, sorry for the noise if this is off-topic. Killer tool though; would love to integrate it further.

[JeffSpies]

A non-issue until I figure out how permissions in go/gomplate and if that was the root of the problem.

[hairyhenderson]

Hi @JeffSpies - this is an interesting problem for sure, and I'm glad you found a workaround.

I'm going to move this over to discussions as this isn't a bug, but I've got information to add to this 😉

[hairyhenderson]

The way that Docker handles permissions for bind-mounted volumes when running as non-root certainly feels inconsistent...

On a Linux machine, I see two different behaviours:

First, if the directory doesn't exist:

$ docker run -it -v $(pwd)/temp:/temp -u 100:100 alpine ls -ld /temp
drwxr-sr-x    2 root     root          4096 Apr 23 00:56 /temp
$ ls -ld temp
drwxr-sr-x 2 root 4096 Apr 22 20:56 temp

In this case, the directory is created, and owned by root.

But if I pre-create it:

$ mkdir temp
$ ls -ld temp
drwxr-sr-x 2 hairyhenderson 4096 Apr 22 20:57 temp
$ docker run -it -v $(pwd)/temp:/temp -u 100:100 alpine ls -ld /temp
drwxr-sr-x    2 1000     1000          4096 Apr 23 00:57 /temp

This makes sense - the uid/gid are preserved.

The behaviour, however, is different on macOS, running Docker Desktop, which has various layers of translation:

$ docker run -it -v $(pwd)/temp:/temp -u 100:100 alpine ls -ld /temp
drwxr-xr-x    2 root     root            64 Apr 23 00:59 /temp
$ ls -ld temp
drwxr-xr-x 2 hairyhenderson 64 Apr 22 20:59 temp

When the directory doesn't exist at first, it's created, and appears to be owned by root inside the container, but outside it's owned by my user (!)

If I pre-create the directory:

$ mkdir temp
$ ls -ld temp
drwxr-xr-x 2 hairyhenderson 64 Apr 22 21:00 temp
$ docker run -it -v $(pwd)/temp:/temp -u 100:100 alpine ls -ld /temp
drwxr-xr-x    2 root     root            64 Apr 23 01:00 /temp

At least it's consistent, I guess? Depending on which OS you're using, this may have been relevant.

[adrianbumbas]

This is causing issues in Kubernetes where I use gomplate as an init container and the deployment has runAsNonRoot: true security context set. As far as I know there is no reason for gomplate to have any privileges.

[hairyhenderson]

[...]did in fact work correctly without permission issues when the output folder on my host (build/) didn't have a .gitkeep in it.

Ah... The presence of a .gitkeep implies that the output directory was pulled from a git repo. It's a convention sometimes used to make sure otherwise-empty directories are tracked by git. If the .gitkeep file was owned by root that implies that the repo was cloned as root, and therefore the directory would've been also owned by root.

Alternately, is it possible that the repo was cloned by a different user, with a different UID than the one you ran the container with?

Anyway, while this is indeed not directly gomplate-related, I'd be interested in hearing if you get to the bottom of this 😉