Nginx önbellek sembolleri


12

Web sunucumda bir dağıtım sistemim var, her uygulama dağıtıldığında yeni bir zaman damgası dizini oluşturur ve yeni dizine "geçerli" sembolik bağlantılar oluşturur. Tüm bunlar apache'de iyi ve harika çalıştı, ancak kurduğum yeni nginx sunucusunda, yeni symlinked yerine "eski" dağıtımdan bir komut dosyası çalıştırılıyor gibi görünüyor.

Bunu çözmek için bazı öğreticiler ve yazılar okudum ama çok fazla bilgi yok ve hiçbir şey çalışıyor gibi görünüyor. İşte benim vhost dosyam:

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;
    }
}

ve benim fastcgi_params'ım:

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;

Her dağıtımın önceki dağıtımın silinmesini içerdiği için birinin bana bu konuda yardımcı olup olmayacağını gerçekten takdir ediyorum. Sistem Ubuntu 14.04.5 LTS'dir; PHP 7.1; Nginx nginx / 1.4.6 (Ubuntu)

Yanıtlar:


22

Gömülü Değişkenler , $realpath_root: karşılık gelen bir mutlak yoludur kök veya takma geçerli istek için yönerge değeri, tüm sembolik bağlantıları ile gerçek yollara çözüldü

Bunun $realpath_rootyerine kullanmanın çözümü $document_rootQ / A siteleri ve forumlarının her birine kopya olarak yapıştırılır; Bunu bulmaktan kaçınmak gerçekten zor.Yet, Rasmus Lerdorf tarafından sadece bir kez iyi açıklandığını gördüm . Neden çalıştığını ve ne zaman kullanılması gerektiğini açıkladığı için paylaşmaya değer .

Bu nedenle, belge kökünde bir sembolik takas yapan Capistrano gibi bir şeyle konuşlandırdığınızda, tüm yeni isteklerin yeni dosyaları almasını istersiniz, ancak konuşlandırma gerçekleştikçe yürütülmekte olan istekleri iptal etmek istemezsiniz. Sağlam bir dağıtım ortamı oluşturmak için gerçekten ihtiyacınız olan şey, web sunucunuzun bundan sorumlu olmasını sağlamaktır. Web sunucusu, yığının yeni bir istek başladığında anlayan parçasıdır. Opcode önbelleği, bunu bilmek veya ilgilenmek için yığın içinde çok derin.

Nginx ile bu oldukça basit. Bunu yapılandırmanıza eklemeniz yeterlidir:

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

Bu, nginx'e realpath'e, PHP uygulamanızın bildiği kadarıyla, gerçek document_root ise symlink'in hedefinin bulunduğu docroot symlink'i çözmesini söyler. Şimdi, bir istek başladığında, nginx symlink'i o noktada durduğunda çözer ve istek süresi boyunca, symlink anahtarı isteğin ortasında gerçekleşse bile aynı docroot dizinini kullanır. Bu, burada açıklanan semptomları tamamen ortadan kaldırır ve doğru yaklaşımdır. Bu, opcache düzeyinde çözülebilecek bir şey değil.

Kanishk Dudeja bununla ilgili sorunlara sahipti ve faydalı bir uyarı ekledi: bu değişikliklerin gerçekten nihai yapılandırmada olduğundan emin olun, yani daha sonra include fastcgi_params;bunları geçersiz kılar.


Merhaba, bu harika bir cevap, ama benim yapılandırma fark ederseniz fastcgi_param DOCUMENT_ROOT $ realpath_root var; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_params'dan sonra eklenir ve bu aslında yardımcı olmaz. Ben php-fpm yeniden başlattığınızda semboller çözülür. Bu bunun yerine bir php önbellekleme sorunum olduğunu gösterir mi?
Auris

Revize. Sizin SCRIPT_FILENAMEsahip $document_rootdeğil, $realpath_root.
Esa Jokinen

Hmm ... ama anladığım şekilde DOCUMENT_ROOTayarlandı $realpath_root, değeri çekmeli ya da tamamen yanlış mıyım ve DOCUMENT_ROOTilgili değil$document_root
Auris

1
Merhaba, Cevabınız ve açıklamanız için çok teşekkür ederim, benim hatam DOCUMENT_ROOTetkileyen varsayımdı$document root
Auris

2
Bu sorun ile sunucularda Apache + php-fpm kullanıyorum ve dağıtım üzerinde opcached temizleme benim için çalıştı, biz Capistrano değil dağıtım için bir bash betiği var. Bence daha basit bir çözüm ve zaten dağıtımda opcache temizlemek için iyi bir uygulama. Esa altın olan Rasmus yorumuna bağlantı için teşekkürler!
Carlos Mafla

3

Gönderen /unix/157022/make-nginx-follow-symlinks , değiştirerek sorunu gidermek mümkün olabilir gibi görünüyor

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

için

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;

(yani yolu 'dan' konumuna $document_rootdeğiştirme $realpath_root).

Bunu onaylamak için şu anda bir nginx sunucusuna erişimim yok (ev sunucum şu anda yeniden oluşturuluyor), ancak çözüm https://medium.com/@kanishkdudeja/truly-atomic-deployments tarafından ortak çalışıyor gibi görünüyor -nginx- ve-php-fpm-aed8a8ac1cd9 ile .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.