문제 - 앱에 액세스하려고 할 때 404가 표시됩니다. 파일을 찾을 수 없습니다(처음 포함).

문제 - 앱에 액세스하려고 할 때 404가 표시됩니다. 파일을 찾을 수 없습니다(처음 포함).

문제 - 앱에 액세스하려고 할 때 404가 표시됩니다. 파일을 찾을 수 없습니다(처음 포함).

nextcloud.example.com을 통해 브라우저에서 앱에 액세스하려고 하면 NextCloud FMP Docker 컨테이너의 콘솔 로그에서 다음 오류가 발생합니다.

172.19.0.5 -  04/Mar/2023:22:36:01 +0000 "GET /index.php" 404

그리고 NGinX Docker 컨테이너의 콘솔 로그에 다음 오류가 있습니다.

172.69.67.108 - - [04/Mar/2023:22:36:01 +0000] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"

Docker 서버 호스트 및 컨테이너 설정

  1. Docker 호스트 서버 OS는 Ubuntu 22.04 LTS입니다.

  2. NGinX Docker 컨테이너, 나는 docker-compose.yml이 가장 좋다는 것을 알고 있지만 지금은 이것이 제대로 작동할 때까지 다음을 사용하여 컨테이너를 실행하고 있습니다.

    docker run -p 80:80 -p 443:443 --name nginx \
        --restart=unless-stopped \
        -v certbot:/etc/letsencrypt \
        -v nginx:/etc/nginx/conf.d \
        -v www:/usr/share/nginx/html \
        --network tools \
        -d nginx
    

    이는 포트가 노출된 Docker 서버 호스트의 유일한 컨테이너이며 볼륨 마운트를 사용하여 다음을 공유합니다.

    • CertBot 컨테이너가 포함된 인증서
    • 각 앱에 대한 conf를 설정하는 NGinX Conf 디렉터리
    • NextCloud FPM Docker 컨테이너와 공유할 HTML www 루트 홈
    • 네트워크 도구
  3. NextCloud FPM Docker 컨테이너, 다음을 사용하여 컨테이너를 실행하고 있습니다.

    docker run --name nextcloud-fpm \
        --restart=unless-stopped \
        -v www:/var/www/html \
        -e 'TRUSTED_PROXIES=nginx' \
        -e 'POSTGRES_HOST=database.server.com' \
        -e 'POSTGRES_USER=database_user' \
        -e 'POSTGRES_PASSWORD=database_user_password' \
        -e 'POSTGRES_DB=databse_name' \
        --network tools \
        -d nextcloud:fpm
    

    이 컨테이너는 앱의 포트를 Docker 호스트 서버에 노출할 필요가 없고 IP 대신 컨테이너 이름을 사용하여 컨테이너 스택 및 NGinX conf 파일을 생성할 때 더 쉽게 만들기 위해 동일한 네트워크 도구에서 실행됩니다. 프록시 역방향

    • NGinX Docker 컨테이너와 공유할 HTML www 루트 홈
    • 신뢰할 수 있는 프록시(NGinX 컨테이너)에 대한 환경 변수
    • PostgreSQL 데이터베이스의 환경 변수
    • 이 Cotainer는 포트 9000에서 FPM을 실행합니다.
    • 네트워크 도구
  4. NGinX conf 파일, 그 중 2개가 있습니다. 하나는 기본적으로 IP 및 포트를 통해 호스트 서버에 직접 접근하는 것을 허용하지 않는 default.conf입니다(예: xxx.xxx.xxx.xxx:80 또는 xxx.xxx.xxx.xxx:443). ):

    server {
        # Removes Web Server Info
        server_tokens off;
        # HTTP
        listen      80 default_server;
        listen [::]:80 default_server;
        listen      443 ssl http2 default_server;
        listen [::]:443 ssl http2 default_server;
        ssl_reject_handshake on;
        # Identify Server without the name, hence just IP
        server_name _;
        # Return Empty Response
        return 444;
    }
    

    마지막으로 nextcloud.conf에서 가져왔습니다.GitHub NextCloud FPM 공식 레포:

    upstream php-handler {
        server nextcloud-fpm:9000; # In here I set up the Stream with the NextCloud FPM Container name
    }
    
    server {
    listen 80;
    listen [::]:80;
    server_name nextcloud.example.com;
    
    return 301 https://$server_name$request_uri;
    }
    
    server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name nextcloud.example.com;
    
    ssl_certificate /etc/letsencrypt/live/nextcloud.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/nextcloud.example.com/privkey.pem;
    
        # HSTS settings
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
    
        # set max upload size
        client_max_body_size 512M;
        fastcgi_buffers 64 4K;
    
        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/>
        # Pagespeed is not supported by Nextcloud, so if your server is built
        # with the `ngx_pagespeed` module, uncomment this line to disable it.
        #pagespeed off;
    
        # HTTP response headers borrowed from Nextcloud `.htaccess`
        add_header Referrer-Policy                      "no-referrer"   always;
        add_header X-Content-Type-Options               "nosniff"       always;
        add_header X-Download-Options                   "noopen"        always;
        add_header X-Frame-Options                      "SAMEORIGIN"    always;
        add_header X-Permitted-Cross-Domain-Policies    "none"          always;
        add_header X-Robots-Tag                         "none"          always;
        add_header X-XSS-Protection                     "1; mode=block" always;
    
        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;
    
        # Path to the root of your installation
        root /usr/share/nginx/html/; # Since NGinX is the Web Server, I am pointing root to where the NextCloud Files are mounted inside the NGinX Container from the NextCloud FPM Container
    
        # Specify how to handle directories -- specifying `/index.php$request_uri`
        # here as the fallback means that Nginx always exhibits the desired behaviour
        # when a client requests a path that corresponds to a directory that exists
        # on the server. In particular, if that directory contains an index.php file,
        # that file is correctly served; if it doesn't, then the request is passed to
        # the front-end controller. This consistent behaviour means that we don't need
        # to specify custom rules for certain paths (e.g. images and other assets,
        # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
        # `try_files $uri $uri/ /index.php$request_uri`
        # always provides the desired behaviour.
        index index.php index.html /index.php$request_uri;
    
        # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
        location = / {
            if ( $http_user_agent ~ ^DavClnt ) {
                return 302 /remote.php/webdav/$is_args$args;
            }
        }
    
        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }
    
        # Make a regex exception for `/.well-known` so that clients can still
        # access it despite the existence of the regex rule
        # `location ~ /(\.|autotest|...)` which would otherwise handle requests
        # for `/.well-known`.
        location ^~ /.well-known {
            # The rules in this block are an adaptation of the rules
            # in `.htaccess` that concern `/.well-known`.
    
            location = /.well-known/carddav { return 301 /remote.php/dav/; }
            location = /.well-known/caldav  { return 301 /remote.php/dav/; }
    
            location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
            location /.well-known/pki-validation    { try_files $uri $uri/ =404; }
    
            # Let Nextcloud's API for `/.well-known` URIs handle all other
            # requests by passing them to the front-end controller.
            return 301 /index.php$request_uri;
        }
    
        # Rules borrowed from `.htaccess` to hide certain paths from clients
        location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
        location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }
    
        # Ensure this block, which passes PHP files to the PHP process, is above the blocks
        # which handle static assets (as seen below). If this block is not declared first,
        # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
        # to the URI, resulting in a HTTP 500 error response.
        location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;
    
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;
    
            try_files $fastcgi_script_name =404;
    
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;
    
            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;
    
            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }
    
        location ~ \.(?:css|js|svg|gif)$ {
            try_files $uri /index.php$request_uri;
            expires 6M;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }
    
        location ~ \.woff2?$ {
            try_files $uri /index.php$request_uri;
            expires 7d;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }
    
        # Rule borrowed from `.htaccess`
        location /remote {
            return 301 /remote.php$request_uri;
        }
    
        location / {
            try_files $uri $uri/ /index.php$request_uri;
        }
    }
    

