Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to pass Caddyfile config via environment variable #248

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

haraldreingruber-dedalus
Copy link

@haraldreingruber-dedalus haraldreingruber-dedalus commented Jul 14, 2022

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
Copy link
Contributor

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
Copy link
Author

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.

@haraldreingruber-dedalus haraldreingruber-dedalus changed the title Allow to pass Caddyfile convig via environment variable Allow to pass Caddyfile config via environment variable Jul 18, 2022
Copy link

@polarathene polarathene left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +4 to +8
# Check if Caddyfile config is passed via $CADDYFILE
if [[ "$CADDYFILE" ]]; then
echo 'Storing $CADDYFILE variable to ./Caddyfile'
printf "$CADDYFILE" > Caddyfile # echo doesn't preserve newlines
fi
Copy link

@polarathene polarathene Sep 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +10 to +13
# Running passed command
if [[ "$1" ]]; then
exec "$@"
fi
Copy link

@polarathene polarathene Sep 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants