Trois approches pour déployer une application web (Partie 1)

Exemple d’application : un programme de webscraping d’articles de presse avec analyse de sentiments.

Imaginez : Votre projet de webscraping est enfin terminé! ou presque… Vous avez maintenant une application capable d’extraire des articles de presse en ligne puis d’effectuer une analyse de sentiment sur leur contenu. Vous avez réglé tous les problèmes de compatibilité entre librairies NLP dans votre environnement virtuel. Votre approche de parsing est robuste, l’analyse de sentiment tient la route et vous êtes satisfait du rendu visuel.

Comment faire profiter le monde de votre invention? par le web bien sûr!

Entre un programme développé sur une machine locale et un service web sécurisé et accessible au monde entier, il existe un certain nombre d’étapes à considérer. Le terme « déploiement » désigne le processus nécessaire à la mise en service d’une application également appelé service web. Les approches pour déployer un service web sont multiples.

Dans cette série d’articles, nous présenterons 3 scénarios :

Scénario 1: Approche from scratch

Scénario 2: Approche dockers

Scénario 3: Approche serverless

Scénario 1: Approche from scratch 

Utiliser fastAPI et NGINX

Qu’est-ce qu’une API ?

Quand je vais au restaurant, je ne suis intéressé que par deux choses : les boissons et la nourriture. Le reste ne me concerne pas. La recette du poulet général Tao m’est inconnue et je ne veux rien savoir du roulement d’inventaire, de la comptabilité ni des visites impromptues du service d’hygiène. Le fonctionnement du restaurant et les étapes nécessaires au service qu’il offre ne sont pas mon problème. Dans cette situation, le serveur du restaurant joue le rôle de l’API entre moi et les processus complexes du restaurant (cuisine, inventaire, gestion, etc.). Il facilite et simplifie mon interaction avec le restaurant.

Le rôle d’une API ou “Application Programming Interface” est d’assurer la communication entre deux applications A et B. L’application A accède à la fonctionnalité F de l’application B via une API qui permet :

  • D’étendre les fonctionnalités de A

  • De réduire la complexité : le concepteur de A n’a pas besoin de développer la fonctionnalité F lui même

  • D’assurer une communication sécuritaire entre A et B

Ce mode de fonctionnement est en réalité EXTRÊMEMENT répandu, il est même omniprésent. Pensez-y, la fonctionnalité est la raison d’être d’une application et fait toute sa valeur ajoutée. Concevoir une application revient à mettre une fonctionnalité à la disposition d’un utilisateur. Mais un fournisseur d’application ne se limite pas à offrir des fonctionnalités « natives » développées par lui-même, il offre aussi des fonctionnalités issues d’autres applications.

Par exemple, quand Google fournit la météo, l’information vient en réalité de tiers tels que Weather Underground ou The Weather Channel. La connectivité entre les deux est alors gérée par une API.

Qu’est-ce que fastAPI ?

FastAPI est un cadre d’application (application framework) utilisé pour bâtir des applications web. Cet outil est basé sur deux autres cadres : Starlette (serveur web) et Pydantic (validation de données). Rapide, facile à utiliser, à déployer et permettant d’éviter les doublons, fastAPI est très apprécié pour des projets de science de données et d’apprentissage automatique ( machine learning ).

Qu’est-ce que NGINX ?

NGINX est un logiciel de gestion d’applications web qui joue à la fois les rôles de serveur web*, reverse proxy*, load balancer* et cache*.  


Quelques définitions s’imposent… 

Le serveur web agit comme un ordinateur qui contient l’ensemble des fichiers composant un site internet (documents HTML, images, fichiers CSS et JavaScript, etc.) et envoie le contenu de ces fichiers à l’utilisateur qui consulte le site web. 

Un proxy est un intermédiaire entre le client et le serveur web qui fournit au client un certain niveau de service (ex : caching) et de sécurité (agit comme un pare-feu, effectue l’encryption-désencryption).

Un reverse proxy agit dans le sens inverse : Il protège le serveur web au lieu du client et peut également assurer le load balancing (c’est le cas de NGINX).

Également connu sous le nom de « Application Delivery Controllers », le load balancing consiste à gérer le trafic entrant d’une application web en distribuant le trafic sur plusieurs serveurs. Autrefois pris en charge par des plateformes matérielles (hardware) dans des centres de données privés, il peut aujourd’hui être pris en charge par des logiciels (ex : NGINX)

Le caching conserve l’information fréquemment demandée/utilisée dans un endroit facile d’accès pour l’utilisateur. Le cache contient généralement peu d’information mais celle-ci est facile d’accès (exemple : cache d’un navigateur internet). En guise d’illustration, imaginez un livre que vous consultez fréquemment. Il est plus pratique de l’avoir posé sur la table à votre portée que dans la bibliothèque de l’autre côté de la pièce.  

Les étapes à suivre pour le scénario 1

1) Créer le serveur : la première étape est de mettre en place un serveur avec une plateforme infonuagique comme une instance EC2 sur AWS (Amazon Web Services).

2) Configurer l’instance :

o   mettre à jour le système d’exploitation

o   installer NGINX

o   cloner le code de l’API

3) Configurer NGINX : créer un fichier de configuration avec sudo – nano pour le server web NGINX appelé fastAPI_nginx :

server {
    listen 80;
    server_name 18.116.199.161;
    location / {
        proxy_pass http://127.0.0.1:8000;
    }
}

4) Lancer le serveur web:  sudo service nginx restart 

5) Lancer le service applicatif (uvicorn) : python3 -m uvicorn main:app

 

Et voilà ! NGINX fait alors la connexion entre le serveur applicatif (uvicorn) et le web, en plus de gérer le trafic qui vient du web (load balancing).

Restez à l’écoute pour le prochain article avec le scénario numéro 2 : approche «Docker» !

FrÉmile Zerbib et Sébastien Duguayweb, application, déploiementCommentaire