내가 지금까지 시도한 것

  1. 내 첫 번째 본능은 로그를 확인하는 것이었고, 이 게시물의 시작 부분에서 로그를 공유했으며, 이를 기반으로 두 컨테이너에 파일이 있는지 확인하기 위해 두 가지 방법으로 이 작업을 수행했습니다.

    동일한 Docker 호스트 서버에서 실행되는 Portainer 컨테이너가 있고 정상적인 NGinX Docker 컨테이너 뒤에 Proxy Reverse가 있습니다. 콘솔을 연결하고 두 컨테이너 내부의 파일을 찾았습니다. docker exec container_name -it bash두 컨테이너에서도 마찬가지입니다.

    NginX 컨테이너, 마운트가 켜져 있었던 것을 기억하세요/usr/share/nginx/html

    root@61564cff4e67:/# ls -lha /usr/share/nginx/html
    total 180K
    drwxrwxrwx 15 www-data www-data 4.0K Mar  4 13:24 .
    drwxr-xr-x  3 root     root     4.0K Feb  9 04:36 ..
    -rw-r--r--  1 www-data www-data 3.2K Mar  4 13:24 .htaccess
    -rw-r--r--  1 www-data www-data  101 Mar  4 13:24 .user.ini
    drwxr-xr-x 47 www-data www-data 4.0K Mar  4 13:24 3rdparty
    -rw-r--r--  1 www-data www-data  19K Mar  4 13:24 AUTHORS
    -rw-r--r--  1 www-data www-data  34K Mar  4 13:24 COPYING
    drwxr-xr-x 50 www-data www-data 4.0K Mar  4 13:24 apps
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 config
    -rw-r--r--  1 www-data www-data 4.0K Mar  4 13:24 console.php
    drwxr-xr-x 23 www-data www-data 4.0K Mar  4 13:24 core
    -rw-r--r--  1 www-data www-data 6.2K Mar  4 13:24 cron.php
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 custom_apps
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 data
    drwxr-xr-x  2 www-data www-data  12K Mar  4 13:24 dist
    -rw-r--r--  1 www-data www-data  156 Mar  4 13:24 index.html
    -rw-r--r--  1 www-data www-data 3.4K Mar  4 13:24 index.php
    drwxr-xr-x  6 www-data www-data 4.0K Mar  4 13:24 lib
    -rwxr-xr-x  1 www-data www-data  283 Mar  4 13:24 occ
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocm-provider
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs-provider
    -rw-r--r--  1 www-data www-data 3.1K Mar  4 13:24 public.php
    -rw-r--r--  1 www-data www-data 5.5K Mar  4 13:24 remote.php
    drwxr-xr-x  4 www-data www-data 4.0K Mar  4 13:24 resources
    -rw-r--r--  1 www-data www-data   26 Mar  4 13:24 robots.txt
    -rw-r--r--  1 www-data www-data 2.4K Mar  4 13:24 status.php
    drwxr-xr-x  3 www-data www-data 4.0K Mar  4 13:24 themes
    -rw-r--r--  1 www-data www-data  383 Mar  4 13:24 version.php
    

    NextCloud FPM 컨테이너, 마운트가 켜져 있었던 것을 기억하세요/var/www/html

    root@938c95d0e1ae:/var/www/html# ls -lha
    total 180K
    drwxrwxrwx 15 www-data www-data 4.0K Mar  4 13:24 .
    drwxrwxr-x  1 www-data root     4.0K Feb 16 03:06 ..
    -rw-r--r--  1 www-data www-data 3.2K Mar  4 13:24 .htaccess
    -rw-r--r--  1 www-data www-data  101 Mar  4 13:24 .user.ini
    drwxr-xr-x 47 www-data www-data 4.0K Mar  4 13:24 3rdparty
    -rw-r--r--  1 www-data www-data  19K Mar  4 13:24 AUTHORS
    -rw-r--r--  1 www-data www-data  34K Mar  4 13:24 COPYING 
    drwxr-xr-x 50 www-data www-data 4.0K Mar  4 13:24 apps
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 config
    -rw-r--r--  1 www-data www-data 4.0K Mar  4 13:24 console.php
    drwxr-xr-x 23 www-data www-data 4.0K Mar  4 13:24 core
    -rw-r--r--  1 www-data www-data 6.2K Mar  4 13:24 cron.php
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 custom_apps
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 data
    drwxr-xr-x  2 www-data www-data  12K Mar  4 13:24 dist
    -rw-r--r--  1 www-data www-data  156 Mar  4 13:24 index.html
     -rw-r--r--  1 www-data www-data 3.4K Mar  4 13:24 index.php
    drwxr-xr-x  6 www-data www-data 4.0K Mar  4 13:24 lib
    -rwxr-xr-x  1 www-data www-data  283 Mar  4 13:24 occ
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocm-provider
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs
    drwxr-xr-x  2 www-data www-data 4.0K Mar  4 13:24 ocs-provider
    -rw-r--r--  1 www-data www-data 3.1K Mar  4 13:24 public.php
    -rw-r--r--  1 www-data www-data 5.5K Mar  4 13:24 remote.php
    drwxr-xr-x  4 www-data www-data 4.0K Mar  4 13:24 resources
    -rw-r--r--  1 www-data www-data   26 Mar  4 13:24 robots.txt
    -rw-r--r--  1 www-data www-data 2.4K Mar  4 13:24 status.php
    drwxr-xr-x  3 www-data www-data 4.0K Mar  4 13:24 themes
    -rw-r--r--  1 www-data www-data  383 Mar  4 13:24 version.php
    

    Docker 서버 호스트 바인딩 마운트마지막으로 Docker 호스트 서버 자체의 파일을 확인하려면 두 컨테이너의 루트 위치를 공유하고 싶을 뿐만 아니라 컨테이너를 이동해야 하는 경우 영구 데이터도 있어야 합니다.

    ❯ ll
    total 180K
    drwxrwxrwx 15 www-data  www-data  4.0K Mar  4 13:24 .
    drwxrwxr-x 10 Alejandro Alejandro 4.0K Mar  4 13:24 ..
    drwxr-xr-x 47 www-data  www-data  4.0K Mar  4 13:24 3rdparty
    drwxr-xr-x 50 www-data  www-data  4.0K Mar  4 13:24 apps
    -rw-r--r--  1 www-data  www-data   19K Mar  4 13:24 AUTHORS
    drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 config
    -rw-r--r--  1 www-data  www-data  4.0K Mar  4 13:24 console.php
    -rw-r--r--  1 www-data  www-data   34K Mar  4 13:24 COPYING
    drwxr-xr-x 23 www-data  www-data  4.0K Mar  4 13:24 core
    -rw-r--r--  1 www-data  www-data  6.2K Mar  4 13:24 cron.php
    drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 custom_apps
    drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 data
    drwxr-xr-x  2 www-data  www-data   12K Mar  4 13:24 dist
    -rw-r--r--  1 www-data  www-data  3.2K Mar  4 13:24 .htaccess
    -rw-r--r--  1 www-data  www-data   156 Mar  4 13:24 index.html
    -rw-r--r--  1 www-data  www-data  3.4K Mar  4 13:24 index.php
    drwxr-xr-x  6 www-data  www-data  4.0K Mar  4 13:24 lib
    -rwxr-xr-x  1 www-data  www-data   283 Mar  4 13:24 occ
    drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocm-provider
    drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocs
    drwxr-xr-x  2 www-data  www-data  4.0K Mar  4 13:24 ocs-provider
    -rw-r--r--  1 www-data  www-data  3.1K Mar  4 13:24 public.php
    -rw-r--r--  1 www-data  www-data  5.5K Mar  4 13:24 remote.php
    drwxr-xr-x  4 www-data  www-data  4.0K Mar  4 13:24 resources
    -rw-r--r--  1 www-data  www-data    26 Mar  4 13:24 robots.txt
    -rw-r--r--  1 www-data  www-data  2.4K Mar  4 13:24 status.php
    drwxr-xr-x  3 www-data  www-data  4.0K Mar  4 13:24 themes
    -rw-r--r--  1 www-data  www-data   101 Mar  4 13:24 .user.ini
    -rw-r--r--  1 www-data  www-data   383 Mar  4 13:24 version.php
    
    root@myserver /mnt/Volume/data/www
    

    권한 측면에서 이것이 작동하지 않을 이유가 없으며 파일이 세 가지 인스턴스 모두에 정상적으로 존재하는지 확인했습니다.

  2. NextCloud FPM nextcloud.conf에 대한 NGinX conf 파일을 확인하세요. 브라우저의 도메인을 통해 NGniX 웹 서버 컨테이너까지 연결하기 때문에 잘못될 수 있다고 생각되는 유일한 것은 많은 고려 끝에 404가 있기 때문입니다. 로그에 Not Found 항목이 있고 NextCloud Container 인스턴스 자체에서도 404 Not Found라는 응답을 받습니다. 제가 가진 유일한 문제는 conf 파일의 루트 항목과 관련이 있다는 것입니다.

    NextCloud 로그:

    172.19.0.5 -  04/Mar/2023:22:36:01 +0000 "GET /index.php" 404
    

    NginX 로그:

    172.69.67.108 - - [04/Mar/2023:22:36:01 +0000] "GET / HTTP/2.0" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"
    

    그래서 루트 지시어를 로 변경했는데 /var/www/html동작이 조금 바뀌었습니다. 여전히 404 Not Found 항목이 표시되지만 NGinX 웹 서버 컨테이너 로그에서만 NextCloud 컨테이너가 조용하므로 도달하지 못합니다. 이 변경으로:

    NextCloud 로그(아무 항목도 비어 있음):

    
    

    NginX 로그:

    2023/03/05 00:13:24 [error] 473#473: *4152 "/var/www/html/index.php" is not found (2: No such file or directory), client: 172.69.65.73, server: nextcloud.example.com, request: "GET / HTTP/2.0", host: "nextcloud.example.com"
    172.69.65.73 - - [05/Mar/2023:00:13:24 +0000] "GET / HTTP/2.0" 404 174 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" "xxx.my.ip.xxx"
    

    "nextcloud.example.com"웹 서버의 작동 방식에는 뭔가 다른 점이 있습니다. 루트 지시어가 변경된 후에는 이전에 대시만 표시되었을 때 로그에서 따옴표 사이에 실제 도메인이 표시되는 것을 확인했습니다 "-".

  3. 다음은 default.conf NGinX conf 파일을 비활성화하는 것이었습니다. 위와 동일한 결과를 생각할 수 있는 유일한 곳이었으며 "-"이미 시도한 시나리오 1과 2 모두에서 반복했습니다. 이는 "_"서버 지시문에 있습니다. default.conf 역시 어둠 속에서의 일이었습니다.

  4. 나는 conf를 사용하여 다른 많은 설정을 시도했지만 대부분은 , 또는 단순한 오류로 Too Many RedirectionsBad Certificate납니다 502.

