Кешування Nginx символізує кешування


12

У мене на веб-сервері є система розгортання, кожен раз, коли програма розгорнута, вона створює нову директорію з тимчасовою маркою і посилається "поточно" на новий каталог. Це все добре і чудово працює на apache, але на новому сервері nginx, який я створив, схоже, що сценарій зі "старого" розгортання запускається замість нового зв'язаного.

Я прочитав кілька підручників та публікацій про те, як вирішити це, але інформації не так багато, і, здається, нічого не працює. Ось мій файл vhost:

server {
    listen 80;

    server_name ~^(www\.)?(?<sname>.+?).testing.domain.com$;
    root /var/www/$sname/current/public;
    index index.html index.htm index.php;

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

    location ~* \.(jpg|jpeg|gif|png|bmp|ico|pdf|flv|swf|exe|html|htm|txt|css|js) {
        add_header        Cache-Control public;
        add_header        Cache-Control must-revalidate;
        expires           7d;
    }

    location ~ \.php$ {
        #fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        include fastcgi_params;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
    }

    location ~ /\.ht {
        deny all;
    }
}

і ось мій fastcgi_params:

fastcgi_param   SCRIPT_FILENAME         $document_root$fastcgi_script_name;
fastcgi_param   QUERY_STRING        $query_string;
fastcgi_param   REQUEST_METHOD      $request_method;
fastcgi_param   CONTENT_TYPE        $content_type;
fastcgi_param   CONTENT_LENGTH      $content_length;

fastcgi_param   SCRIPT_NAME     $fastcgi_script_name;
fastcgi_param   REQUEST_URI     $request_uri;
fastcgi_param   DOCUMENT_URI        $document_uri;
fastcgi_param   DOCUMENT_ROOT           $realpath_root;
fastcgi_param   SERVER_PROTOCOL     $server_protocol;

fastcgi_param   GATEWAY_INTERFACE   CGI/1.1;
fastcgi_param   SERVER_SOFTWARE     nginx/$nginx_version;

fastcgi_param   REMOTE_ADDR     $remote_addr;
fastcgi_param   REMOTE_PORT     $remote_port;
fastcgi_param   SERVER_ADDR     $server_addr;
fastcgi_param   SERVER_PORT     $server_port;
fastcgi_param   SERVER_NAME     $server_name;

fastcgi_param   HTTPS           $https if_not_empty;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param   REDIRECT_STATUS     200;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;

Я дуже вдячний, якщо хтось міг би допомогти мені в цьому, оскільки на даний момент кожне розгортання передбачає видалення попереднього розгортання. Система - Ubuntu 14.04.5 LTS; PHP 7.1; Nginx nginx / 1.4.6 (Ubuntu)

Відповіді:


22

Вбудовані змінні , $realpath_root: абсолютний шлях , відповідний в кореневій або псевдонім значення директиви для поточного запиту, з усіма символічними посиланнями дозволені до реальних шляхах

Рішення використання $realpath_rootзамість цього $document_rootвставляється копіюванням навколо Q / A сайтів та форумів; насправді важко уникнути його пошуку. Однак я лише один раз бачив, як це добре пояснив Расмус Лердорф . Варто поділитися, як це описує, чому він працює і коли його слід використовувати.

Отже, коли ви розгортаєтесь через щось на зразок Capistrano, яке здійснює заміну символу посилання на корінь документа, ви хочете, щоб усі нові запити отримували нові файли, але ви не хочете перекручувати запити, які в даний час виконуються, коли відбувається розгортання. Те, що вам справді потрібно для створення надійного середовища розгортання, - це щоб ваш веб-сервер відповідав за це. Веб-сервер - це частина стека, яка розуміє, коли починається новий запит. Кеш-код опкоду занадто глибокий у стеку, щоб знати про це чи піклуватися про це.

З nginx це досить просто. Просто додайте це до своєї конфігурації:

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;

Це говорить nginx для вирішення realpath довільного символу зв'язку, тобто, наскільки знає ваша програма PHP, ціль символьного посилання, якщо справжній document_root. Тепер, як тільки запит запускається, nginx вирішить симпосилання, як воно стоїть у цій точці, і протягом тривалості запиту він буде використовувати той самий каталог docroot, навіть якщо перемикач символьної посилання відбувається посеред запиту. Це повністю усуває описані тут симптоми, і це правильний підхід. Це не те, що можна вирішити на рівні опису.

У Канішка Дудея виникли проблеми з цим, і додав корисне повідомлення: переконайтеся, що ці зміни дійсно будуть у остаточній конфігурації, тобто після include fastcgi_params;чого їх інакше буде замінено.


Привіт, це чудова відповідь, але якщо ви помітили в моїй конфігурації, у мене є fastcgi_param DOCUMENT_ROOT $ realpath_root; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; включається після fastcgi_params, і це насправді не допомагає. Коли я перезапускаю php-fpm, символьні посилання вирішуються. Чи вказує це на те, що натомість у мене є проблема кешування PHP?
Ауріс

Перегляньте. У вас SCRIPT_FILENAMEє $document_root, ні $realpath_root.
Еса Йокінен

Хм ... але DOCUMENT_ROOTналаштовано $realpath_rootтак, як я це розумію, воно повинно витягнути значення або я повністю помиляюся і DOCUMENT_ROOTне пов’язана з цим$document_root
Auris

1
Привіт, дуже дякую за вашу відповідь та ваше пояснення, моєю помилкою було припущення, яке DOCUMENT_ROOTвпливає$document root
Auris

2
Я використовую Apache + php-fpm на серверах з цією проблемою, і очищення, налаштоване на розгортання, працювало для мене, у нас є сценарій bash для розгортання, а не Capistrano. Я думаю, що це більш просте рішення, і це найкраща практика, щоб очистити свій привід при розгортанні в будь-якому випадку. Esa дякую за посилання на коментар Расмуса, що це золото!
Карлос Мафла

3

З /unix/157022/make-nginx-follow-symlinks , можливо, ви зможете вирішити проблему, змінивши

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

до

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;

(тобто зміна шляху від $document_rootдо $realpath_root).

В даний час у мене немає доступу до сервера nginx, щоб підтвердити це (мій домашній сервер наразі перебуває у відновленні), але, здається, рішення співпрацює https://medium.com/@kanishkdudeja/truly-atomic-deployments -with-nginx-і-php-fpm-aed8a8ac1cd9 .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.