latest version does break docker-compose wordpress setup

The latest version with tag latest pushed to hub.docker.com 3 days ago is breaking our docker-compose nginx setup. All other 80 containers for all systems do work except for the two wordpress containers for our websites. We do have a docker-compose setup with nginx-proxy and letsencrypt-nginx-proxy-companion which is the frontend for more than 80 containers all running own docker-compose setups.

For both wordpress containers I do see in the nginx log that the nginx reload does exit with status 1: nginx_1 | dockergen.1 | 2021/08/25 17:13:30 Error running notify command: nginx -s reload, exit status 1

I am unable to find what is causing the error.

Going back to the verstion with tag 0.9.2 that was pushed to hub.docker.com 14 days also the two wordpress container do work again without any problem. So something in the latest version is breaking our nginx docker-compose setup for the wordpress containers.

Can I somehow enable additional logging to find out why nginx does exit with status 1?

Both containers are contacted with fastcgi_pass <domain>:<external port>, i.e. mydomain.com:9002. One of the wordpress containers does run with:

     ports:
       - '9002:9000'

and the other one with

     ports:
       - '9004:9000'

[buchdag]

Hi. We will need more detailed information if we want to troubleshoot this : compose file for nginx-proxy and acme-companion, compose file(s) for the the WordPress containers, result of docker exec yournginxproxycontainer nginx -T.

On a side note please do not use the latest tag for production setups. This recommendation stands for pretty much every Docker image. latest is nothing more than a convenient default if no specific tag is provided, there isn’t any convention on what goes into this tag over different projects, and it does not carry any promise of stability.

[GuidoDr]

thanks for your help. “I’m not certain if you really fixed it in a stable way with SHA1_UPSTREAM_NAME or if it’s an accidental fix.” Well perhaps you’re right and it is just an accidental fix. At least just setting SHA1_UPSTREAM_NAME to true in the docker-compose.yml file did make the websites available again.

The problem is that the original setups on our server were done by someone who is no longer available in our small team of volunteers and I am not really familiar in nginx-proxy setups with docker containers that run with docker-compose behind the frontend nginx-proxy and letsencrypt-nginx-proxy-companion combination in another docker-compose setup. 😦 But I am willing to learn new topics. 😉 In the meantime I am able to do new setups of new systems or modify and upgrade the existing systems. I read thru a lot of information found by a google search about nginx wordpress docker-compose setups. But the configurations there were not like ours with the different directories and docker-compose.yml files for each system and the nginx-proxy and letsencrypt-nginx-proxy-companion combination in front of all the different systems.

I do not know if the original plan for the wordpress sites really has been to bypass the nginx-proxy and open a direct port 9002 or 9004 on the host. Originally it had been just expose: 9000 in the docker-compose config file but at a later time it was changed to ports: with external ports 9002/9004 and container port 9000. In a short documentation from our former admin I found that the websites will be accessed by fastcgi with config files in nginx/vhost.d , where the server_name and server_name_location files are located that I mentioned (in a little bit modified form) above. I do not know if the fastcgi setup is the preferred way to have wordpress sites on a server together with other systems or if they should better accessed with another setup.

I will do a little more research about wordpress sites behind the nginx-proxy and letsencrypt-nginx-proxy-companion combination. Perhaps I will have to find someone to show me what would be the best way to do the wordpress sites setups in our server configuration.