문제가 무엇인지, 어디에 문제가 있는지에 대한 나의 결정

원하는 도메인이 있는 브라우저에서 두 컨테이너 모두에 도달하고 SSL도 잘 해결되므로 원하는 결과에 매우 가까운 것 같습니다. 그러나 서버 이름이 NGinX conf 파일에 캡처되지 않는 것 같습니다. , NextCloud에 올바르게 전달되지 않았지만 정확히 무엇을 변경해야 할지 모르겠습니다.

내 생각에 특정 문제라고 생각되는 것으로 범위를 좁힌 것 같아서 누군가가 NGinX conf 파일 nextcloud.conf를 검토하고 무엇이 잘못 설정되었는지 지적하는 데 도움을 줄 수 있습니다.

오늘도 긴 글을 읽어주셔서 감사합니다.

답변1

나는 그것을 알아냈으므로 이미 동일한 문제를 겪고 있는 사람들과 앞으로 이 문제가 발생할 수 있는 사람들을 돕기 위해 이에 대해 답변 없이 발견한 질문과 문제가 얼마나 많은지 고려하여 자세한 정보를 제공할 것입니다.

문제는 NGinX conf 파일의 FastCGI 매개변수에 있는 FPM 루트 위치였습니다.

그래서 나는 올바른 길을 가고 있었고 문제는 루트 지시문과 관련이 있었습니다.

