0

This is more of a Docker question that anything else, I think, but allow me to describe the situation first.

We upgraded the base image to one of our containers from php:7.3.28-fpm-alpine3.13 to php:7.3.28-fpm-alpine3.14. The items that changed within the images included:

  • Alpine Linux: from version 3.13.5 to 3.14.0 (according to cat /etc/os-release )
  • Nginx: from 1/18.0 to nginx/1.20.2

Neither the nginx config files nor the Dockerfile used to generate both final images were changed between builds. However, netstat -tulpn had a much different story to tell.

A container built with the older image revealed:

# netstat -tupln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      51/nginx
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      51/nginx
tcp        0      0 127.0.0.11:36625        0.0.0.0:*               LISTEN      -
tcp        0      0 :::9000                 :::*                    LISTEN      52/php-fpm.conf)
udp        0      0 127.0.0.11:57860        0.0.0.0:*                           -

The newer one revealed:

# netstat -tupln

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.11:40511        0.0.0.0:*               LISTEN      -
tcp        0      0 :::9000                 :::*                    LISTEN      49/php-fpm.conf)
udp        0      0 127.0.0.11:49917        0.0.0.0:*                           -

So I don't know which component upgrade is responsible for the sudden refusal to listen to either port 80 or port 443.

I think I'll have to deal with a similar situation again, so I'm very interested in ways to diagnose and isolate this kind of problem. I pored through release notes for all components in question, but didn't notice any changes that would shut off access to the ports.

I think nginx would be the most likely culprit, but I have no way of knowing that. Its main config file looks fine:

# cat /etc/nginx/conf.d/default.conf
server {
    listen 80 default_server;
    include ssl.conf;

    server_name my_server.test;

    root /var/www/html/my_server;
    index index.php;
    location / {
        try_files $uri $uri/ =404;
    }

    rewrite ^/v1/(.*) /api.php/$1 break;

    location ~ [^/]\.php(/|$) {
        include php-fpm.conf;
    }
}

Is this a known (but not very well documented) issue? What else can I examine?

AckThpfft
  • 1
  • Is nginx running at all? And what do the logs say? – Håkan Lindqvist Jan 13 '23 at 18:23
  • Nothing. Not in the docker logs for the container, nor underneath /var/log within it. I'm wondering if I need to use the _server_ directive for both 80 and 443 now. (And if so, why didn't I need to do so with the earlier version??) – AckThpfft Jan 13 '23 at 19:21
  • It's not listening on either port as far as I understood your description? I kind of assumed that the `ssl.conf` file that you included has the other listen directive? For clarity: is nginx running at all? – Håkan Lindqvist Jan 13 '23 at 19:28
  • It is. But I noticed that the _/etc/nginx/conf.d_ directory is missing in the upgraded container. Very strange. – AckThpfft Jan 13 '23 at 19:42

1 Answers1

0

I've experience similar and it was due to nginx attempting to open a privileged port (below 1024) when docker was running as a non-root user.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
Andy
  • 1