Projet E5 SAB - Urbanisation des SI

Ce document présente la démarche et les étapes réalisées dans le cadre du projet d’urbanisation des systèmes d’information (SI).

Groupe et Références

• Membres du groupe :

  • BILLON Anthony
  • BLAIZOT Éloïse
  • CADET Lucie
  • DUPRESSOIR Amaury
  • LALANDE Mathieu

• Dépôt GitHub du projet

• TP : Projet E5 SAB - Urbanisation des SI (PDF)

• Ressource fournié dans le devoir

Partie 0 : Applications sélectionnées

• Application Rocket Flask Stripe
• MariaDB
• PHPMyAdmin

Partie 1 : Mise en place de l’environnement

Choix du framework Kubernetes

Le framework sélectionné pour répondre aux critères du MVP est Minikube.

Minikube correspond à ce framework, il sera donc utilisé pour la suite du projet.

Lancement de Minikube

minikube start --listen-address=0.0.0.0 --memory=max --cpus=max --kubernetes-version=v1.35.0

Chargement de l’image Docker dans Minikube

L’image Docker n’était pas présente dans l’environnement Docker de Minikube, elle avait été construite uniquement dans le Docker local. Il a donc été nécessaire de charger l’image locale dans Minikube pour l’utiliser dans le cluster.

minikube image load rocket:local

Après avoir fait fonctionner l’image en local, nous l’avons publiée sur Docker Hub afin que les images des applications soient accessibles depuis un repository Docker Hub.

---

Publication de l’image sur Docker Hub

Pour permettre le déploiement sur différents environnements et garantir l’accessibilité de l’image, celle-ci a été publiée sur un repository Docker Hub public : warpprod/rocket-ecommerce.

L’image à été envoyée dans DockerHub via la commande suivante :

docker build -t warpprod/rocket-ecommerce .&& docker push warpprod/rocket-ecommerce

[+] Building 14.4s (8/16) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.09kB 0.0s
=> [internal] load metadata for docker.io/library/python:3.11.5 0.7s
=> [auth] library/python:pull token for registry-1.docker.io 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> CACHED [ 1/11] FROM docker.io/library/python:3.11.5@sha256:2e376990a11f1c1e03796d08db0e99c36eadb4bb6491372b227f1e53c3482914 0.0s
=> => resolve docker.io/library/python:3.11.5@sha256:2e376990a11f1c1e03796d08db0e99c36eadb4bb6491372b227f1e53c3482914 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 24.75kB 0.0s
=> [ 2/11] COPY requirements.txt . 0.3s
=> [ 3/11] RUN pip install --upgrade pip 5.2s
=> [ 4/11] RUN pip install --no-cache-dir -r requirements.txt 7.8s => => # Downloading mysqlclient-2.2.0.tar.gz (89 kB) => => # Installing build dependencies: started => => # Installing build dependencies: finished with status 'done' => => # Getting requirements to build wheel: started => => # Getting requirements to build wheel: finished with status 'done' => => # Preparing metadata (pyproject.toml): started ... etc

Après avoir construit l’image, vous pouvez vérifier qu’elle est bien disponible avec la commande suivante :

docker images | grep warpprod/rocket-ecommerce

On spécifie donc l’image dans nos manifestes Kubernetes comme ceci :

image: warpprod/rocket-ecommerce:latest

Cela assure que toutes les équipes et environnements peuvent accéder à la même version de l’application.

Configuration de l'application pour MariaDB

L'application n'avait pas le connecteur de MariaDB présent dans les requirements de l'aplication, nous avons dû l'ajouter

1. Installer le connecteur :
   Modifier le fichier requirements.txt pour ajouter la dépendance suivante :

   PyMySQL==1.1.0

2. Migration de la database : Nous nous sommes connecté à l'un des conteurs via les commandes suivantes :

   minikube ssh
   docker ps
   docker exec -ti container_name /bin/bash

   Nous avons ensuite suivi la documentation de l'application ecommerce et tapé les commandes suivantes :

   python manage.py makemigrations
   python manage.py migrate

   

Nous avons ensuite ajouté un produit Mug dans Stripe, qui apparaît bien dans l’interface du site e-commerce :

Produit ajouté dans Stripe	Affichage du produit sur le site

Pour valider le parcours d’achat, une transaction a été réalisée depuis le site pour acheter ce Mug. La réussite de la transaction est visible à la fois dans Stripe et sur le site e-commerce :

Transaction réussie dans Stripe	Confirmation sur le site e-commerce

Enfin, les informations de la commande et du produit acheté sont bien enregistrées dans la base de données, consultables via phpMyAdmin :

Commandes dans phpMyAdmin	Produit acheté

Vérification du nombre de réplicas

Pour garantir la haute disponibilité de l’application, le nombre de réplicas a été défini à 3 dans le manifeste Kubernetes :

spec:
replicas: 3

Cela permet d’assurer que trois pods de l’application sont toujours déployés et disponibles dans le cluster.

Partie 2 : Déploiement multi-environnements

Pour permettre l’accès aux applications à plusieurs équipes, des environnements isolés doivent être créés pour :

• mlops
• preprod
• prod

L’infrastructure as code doit être déployée de façon identique dans ces trois environnements.

Déploiement multi-environnements

