3

I am running Drupal in Docker with Drupal-fpm, mariadb, and Nginx images. It works just fine for clean, standard installs as described in my Quick Start section of my repository at https://github.com/RightsandWrongsgit/12-factor-demo . I am now attempting to 'import' via synchronizing configurations under Drupal's administration menu an existing site Tar.gz file that is about 4M in size. I have made modifications in the php.ini file to handle greater than the default 2M size there; (elaborated in the notes in my repo README.md if you care to see the details of that point.) However, where I am hung up is dealing with the Ngnix limitations around client_max_body_size. During the attempted import, after a brief run time, Ngnix throws an error that the file size is too large and stops. The situation of too large of a file size for Ngnix upload is an existing issue addressed here nginx - client_max_body_size has no effect.

Where I am running into a roadblock is syntax for getting a client_max_body_size increase in all three locations in a Docker container environment. My pull in the Docker-compose.yml file is for 'nginx:latest' to be from local or from DockerHub if the image isn't already loaded. This image brings down its 'nginx.conf' file and I can review it within the running container on my clean, standard quick start install. The key thing from 'nginx.conf' is that it contains an http section whose last statement is 'include /etc/nginx/conf.d/*.conf' (In other words, it is calling any additional *.conf files from that directory within the container).

And, YES, there is another *.conf in that directory in the container because I can see it and list it out for review. That additional *.conf file is actually 'default.conf' and it was placed there during my establishment of this 'volumes: - ./config/nginx/site.conf:/etc/nginx/conf.d/default.conf:ro' via my docker-compose.yml service establishment of nginx. I can also confirm that the content of the container running the 'default.conf' file exactly matches the local hosts site.conf file. So the 'docker-compose.yml up' is putting it in the container and I see no reason that the 'nginx.conf' include statement wouldn't be pulling it into use. All this seems to work along the lines described here How to overwrite nginx default config with docker file?

Here is my problem, the 'site.conf' seems to accept the client_max_body_size statement in the server {} context but I don't seem to be able to figure out two things-- first, which location{} context to add it to or what additional location section syntax I should use and second how to add client_max_body_size to the http{} context at all. Every try I have made seem to result in an error being thrown and the nginx server image not loading within the container.

Here is the code that works just fine during the standard quick start but that doesn't truly expand the allowed file size upload and gives the nginx file size to large error:

server
{
    listen   80;
    root /var/www/web;
    index index.php;
    client_max_body_size 100M;

    location / {
        error_page 404 = @drupal;
    }

    location @drupal {
        rewrite ^(.*)$ /index.php?q=$1 last;
    }
    location ~ \.php$ {
        fastcgi_pass   php:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

How would I add this client_max_body_size statement to the http and location contexts? Per the need to do so noted here - nginx - client_max_body_size has no effect

I would really appreciate if you might suggest specific edits to the code presented above since I am a relative novice at all this and could use pretty clear help to actually make this work! Thanks

emofsnead
  • 61
  • 1
  • 5
  • Welcome to the community. Please improve your question so that it could solve more than your own specific question. If you are new to nginx, you could use http://nginxconfig.io/ as a starting point. Doing a google search before posting question helps as well. – ttimasdf Feb 05 '21 at 01:19
  • Obviously I did dozens of google searches before posting; even including other close but not direct Stackoverflow question links as references in the post. The content of the post itself was constructed to provide a good number of link term elements very much intended for others to benefit from not only the response but the details of how the involved parts to address the issue are constructed. – emofsnead Feb 05 '21 at 13:59

1 Answers1

3

Found the basic answer and thought it might help others so I am posting it. The NGINX Docker image includes the pull of a 'nginx.conf' file for basic configuration. The 'nginx.conf' file has a http context in it and at the end of but within that section contains an 'include' statement that references a subdirectory below where the 'nginx.conf' file is located (include /etc/nginx/conf.d/*.conf;). The wildcard picks up any additional configuration files of the '.conf' extension that you put there. My container included the additional configuration file named 'site.conf' that was moved to that subdirectory during build.

Here is the 'site.conf' file that is pulled via the include statement at the end of the 'nginx.conf' associated with the NGINX image pull. The key thing is that the http context was already established and thus the first 'client_max_body_size' statement already has the http context and doesn't need to be restated in the 'site.conf' being called by the include.

`client_max_body_size 0; # within http context via the 'include'

server
{
    listen   80;
    root /var/www/web;
    index index.php;
    client_max_body_size 0; # within server context

    location / {
        error_page 404 = @drupal;
    }

    location @drupal {
        rewrite ^(.*)$ /index.php?q=$1 last;
    }
    location ~ \.php$ {
        client_max_body_size 0; # within location context  
        fastcgi_pass   php:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param  PHP_VALUE   "memory_limit = 500M; post_max_size = 400M; upload_max_filesize = 300M;";
        include        fastcgi_params;
    }
}`

All of this really started because of attempting to migrate a Drupal site from a LAMP stack to an NGINX container. Fixing the file size allowed larger sites to be moved. For an additional heads up if this doesn't totally fix the migration is to also change the container build to a php version consistent with the original site. I found that some lines of code that were deprecated in the move to php 7.4.x were also causing the migration to 'hang' and making the container php7.3.4 like the lamp stack was using was also required.

emofsnead
  • 61
  • 1
  • 5