diff --git a/README.md b/README.md
index 1829a6d0edf6b5f0a9f9445cad29881a0fb369ce..e7de17b54c20add7705829dd1def54176c7ca53b 100644
--- a/README.md
+++ b/README.md
@@ -61,34 +61,37 @@ Et cette application c'est VRoum.
Pour cette première partie, l'objectif est de construire les images qui vont faire tourner notre site, il y a deux images à vous répartir (ou à faire ensemble séquentiellement).
Pour un petit pense-bête sur Docker, n'hésite pas à lire [cette petite fiche](./Docker.md)
-### Le Front
+### 2.1 Le Front
-#### Créer l'image
+#### 2.1.1 Créer l'image
Le code source du front est dans le dossier front.
Ton objectif est de créer un Dockerfile et de faire tourner le front de VRoum en local.
Le front est fait en React: vous deverez donc faire un **multi-stage** build:
- Stage 0: build l'application React (Attention le .env doit être rempli pour cette étape)
- Stage 1: Servir le site avec une image Nginx.
-#### Tester l'image
+#### 2.1.2 Tester l'image
Test ton image Docker:
```bash
docker run -p 8080:80 vroum-front
```
Vérifie ensuite dans ton navigateur que tu peux bien voir le front de Vroum
-#### Challenge supplémentaire (Facultatif)
+#### 2.1.3 Challenge supplémentaire (Facultatif)
Il est souvent considéré comme une mauvaise pratique d'avoir des conteneurs qui tournent avec l'utilisateur **root** en production.
Vérifie que ce n'est pas le cas ou alors fait les changements nécéssaires.
-### Le Back
+### 2.2 Le Back
-#### Créer l'image
+#### 2.2.1 Créer l'image
Le code source du back est dans le dossier back.
Ton objectif est de créer un Dockerfile et de construire une image avec pour enfin le faire tourner en local.
-Le back est fait en Django: je te souhaite bon courage.
+Le back est fait en Django, tu dois donc:
+ - partir d'une image python
+ - installer les dépendences nécessaires avec pip
+ - lancer le serveur python dans l'entrypoint
-#### Tester l'image
+#### 2.2.2 Tester l'image
Pour tester que le back fonctionne bien il va falloir d'abord mettre en place une base de donnée mysql, pour que le back s'y connecte.
```
docker run -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -d mysql
@@ -101,16 +104,16 @@ Attention à bien remplir le .env avec les bonnes valeur pour se connecter à la
Faire des curl pour tester que tout marche à peu près bien.
-#### Challenge supplémentaire (Facultatif et plus dur que pour le front)
+#### 2.2.3 Challenge supplémentaire (Facultatif et plus dur que pour le front)
Il est souvent considéré comme une mauvaise pratique d'avoir des conteneurs qui tournent avec l'utilisateur **root** en production.
Vérifie que ce n'est pas le cas ou alors fait les changements nécéssaires.
+Ne cherchez pas de solution j'ai eu la flemme d'en faire une.
-#### Challenge supplémentaire (Facultatif et un peu dur ne pas hésiter à passer)
+#### 2.2.4 Challenge supplémentaire (Facultatif et un peu dur ne pas hésiter à passer)
On préfère souvent utiliser une image alpine à une image debian en production, car celle-ci sont beaucoup plus légère. Néanmoins la gestion des dépendences, est souvent plus difficile.
Utilise une image alpine (python:3.8-alpine) comme base pour ton image.
-Ne cherchez pas de solution j'ai eu la flemme d'en faire une.
-## Déployer l'application sur kubernetes
+## 3. Déployer l'application sur kubernetes
Kubernetes c'est un orchestrateur de conteneur. Ca permet de gérer pleins de conteneurs et de faire des trucs inteligents avec comme créer des réplicat et de recréer dynamiquement les conteneurs qui crashent.
@@ -129,28 +132,74 @@ On peux aussi obtenir des détails sur l'objet:
kubectl describe <objet> <nom de l'objet>
```
-### Pousser les images sur le registry
+### 3.1 Déployer un pod à la main sur kubernetes
+
+Dans un premier temps, pour créer la BDD, on va faire tourner un simple pod _mysql_. Cette solution est loin d'être optimal mais va nous permettre de se familiariser avec **kubectl**.
+
+Pour créer un pod c'est pas très compliqué:
+```bash
+kubectl run mysql --image=mysql --port 3306 --env "MYSQL_USER=username" --env "MYSQL_PASSWORD=password" --env "MYSQL_DATABASE=vroum" --env "MYSQL_RANDOM_ROOT_PASSWORD=yes"
+```
+
+Vérifie que ton pod tourne comme il faut avec:
+```bash
+kubectl get pod mysql
+```
+(Ça peut prendre un peu de temps)
+
+Récupère un shell dans le pod avec:
+```bash
+kubectl exec -it mysql -- bash
+```
+
+Vérifie que tu peux te connecter à la base de donnée:
+```bash
+mysql --protocol=tcp -u username --database vroum -p
+```
+
+Regarde les logs de ton pod pour voir comment il se porte:
+```bash
+kubectl logs mysql
+```
+
+Récupère un peu plus d'information pour ton pod
+```bash
+kubectl get pod mysql -o wide
+```
+Attention, note bien l'addresse ip du pod dans un coin de ta tête, tu en aura besoin plus tard.
+
+### 3.2 Pousser les images sur le registry
La première étape du déploiement sur kubernetes va être de pousser les images sur le registry afin que le cluster kube puisse les récupérer. Le registry c'est un serveur qui stocke les images docker.
Pour cela il faut d'abord renomer nos images docker afin d'indiquer a docker ou les pousser. La forme du tag du docker doit être :
```
registry/project/nom_de_l'image:version
```
-Dans notre cas on souhaite pousser sur le registry de viarezo (registry.viarezo.fr) dans le projet "formation-kube".
+Dans notre cas on souhaite pousser sur le registry de viarezo (registry.viarezo.fr) dans le projet "formation-kube", cela donne donc:
-Il suffit ensuite de pousser l'image avec
-```
-docker push
+La commande pour tagger une image est `tag`:
+```bash
+docker tag <image> registry.viarezo.fr/formation-kube/<image>:<version>
```
-Note:
-Dans notre cas le projet formation-kube est en public est donc accessible à tous. Si ça n'est pas le cas il peut etre nécessaire de faire un
+Il faut ensuite s'authentifier au près du registry avec la commande `login`:
```bash
-docker login
+# En utilisant Bitwarden
+docker login registry.viarezo.fr
```
-pour s'identifier auprès du registry.
-### Déploiement ###
+Il suffit ensuite de pousser l'image avec
+```
+docker push registry.viarezo.fr/formation-kube/vroum-front:<un truc rigolo unique>
+```
+
+Note importante,
+ Si vous avez décidé de sauter ou d'abandonner la partie précédente, vous pourrez trouver une image pour le back et pour le front disponible sur le registry avec le `tag` **:correction**.
+
+
+Maintenant les choses sérieuses commencent, on commence à faire du Kubernetes et à déployer des ressources, à chaque fois il faudra créé une ressource pour le back et une pour le front, vous pouvez vous partager les tâches ou tout faire ensemble séquentiellement au choix.
+
+### 3.3 Déploiement
L'unité de base de kubernetes c'est le pod. Un pod correspond à une ou plusieurs conteneurs gérés comme un tout.
Il est possible de créer un pod directement mais en pratique personne le fait. Habituellement on créer les pods au travers de déploiement. Le déploiement est un objet qui permet de créer un pod et gère ses réplications. Il s'assure qu'il y ait toujours le bon nombre de réplicat disponible sur le cluster en récréant/supprimant des pods si besoin.
@@ -184,11 +233,29 @@ spec:
Ecrivez donc un déploiement pour le back et un pour le front.
Vérifiez ensuite que vos pods sont bien marqués en ready.
+En ce qui concerne les labels, un déploiement régis les pods qui contiennent les labels qui sont dans sont _selector.matchLabels_, il faut donc que pour le front et le back ces labels soit différent, et que les labels dans _selector.matchLabels_ soit inclue dans les labels du template.
+
+Un label peut-être n'importe quel couple clef valeur, par exemple:
+```yaml
+type: front
+app: vroum
+demandé: non
+ratio: probablement
+patek: annulé
+```
+
+Attention pour le back, il est nécéssaire de passer au conteneur des [variables d'environnement](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) !
+
+Tu peux retrouver les client ID et client secret sur l'auth, tandis que les variables de la base de données sont à récupérer à l'étape n-2.
+
+
+Tu peux alors tester que ton front marche bien avec
```
-kubectl port-forward <nom_du_pod> <port_du_pod>:<port_où_exposer>
+kubectl port-forward <nom_du_pod> <port_de_ton_pc>:<port_du_pod>
```
+mais il n'arrivera pas à se connecter au back tant que l'on ne l'a pas exposé sur internet...
-### Service
+### 3.4 Service
Un service est une entitée qui permet aux pods de communiquer entre eux au sein du cluster. Il s'occupe aussi du load balancing entre les réplicats des pods.
Le template d'un service est le suivant :
``` yaml
@@ -204,7 +271,11 @@ spec:
targetPort: <Target Port>
```
-### Exposer un service vers l'exterieur
+Le **selector** est particulièrement important, les labels qui sont dedans doivent correspondre aux labels des pods qui correspondent au service, donc les mêmes que vous avez mis dans votre déploiement.
+
+Le **targetPort** correspond au port que vous avez choisi d'exposer dans votre déploiement, et le **port** correspond au port sur lequel vous aimeriez bien joindre ce service (souvent le port 80).
+
+### 3.5 Exposer un service vers l'exterieur
Avec notre service nous avons exposés notre app au sein du cluster. Maintenant nous allons l'exposer vers le moooooooonde. Pour cela nous alons mettre en place des ingress. Un ingress est un proxy qui en fonction du nom de domaine de la requête redirige vers le service adapté. Ici, à Viarezo, nous utilisons des IngressRoutes gérés par traefik. Traefik est un logiciel qui s'occupe de gérer toutes les routes décrites dans des ingress et ingressroutes (c'est sensiblement la même chose).
Pour les noms de domaine, il faut créer une entrée A sur le DNS qui redirige vers traefik. Cette partie a déja été fait pour vous, prenez juste un nom de domaine en ``.kube.test.viarezo.fr``
@@ -220,7 +291,6 @@ spec:
routes:
- kind: Rule
match: Host(`<nom de domaine>`)
- priority: 30
services:
- kind: Service
name: <nom du service>
@@ -242,9 +312,9 @@ spec:
name: letsencrypt
kind: ClusterIssuer
```
-Ce certificat va être autaumatiquement être signé par Letsencrypt grace à certmanager un utilitaire installé sur les clusters.
+Ce certificat va être automatiquement être signé par Letsencrypt grace à certmanager un utilitaire installé sur les clusters.
A l'issue de cette étape vous devriez pouvoir acccéder à votre application en HTTPS sur votre nom de domaine !!
-Si c'est le cas bravo ! Sinon vous pouvez vérifier que votre ingress apparaaisse bien sur https://traefik.test.viarezo.fr
+Si c'est le cas bravo ! Sinon vous pouvez vérifier que votre ingress apparaisse bien sur https://traefik.test.viarezo.fr
A ce point de la formation vous devez avoir les fichiers suivants.
@@ -258,10 +328,15 @@ ingress_back.yaml
```
Afin d'éviter de flood la cluster pensez à supprimer vots ressources afin de passer à la suite.
Vous pouvez le faire avec la commande suivante.
-## Helm le apt de kubernetes
+
+```bash
+kubeclt delete -f le_dossier_qui_contient_tous_mes_fichiers
+```
+
+## 3.6 Helm le ansible de kubernetes
C'est bien sympatique tout ça mais c'est loooong. Heureusement helm est la.
Helm permet de templatiser les fichiers kubernetes. Une application Helm s'appelle une chart.
-Une chart s'organise comme suis:
+Une chart s'organise comme suit:
```
VROUM
│ Chart.yaml
@@ -276,22 +351,22 @@ VROUM
| ingress_back.yaml
```
-Le fichier Chart.yml décrit l'application. Il permet aussi d'inclure d'autre charts en dépendance de la notre. Il s'écrit sous la forme :
+Le fichier Chart.yml décrit l'application. Il s'écrit sous la forme :
```
apiVersion: v2
name: <nom>
description: <description>
type: application
-version: 0.1.1
+version: 0.0.0
appVersion: "<version>"
```
Le values.yaml permet de passer en argument des paramètres aux templates.
On va remplacer dans les fichiers créés précedement les valeurs par de la templatisation de la forme:
```
-{{.Values.front.deploiement.name}}
+{{.Values.front.deployment.name}}
```
-Cette chaine de caractère va être remplacé par la valeur donnée dans le value.yaml :
+Cette chaine de caractère va être remplacé par la valeur donnée dans le values.yaml :
```yaml
front:
deployment:
@@ -307,27 +382,134 @@ Vous pouvez ensuite lancer un
helm install <nom_de_la_chart> <nom_de_l'installation>
```
pour installer votre application.
-Normalement à ce moment votre vroum est disponible à sur son nom de domaine.
+Normalement à ce moment votre vroum est disponible sur son nom de domaine.
Vous pouvez ensuite désinstaller votre chart avec
```
helm uninstall <nom_de_l'installation>
```
avant de passer à la suite.
-## Argocd
+## 4. Helm le apt de kubernetes
+
+### 4.1 Helm install mysql
+
+Helm est aussi très pratique pour installer des trucs fait par des autres gens.
+On va notamment utiliser Helm pour faire un déploiement un peu plus propre de notre base de donnée mysql.
+
+D'abord supprimons notre pod mysql
+```bash
+kubectl delete pod mysql
+```
+
+Puis on va commencer par ajouter un repo de charte helm (celui de bitnami, c'est des mecs cool qui filent pleins de charts toute faites):
+```bash
+helm repo add bitnami https://charts.bitnami.com/bitnami
+```
+
+Crééz le fichier values.yaml qui contient
+```yaml
+auth:
+ rootPassword: verystrongpassword
+ username: username
+ database: vroum
+ password: password
+```
+
+Installe mysql avec
+```bash
+helm install mysql bitnami/mysql
+```
+
+Récupère le nom du service mysql
+```bash
+kubectl get services
+```
+
+Modifie les variables d'environnement pour ton déploiement back pour qu'il se connecte à cette nouvelle BDD.
+
+### 4.2 Utiliser les dépendences helm
+
+Au lieu d'installer MySQL à la main puis d'installer ta charte **VRoum** tu peux faire d'une pierre deux coups en déclarant MySQL comme dépendance de **VRoum** pour cela:
+
+Pense d'abord à désinstaller MySQL
+```bash
+helm uninstall mysql
+```
+
+Modifie ton Chart.yaml:
+```yaml
+apiVersion: v2
+name: vroum
+description: vroum deployment with MySQL backend
+type: application
+version: 0.0.1
+appVersion: "0.0.1"
+dependencies:
+ - name: mysql
+ version: 9.0.0
+ repository: https://charts.bitnami.com/bitnami
+```
+
+Et ajoute dans ton values.yaml
+```yaml
+mysql:
+ auth:
+ rootPassword: verystrongpassword
+ username: username
+ database: vroum
+ password: password
+```
+
+Désormais, lorsque tu déploiera **VRoum** comme à l'étape précédente, ton application sera déployé avec ta base de donnée MySQL.
+
+Pour le tester,
+```bash
+helm dependency build vroum
+helm install vroum vroum/
+```
+
+## 5. ArgoCD
VOus qui arrivez ici, BRAVO!
Il ne vous reste plus qu'a automatiser ce déploiement. Pour cela on utilise un utilitaire du nom de argocd. Argocd synchronise automatiquement le cluster avec les ressources décrites sur le gitlab.
Dans le cadre d'une mise en production tout se passerais sur le dépot [argocd](https://gitlab.viarezo.fr/ViaRezo/kubernetes/argocd) du gitlab. Cependant pour l'occasion vous allez reconfigurer un nouveau dépot de 0.
-Vous pouvez donc créer un nouveau dépot sur le gitlab et push votre chart dessus.
+Vous pouvez donc créer un nouveau dépot sur le gitlab et push votre chart dessus. (Ou alors faire un fork du projet et ajouter votre camarade dessus)
-Tous se passe sur le site argocd.viarezo.fr. ``Attention ce site gère aussi la prod``
+Tous se passe sur le site [argocd.viarezo.fr](https://argocd.viarezo.fr). ``Attention ce site gère aussi la prod``
-Argocd fontionne avec des entitées appelées applications chauque applications gère une chart.
+ArgoCD fontionne avec des resources appelées **Applications** chauque applications gère une chart.
Vous pouvez créer des applications depuis l'interface.
-``Attention a bien mettre l'url https://138.195.139.40:6443 pour le cluster afin de bien déployer sur le cluster de test``
+D'abord ajouter un nouveau repository sur ArgoCD:
+ - Sur votre repo git dans _Settings -> Access Tokens_, il faut créer un access token (duh) avec comme droit: _read\_repository_
+ - Sur [argocd.viarezo.fr](https://argocd.viarezo.fr) dans _Settings -> Repositories_, ajoute ton repository git.
+ Attention, l'url doit finir avec .git sinon ça marche pas.
+
+Ensuite créer une application qui déploit ta charte:
+ - Dans Apps, clique sur **New App**.
+ - Dans project, choisi **applications**
+ - Dans Sync Policy, choisi **Automatic** et coche **PRUNE RESOURCES** et **SELF HEAL**
+ - Dans destinations, choisi le cluster en fonction du nom et non de l'url et sélectionne **testing**
+ - Pour le reste les arguments par défaut suffisent.
+
+Vérifie que ton application s'est bien déployée sur le cluster:
+```bash
+kubectl get all
+```
+Si ce n'est pas le cas, **it's debug time**.
+
+Une fois l'application créée il suffit de push ses modifications sur le gitlab afin qu'elles soient déployées sur le cluster, (ArgoCD peut mettre plusieurs minutes à synchroniser de lui-même, mais on peut accélérer le processus en cliquant sur **refresh** sur l'interface graphique)
+
+Testons ArgoCD (et récapitulons un peu ce que nous avons fait pour l'instant):
+ - Dans le repo du front, modifie la couleur d'un composant bien visible.
+ - Rebuild l'image du front et push la sur le registry de nouveau avec un nouveau tag.
+ - Modifie dans ton values.yaml, l'image du front par celle avec ce nouveau tag.
+ - Observe que ton site change bien de couleur. (Refresh si ça met un peu de )
+
-Une fois l'application créée il suffit de push ses modifications sur le gitlab afin quelles soient déployés sur le cluster.
+## 6. Pour aller plus loin
+Appeler un staffeur et demander lui de vous parler de:
+ - SealedSecrets
+ - ArgoCD Image Updater