Allow to pass Caddyfile config via environment variable

[haraldreingruber-dedalus]

Sometimes it can be convenient to pass the config via an environment variable in order to avoid mounting a config file into the docker container.

For example, I wasn't able to figure out an elegant way to pass a Caddyfile from an Azure Container Group YAML.
This way I was able to avoid creating an Azure File Share that can be mounted.

Implementation

An entrypoint.sh script was added, which checks if the variable CADDYFILE is set. If it is, the content is written to ./Caddyfile.
Afterward, the command passed to the container is executed.

Usage example

This PR can be tested like this with docker compose

version: "3.9"
services:
  caddy:
    image: haraldreingruberdedalus/caddy:latest
    command: 'cat Caddyfile'
    environment:
      CADDYFILE: |
        # Reverse proxy from localhost:80 to localhost:8080
        localhost:80 {
          reverse_proxy localhost:8080
        }

Maybe there are more elegant ideas to achieve this. Looking forward to your input.

[hairyhenderson]

I don't think that entrypoint script will correctly propagate signals to the Caddy process.

In general I would recommend either mounting the Caddyfile in, or creating a new image with the Caddyfile baked-in.

[haraldreingruber-dedalus]

I don't think that entrypoint script will correctly propagate signals to the Caddy process.

Thanks for the great remark.

I've looked up how entrypoint scripts can forward signals to the main process. Apparently, when using exec instead of eval caddy is not started as a child process and handles signals correctly. I've updated the PR accordingly.

[polarathene]

This isn't something I'm interested but I thought I'd provide a bit of feedback.

[polarathene]

Doesn't this run from the WORKDIR that is set to /srv? While the --config for CMD is set to /etc/caddy/Caddyfile? Is that intentional?

---

NOTE: the ENV check is using [[ ... ]], this is bash specific and not supported by plain sh AFAIK. In this case /bin/sh is symlinked to busybox; ash also symlinks to that - busybox is compatible with this syntax, although it wouldn't hurt to instead use #! /bin/ash though? :)

Have you tested that this is working correctly? Surely you're changing the CMD on your end if that is the case?

[polarathene]

This will be true all the time (custom CMD passed in, or falling back to default CMD), unless the ENTRYPOINT is modified when extending theDockerfile (seems to apply to both "shell" and "exec" forms of ENTRYPOINT ignoring the CMD directive). Whereas only the "shell" form of ENTRYPOINT while in the same stage as the CMD directive results in CMD being ignored.

If the --entrypoint option is used (always "exec" form), then CMD from the Dockerfile is ignored (even if referencing the same entrypoint.sh file the original ENTRYPOINT would have used). Only when an explicit command is provided after the image name with docker run will the $@ have any values/args that can be processed.

Is the check for args (command) being provided serving any real purpose? (could just exec $@ without the conditional?)