So this is what it should look like… for those who are familar with the OMV plugin know that it looks a little different
For that Caddyfile the docker hub says the path inside the docker container should be /etc/Caddyfile which is now working … i´ve changed it to /etc and it works.
But now to my Problem… i want to use caddy as a reverse proxy using my dynamic dns “xxx.darktech.org” - i´ve used this quite a while running let´s encrypt container with nginx from linuxserver.io but wanted to try caddy because it looks very interesing to me.
2017/07/08 23:12:31 get directory at 'https://acme-v01.api.letsencrypt.org/directory': failed to get json "https://acme-v01.api.letsencrypt.org/directory": Get https://acme-v01.api.letsencrypt.org/directory: x509: failed to load system roots and no roots provided
What also makes me wonder is the i bind mount the host path /home/caddy/certs to /root/.caddy and after starting the container i have a Certificates DIR on my Host in /home/Caddy/Caddyfile
I think you’re misunderstanding how volume mounting works.
You have a Caddyfile, but you’re mounting it to /etc. That means Docker is going to replace the directory/etc inside the container with a file called etc that has the contents of the Caddyfile.
The side effect of this is that you have no /etc directory - and the result is a laundry list of missing important configuration and system files. Among other things, this means you have no default (system) trusted root certificate authorities. Your container no longer has any reference by which to validate HTTPS certificates in the wild. It can’t even trust Letsencrypt’s website any more.
If you try @astei’s example instead, you’ll have your /etc folder still, but there will be a Caddyfile just inside, at /etc/Caddyfile.
When i try to bin mount /home/Caddy/Caddyfile to /etc/Caddyfile the container won´t even start.
Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; docker run -d --restart=always -v /etc/localtime:/etc/localtime:ro --net=bridge -e PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" -v "/home/caddy/Caddyfile":"/etc/Caddyfile":rw "abiosoft/caddy:latest" 2>&1' with exit code '125': c9e00e9da4c83548381cfacb6c75584191614ae27262b765529900f9a2bb2963 docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:54: mounting \\\"/home/caddy/Caddyfile\\\" to rootfs \\\"/var/lib/docker/overlay2/761ee8aa765d062c870bc76ee483c7b55e0887f2f25ca6b88d026951f2124a6a/merged\\\" at \\\"/var/lib/docker/overlay2/761ee8aa765d062c870bc76ee483c7b55e0887f2f25ca6b88d026951f2124a6a/merged/etc/Caddyfile\\\" caused \\\"not a directory\\\"\"" : Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.
I´ve never had that much trouble with a container before…
Anyway i´ve pulled joshix/caddy container now and it works like a charm
On the host filesystem, is home/caddy/Caddyfile a file or a directory?
In the abiosoft/caddy container, /etc/Caddyfile is a file. If home/caddy/Caddyfile on the host is in fact a directory containing your Caddyfile inside it, and you tried to mount it to the location of a file, that would give you that error.
In fact, home/caddy/Caddyfile being a directory would explain how you were able to mount it to /etc without getting that error in the first place.
Yep. Link the Caddyfile in directly, file to file. Assuming the host file is called Caddyfile inside the directory /home/caddy/Caddyfile, you’d want -v /home/caddy/Caddyfile/Caddyfile:/etc/Caddyfile, if you were still planning to use the abiosoft/caddy container.
Quick tips for Docker, because I suspect most of these apply here:
Don’t rely on the container runtime to create any directories. Their ownership might be off and don’t match the user caddy runs as.
Run containers with docker … run … --read-only --rm … <image>… and mount the directories to be served as well as /etc/caddy/ as volumes.
If caddy’s apparent user is ›root‹ (as seen from the host), then abandon the Docker image in favour of a different one. Never expose any process that runs as root to the net. (Or use Docker’s/Linux’ user mappings for the container, but that’s a different topic.)
… and, admittedly less important:
Start the Docker daemon with --userland-proxy=false, it’ll skip Docker’s proxy process(es) for better performance.
This sounds interesting, never looked too far into it before. Googling it resulted in some Docker docs referring to hairpin NAT (which I’m vaguely familiar with) and iptables (which I try to avoid at all costs because I don’t grok iptables, unfortunately).
Curious what other ramifications configuring the Docker daemon in this way might have?
I did understand the words you’ve mentioned, but not quite your question. (Furthermore: off-topic?)
I suggest giving this a try, and test if a container A talks to container B using the IP address of the host (use exposed ports, of course). Unless you run very old Linux it should work flawlessly.
Anyway, especially on brutally slow machines, and when using non-TCP protocols (currently UDP), the Docker proxy should be avoided. I’ve mentioned this repeatedly on chat and here, so nobody runs into this and opens an issue, only for us to find the proxy caused it.
