Disclaimer: I'm no devops, so please tell me if I'm doing this wrong.
I have a webapp in a container. I use Podman and Podman Compose to bring it up. In compose.yml, I expose the port 5000 and bind it to the internal port 80. Here's a quick diagram:
┌────────────────────────────────────┐ │ PODMAN COMPOSE │ │ │ │ ┌────────────────────────────────┐ │ │ │ PODMAN CONTAINER │ │ ┌─────────────────┐ │ │ │ │ │ │ proxy_pass │ │ │ │ │ │ http://localhost:5000 │ │ NAME: my_container │ │ │ NGINX │───────────────────────────►│ │ │ │ │ │ │ │ INTERNAL PORT: 80 │ │ │ │ │ │ EXTERNAL PORT: 5000 │ │ └─────────────────┘ │ │ │ │ │ │ NETWORK: my_container_default │ │ │ │ │ │ │ └────────────────────────────────┘ │ │ │ └────────────────────────────────────┘ Note: Nginx is running on the server directly and I want it to be a reverse proxy for the several apps that I'll install on my server (e.g. if this domain, go to localhost with port 5000, but with this domain, go to localhost with port 5001, etc. etc.).
This works... but only if I set SELinux to permissive :/
I tried to add some rules with semanage but I really don't know what to do here. While in enforcing mode, I tried this command-line: sudo semanage port -a -t http_port_t -p tcp 5000 but it didn't seem to work.
So I've got two questions:
- Is my design correct? (i.e. raw Nginx forwarding to container)
- If it is, what's the correct
semanagecommand-line? If it's not, what's the correct design?
Thanks!
httpd_can_network_connectSELinux boolean as described here: serverfault.com/questions/1082399/… The design itself, having a single host-wide nginx instance, is perfectly fine (I'd use exactly this option if I needed to serve several different dockerized web apps), though it requires you to manage a larger and more complex combined nginx configuration.server { server_name app1.example.com; location / { proxy_pass http://127.0.0.1:<exposed_app1_port>; } }(somewhat simplified). Using the joined configuration at the top level nginx allows you to eliminate an extra proxying layer (better performance) though you'd need to assemble the joined configuration yourself.server { server_name example.com; location /app1/ { proxy_pass ... } location /app2/ { proxy_pass ... } ... }). Generally, the apps should be set up to use the appropriate base path unless the app is able to detect such a prefix automatically.