Application développée personnellement Serveur WEB: Nginx Serveur d'application: Puma J'ai déployé sur AWS EC2 en utilisant.
Ruby 2.5.3 Rails 5.2.4.2 MacOS:Catalina 10.15.6
Les paramètres AWS étaient corrects tout en faisant progresser la compréhension selon l'excellent article déjà mentionné, mais depuis que je viens de commencer, j'ai senti que les paramètres Nginx (nginx.conf, etc.) étaient particulièrement difficiles, surmontaient de nombreuses erreurs et essayaient et faisaient des erreurs. Et effacé.
Je pense que de nombreuses personnes choisissent Puma comme serveur d'applications ces jours-ci.
Je n'avais pas d'article qui répertorie les deux paramètres pour nginx.conf et yourapp.conf qui sont nécessaires pour le déploiement, j'ai donc pensé que ce serait utile pour quelqu'un.
Je suis heureux d'avoir trébuché sur l'erreur et d'avoir approfondi ma compréhension du serveur en l'examinant, mais probablement tous ceux qui le contesteront trébucheront également au même endroit, alors ** j'ai pu déployer avec un tel paramètre **, Je voudrais écrire un article avec mon corps.
Je vais organiser les deux avec le sens de la critique moi-même (veuillez me dire s'il y a des différences!).
[** Nginx **] ... serveur WEB. Reçoit les demandes de contenu du navigateur et répond au navigateur. Dans le cas d'une demande de contenu statique (image, etc.), le serveur WEB le traite. Le serveur d'application est en charge du contenu dynamique. Les représentants des serveurs WEB sont Apache, Nginx, etc.
[** Puma **] ... Serveur d'applications. Nginx gère le traitement du contenu statique sur le serveur WEB, mais cela gère le contenu dynamique que Nginx ne peut pas traiter. Requête du serveur WEB → Réception du serveur d'application → Renvoie le résultat du traitement de l'application Rails au serveur WEB. Des exemples typiques sont Unicorn, Puma, etc. Rails utilise actuellement Puma comme serveur d'applications par défaut.
Il semble y avoir une différence entre Puma et Unicorn, mais le premier est multi-thread et le second est multi-traité. Puma semble avoir l'avantage de gérer plus de demandes plus efficacement, mais certains disent que cela ne change pas beaucoup en utilisation normale. J'ai choisi Puma, qui est recommandé par Rails.
Vient ensuite le réglage de puma.rb. Voici mes paramètres.
puma.rb(local)
#Répertoire des applications
app_dir = File.expand_path("../../", __FILE__)
#Spécifiez l'URI avec la liaison pour la communication socket
bind "unix://#{app_dir}/tmp/sockets/puma.sock"
#Emplacement du fichier PID(ID de processus)
pidfile "#{app_dir}/tmp/pids/puma.pid"
#Le fichier d'état fait fonctionner le serveur avec la commande pumactl. Ses allées et venues.
state_path "#{app_dir}/tmp/pids/puma.state"
#Sortie standard/L'emplacement du fichier qui génère l'erreur standard.
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
J'ai commenté parce que je n'utilise pas le port.
Puma et Nginx sont spécifiés par bind sur la deuxième ligne pour la communication socket. Dans bind, spécifiez le chemin avec l'URI comme indiqué ci-dessous.
bind "unix://#{app_dir}/tmp/sockets/puma.sock"
Nginx modifie principalement deux fichiers. 1 nginx.conf ... propre fichier de configuration de Nginx 2 yourapp.conf ... Fichier de configuration Nginx pour chaque application
Voici mon paramètre 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;
}
}
}
Bien qu'il s'appelle yourapp.conf, yourapp contiendra le nom de l'application que vous créez.
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;
}
Voici un article auquel j'ai fait référence lors du déploiement.
Déployer un environnement Rails5 + Puma + Nginx sur EC2 avec Capistrano3 (partie 2)
Un novice en infrastructure déploie l'application Nginx + Puma Rails 5 sur Capistrano 3
Comme je n'étais pas habitué à gérer le serveur, j'ai eu plus de mal à configurer Nginx et Puma ci-dessus que de configurer AWS, etc. lors du déploiement sur EC2. Enfin, j'ai pu déployer sur AWS EC2 en utilisant Capistrano et CircleCI. Concernant le CD, je pense que vous pouvez le faire sans difficulté si vous procédez selon les articles des prédécesseurs. Je viendrai quand il y aura beaucoup d'erreurs, mais je ne peux pas m'arrêter car je suis plus qu'heureux quand je peux implémenter de nouvelles fonctions et résoudre les erreurs!
Recommended Posts