Architecture du cloud
Le layout de notre infrastructure Cloud chez Infomaniak:
Le but premier de cette infrastructure est de limiter les dommages collatéraux quand une application plante.
C'est pourquoi on isole entièrement les services internes et staging de la production.
Isolation
internal
Le sous-réseau "internal" comprend quatre instances:
- NGINX-Internal -> la seule instance accessible depuis l'extérieur. (On appelle cela un "Bastion" 🛡️) Ce serveur a deux roles:
- Agir de serveur proxy pour les requêtes HTTP/S vers les services internes
- Agir de "Jump Server" si on veut se SSH dans les autres serveurs
- Services-Internal -> cette instance héberge tous nos services internes. Vous pouvez voir et y accéder ici. (uniquement accessible depuis le réseau interne Spektrum)
- Staging-Internal -> Cette instance contient les apps de staging afin de les tester
- DB-Internal -> Cette instance contient toutes les bases de données utilisées par les services et les app de staging.
#TODO
On ajoutera en temps voulu une Instance Windows-Server pour déployer les applications qui ne peuvent pas tourner sur Linux/Docker. (on privilégie toujours linux/docker)
production
Bien que pas encore monté, le sous-réseau production aura une structure très similaire que internal avec 4 instances:
- NGINX-Production -> Pareil, bastion HTTP/S et SSH pour tout le réseau.
- Apps-Production -> une instance très robuste (réacteur nucléaire) pour faire tourner toutes les applis de production.
- DB-Production -> une instance avec les moteurs de DB nécessaire pour les applis dans
Production - Apps-Prodution-Windows -> instance Windows Serveur pour les applis qui ne peuvent pas tourner sur Linux/Docker.
Stockage
Volumes -> /data
Toutes ces instances sont rattachées à des Volumes (similaire à des volumes docker) à l'emplacement /data. Si on veut recréer, agrandir, rétrécir, améliorer une instance, ces données sont séparées et ne risquent pas d'être effacées.
ATTENTION ⚠️
Absolument tout ce que vous mettez sur ces instances doit être mis dans le dossier /data. On applique une mentalité "cattle, not pets" ce qui veut dire qu'à n'importe quel moment, on doit pouvoir rapidement supprimer et recréer une instance.
DB séparées
Pourquoi séparer la base de donnée? C'est overkill non ?
Eh non! Un serveur qui se remplit et n'a plus de place, c'est vraiment la galère, et c'est chaud à remettre sur pieds sans perdre des données.
Pour éviter qu'une database qui se remplisse trop fasse planter toutes les applications, on sépare la logique du stockage. On garde un moteur de DB de chaque, et on construit tout là dessus. Cela évite aussi d'avoir plein de bases partout et qu'on les perdes... Le volume de stockage peut très facilement être agrandi pour ces bases de données. Actuellement, on a les DB suivantes:
- PostgreSQL (a privilégier... open-source, ultra-rapide, ultra-puissant.)
- MariaDB (exactement la même que MySQL mais open-source et plus rapide)
- MS-SQL
Stockage S3 / BLOB
On a aussi l'option de stocker des données dans des "buckets" sur notre instance avec le protocole S3 (ou BLOB storage). C'est LE standard dans le développement web moderne.
À savoir 💡
Le stockage S3/BLOB est un stockage objet, idéal pour des données que l’on écrit une fois et qu'on lit autant qu'on veut. Il est souvent utilisé pour des données statiques, des backups ou des fichiers multimédias.
Provider secondaire
Le talon d'achille de cette infrastructure cloud est le fait qu'on a un peu tous nos oeufs dans le même panier. Si Infomaniak se casse la gueule, on n'a plus rien. Si le serveur avec Grafana tombe, plus d'alertes. Du coup on a aussi un deuxième petit serveur chez un autre provider européen : Hetzner.
Il est responsable pour 2 choses:
- vaultwarden Spektrum Suisse
- Grafana secondaire (pour nous alerter si Grafana tombe)
Contributors
Clément Favre