많은 책을 읽은 후 나는 다음 게시물을 우연히 발견했습니다.

php-fpm과 Nginx Docker 컨테이너를 올바르게 연결하는 방법은 무엇입니까?

그리고 갑자기 두 개의 서로 다른 경로를 읽는 두 개의 서로 다른 서비스가 있고 하나는 존재하지 않는 다른 하나의 루트 경로를 제공하고 있다는 것이 분명해졌습니다.

두 컨테이너 간에 공유할 www 볼륨을 마운트했다는 것을 기억하시나요?

  1. NGinX 컨테이너의 경우www:/usr/share/nginx/html
  2. NextCloud FPM 컨테이너의 경우www:/var/html/www

그 뒤에 있는 아이디어는 두 컨테이너가 NextCloud 앱의 파일 시스템을 공유하는 것이었습니다.

내가 깨닫지 못한 것은 이 배포에서 NGinX의 목적은 FastCGI 매개변수를 사용하여 PHP 호출을 NextCloud FPM 컨테이너로 라우팅하는 동시에 CSS, HTML, JPG, JS 등과 같은 정적 파일을 제공하는 것입니다.

NGinX conf 파일의 루트 지시문이 선언되면 변수로 설정됩니다 $document_root.

root /usr/share/nginx/html;

따라서 NGinX 컨테이너의 경로에 루트를 설정하면 /usr/share/nginx/html문제 없이 정적 파일을 제공하는 데 작동하지만 PHP 호출이 이루어지면 해당 위치가 그렇지 않기 때문에 NextCloud FPM 컨테이너의 php-hanlder에 공급됩니다. 두 번째 컨테이너 안에 존재하면 PHP 파일을 찾을 수 없습니다.

