Élasticité

Une infrastruture web aws élastique qui s'adapte à l'intensité du trafic (golden image + ASG), idéal pour trafic saisonnier, solutions saas, site e-commerce...

Mode On/Off en 1 clic depuis Gitlab

Une automatisation capable de créer et de détruire une infrastructure entière à la volée en 1 clic depuis Gitlab, avec reprise des données à la re-création. Peut se programmer à heures fixes depuis un scheduled pipeline. Très utile pour éteindre la pp la nuit et le weekend. Possible aussi en production, les magasins sont fermés la nuit et le dimanche, pourquoi pas les sites internet.

Déploiement applicatif automatisé depuis Gitlab

2 types de déploiements possibles (au choix depuis gitlab) :

- "Straightforward" : pour les mises à jours mineures et sans modification de la bdd : on crée une nouvelle image ec2 (systeme + application), on la déploie et on vide les caches. Temps du build/deploy inférieur à 10mn.

- "With-maintenance-or-bdd-changes" : pour les mises à jours majeures qui requièrent une mise en maintenance et/ou des modifications en bdd. On crée une nouvelle image ec2, puis au choix en 1 clic depuis gitlab : maintenance du site --> snapshot de la bdd --> modifications de la bdd --> déploiement de l'image --> clear-cache --> retrait de la maintenance

- Tout est déjà prévu pour déployer, seul quelques ajustements seront faits en fonction de l'applicatif (en particulier la personnalisation du script de build de l'application dans la golden image)

Copie de données anonymisées prod-pp en 1 clic depuis gitlab.

Par défaut, la copie concerne la bdd RDS et l'EFS. L'anonymisation est faite depuis la prod avant l'envoi sur pp (le script d'anonymisation sera donné par les dev). Un pipeline gère l'intégralité de l'opération de copie et anonymisation, un autre pipeline gère la restauration sur la pp. Peut se programmer à heures fixes depuis un scheduled pipeline.

Page de maintenance en 1 clic depuis gitlab

Une page de maintenance du site est activable en quelques secondes en 1 clic depuis Gitlab et contournable par l'envoi d'un header http spécifique (donc sans avoir besoin d'une IP particulière). La page est personnalisable. Maintenance possible aussi depuis Cloudflare.

3 types de disponibilité possibles : Mono-AZ, Smart-Multi-AZ, Full-Multi-AZ

Ce projet propose 3 types d'infrastructures ayant chacun leurs avantages et inconvénients en matière de coût financier, disponibilité de service et coût écologique, avec la possibilité de passer d'un type à l'autre pendant le run : Mono-AZ, Smart-Multi-AZ, Full-Multi-AZ. Le Smart-Multi-AZ étant une évolution du Multi-AZ qui permet d'économiser les coûts de bande-passante inter-zone tout en diminuant les temps de latence des échanges réseaux.

3 types de Cache HTTP - Varnish-cache

3 types d'infrastructures possibles en matière de cache http en fonction de la taille de l'infra et du trafic attendu : Varnish-Less, Varnish-Light, Varnish-Full. Varnish-light embarque varnish sur les vm applicatives, Varnish-Full a des vm dédiées à celui-ci. Possibilité de passer d'un type à l'autre. Un proxy pour les purges varnish est en place sur les machines ec2 applicatives. Il faudra juste configurer les purges de l'application sur localhost:82 et le système mis en place par cette automatisation se chargera de purger l'ensemble des varnish de l'infra.

Environnements ISO et complètement indépendants

- 1 environnement = 1 compte aws et 1 répertoire contenant toute l'automatisation (dupliquée pour chaque environnement).

- Résultat : pas d'adhérence entre les environnements et aucun fichier commun. Si l'on veut une spécificité sur un environnement, les autres ne nous empêchent pas de le faire, approche simple. La comparaison des environnements se fait en comparant leurs répertoires respectifs qui sont quasiment les mêmes.

Monorepo

- Un repo "infra-devops" contenant la totalité de l'automatisation "infra-devops" : bash, packer, ansible, terraform.

- Les pipelines seront lancés depuis le repo "app", ce qui permet aux développeurs d'être autonomes sur les différentes tâches tels que les déploiements, les copies de données prod-pp, l'extinction/démarrage d'un environnement etc... Le repo infra-devops (branche main) est chargé depuis le pipeline. Ainsi, l'infra est toujours déployée depuis la branche main, les dev sont libres de choisir le workflow git qu'ils veulent sur leur repo app.

Un code fait entièrement maison, simple, léger et maîtrisé

- Un simple enchaînement de ressources terraform et de tasks ansible sans surcouche et orienté Sysops, c'est à dire facilement compréhensible et maintenable par des sysadmins (pas besoin d'être développeur). On se concentre sur l'infra et non le code.

