Rootless podman and django project composed with nginx container?

[amkearns-usgs]

My group is in charge of developing a few django-based projects. We are looking into making them containerized for potential off-premises deployment. These projects have static files and thus simply running gunicorn inside a container with a django project's source code is not sufficient for serving content.

As we are running off a test server on ubuntu 22.04, we are using the packaged podman (rootless) and pip-installed podman-compose:

> podman-compose --version
podman-compose version 1.5.0
podman version 3.4.4

Meanwhile, here's what the docker-compose file we are using for a (genericized) project looks like:

secrets:
  settings:
    file: ./local_settings.py

services:
    nginx:
        build:
          dockerfile: nginx.Dockerfile
        ports:
          - "8001:80"
        volumes:
          - static:/var/www/html/static
          - ./nginx.conf:/etc/nginx/conf.d/default.conf
        depends_on:
          - djproj
    djproj:
      container_name: djproj
      hostname: djproj
      restart: always
      volumes:
        - static:/var/www/html/static
      build:
        dockerfile: djproj.Dockerfile

volumes:
  static:

The main reason that we have a custom nginx Dockerfile is to add some SSL certs to deal with intranet filtering/monitoring, otherwise we'd probably use the stock image. Pulling content into the django project's container does require it.

EXPOSE 80 is set in both dockerfiles.
The nginx.conf file that gets passed in as a volume looks like this:

server {
        listen 80;
        location /static/ {
                alias /var/www/html/static/;
        }

        location / {
                proxy_pass http://djproj:80;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote-addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
        }
}

The idea here is that the nginx server should be able to serve all the static content and then direct traffic to the djproj container if something else is requested. When the djproj container runs it does python manage.py collectstatic before running gunicorn [gunicorn djproj.wsgi --bind 0.0.0.0:80] which should ensure all the project's static content is set in the static volume (since the static root setting starts with /var/www/html/static).

The problem is that hostname in the djproj isn't recognized, per podman logs djproj_nginx_1 (edited to relevant content):

/docker-entrypoint.sh: Configuration complete; ready for start up
2026/03/04 23:24:22 [emerg] 1#1: host not found in upstream "djproj" in /etc/nginx/conf.d/default.conf:8
nginx: [emerg] host not found in upstream "djproj" in /etc/nginx/conf.d/default.conf:8

This may be an issue with using the apt podman, that the version is actually too old and does not support the kind of rootless networking I want, if it is possible at all.

I have manually updated the containernetworkingplugins to 1.1.1 using the debian package available here: https://archive.ubuntu.com/ubuntu/pool/universe/g/golang-github-containernetworking-plugins/containernetworking-plugins_1.1.1+ds1-3build2_amd64v3.deb

If you are curious about podman info as it pertains to networking, it uses slirp4netns:

  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1

And the plugins:

plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local

I did not thoroughly examine the slirp4netns documentation. Looking up info related to this error suggests that the error may be due to nginx container starting up too soon, or it might be that the network interface requires exposing ports on the server's interface rather than leaving them internal.

My understanding is that docker can do this with internal ports, so if we were not running rootless we would not have that issue. For straightforward security reasons, we would prefer to run rootless and not expose ports if it is necessary. Is there any configuration that will allow us to do that? What is recommended here?

[amkearns-usgs]

Because it was preventing startup, I removed the proxying lines from the nginx config to see what would happen if I could start the nginx container up, allowing me to see its /etc/hosts file:

127.0.0.1 localhost
127.0.1.1 [host machine name]

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.88.0.3	369cd501a8cc djproj_nginx_1
10.88.0.1 host.containers.internal

And the same for the djproj container:

127.0.0.1 localhost
127.0.1.1 [host machine name]

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.88.0.2	djproj djproj
10.88.0.1 host.containers.internal

Now, correct me if I'm wrong, but shouldn't the containers have entries for the other machine, given the shared network and exposed ports?

Given that I am running a version of podman from the OS's package manager, I am hesitant to do further piecemeal updates to try to get a configuration that actually works. I understand that the netavark backend may fix some of these issues, but I do not know if it is compatible with podman 3.4.4 and do not want to break things further by updating only that and not the rest of the project; however, I am only using 3.4.4 because it is what apt provides for ubuntu 22.04.