Persönlich entwickelte App WEB-Server: Nginx Anwendungsserver: Puma Ich habe AWS EC2 mit bereitgestellt.
Ruby 2.5.3 Rails 5.2.4.2 MacOS:Catalina 10.15.6
Die AWS-Einstellungen waren in Ordnung, während das Verständnis gemäß dem bereits erwähnten ausgezeichneten Artikel verbessert wurde, aber seit ich gerade angefangen habe, hatte ich das Gefühl, dass die Nginx-Einstellungen (nginx.conf usw.) besonders schwierig waren, viele Fehler überwunden und versucht und fehlerhaft. Und gelöscht.
Ich denke, dass heutzutage viele Leute Puma als Anwendungsserver wählen.
Ich hatte keinen Artikel, in dem die beiden Einstellungen für nginx.conf und yourapp.conf aufgeführt sind, die für die Bereitstellung erforderlich sind. Daher dachte ich, dass dies für jemanden nützlich wäre.
Ich bin froh, dass ich über den Fehler gestolpert bin und mein Verständnis des Servers vertieft habe, indem ich ihn untersucht habe, aber wahrscheinlich wird auch jeder, der ihn in Frage stellt, an derselben Stelle gestolpert sein. ** Ich konnte ihn mit einer solchen Einstellung bereitstellen **, Ich möchte einen Artikel mit meinem Körper schreiben.
Ich werde beide mit der Bedeutung der Überprüfung selbst organisieren (bitte sagen Sie mir, wenn es Unterschiede gibt!).
[** Nginx **] ... WEB-Server. Empfängt Inhaltsanfragen vom Browser und antwortet dem Browser. Bei einer Anfrage nach statischem Inhalt (Bild usw.) verarbeitet der WEB-Server diesen. Der Anwendungsserver ist für den dynamischen Inhalt verantwortlich. Vertreter von WEB-Servern sind Apache, Nginx usw.
[** Puma **] ... Anwendungsserver. Während Nginx statische Inhalte auf dem WEB-Server verarbeitet, verarbeitet dies dynamische Inhalte, die Nginx nicht verarbeiten kann. Anforderung vom WEB-Server → Anwendungsserver empfangen → Das Verarbeitungsergebnis der Rails-Anwendung an den WEB-Server zurückgeben. Typische Beispiele sind Unicorn, Puma usw. Rails verwendet derzeit Puma als Standardanwendungsserver.
Es scheint einen Unterschied zwischen Puma und Unicorn zu geben, aber das erstere ist multithreaded und das letztere ist multiverarbeitet. Puma scheint den Vorteil zu haben, mehr Anfragen effizienter zu bearbeiten, aber einige sagen, dass sich im normalen Gebrauch nicht viel ändert. Ich habe mich für Puma entschieden, was von Rails empfohlen wird.
Als nächstes folgt die Einstellung von puma.rb. Unten sind meine Einstellungen.
puma.rb(local)
#Anwendungsverzeichnis
app_dir = File.expand_path("../../", __FILE__)
#Geben Sie den URI mit Bindung für die Socket-Kommunikation an
bind "unix://#{app_dir}/tmp/sockets/puma.sock"
#Speicherort der PID-Datei(Prozess ID)
pidfile "#{app_dir}/tmp/pids/puma.pid"
#Die Statusdatei betreibt den Server mit dem Befehl pumactl. Sein Aufenthaltsort.
state_path "#{app_dir}/tmp/pids/puma.state"
#Standardausgabe/Der Speicherort der Datei, die den Standardfehler ausgibt.
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
threads threads_count, threads_count
#port ENV.fetch("PORT") { 3000 }
environment ENV.fetch("RAILS_ENV") { "development" }
plugin :tmp_restart
Ich habe auskommentiert, weil ich keinen Port benutze.
Puma und Nginx werden durch Binden in der zweiten Zeile für die Socket-Kommunikation angegeben. Geben Sie beim Binden den Pfad mit URI wie unten gezeigt an.
bind "unix://#{app_dir}/tmp/sockets/puma.sock"
Nginx ändert hauptsächlich zwei Dateien. 1 nginx.conf ... Nginx-eigene Konfigurationsdatei 2 yourapp.conf ... Nginx-Konfigurationsdatei für jede Anwendung
Unten ist meine Einstellung nginx.conf
(EC2)etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
include /etc/nginx/conf.d/*.conf;
index index.html index.htm;
upstream puma {
server unix:///var/www/rails/yourapp/shared/tmp/sockets/puma.sock;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name Elastic IP(URL);
root /var/www/rails/yourapp/current/public;
location / {
try_files $uri $uri/index.html $uri.html @webapp;
}
location @webapp {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://puma;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
server {
listen 443 ssl;
server_name Elastic IP(URL);
location @webapp {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass http://puma;
}
}
}
Obwohl es yourapp.conf heißt, enthält yourapp den Namen der Anwendung, die Sie erstellen.
ruby:(EC2)/etc/nginx/conf.d/yourapp.conf
# log directory
error_log /var/www/rails/yourapp/shared/log/nginx.error.log;
access_log /var/www/rails/yourapp/shared/nginx.access.log;
upstream app_server {
# for UNIX domain socket setups
server unix:/var/www/rails/yourapp/shared/tmp/sockets/yourapp-puma.sock fail_timeout=0;
}
server {
listen 80;
server_name ;
# nginx so increasing this is generally safe...
# path for static files
root /var/www/rails/yourapp/current/public;
# page cache loading
try_files $uri/index.html $uri @app_server;
location / {
# HTTP headers
proxy_pass http://app_server;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
}
# Rails error pages
error_page 500 502 503 504 /500.html;
location = /500.html {
root /var/www/rails/yourapp/current/public;
}
client_max_body_size 4G;
keepalive_timeout 5;
}
Hier ist ein Artikel, auf den ich bei der Bereitstellung verwiesen habe.
Bereitstellen einer Rails5 + Puma + Nginx-Umgebung auf EC2 mit Capistrano3 (Teil 2)
Anfänger in der Infrastruktur stellt die Anwendung Nginx + Puma Rails 5 auf Capistrano 3 bereit
Da ich nicht an den Umgang mit dem Server gewöhnt war, fiel es mir schwerer, Nginx und Puma oben einzurichten, als AWS usw. bei der Bereitstellung auf EC2 einzurichten. Schließlich konnte ich mit Capistrano und CircleCI auf AWS EC2 bereitstellen. In Bezug auf CD denke ich, dass Sie es ohne Schwierigkeiten tun können, wenn Sie gemäß den Artikeln der Vorgänger vorgehen. Ich werde kommen, wenn es viele Fehler gibt, aber ich kann nicht aufhören, weil ich mehr als glücklich bin, wenn ich neue Funktionen implementieren und die Fehler beheben kann!
Recommended Posts