J'ai utilisé Nginx pour le développement d'applications Web avec Flask + docker-compose. J'ai extrait et résumé les points de Nginx à l'époque, en particulier le fichier de paramétrage: thumbsup_tone3:
Cliquez ici pour l'article des parents. ■ J'ai créé une WebApp de jeu avec Flask + Docker + Vue.js + AWS ...
■ Le code source est disponible sur Github
Gunicorn ** recommande d'utiliser Nginx sur sa page officielle **. https://docs.gunicorn.org/en/stable/deploy.html
Comme Nginx est mis en mémoire tampon par défaut, il n'est pas facilement affecté par les clients lents et semble être capable de gérer efficacement les travailleurs Gunicorn. Particulièrement efficace lorsque le nombre de travailleurs (nombre de sessions) est limité. Au fait, le serveur Apache ne met pas en mémoire tampon les requêtes. Sauf si vous avez une raison spécifique, si vous choisissez Gunicorn pour WSGI, la combinaison de Nginx est bonne.
Commençons par le premier plan. Ce qui suit est la partie commande du Dockerfile.
CMD ["nginx", "-g", "daemon off;", "-c", "/etc/nginx/nginx.conf"]
docker arrêtera le conteneur si vous n'exécutez pas la commande au premier plan.
Puisque nginx s'exécute en tant que démon, il doit être défini avec deamon off pour fonctionner au premier plan.
Un examen rapide du fichier de configuration.
Traitement d'écriture pour chaque module Il y a quatre modules
--core: modules liés au contrôle de processus, aux fichiers de configuration, etc. --event: Module lié au traitement des événements --http: Module lié à http --Module de messagerie lié au courrier
Décrivez chaque paramètre dans un contexte fixe. Écrivez le module principal dans le contexte principal. En d'autres termes, écrivez-le en haut du fichier de paramètres.
paramètres du module principal
events {
paramètres du module d'événement
}
http {
Paramètres du module http
}
mail {
paramètres du module de messagerie
}
Il s'agit d'un fichier de configuration de Nginx intégré à l'environnement Flask + Gunicon + docker-compose.
user nginx;
worker_processes auto;
#contexte d'événements: obligatoire
events {
worker_connections 512; #Limiter le nombre de connexions
}
#Contexte http: obligatoire
http {
keepalive_timeout 60;
server_tokens off;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
server {
listen 80;
server_name nginx_container;
charset UTF-8;
proxy_read_timeout 60s;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
#Nécessaire, un numéro de port approprié sera donné lors de la redirection dans l'application
port_in_redirect on;
# docker-Peut être spécifié par le nom du conteneur car il s'agit de réseaux avec composer
location / {
proxy_pass http://flask:5000;
}
}
}
À partir de maintenant, j'aborderai chaque point en détail: arrow_down:
worker_processes Vous pouvez spécifier le nombre de processus d'exécution. Réglez en fonction du nombre de cœurs. Si vous le réglez sur auto, il définira le nombre optimal de cœurs. La valeur par défaut est 1.
worker_connections Limite le nombre de connexions qu'un collaborateur peut gérer en même temps. S'il y a deux processus et 512 connexions, c'est un calcul qui peut traiter jusqu'à 1024 connexions en même temps. La valeur par défaut est 512.
C'est la même valeur que la valeur par défaut, mais je l'ai laissée intentionnellement parce que je considérais une autre valeur.
keepalive_timeout Il s'agit du nombre de secondes d'expiration du délai côté serveur. La valeur par défaut est 75.
server_tokens Définissez s'il faut afficher la version Nginx dans le pied de page de la page d'erreur. Il est inutile et doit être supprimé pour des raisons de sécurité. ʻOff`.
proxy_set_header Redéfinissez l'en-tête à envoyer au serveur principal.
proxy_redirect En-tête d'emplacement lors de la redirection du serveur principal. Si cette option est activée, proxy_pass est utilisé comme nom d'hôte, et si elle est désactivée, redirige comme indiqué par le serveur. Puisqu'il n'est pas nécessaire d'exposer le nom d'hôte qui est la configuration du conteneur dans l'en-tête d'emplacement, définissez-le sur ʻoff`.
port_in_redirect Un numéro de port approprié sera attribué. Si vous ne le définissez pas lors de la redirection dans l'application, le PORT du conteneur d'application sera utilisé. La redirection échoue à chaque fois car le port Nginx (80) et le port du conteneur App (5000) sont différents. Si vous souhaitez utiliser ridirect avec Flask, ce paramètre est indispensable.
location
Il est connecté au conteneur d'applications exécutant Flask comme suit.
proxy_pass http://flask:5000;
Cela est dû au fait que le conteneur flask de la source de connexion a les paramètres suivants dans les paramètres de docker-compose.
#Extrait
flask:
build: .
container_name: flask
#réduction
networks:
- front
expose:
- 5000
Je suis connecté à nginx via le réseau frontal. Par conséquent, vous pouvez vous connecter avec flask de nom_conteneur. De plus, puisque PORT est ouvert dans le conteneur de connexion avec «exposer 5000», connectez le numéro de port avec «5000».
C'était le contenu minimum, mais je n'ai pas encore suffisamment étudié. : crier: Si vous étudiez Nginx, vous apprendrez à gérer le trafic et à répartir la charge, ce qui semble être rentable. Merci d'avoir lu jusqu'au bout. : lift_hands_tone3:
Recommended Posts