- Environ 3800 lignes au total (Versus des centaines de milliers pour le code communautaire utilisé par beaucoup d'entreprises).

- Code Terraform : environ 1600 lignes

- Code Ansible : Environ 1400 lignes au total (Comprend tous les rôles : debian-common, debian-apache-php, debian-varnish, debian-haproxy, debian-filebeat, debian-logstash, debian-proxy-purge-varnish-aws). Environ 3000 lignes avec les fichiers de configuration des middlewares : répertoire "files" et "templates".

- Scripts bash : environ 800 lignes (essentiellement déclenchés depuis des pipelines gitlab)

Finops / Greenops / Performances

- Élasticité, golden images, dimensionnements optimaux, réservations d'instances, mode ON/OFF, légèreté du code et de son exécution, cache varnish, Mode Smart-Multi-AZ, Mode Full-Mono-AZ + PRA, configurations optimisées.

- Cette automatisation apporte beaucoup d'éléments greenops, primordiaux à notre époque, cependant il sera essentiel de choisir un datacentre qui se trouve dans une zone qui fournit de l'électricité la plus propre possible, comme c'est le cas pour Paris. Ne surtout pas installer son infra dans un datacentre qui utilise le gaz (oui, cela existe chez aws, honte à eux).

- Rmq : le finops/greenops demande un monitoring actif et des adaptations régulières

Une vraie expertise Gnu/Linux

Expertise concernant la partie configuration management des serveurs GNU/Linux, en plus de la partie infrastructure as code, en particulier dans mes rôles ansible faits maison que je maintiens depuis des années : performance, stabilité, sécurité et administration système simplifiée (optimisation sysctl, commandes cli et alias pratiques etc...)

Un build rapide

- Le provisionning est déployé en 15 minutes en seulement 2 exécutions terraform pour la 1ere fois puis une seule les fois d'après. Provisionning = déploiement de l'infrastructure hors configuration des vm avec ansible.

- La création et le déploiement d'une nouvelle image ec2 (comprenant une nouvelle configuration systèmes et/ou un nouveau code applicatif) se fait en 1 clic depuis gitlab en moins de 10 minutes.

- Temps du "terraform plan "pour l'intégralité de l'infra : 4 secondes (J'ai vu dans des entreprises des "terraform plan" qui duraient plus d'une minute pour seulement une petite partie de l'infra, imaginez la perte de temps lorsque l'on itère plusieurs fois sur un plan pour débugguer une erreur).

Une stack ELK pour la visualisation des logs

Une stack ELK est activable en quelques minutes. Par défaut, les logs apache (accès et erreur) y sont envoyés. Un gros travail de découpage des logs apache a été fait pour qu'ils soient exploitables sur Kibana : chaque information présente dans les logs est facilement recherchable : timestamp, ip source (avec ou sans proxy cloudflare), méthode http, path de l'url, code de réponse, taille de la requête avec et sans les headers, temps d'exécution, referer, agent, host http, pid du process.

Cet ELK est juste un complément à la centralisation des logs déjà existante sur efs (pour les logs récents, compressés) et s3 (pour les plus anciens).

Gestion simple et centralisée des mots de passes

Pour chaque environnement, les mdp terraform et ansible sont disponibles dans un seul et unique fichier vault ansible chiffré dans le git du projet (ansible/group_vars/all/vault) accessibles en local et utilisables par terraform et ansible de la même manière, leur gestion en est donc simplifiée.

Les seuls mot de passe à retenir à l'extérieur de notre projet git (dans un teampass par exemple) seront donc le mot de passe de déchiffrement de ce vault (en cas de perte de notre poste), celui de notre compte aws racine et celui de notre compte IAM.

Pas de drifts terraform

L'entièreté de l'infra étant jouée en un seul terraform apply (excepté quelques bases séparées dans un 2eme répertoire que l'on joue rarement), il n'y a jamais de drifts terraform puisqu'on joue tout à chaque changement. L'automatisation étant simple, on n'a pas de raison de faire des changements manuels, sauf ceux prévus exclusivement en manuel et que terraform ignore. Pour Ansible, idem, tous les playbooks sont joués en entier, ce qui assure une intégrité des configurations.

Des retours de commandes clairs et synthétiques

Pour l'ensemble du projet, les outputs Terraform, Ansible et bash ont été travaillés pour être clairs et synthétiques.

Une maintenabilité ridiculement simple

Il y a très peu de changements à faire lors des montées en versions des différents outils (Terraform, Provider Aws, Ansible, Debian) dû à la simplicité et au minimalisme du code qui est sans surcouche. Les versions de terraform et de ses providers sont figées dans le code et changeables facilement. L'outil tfenv utilisera automatiquement la bonne version de terraform

Très facilement évolutif

S'il y a des besoins spécifiques non prévus par cette automatisation, il est très facile d'intercaller de nouveaux bouts de codes à l'intérieur du projet ou de modifier l'existant sans compétences particulières en développement car :

- Terraform n'utilise pas de modules, vous pouvez modifier directement les blocs ressources existants ou en ajouter.

- Ansible n'utilise pas de rôles figés, vous pouvez modifier simplement ces derniers ou modifier directement les playbooks.

- Les seuls scripts présents sont du bash simple et documenté, langage connu des SysAdmins.

- Ainsi, un Sysadmin pourra parfaitement se débrouiller sans autre compétences de développement.

Bastion SSH

Avec accès filtré par IP ou vpn + clé ssh (mdp interdit). L'empreinte ssh du serveur est personnalisée, pas de risque MITM à la première connexion

Possibilité de filtrage IP

- Un environnement entier, exemple : la pré-production.

- Une url ou un domaine spécifique depuis Apache ou Cloudflare, exemple : filtrage du BO de la production.

Backups

RDS : doubles backups réguliers --> snapshots aws automatisés quotidiens en multi-az (voir inter-region si PRA) mais aussi dumps sql réguliers (plusieurs fois par jour) envoyables sur un serveur externe pour PRA. Possibilité de point in time recovery donnée par aws.

EFS : backups aws quotidiens en multi-az, sauvegarde rsync manuelle sur serveur externe possible.

EC2 : Les ami des anciens build sont gardées pour rollback de l'applicatif (rétention configurable).

Supervision / Alertes Cloudwatch

- Alertes factures : un mail est envoyé si la facture aws dépasse un certain montant ou si la consommation paraît inhabituelle.

- Alertes techniques : des alertes mail sont rapidement envoyées si certaines métriques essentielles atteignent un niveau critique. Seules les alertes importantes sont configurées (environ 15 alertes), ce qui évite les faux positifs. Ces alertes permettent d'intervenir préventivement.

- Une alerte de disponibilité générale du site sera aussi configurée à l'extérieur de aws.

Bientôt : un PRA

En cours de développement : une procédure de PRA pour reconstruire l'infra dans une autre zone ou une autre région en moins d'une heure, ce qui permettrait de construire l'infra en mode Mono-AZ sans risque, pour un coût financier et écologique idéal.