2 min read

Docker networks

I had an issue recently, trying to access one docker container from another one - when they were part of different apps & the option of using the host's ports wasn't available & where one of the apps (Huginn) wasn't using standard internal ports (80 & 443) - it was only available on port 3000. That meant that the usual means of referring to a container by name, with the protocol being defined as http/https was doomed to fail. I already had a reverse proxy on the same host, using ports 80 & 443 for the localhost - although these are available "privately" within the docker networks without causing a clash as long as you don't use them to do more than access a single container (a bit like if each container was a separate computer - they can all have a port 80, but you have to specify which computer's port 80 you want to talk to)

After a lot of poking & eventually asking for help it was pointed out the you can use a reverse proxy to redirect the ports used (so listen on port 80 & pass that to the container of interest on port 3000 for example)...

I only really have need for a single purpose “internal reverse proxy sidecar container”, to connect huginn to a test install of tt-rss, but there’s no reason that this can’t be extended to handling multiple services through a single instance of the caddy container. I’ll assume that you’re using linux & have chosen to keep your docker stuff in your home directory…
Change the <user> to your own username & alter the networks to suit your needs:

$ cd ~/docker/
$ mkdir caddy
$ mkdir caddy/config
$ mkdir caddy/data
$ mkdir caddy/conf
$ cd caddy
$ nano docker-compose.yml
services:
caddy:
image: caddy:2.8.4-alpine
container_name: caddy
restart: unless-stopped
cap_add:
- NET_ADMIN
ports:
- “7080:80”
- “7443:443”
- “7443:443/udp”
volumes:
- /home/<user>/docker/caddy/conf:/etc/caddy
- /home/<user>/docker/caddy/data:/data
- /home/<user>/docker/caddy/config:/config
networks:
- caddy_default
- ttrss_default
- huginn-default

networks:
caddy_default:
ttrss_default:
external: true
huginn-default:
external: true
$ nano ./conf/Caddyfile
(logs) {
log {
output file /data/logs/docker-access.log
}
}

:80 {
reverse_proxy huginn:3000
}
$ sudo docker compose up -d

The networks part of the docker-compose.yml joins caddy to the networks (apps) that need to be able to see each other. Which lets container to container DNS work so that we can use the container name for access. i.e. ttrss can “see” caddy, & caddy can “see” huginn, which is what is needed.
The Caddyfile just redirects all incoming traffic on port 7080 to the huginn container, at port 3000. If there were more apps then they could be filtered into the correct containers using the URL that was sent to caddy. Something like this:

:80 {
@h huginn
handle @h{
reverse_proxy huginn:3000
}
@r redlib
handle @r {
reverse_proxy redlib:8080
}
}

(It’s worth pointing out again that my issue was with having a reverse proxy on the same host, so ports 80 & 443 were in use. That doesn’t stop you using that reverse proxy to forward requests & their requested URL to caddy on port 7080 though, all that you need is a suitable proxy URL (for each service that you want to link - together with sharing their networks). Or you can do what I did & refer to the caddy container from within the docker network - so ttrss can refer to caddy in the RSS URL by using the docker internal DNS & the visibility allowed by the shared docker networks e.g.
http://caddy/users/1/web_requests/33/Lemmy-Highlights.xml)

Also posted on the tt-rss forum

Andy