ddns: Recreating ddns_caddy_1 error

No it doesn’t fetch something from a repo. docker-compose run does not rebuild the containers by itself https://github.com/docker/compose/issues/1487 so you have to explicitly build the containers via docker-compose build and remove the old containers via docker-compose down before executing the run command from the docs again.

Feel free to close this issue if you problems have now been solved.

If you create a host via the frontend a curl command is printed and this has to be executed from inside the network that you wanna access through the registered name. If you can successfully resolve the registered name via dig or nslookup ddns works correctly and the problem ist somewhere else.

dig something.d.somewhere.com A @8.8.8.8

You can control which DNS server should be used via the @x.x.x.x.

This port 2015 seems to be a caddy default when it doesn’t manages the TLS certificates itself and no https:// is used in the Caddyfile. There are multiple issues in the Caddy repo like the following https://github.com/mholt/caddy/issues/1673. You could probably fix this via the Caddyfile or you could map your external 443 port to 2015 inside the caddy container. I hope that it helps.

This normally consists of adding the local directory containing the certificates to the caddy container by declaring another volume like here https://github.com/pboehm/ddns/blob/master/docker/docker-compose.override.yml.sample#L27. You could add something like /local/path/to/certs:/etc/caddy-certs to the volumes list in the caddy container. Within the caddy container you then have access to these certificates and can reference them in the Caddyfile e.g via /etc/caddy-certs/cert.pem.

The Caddy webserver is totally optional and is only included in the docker-compose.override.yml sample to provide a working out-of-the-box setup. But you can remove it and use nginx as a reverse proxy (make sure that the X-Forwarded-For header is included, so that the real remote address is available to ddns) or you could configure Caddy to take your certificate which should be possible, but I haven’t used it.

Ok, cool that the original problem is solved. For the other problem the output of the caddy container would be interesting because after startup it tries to gather a TLS certificate for the configured domain. Until this process is successful, caddy probably does not serve the frontend code or responds to curl. If the errors are more low-level like “connection refused”, it probably has something to do with some firewall rules or that the docker port-forwarding for port 80 and 443 are bound to the wrong network interface. In this case you have to provide some more information like the output of netstat -tulpen.

Hi,

sorry for my late reply. Your docker-compose.override.yml looks okay for me. Looking at the original error message ... mounting /caddy/Caddyfile ......, the problem seems to be that the ${PWD} has not contained the current working directory but was empty https://stackoverflow.com/questions/41948232/docker-compose-wont-find-pwd-environment-variable?rq=1 . Could you try replacing ${PWD} with a ., this hopefully solves the problem.

Okay, could you provide your docker-compose.override.yml and please redact any sensitive data.

Hi,

without knowing anything about your setup (looking at the terminal font and all the backslashes in the screenshot, it is probably a Windows system?) the error probably refers to the following line in the docker-compose.override.yml https://github.com/pboehm/ddns/blob/master/docker/docker-compose.override.yml.sample#L27 where the Caddyfile is mounted into the caddy container.

If your setup is a Windows system the problem probably has something to do with paths, like the following issue https://github.com/docker/compose/issues/4303.

Please provide more information about your setup.

Philipp