Trois fichiers de déploiement Kubernetes ont été créés pour isoler les environnements :

• prod-deployment.yaml : environnement de production
• preprod-deployment.yaml : environnement de préproduction
• mlops-deployment.yaml : environnement MLOps

Chaque fichier contient la même structure d’infrastructure (namespace, déploiements, services, volumes, etc.), adaptée à l’environnement cible.
Cela permet à chaque équipe de travailler dans un environnement isolé, tout en garantissant la cohérence des ressources déployées.

Commande pour appliquer les environnements

k apply -f prod-deployment.yaml
k apply -f preprod-deployment.yaml
k apply -f mlops-deployment.yaml

Commande pour appliquer les modifications :

• 

Vérification de l'état des déploiements :

• 

Chaque environnement dispose ainsi de ses propres ressources, assurant l’isolation et la reproductibilité des déploiements.

---

Partie 3 : Intégration d’une base de données

Une base de données autre que SQLite doit être déployée et connectée à l’application Stripe.

Exemple de configuration MariaDB dans prod-deployment.yaml

La documentation MariaDB sur Kubernetes de IONOS a été utilisée pour intégrer MariaDB au projet. Le fichier a été adapté pour répondre aux besoins spécifiques.

Nous avons ajouter les namespaces "prod" sur notre fichier pour faire fonctionner MariaDB et PhpMyAdmin (qui permettra à un adaministrateur de maintenir la base de données du site).

Pour voir les infos de mariadb, vous pouvez lire prod-deployment.yaml.

# Principales informations de mariadbapiVersion: v1kind: PersistentVolumemetadata:
name: mariadb-pvspec:
capacity:
storage: 10GiaccessModes:
- ReadWriteOncepersistentVolumeReclaimPolicy: RetainhostPath:
path: /mnt/data/mariadb
---
apiVersion: v1kind: PersistentVolumeClaimmetadata:
name: mariadb-pvcnamespace: prodspec:
accessModes:
- ReadWriteOnceresources:
requests:
storage: 10Gi
---
apiVersion: v1kind: ConfigMapmetadata:
name: mariadb-confignamespace: prodlabels:
app: mariadbdata:
my.cnf: | [mysqld] bind-address=0.0.0.0 default_storage_engine=InnoDB innodb_file_per_table=1 max_connections=1000---
apiVersion: apps/v1kind: StatefulSetmetadata:
name: mariadbnamespace: prodspec:
replicas: 3selector:
matchLabels:
app: mariadbserviceName: mariadbtemplate:
metadata:
labels:
app: mariadbspec:
containers:
- env:
- name: MYSQL_ROOT_PASSWORDvalue: "SuperSecurePass123"
- name: MYSQL_DATABASEvalue: "ecommerce"image: mariadb:latestname: mariadbports:
- containerPort: 3306name: mariadbvolumeMounts:
- mountPath: /var/lib/mysqlname: mariadb-storage
- mountPath: /etc/mysql/conf.dname: config-volumevolumes:
- configMap:
name: mariadb-configname: config-volumevolumeClaimTemplates:
- metadata:
name: mariadb-storagespec:
accessModes:
- ReadWriteOnceresources:
requests:
storage: 10Gi
---
apiVersion: v1kind: Servicemetadata:
name: mariadbnamespace: prodspec:
ports:
- port: 3306targetPort: 3306selector:
app: mariadb

# Partie pour phpmyadminapiVersion: apps/v1kind: Deploymentmetadata:
name: phpmyadminnamespace: prodspec:
replicas: 3selector:
matchLabels:
app: phpmyadmintemplate:
metadata:
labels:
app: phpmyadminspec:
containers:
- name: phpmyadminimage: phpmyadmin/phpmyadmin:latestenv:
- name: PMA_HOSTvalue: mariadb
- name: PMA_PORTvalue: "3306"
- name: PMA_ARBITRARYvalue: "1"ports:
- containerPort: 80
---
apiVersion: v1kind: Servicemetadata:
name: phpmyadmin-servicenamespace: prodspec:
type: NodePortports:
- port: 8080targetPort: 80nodePort: 30080selector:
app: phpmyadmin

# Afficher toutes les ressources principales Kubernetes dans le namespace courant
k get all

Retour :

NAME READY AGE
statefulset.apps/mariadb 1/1 22s

---

Accès aux services depuis l'extérieur

Nous avions rencontré des difficultés d'usage avec mikicube port forward qui était extrêmement lent, nous l'avons donc remplacé par socat qui nous a permis de publier nos NodePorts sur l'IP Publique de notre VM avec de bien meilleures performances.

# Commande pour le site e-commerce de Prod
sudo socat TCP-LISTEN:5005,fork,reuseaddr TCP:$(minikube ip):30005

# Commande pour PhpMyAdmin de Prod
sudo socat TCP-LISTEN:8080,fork,reuseaddr TCP:$(minikube ip):30080

---

Conclusion

Ce projet nous a permis de mettre en pratique les principes fondamentaux de Kubernetes à travers le déploiement d'une application e-commerce et d'une stack complète. Nous avons réussi à containeriser nos services (Flask, MariaDB et PHPMyAdmin), publier une "application métier" sur Docker Hub et les orchestrer via Minikube.