Composition de l’infrastructure

On prévoit une infrastructure complète en partant d’une architecture 3-tièrs avec un Front une API pour le Backend et une DataBase.

• Front
• API
• Database

On veut que l’infrastructure puisse être scallée et dupliquée et la base de donnée soit backupée. L’ensemble représentera notre version de Production dans un cluster Prod et dans un cluster Staging pour les versions de tests.

On veut également pouvoir gérer plusieurs environnements chacun sera représenté par un cluster.
L’ensemble de ses clusters sera géré par Kubernetes.

• Cluster Prod
• Cluster Staging
• Cluster technique avec des outils d’observabilité et de contrôle

Stack de l’infrastructure

L’ensemble est géré par Kubernetes qui est un orchestrateur de conteneurs Docker.
Mais, décrivons d’abord les outils composants chaque cluster.

Architecture 3-tièrs pour les versions Prod et Staging

Cluster technique

Gestion de l’environnement de dev et de l’infrastructure

Les nouvelles technologies permettent de gérer l’infrastructure avec du code. On appel cela l’infra as code.

L’ensemble est déployé grâce à un systeme de gestion de version qui archive notre code et communique avec l’ensemble des outils installés sur nos clusters y compris Kubernetes qui organise l’ensemble des déploiements et des processus de clonage, de scalabilité et des ressources clusters.

Les configurations, variables d’environnements et persistence des accès sécurisés sont gérés respectivements par les outils Terraform, Ansible et Vault.

Historique de la mise en place de l’infrastructure et du code source

Le codage de l’infrastructure sera déposé dans GitLab.
Dans GitLab on va retrouver le codage de l’infrastructure et des outils comme Terraform et Ansible.

Résumé des opérations

• Montage d’une infrastructure complète
• Sur Kubernetes
• Avec une application 3-tiers scalée
• Et un socle d’observabilité
• Le tout déployé via une pipeline

Création des comptes

• Création d’un compte chez un hébergeur AWS (S3 – service Route 53)
• Location de plusieurs serveurs dédiés (Cluster)
• Création d’un nom de domaine principal chez un fournisseur de nom de domaine
  (importé dans un service Route 53 d’AWS)

Définitions et principes de base

Infrastructure As Code

3 étapes principales :

• Provisionning d’infrastructure
• Configuration Management
• Orchestration d’applications

Provisionning d’infrastructure (hardware)

Cela concerne du stockage, du réseau et du compute.
Il nous faut des serveurs et grâce aux clouds providers on peut louer un équipement, décrire sa config et les raccorder au réseau.

On instancie les serveurs, le réseau, le stockage avec Terraform.

Configuration Management (Software)

Cela concerne l’installation d’OS, la sécurisation et la configuration en résumé, rendre prêt à exécuter les applis.

On configure les serveurs pour qu’ils puissent recevoir les applications avec Ansible.

Orchestration d’applications

Cela concerne le déploiement d’applications, gérer leurs configurations, leurs cycles de vie et leurs publications sur des hostnames.

On déploie et orchestre l’exécution, la conf et la publication des applis en utilisant l’écosystème de Kubernetes – Helm

GitOps

L’outil Git nous permet de gérer l’évolution de l’ensemble du code (versioning) en travail collaboratif avec plusieurs développeurs.

L’infra As code décrit un état d’une infra à un instant précis. Puisque notre code évolue nous avons besoin de faire aussi évoluer notre infrastructure. Cette technique appelée GitOps permet de synchroniser le plan de notre infrastructure avec son état réel déployer chez un provider.

Cette synchronisation est effectuée depuis Git.

La plateforme GitLab dans laquelle, nous déposons l’ensemble de notre code (Infra + Applis) est justement optimisée pour intégrer toutes les opérations GitOps.

Docker et Kubernetes (conteneur et orchestrateur)

Définition et principe de base

Prenons l’exemple d’une application Java.

• Le développeur à partir de son code .java génère la compilation de son code .war
• Pour éxécuter le fichier .war il faut utiliser le jre de Java qui est donc le Runtime de l’application.

En général l’applicatif a besoin d’un environnement d’exécution (avec des librairies) que l’on appel le Runtime.

Docker

L’outil Docker permet en quelque sorte de ‘Shiper’ l’applicatif. Il fournit des conteneurs dans lesquels on introduit à la fois le runtime et l’applicatif. Chaque conteneur est un exécutable qui fait tourner l’applicatif et son environnement d’exécution avec toutes les librairies, dont l’ensemble du système a besoin, en respectant les versions de chaque composant compatibles entre elles.

Une image Docker se compose donc du code source et de son runtime.
Un conteneur possède aussi les caractéristiques d’être idempotent quelque soit l’environnement sur lequel il tourne. Cette image est également immuable.

On dispose donc dans Docker Hub des paternes d’images aussi bien pour du code d’application que de l’infra as code.

Autre avantage, si on envisage plusieurs conteneurs sur une machine, communiquants entre eux via différents ports du réseau, on commence à entrevoir la notion de Micro-Services.

Micro-Services

Les Micro-Services sont de petites applications isolés pouvant communiquer entre elles comme des APIs facilitant la maintenance et l’optimisation des ressources disponibles.

Si l’on souhaite que nos micro-services soit répartis en fonction de la charge nous pouvons aussi envisager la notion de répliquas (clonage) sur plusieurs serveurs (clusters), afin que toutes les requêtes puissent être Load-balancer sur ces répliquas.

Concernant le déploiement progressif d’une nouvelle API, nous pourrions également faire un roolback si les modifications de la nouvelle version de l’API ne fonctionne pas correctement afin de rétablir la version antérieure.

Le Chef d’orchestre

Afin de pouvoir gérer tous ces micro-services il nous faut un chef d’orchestre qui va contrôler tous nos conteneurs sur plusieurs Clusters. Pour cela l’outil indispensable pour effectuer cette tâche est Kubernetes.

Kubernetes

Dans un environnement hyper distribué on parle de flotte de conteneurs sur une flotte de serveurs et l’ensemble qui gère tout cela est le standard Kubernetes.

Gitflow

La gestion des révisions et le travail en équipe des mises a jours et différentes versions de l’application suivent un processus privilégiant les tests et les merges suivant des pipelines de déploiement gérer par Gitlab.

Front

Backend

Monitoring