After my previous post here looking for input on an easily maintained docker and reverse proxy setup, I opted to go for NPM. I also moved my domain registration and DNS from Google Domains to Cloudflare.
It was a breeze to set up for the most part, I did have some pain getting my certs in order - NPM easily pulled down certs from LetsEncrypt, but Cloudflare didn't like it unless I used their 15-year origin server cert, which worked perfectly. I set up Portainer first, then wordpress and NPM. (I'm generally comfortable with command-line stuff, but I have much less experience with Docker so Portainer is great for someone like me.)
I specified a network I created ("proxy") in the docker compose files, and that allowed me to use the container name in NPM to set up the proxy hosts. I quickly and easily set up proxy hosts for the main domain (points toward the WP container), a portainer subdomain pointing to the portainer container, and an NPM subdomain pointing to NPM. At this point things have been easy, everything is working beautifully, and I'm thinking about all the other things I want to eventually spin up and host.
Then I started with FreshRSS. I was able to set it up - I could access it via the IP:port but no matter what I did, the subdomain gave me Cloudflare's 502 Bad Gateway error. I adjusted the BASE_URL in the container, I've tried all sorts of settings in NPM - http, https, using different subdomains, different ports, etc (changing them in the docker compose as well of course) but no dice. I did some searching around and found a few examples like this and this where I've seen others having similar issues and not being able to fix them.
So I thought maybe it was some kind of weird issue with FreshRSS specifically, so I removed it and spun up Miniflux instead. Same as the previous time - I could access Miniflux perfectly well via the IP:port but the reverse proxy gives me a 502 every single time. The containers are on the same network. What am I missing with these?
For reference, here's the docker compose for the miniflux stack:
services:
miniflux:
image: miniflux/miniflux:latest
container_name: miniflux
ports:
- "8099:8080"
depends_on:
db:
condition: service_healthy
environment:
- DATABASE_URL=postgres://miniflux:secret@db/miniflux?sslmode=disable
- BASE_URL=[redacted]
db:
image: postgres:15
container_name: miniflux_db
environment:
- POSTGRES_USER=miniflux
- POSTGRES_PASSWORD=secret
volumes:
- /media/config/miniflux:/var/lib/postgresql/data
healthcheck:
test: ["CMD", "pg_isready", "-U", "miniflux"]
interval: 10s
start_period: 30s
networks:
default:
name: proxy
Here is an example of the NPM setup. Cloudflare is the access list I created that limits it to Cloudflare's IP ranges, and the site-wide origin cert is selected on the SSL tab, just like my other proxy entries which are currently working.
Repost from kbin directly since federation is being weird.
I use a similar setup with dockerized NPM. I see 2 things in this example that I do differently.
external: true
in the network definition. I'm not sure what compose will do if you don't. But I wouldn't want it making any new proxy networks accidentally.networks
list for each container you want accessible from NPM. I don't believe just defining it in the compose adds all containers to that automatically.Awesome, thanks...I'll try that. So to be sure I'm understanding - I want to add "external: true" beneath "name: proxy: and then add the following to each container in the compose?
I believe I might be doing that wrong because I get an error about undefined network when I try the below, and simply defining "external" doesn't fix it:
Interestingly - when I point it to port 80 at the freshrss host, it works. Which doesn't make sense to me, likely due to a fundamental misunderstanding of how Docker works? My understanding was the above compose would expose port 8040, not port 80. Setting it to port 80 didn't even cross my mind. I noticed that my wordpress compose listed "8080:80" and NPM was set to port 80, and it was already working...it was late last night when I got that up and running, so that might explain some of the confusion...
Ah ok I think I see some of the confusion. Docker networking is a little weird and imo compose abstracts a little too much away.
If 2 containers are on the same docker network they are exposing all their internal ports to each other with individual virtual network adapters. This is really nice because there's no issues with port overlap, each container has its own hostname and virtual adapter with all ports available.
The port mapping actually binds the internal port of the container to the port on your host. This is useful for applications outside of docker to connect directly, but not necessary for anything you want behind the reverse proxy anyway.
That makes sense - thanks for the explanation!