tiredofit / docker-wordpress

Dockerized Content Management System many with customizable options
MIT License
36 stars 7 forks source link

Running with existing site files #9

Open juanluisbaptiste opened 4 years ago

juanluisbaptiste commented 4 years ago

Hi,

I'm testing the images with one of our existing sites on my local machine, I replaced the volume wordpress directory with the contents of our wordpress installation (using an external database) and started the service up. The site works but it is timing out on nginx, so it takes a long time to load (until it times out). This is the error in nginx's error.log:

2019/12/20 18:08:12 [crit] 1054#1054: *23 connect() to [::1]:9000 failed (99: Address not available) while connecting to upstream, client: 172.18.0.1, server: , request: "GET /sobre-grival/nuestra-marca HTTP/1.1", upstream: "fastcgi://[::1]:9000", host: "www.website.com", referrer: "http://www.website.com/"
> 2019/12/20 18:08:12 [warn] 1054#1054: *23 upstream server temporarily disabled while connecting to upstream, client: 172.18.0.1, server: , request: "GET /sobre-grival/nuestra-marca HTTP/1.1", upstream: "fastcgi://[::1]:9000", host: "www.website.com", referrer: "http://www.website.com/"

As this is a local install, the domain I'm using does not exist, I add it to /etc/hosts. I have also tested adding external_hosts to the compose file but the error still appears so I really don't know what else to look, I'm not an nginx expert.

Any ideas on what could be going on ?

Thanks

juanluisbaptiste commented 4 years ago

I ran it on a pubic instance with an existing hostname and there is no more time outs. Any idea how to do this locally and avoid that issue ?

tiredofit commented 4 years ago

That's bizarre that it can't find the locally installed PHP engine. I'm seeing what looks like IPv6 in the logs there, even though inside the application I'm referencing 127.0.01:9000. Can you post the assembled nginx/conf.d/default.conf for me (with any bits stripped if need be).

juanluisbaptiste commented 4 years ago

Here it is:

# more default.conf 
    server {
      listen 80;

      root /www/wordpress;
      index  index.php;

      location / {
        try_files $uri $uri/ /index.php?$args;
      }

      location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        if (!-f $document_root$fastcgi_script_name) {
          return 404;
        }
        include /etc/nginx/nginx.conf.d/php-fpm.conf;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      }

      # Deny access to any files with a .php extension in the uploads directory
      location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
      }

      ### Don't edit past here
      include /etc/nginx/nginx.conf.d/site_optimization.conf;
      include /etc/nginx/nginx.conf.d/exploit_protection.conf;
}
juanluisbaptiste commented 4 years ago

This is still happening from time to time, now that I'm starting to deploy the production swarm cluster where I'm running the wordpress sites. Now I'm testing with the existing hostnames (that are still pointing to the current host where the were the sites are hosted at the moment) and pointing them to the load balancer in front of the instances where the wordpress containers are running and I get the same error, so it seems it is indeed related to hostname resolving ?

I'm going to do some tests using existing hostnames and see what happens.

This is starting to really stress me out as I have the project's deadline on monday and this issue makes me no confident on what I would be delivering that day. I hope you could take a look at it soon we :smile:

tiredofit commented 4 years ago

I actually was referencing localhost for the PHP_FPM_HOST variable - which may be the issue.

Release 5.3.0 of the upstream nginx-php-fpm image now uses 127.0.0.1 as the host.

There's a new mode in there that may work better for your swarm usage - CONTAINER_MODE=php-fpm will run the php-fpm engine standalone, and CONTAINER_MODE=nginx will allow you to input multiple backend hosts for PHP_FPM_HOST disabling the in container version of php-fpm. You could then take advantage of some of the nginx upstream parameters here: https://nginx.org/en/docs/http/ngx_http_upstream_module.html.

Interested to try to figure out just what is happening here.