Code: Select all
location ~ \.php$ {
root /data/web/php-project-v1.0.0;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
Code: Select all
location ~ \.php$ {
root /data/web/php-project-v1.1.0;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
Kann dies eine Bereitstellung ohne Ausfallzeiten ermöglichen? Vorteile, Nachteile und Punkte, auf die Sie achten sollten, insbesondere in Zeiten mit hohem Datenverkehr.
Ich habe diesen Ansatz getestet und er verursacht zumindest keine serverseitigen 500-Fehler. Nach der Änderung der Konfiguration liefern Anfragen, die noch nicht abgeschlossen wurden, nach Abschluss ihrer Verarbeitung weiterhin Ergebnisse basierend auf der Logik des alten Projekts. Meiner Beobachtung nach wird diese Änderung jedoch nicht sofort nach der Ausführung von nginx -s reload wirksam. Es scheint, dass die Logik des alten Projekts noch eine Weile bestehen bleibt. Ich hoffe, dass Entwickler, die mit Nginx vertraut sind, dieses Phänomen erklären und meine Frage aus einer tieferen, zugrunde liegenden Perspektive beantworten können. Außerdem ist mir bei der Suche nach diesem Problem bei Google aufgefallen, dass nur sehr wenige Leute diese Methode nutzen. Warum nutzen nicht mehr Menschen diese Technik für die automatisierte Bereitstellung, insbesondere in Szenarien, in denen es nicht viele redundante Hosts gibt? Liegt es daran, dass sie nicht darüber nachgedacht haben, oder bestehen potenzielle Risiken?