Utilisation de Flask avec la configuration Nginx + gunicorn [Environnement local]

Résumé de cet article

• Comme étape 1 de la Feuille de route d'apprentissage des applications Web avec Python * ** Décrit la procédure de lancement d'une application Flask avec la configuration suivante dans l'environnement local et les paramètres associés **. (Voir la figure ci-dessous pour la configuration) Il suppose que «Python a installé Mac OS». (Mais je ne pense pas qu'il y ait une grande différence sur les autres plates-formes.)

Tableau de référence rapide des articles

――Quand vous lisez un article similaire, pourquoi souvent? Que voulez-vous dire? Je me sens-> [Qu'est-ce que / qu'est-ce que ○○? ](Que signifie) --Je devrais bouger-> [Essayer de bouger](# Essayer de bouger) --Je veux en savoir plus sur le fichier de paramétrage de gunicorn et Nginx-> [Démêler le fichier de paramétrage et la commande start / end](#Unravel la commande start / end du fichier de paramétrage)

Essayez de bouger

Tout d'abord, fonctionnons avec la configuration ci-dessus. Installez les packages requis.

brew install nginx
pip install gunicorn

Structure du projet et contenu de chaque fichier

PROJECT
├── config
│   ├── gunicorn_settings.py #Fichier de configuration du serveur d'applications
│   └── nginx.conf           #Fichier de configuration du serveur Web
└── flask_app.py             #Application principale

--Fichier d'application
Cette fois, nous ne nous soucions pas du comportement de l'application, nous allons donc préparer seulement deux routes pour renvoyer la chaîne de caractères.

flask_app.py

from flask import Flask

app = Flask(__name__)

@app.route('/')
def index():
    return 'Index Page!'

@app.route('/health')
def health():
    return 'Health Check OK!!'

--Fichier de configuration du serveur Web

gunicorn_settings.py

import os

bind = '127.0.0.1:' + str(os.getenv('PORT', 9876))
proc_name = 'Infrastructure-Practice-Flask'
workers = 1

--Fichier de configuration Nginx

nginx.conf

#Voir la section du fichier de configuration pour plus de détails
worker_processes  1;

events {
	worker_connections 512;
}

http {
    server {
    	listen  9123;
    	server_name INFRA-PRACTICE-NGINX;
		charset UTF-8;

		proxy_set_header    Host    $host;

    	location / {
        	proxy_pass http://127.0.0.1:9876;
    	}

	    location /health/ {
        	proxy_pass http://127.0.0.1:9876/health;
    	}
    }
}

Démarrez le processus

Terminal

#Démarrez le serveur Web
nginx -c ${PROJECT_PATH}/config/nginx.conf

#Démarrer le serveur d'applications
gunicorn flask_app:app -c config/gunicorn_settings.py

Confirmer la communication

Terminal

curl http://localhost:9123/
# -> Index Page!OK si ça revient
curl http://localhost:9123/health/
# -> Health Check OK!!OK si ça revient

Démêler le fichier de paramètres et les commandes de démarrage / fin

gunicorn

fichier de configuration

Dans les Documents officiels, il est décrit dans un format facultatif. Lors de l'utilisation d'un fichier de paramétrage, il est écrit au format key = value avec le nom de l'élément de paramétrage comme clé (* par exemple * loglevel = 'debug'). L'extension du fichier de paramètres est arbitraire. Certains des paramètres sont indiqués ci-dessous.

Commande de début / fin

【Commencez】

Terminal

gunicorn {Nom du fichier d'application Flask}:{Nom de la variable d'instance Flask dans le fichier} -c {Chemin du fichier de configuration}

• Comme mentionné dans la section du fichier de configuration, le paramètre peut également être spécifié comme option de démarrage.

[Fin] Ctrl + C dans le terminal où le processus est en cours d'exécution

Nginx

fichier de configuration

En regardant les Documents officiels, contrairement au format key = value de gunicorn, Vous pouvez voir que la directive (instruction) est décrite dans le format de contexte (* accolade: * bloc inclus dans {}) à l'intérieur du module.

Module

• De plus, il y a mail et stream.

Directive Syntax in http context Contexte du serveur dans le contexte http, contexte de localisation supplémentaire dans le contexte du serveur Et ainsi de suite, nous écrirons en contexte dans un format contextuel. Voici un exemple de configuration du bloc http. En regardant l'exemple, vous pouvez comprendre ce que signifie le fichier de paramètres au début.

--Paramètres de base

config

http {
    server {
        listen        80;                          #Attendez la connexion sur le port 80
        server_name   MY_SERVER;                   #Le nom du serveur est MY_SERVER
        charset       UTF-8;                       #Contenu de l'en-tête de la réponse-tapez en UTF-Désigné comme 8
        error_page    404  /404_not_found.html;    #404 lorsque le code d'état est 404_not_found.Redirection interne vers html
    }
}

• Proxy inverse

config

http {
    server {
        # /Accès à l'index
        location /index {
            proxy_pass          http://127.0.0.1:8080;  # 127.0.0.Proxy inverse vers le port 1 8080
            proxy_set_header    Host    $host;          #Parmi les en-têtes de demande transmis au serveur proxy, l'hôte$Réinitialiser l'hôte
　　　　　　  proxy_read_timeout  60s;                    #Délai d'attente en l'absence de réponse du serveur mandaté pendant 60 secondes
        }
    }
}

• Contrôle d'accès / filtrage IP

config

config
http {
    server {
        location / {
            allow 192.168.0.1;    # 192.168.0.Autoriser l'accès à partir de 1
            deny  all;            #Refuser tout autre accès au réseau
        }
    }
}

--Certification BASIQUE

config

http {
    server {
        location / {
            auth_basic             "Basic Auth closed site";　　#Précisez que l'authentification BASIC est requise
            auth_basic_user_file   conf/htpasswd;               # .htpasswd Spécifiez le chemin du fichier
        }
    }
}

--Contrôle par référence

config

http {
    server {
        #Il n'y a pas de référent dans l'en-tête de la demande(none), Dans l'en-tête mais http://Ou https://Ne commence pas par(blocked)、
        # mintak.Ne se termine pas par com(server_names)Jugé invalide lors de l'accès à partir de la racine->$invalid_Définir le référent sur 1
        valid_referers none blocked server_names *mintak.com
        if ($invalid_referer) {
           return 403;  #S'il est jugé invalide, il sera renvoyé avec 403 Interdit.
        }
    }
}

Embbed Variable Quelque chose comme une variable d'environnement sur un serveur Nginx. Pour plus d'informations, cliquez ici (https://nginx.org/en/docs/http/ngx_http_core_module.html#variables). Certains sont présentés ci-dessous.

Commande de début / fin

【Commencez】

Terminal

nginx -c {Chemin du fichier de configuration}

[Fin]

Terminal

nginx -s stop

#Si ce qui précède échoue, identifiez le processus et tuez
ps ax | grep nginx
kill -9 ${PID}

[Confirmation de démarrage]

Terminal

ps aux | grep nginx    #Ici nginx:Si cela indique le processus maître, nginx est en cours d'exécution.

#Commande qui peut confirmer PORT
lsof -i -P | grep nginx
#=> nginx     41845 mintak    6u  IPv4 0x595e7f947462ada5      0t0  TCP *:9123 (LISTEN)

Qu'est-ce que ○○?

Vous pouvez atteindre l'objectif en préparant les fichiers jusqu'à ce point et en appuyant sur la commande. Cependant, il existe de nombreux mots et concepts difficiles pour les débutants comme moi. À partir de là, je décrirai ma propre interprétation de ces mots-clés.

Pourquoi est-ce une telle configuration

Selon un expert, le serveur Web et le serveur d'applications n'étaient pas séparés dans le passé. Cette configuration est devenue problématique face au fait qu'avec la diffusion d'Internet, le nombre d'accès aux services ouverts au public a augmenté, ce qui a augmenté la charge sur le serveur et réduit les performances globales. fait. Par conséquent, en visant un fonctionnement stable en répartissant la charge, le flux consiste à diviser le serveur selon le rôle décrit plus loin. Cette idée est courante dans les temps modernes, et il semble que les services Web sont généralement constitués d'une structure à trois couches de serveur Web <-> serveur d'application <-> serveur de base de données. Je pense que l'idée de base de ** séparer les processus (serveurs) pour chaque rôle ** a quelque chose en commun avec le concept de conception pour le codage (un rôle clair pour chaque classe / fonction).

Mais cela fonctionne avec python flask_app.run

En effet, le framework appelé Flask est un framework qui peut être démarré tout en servant simultanément de serveur Web / serveur d'applications. Il est utile lorsqu'il est difficile de configurer séparément le serveur Web et le serveur d'applications, comme ** pour une simple vérification et un contrôle de fonctionnement pendant le développement **. Au démarrage de cette commande, le journal "AVERTISSEMENT: Ceci est un serveur de développement. Ne l'utilisez pas dans un développement de production .`" apparaît [^ 1], mais il est pour le développement uniquement, et avec cette configuration, l'accès en masse Cela signifie qu'il y a un gros risque de crevaison pendant le traitement, donc ** arrêter la production **.

• Si vous ajoutez ʻapp.run (host = '0.0.0.0, port = 9876) `à flask_app.py, il démarrera même avec la commande ci-dessus.

Le rôle principal du serveur Web et du serveur d'applications

Je résumerai chacun en un mot. Voir la page de lien de référence pour plus de détails.

• Serveur Web: prend en charge les demandes qui ne changent pas, quel que soit leur accès (traitement statique). La page TOP est facile à atteindre.
• Serveur d'application: prend en charge les réponses qui changent en fonction de l'accès (traitement dynamique). Membre Ma page etc. (Le contenu d'affichage diffère selon le membre).

Pourquoi un proxy inverse est-il inversé?

S'il y a un inverse, il y a un avant **. Ce que nous appelons généralement un proxy est un proxy direct.

Quelle est la différence entre un proxy direct et un proxy inverse?

Ils sont toujours par procuration l'un de l'autre. Le traitement entre client-> Internet est un proxy direct (serveur), et le traitement entre Internet-> serveur Web cible est un proxy inverse (serveur). [^ 2]

Il vous suffit de vous connecter directement au serveur cible! Vous pourriez penser, mais vous pouvez bénéficier de mordre le serveur proxy (voir ci-dessous).

Utilisation du proxy direct

Utilisation du proxy inverse

Qu'est-ce que WSGI?

Abréviation de Web Server Gateway Interface. ~~ Connu sous le nom d'Uesugi-kun. ~~ Django et Flask sont des frameworks compatibles WSGI, et gunicorn et uWEGI sont des serveurs compatibles WSGI, donc je pense qu'il n'y a pas de problème de reconnaissance. Le fond de son apparence est le suivant. [^ 3]

・ Framework A-chan> Je suis cool, donc je suis fou sauf α-kun, un serveur web sympa ・ Framework B> J'aime un β-kun solide ♡

Dans le passé, les serveurs Web pouvant être utilisés pour chaque framework Web Python étaient limités (et vice versa). En fait, je voulais que B-chan utilise α-kun, mais ici, la relation de mariage avec A-chan sera un frein. Uesugi-kun et WEGI semblaient résoudre ce problème. WEGI dit: "Choisissons librement le serveur et le framework ~~ love ~~ Connectons-nous", comment communiquer dans la relation du framework d'application <-> Serveur Web J'ai établi la règle. Grâce aux serveurs et frameworks compatibles WSGI et WSGI, nous sommes désormais libres de choisir la combinaison serveur et framework. Je suis heureux.

References

• Document officiel de Gunicorn
• Document Nginx (original)
• Document Nginx (traduction japonaise)
• Résumé des paramètres Nginx (Qiita)
• Différence entre le serveur Web et le serveur AP (Think IT)

[^ 1]: Lorsque FLASK_ENV = development n'est pas défini. [^ 2]: Cette fois, Nginx est à la fois un serveur proxy et un serveur Web. [^ 3]: Je pense que c'est la seule façon d'expliquer cette chose stupide. .. ..