이 문제를 해결하기 위해 FastCGI 매개변수를 사용하여 블록을 검색하고 $document_root변수를 검색하여 찾았으며 다음과 같습니다.

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;이미 선언된 루트를 사용하여 스크립트 경로를 형성하는 줄이 있으므로 처리 시 nextcloud.example.com읽기를 시도하며 index.php이는 NextCloud FPM 컨테이너에 대한 결과 호출입니다.

/usr/share/nginx/html/index.php

올바른 호출은 다음과 같습니다.

/var/www/html/index.php

그래서 저는 이라는 이름의 새 변수를 생성 $fpm_root하고 로 설정한 다음, 다음 /var/www/html/과 같은 줄을 변경했습니다.fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;

이제 정적 콘텐츠에 대한 호출을 받을 때마다 NGinX의 컨테이너 경로를 확인하고, PHP 콘텐츠에 대한 호출을 받으면 NextCloud FPM의 컨테이너 경로를 확인합니다.

이제 전체 섹션의 모습은 다음과 같습니다.

location ~ \.php(?:$|/) {
            # Required for legacy support
            rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;
            set $fpm_root /var/www/html/;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fpm_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }

이제 작동하며 다음 줄을 추가하면 모든 내부 NextCloud 상태 및 보안 검사를 통과합니다.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

결론

그리고 이것이 이 문제를 검색하는 모든 사람에게 도움이 되기를 바랍니다. 문제는 정적 및 PHP의 두 가지 유형의 콘텐츠를 처리하는 서비스에 대해 두 개의 서로 다른 경로가 있고 그 중 하나만 NGinX conf 파일에 올바르게 설정되었다는 것입니다.

Docker화된 FPM 배포를 위해 두 개의 서로 다른(또는 그 이상의) 루트 위치를 가질 수 있으며 이는 아마도 NextCloud, WordPress, PHPPGAdmin에 대한 PHP 호출을 처리하기 위해 동일한 FPM 컨테이너를 사용하여 두 개 이상의 서로 다른 앱에 정적 콘텐츠를 작업하거나 배포하는 데 도움이 될 수 있습니다. Laravel 또는 귀하가 작업하고 있는 모든 것이 가능합니다.

관련 정보