diff --git a/content/30_specifications_techniques.md b/content/30_specifications_techniques.md index 1e32cb3..26f1cff 100644 --- a/content/30_specifications_techniques.md +++ b/content/30_specifications_techniques.md @@ -2,17 +2,11 @@ # Spécifications techniques -TODO: spécifications techniques - -Mot clé : écosystème DevOps - -Blah blah - -Ainsi nous commençons par nous organiser pour collaborer sur le -projet pour répondre aux besoins ; après quoi nous nous tournons vers -l'étude de l'application pour continuer sur le choix d'une infrastructure pour -accueillir nos services. Finalement nous choisissons aussi des outils autour -de l'application pour garantir un certain niveau de service. +Après avoir décrit, via un cahier des charges, les différents besoins du +projet, les livrables attendus, il est temps de décrire une solution choisie. +Nous aborderons avant tout l'étude de l'existant puis enchaînerons sur le +détail de l'infrastructure choisie pour terminer sur divers sujets intégrés +et quelques outils utilisés. ## Étude de l'application @@ -163,59 +157,80 @@ Les données de ce projet sont multiples. En voici une liste non-exhaustive  * les **copies de sauvegardes** des données elle-même, * et les **fichiers de journalisation** des services en production. -#### TODO - -sous-chapitres : - -* Cas de la BDD ? Adapter une fois la solution choisie + déployée ? -* Stockage : où stocker les sauvegardes ? => Bucket S3 à part ? Si oui : le mettre dans le bootstrap Terraform -* Sauvegardes : fréquence - -#### BDD postgreSQL - -Choix entre : - -* opérateur postgreSQL -* RDS en mode postgreSQL (Aurora ?) sur plusieurs zones ? -* postgresql-ha via une chart Helm +Regardons pour chacun des points où se situe le stockage. #### Stockage +En reprenant les éléments précédent, nous avons : + +* des **dépôts Gitlab** pour notre code applicatif ET les dépôts de l'infrastructure, gérés par Gitlab, +* un **stockage AWS EBS** (Elastic Block Store) pour la base de données postgreSQL, +* et un **stockage AWS S3** (Simple Storage Service) pour les copies de sauvegardes. + +Cela devrait être suffisant pour stocker les diverses données disponibles. + +#### Base de données postgreSQL + +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. + +![Schéma du fonctionnement de postgreSQL-HA](./media/postgresql-ha.png){width=50%}\ + #### Sauvegardes +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. + +[//]: # Cf. https://mermaid.live/view#pako:eNptVE1v00AQ_SvWSr0lkWOTOPEBKU2CFLWUgkuRkKVqY08dK7Y37EegRLlxqiqBygFuvSH4B1zopT-I_gTWazteK1g-2G9m35t5s7sbFJAQkIsMxjGHSYwjitP22vKzgwNjMn02O5mdzV6ceH5myEcwoIZrvOZxEjOZL2iBryEBSi6CJJbRx7ub63MFGOPjWZGwHLALvMqjR2IONAMOzBidllFYMhmZHpUqzFYsX38cimAJ3PDshsqKhE0VCRQJIY3XqsDHu9v76aHXHnuz9kSBdRlrkhQZf85JIlJgZQ1zpuBvn_7-_izXFih-z0qt0RvPqPQSEcVZuYwHeTXTs_GkrGGuFnz5fkoYjyh4L4-LgHL01fR4pPmpddRuP60av7lmWKwhwjSEnSN5fM8ACnJsgoI2HS1PjmNvPHm4HkbOEZA0FVn8TkBzVE3B_VjeueaBRvzf3monQ0hxFoIhX5bhFVsQXvijjbBiK4YVPfysesxplPq8oqs46jHurMQ0WEi6_dpDbU9oihXp7T1kFKKY8UpWTrVREuMkWD788stdoA6P2sabAtAEa6B2rOlPjel1afu1BmT7Wva8-N76GWqhFGiK41CeZVWDj_gCUvCRKz9DuMQi4T7ys61MxYIT7yoLkMupgBaiREQL5F7ihMk_sQrrq6BKWeHsLSHpLkn-I3eDPiDXMu3O0B70TMccmKYz6FotdCVhp9ux7Z5pdYeO1e_1rd62hT4qCrPTty3Hdob2k95ALu23EIQxJ_R5cRepK2n7D1LIfM8 + +![Schéma du système de sauvegarde](./media/schema_velero.png){height=50%}\ + ### Supervision +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. + +[//]: # Cf. https://mermaid.live/view#pako:eNp1VEtu2zAQvQrBImgLKIYs-RctCji2ChhxHMNKUaDQhhZHjiCZNCiqbRL4DgV6gB6g-266C9D79Agl9ZeTaiPyzZsZzvcRB5wCdnAqiYR5RHaC7M8_Wz7z2dkZmrvvF6vF7eJm5fkMqY8SSSjfIQf9_fHtF5oX10IGcarw6Z48cIbcq1Ij4EwKnijJ6s_3jKKnn2hWQuuEMEBPvwviFy5iEG3exwLRhNJ7QLSHHTBZuUY0Q0GSpRJEyWEvcpg2WjDibAsJSMW6Kk5VaOndlhNBlWBenQvRnrNIcv22a32CTLxJ35YiEunYZjwTIoKkANOEBLFCPf03EMig1ySDRAxEP9dhEpgyhuhrcjgkUQ_1T2jWyzSroJFDpENdL5AH4rNOgCrZ7GZ5s6lyn5A0nUOINkBRGCWJ8yoMaUgHRqoKEIMjgJ4wL5MMSioZBCFsK-pWCU6464jFtVkYQFhxD0rQ4uZ123Rc5WW67JrM41nnqnkkG3c5bbVeVbbz83e5dlPuHAlI0yMlpQso603aNBB3ql-ptTu6Nt4Gq2bQgrL606W7uXW95_KqEUoCetYFnZe2yl7jxRhOVx5aumi2_ODdupuyyfTE5kP3WAANWM1cS1AG3gXqpOnveGqlHMgTI52s1YYY6QJNiP_ByxY-dn6F32rHtBzT7jy20lzrYwPvQaiCULXNclUfyzvYg48ddaQQkiyRPvbZUVFJJrl3zwLsSJGBgQXPdnfYCUmSqlt2oM02rCgHwj5xvq9J6o6dR_wVO5Zp9y7sydAcmxPTHE_6loHvFTzu92x7aFr9i7E1Go6s4dHAD7kJszeyrbE9vrAHw4lSHRkYqA7nutjG-VI-_gOoBrf7 Choix de Datadog au détriment de Prometheus, faute de temps -Prévu de : - -* prometheus -* avec nginx-ingress-controller privé -* et accès VPN dessus - -Pas fait faute de temps. - -TODO: SLA (Service Level Agreement) à définir ICI !!!! +![Schéma des agents Datadog dans notre système Kubernetes](./media/schema_datadog.png){height=50%}\ #### Surveillance (monitoring) -Choix indicateurs +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. + +Il y a également : + +* le nombre de pods utilisés par l'instance EC2, +* et la disponibilité du service de l'application API-Utilisateurs. + +Cependant ces moniteurs peuvent s'agrémenter d'alertes. #### Alertes -Système d'alerte : slack, ou autre ? Mail ? +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. -#### PRA (plan reprise activité) +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/). -backup (rappel du chapitre précédent) +En suivant toutes ces indications, nous devrions avoir une base stable et saine pour constuire une supervision correcte de l'API-Utilisateurs. ### Sécurité -#### Gestion utilisateurs +Au niveau de la sécurité, vaste sujet, nous partirons de peu d'éléments : -#### Vault +* lancement de tests sur le code applicatif, +* lancement de tests SAST (Static application security testing), sur Terraform notamment, +* et utilisation d'un coffre fort numérique pour les mots de passes et clés d'accès en tous genres. -#### Système gestion mdp collaboratif +Le coffre-fort choisi est **Vaultwarden**. +Il y a beaucoup à faire pour améliorer la sécurité. Ceci est un processus continu à faire tout au long du suivi et la maintenance du projet. ## Conclusion + +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. diff --git a/media/postgresql-ha.png b/media/postgresql-ha.png new file mode 100644 index 0000000..6620d3e Binary files /dev/null and b/media/postgresql-ha.png differ diff --git a/media/schema_datadog.png b/media/schema_datadog.png new file mode 100644 index 0000000..45b5c65 Binary files /dev/null and b/media/schema_datadog.png differ diff --git a/media/schema_velero.png b/media/schema_velero.png new file mode 100644 index 0000000..9f7033e Binary files /dev/null and b/media/schema_velero.png differ