I think that’s more “smarts” than the Caddyfile was designed for. I don’t think we’ll implement something like that.
You’re probably better off writing a bash script which performs those expansions yourself. Emit it to a file like caddy-cors.txt, mount that at runtime, then do import /etc/caddy/caddy-cors.txt. The file would have this in it:
One last question though. When Caddy imports a file (like your example import /etc/caddy/caddy-cors.txt) is that file subject to templating? i.e. can templating generate Caddy instructions?
I then wrote a small ash script (to stay in the limits of Caddy base image):
for i in $(echo $CORS_ALLOWED_ORIGIN | tr "," "\n"); do
ADDRESS="https://${i}" # strictly https
cat >> /etc/caddy.d/cors.txt << EOF
@origin${ADDRESS} header Origin ${ADDRESS}
header @origin${ADDRESS} Access-Control-Allow-Origin "${ADDRESS}"
header @origin${ADDRESS} Vary Origin
EOF
done
caddy run --config /etc/caddy/Caddyfile --adapter caddyfile
And finally the Dockerfile:
FROM caddy:2.4.6
RUN mkdir -p /etc/caddy.d;
COPY META-INF/resources /static/
COPY caddycmd.sh /usr/share/caddycmd.sh
COPY Caddyfile /etc/caddy/Caddyfile
RUN chmod +x /usr/share/caddycmd.sh
CMD ["sh", "-c", "/usr/share/caddycmd.sh"]
The result is not too onerous
However, Caddyfile would be super powered by allowing go templates on import. Since, as you stated, all imports are resolved before the Caddyfile is parsed, it’d be no different than having an external template engine generate the Caddyfile (except no need for external dependencies. You have the go template engine right there.)
Anyway, just food for thought.
But thanks a bunch for the already awesome product.