Le dépôt Git contenant l'application **existait déjà**. Une étude des composants fournis par le projet a donc été nécessaire. Ce qui a été fournis aux développeurs également. Ce qui a permis d'en mesurer les implications.
L'équipe de développement a fait le choix du **monorepo** pour contenir l'ensemble des éléments de l'application. L'application est composée de :
* une base de données PostgreSQL,
* un backend écrit en Python et construit sur FastAPI,
* un frontend écrit en TypeScript et construit avec ReactJS.
L'ensemble se comprend mieux à l'aide du schéma suivant :
{height=55%}
### Outils fournis aux développeurs
Via le dépôt, les développeurs ont accès à :
* une documentation principale via un fichier **README.md**,
* une documentation secondaire via :
* un fichier **backend/README.md** pour les développeurs du Backend,
* un fichier **frontend/README.md** pour les développeurs du Frontend,
* plusieurs fichiers **Docker Compose** afin de déployer localement :
* une **base de données (BDD) PostgreSQL** avec un **jeu de données préchargé**,
* une interface Web, via l'outil adminer, à la BDD,
* le backend (FastAPI),
* le frontend (ReactJS),
* une documentation **deployment.md** pour déployer le projet à l'aide de **Docker Compose**,
* un fichier **docker-compose.traefik.yml** afin de déployer une instance locale du **proxy Traefik** configuré pour utiliser Docker
Ces éléments sont un bon point de départ pour l'équipe de DevOps qui prendra connaissance des particularités de cette application.
### Points d'attentions
La **partie Frontend** permet de générer des fichiers dits « statiques », du **serverless** est envisageable. L'application, bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la préparation pour un déploiement. Cependant **un nom de domaine est inscrit en dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur plusieurs domaines et environnements.
La partie Backend s'appuie sur une base de données de type PostgreSQL. Elle est donc **dépendante de la BDD**.
La partie proxy utilise actuellement **Traefik comme outil**. Ce qui n'est pas une obligation d'usage pour déploiement en production.
Ces trois parties ont une influence sur le choix de l'infrastructure à mettre en place. Il reste cependant une **marge de manœuvre sur la partie proxy**.
Afin d'accueillir l'application dans le Cloud, l'infrastructure de base va poser les fondations de l'environnement complet nécessaire à un usage quotidien.
La couche basse pourrait définir le minimum nécessaire avant d'installer quoique ce soit pour exploiter l'application. En ce sens, on utilise des éléments de base d'Amazon Web Services (AWS) pour fabriquer notre infrastructure :
* un espace privé, Virtual Private Cloud (**VPC**),
* sur plusieurs **régions**,
* avec plusieurs zones de disponibilités (**Availability Zone**),
* contenant chacune, d'un point de vue réseau informatique, des réseaux publics (**public subnet**) et des réseaux privés (**private subnet**),
* en utilisant une passerelle entre le VPC et Internet, appelée **Internet Gateway** (IGW),
* en utilisant des passerelles **NAT** (Network Access Translation) entre les réseaux privés et les réseaux publics pour un accès à l'IGW,
* avec des groupes de sécurité (**Security groups**) pour définir les règles d'entrée/sortie,
* et des équilibreurs de charge de type réseau (**Network Load Balancer**) afin de gérer les accès aux services de manière équilibrée.
Le schéma de la couche basse de l'infrastructure ressemble donc à :
{width=100%}
C'est sur cette base qu'il est possible d'intégrer un environnement capable de déployer, automatiser et gérer des applications conteneurisées.
Kubernetes est un système capable de faire tourner des applications conteneurisées, d'automatiser le déploiement et de gérer la mise à l'échelle (**auto-scaling**).
Sur l'infrastructure présentée dans le paragraphe précédent il va falloir ajouter quelques éléments comme :
* un cluster Kubernetes appelé EKS (**Elastic Kubernetes Service**) géré par Amazon,
* avec l'usage d'une mise à l'échelle (**autoscaling**) des serveurs virtuels EC2 (Elastic Container) d'Amazon,
* un équilibreur de charge de type réseau entre l'extérieur du cluster et le cluster (**AWS Elastic LoadBalancer** ou ELB) ; présent d'ailleurs dans le schéma de la couche basse de l'infrastructure dans le paragraphe précédent,
* un équilibreur de charge de type réseau (couche 4 du modèle OSI - Open Systems Interconnection) qui fait le lien entre les services et l'extérieur du cluster : **NGINX Ingress Controller** ; il va notamment échanger avec l'AWS Elastic LoadBalancer précédent,
* l'utilisation d'un agent **externaldns** qui va mettre à jour les routes DNS (Domain Name System) de **Route53** pour les sous-domaines utilisés (~16€/mois pour 3 routes),
* et avec l'usage de **cert-manager** pour faire la demande de certificats SSL (Secure Sockets Layer) via le service - gratuit - de **Let's Encrypt** pour nos sous-domaines.
{width=100%}
Dans le cluster pourra donc tourner, en plus des agents précédemment cités, les applications suivantes :
* le serveur de BDD postgreSQL,
* le backend de l'application (FastAPI),
* et le frontend de l'application (en fichiers statiques).
Afin de permettre une livraison régulière de l'application, il va falloir automatiser au maximum les étapes entre la publication d'une nouvelle version de l'application et sa livraison. Puis son déploiement en production via une intervention humaine.
Nous parlons de production depuis un moment. À quoi cela correspond ?
Afin de mener à bien le travail de DevOps, nous avons défini les différents environnements par lesquels nous allons passer pour toute notre chaîne de production logicielle. Ainsi nous avons 4 environnements :
* l'environnement de **développement** : c'est l'environnement disponible sur chaque machine des développeurs à l'aide des outils fournis (Dockerfile, docker-compose du projet applicatif),
* l'environnement de test : il est composé de l'ensemble des Runner Gitlab utilisés à l'intérieur de la chaîne d'intégration continue,
* l'environnement de pré-production (appelé « staging ») : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration dite *plus légère* (moins de machines virtuelles EC2 par exemple),
* et l'environnement de production : c'est l'infrastructure finale ; celle qui est disponible aux usagers.
Il est visé une CI/cd, c'est à dire une Intégration Continue (Continuous Integration) et une livraison continue (continuous delivery). **L'automatisation est donc essentielle.**
Le déploiement en production passera par une validation manuelle.
Doivent être automatisés :
* les tests du backend,
* les tests du frontend,
* l'étude de sécurité sur les dépendances des composants de l'application,
* la génération d'une image Docker pour le frontend et le backend,
* la publication de cette image sur un dépôt d'images,
* le déploiement d'un environnement de pré-production (appelé *staging*, dont nous parlerons dans le chapitre [Démarche suivie](#demarche)),
* le déploiement, une fois la validation manuelle sur l'environnement de pré-production faite, d'un environnement de production,
* et la mise en place initiale de l'infrastructure (appelée boostrap).
Nous retrouverons ces éléments dans les chapitres suivants.
Plusieurs sujets tournent autour des services mis en place :
* les données : définit les éléments enregistrés à l'usage quotidien de l'application,
* la supervision : définit tous les éléments permettant de mesurer les différents services et d'alerter si les métriques dépassent des seuils définis,
* la sécurité : définit tout ce qui peut être mis en œuvre pour palier rapidement à des problèmes de sécurité de l'application, de l'infrastructure et des outils utilisés.
Le sujet des données ne couvre pas uniquement les données brutes enregistrées par l'application, mais aussi la manière de les stocker, de les sauver via un plan de sauvegarde et de les restaurer si besoin.
#### Où sont les données ?
Les données de ce projet sont multiples. En voici une liste non-exhaustive :
* les dépôts contenant le **code applicatif** (backend + frontend),
* les dépôts contenant la **description de l'infrastructure**,
* les données brutes de l'application, stockées dans la **base de données postgreSQL**,
* les **données sensibles** (mots de passe, clés d'accès),
* les **copies de sauvegardes** des données elle-même,
* et les **fichiers de journalisation** des services en production.
Pour le choix d'un service de base de données, nous avons fini par opter pour postgresql-ha (pour postgreSQL High Availability) qui s'appuie sur 2 bases de données répliquées avec un service **pgpool** par lequel on accède pour chaque requête faite à la base de données.
{width=50%}\
Les dépôts de version utilisés étant sur Gitlab, [service qui se targue d'être entre 99% et 100% disponible](https://handbook.gitlab.com/handbook/engineering/monitoring/#historical-service-availability), une sauvegarde dite « préventive » mensuelle suffit.
En revanche la production, même en étant un service en haute disponibilité doit fournir une sauvegarde au moins 1 fois par jour. L'outil de sauvegarde choisi est **Velero**. Compatible avec l'environnement Kubernetes et permettant aussi de sauver l'état du cluster à un moment donné. Son outil en ligne de commande permet de gérer les sauvegardes mais aussi les restaurations.
Comme énoncé précédemment, les sauvegardes du cluster seront mises sur un stockage AWS S3 (dit « bucket »).
Le fonctionnement de Velero dans ce projet est visible sur le schéma suivant.
Le choix se porte sur Datadog pour sa souplesse et sa capacité à proposer des services supplémentaires de manière progressive.
Le fonctionnement semble simple : installation d'agents Datadog dans le système Kubernetes pour receuillir de nombreuses informations. Comme peut le montrer le schéma suivant.
Pour le monitoring, on veillera à suivre des indicateurs simples comme l'utilisation CPU et la mémoire vive des instances AWS EC2 (Elastic Compute Cloud) utilisées.
On veillera à utiliser **un canal Slack** (*#alertes*) pour avertir les DevOps d'une quelconque alerte levée. Datadog permet cela facilement comme énoncé dans l'introduction de ce chapitre sur la Supervision.
Suite aux alertes, les DevOps peuvent opérer et notifier de la prise en charge d'un problème via le chatbot Gitlab intégré à ce canal Slack. Nous utilisons donc le [**Gitlab ChatOps**](https://docs.gitlab.com/ci/chatops/).
Les spécifications techniques étant établies, nous allons pouvoir nous concentrer sur la démarche suivie pour mettre en place le projet. C'est à dire comment nous allons atteindre les objectifs du cahier des charges à l'aide des solutions choisies dans les spécifications techniques.
