Hello! New here to Caddy and the Caddy community. I just set up Caddy (v2) with the official docker image, using the docker flag --network host. It seems to simplify my life a lot, since I now can manage it as if it was running directly on the host machine. I can point it to localhost etc
I now wonder - are there any caveats with doing it like this? Security concerns etc. (I was thinking about the admin port but if I understood it correctly it should still only be reachable from localhost).
docker command:
docker run -d --network host -v caddy_data:/data -v caddy_config:/config -v $PWD/Caddyfile:/etc/caddy/Caddyfile --name stoic_cannon caddy caddy run --watch --config /etc/caddy/Caddyfile
I split your post into a new thread — please don’t post new questions on old threads!
Yes, using --network=host is fine if your usecase is that you don’t have your other services dockerized. Effectively you’re running it like if it wasn’t dockerized from the perspective of networking.
First of all, the reason I “recycled” the other topic was that I was under the impression that I was basically asking the same question. “How do I use caddy-docker as a reverse proxy for other docker containers?” But sure, I didn’t mind to get a thread of my own.
Second, why would my suggestion imply that I don’t have other services dockerized? If I for example run a node-app in a container and expose it on port 3000, I should be able to just point caddy to localhost:3000?
What is the recommended way of running a caddy container and using it as a reverse proxy to point it to other containers (maybe running on different docker networks)?
If you use something like docker-compose to orchestrate your containers, then it becomes very easy to reverse proxy to your other containers. Instead of using localhost, you would use the docker-compose service name.
For example, if you’re running a caddy service and say, a django-app service, then you could do:
reverse_proxy django-app:3000
This makes use of Docker’s internal DNS, which docker-compose uses to add hostnames for each container running in a network.
Hmm, yes I get what you are saying. The reason I wanted to have caddy on the host was that I tend to have one docker network / stack per application. But maybe I should reconsider this and have them run on the same docker network. I’m not really sure.
What you can do is make the caddy container join each of your other separate networks (with docker network connect <network> <container> or via docker-compose networks:).