From e9ff2f123e2bda455c85cca0b555be31ecfcc09e Mon Sep 17 00:00:00 2001
From: Florentin Labelle <florentin.labelle@student-cs.fr>
Date: Thu, 8 Dec 2022 11:57:17 +0100
Subject: [PATCH] Update README.md

---
 README.md | 53 +++++++++++++++++++++++++++++++++++------------------
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/README.md b/README.md
index 4a34166..83ce211 100644
--- a/README.md
+++ b/README.md
@@ -18,8 +18,8 @@ Il va ensuite falloir mettre en place quelque utilitaires de base pour pouvoir r
 Pour configurer l'accès au cluster de test de ViaRézo, il faut que tu ailles récupérer un fichier sur le cluster de test de ViaRézo:
 ```bash
 mkdir -p ~/.kube
-ssh 138.195.139.68 "sudo cp ~root/.kube/config ."
-scp 138.195.139.68:config ~/.kube/config
+ssh 138.195.135.152 "sudo cp ~root/.kube/config ."
+scp 138.195.135.152:config ~/.kube/config
 chmod 600 ~/.kube/config
 ```  
 
@@ -45,7 +45,7 @@ Un petit conseil pour ceux qui n'utilisent pas OhMyZsh: **installer ohmyzsh**.
 
 - [ ] Je peux lancer un `kubectl get nodes`
 - [ ] Je peux lancer un `helm version`
-- [ ] Je peux lancer un conteneur `docker run hello-world`
+- [ ] Je peux lancer un conteneur `docker run --rm docker/whalesay cowsay Hello ${USER} | cat`
 
 ## 1. Créer un namespace pour le groupe
 
@@ -64,7 +64,7 @@ kubectl config set-context --current --namespace <le nom de mon équipe géniale
 Cela veut dire que si vous ne spécifiez pas explicitement de namespace lorsque vous créez des ressources, elles seront créées dans ce namespace.
 
 
-C'est ici qu'on va déployer notre application, mais avant de la déployer sur Kubernetes, il est impératif de la Dockerisé.
+C'est ici qu'on va déployer notre application, mais avant de la déployer sur Kubernetes, il est impératif de la Dockeriser.
 
 ## 2. Il est temps de construire l'application elle-même
 
@@ -95,8 +95,16 @@ Vérifie ensuite dans ton navigateur que tu peux bien voir le front de Vroum
 
 #### 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.  
-> Hint: `docker exec -it vroum-front ...`  
+Trouve une commande pour vérifier avec quel utilisateur ton conteneur tourne:
+
+<details>
+  <summary>Hint</summary>
+
+> Execute whoami dans ton conteneur
+
+</details>
+
+Adapte ton Dockerfile pour que ton service tourne avec un user non privilégié.
 
 ``Attention si ton image ne tourne pas en root, ça veut dire qu'elle n'expose pas le site web sur le port 80, mais plutôt 8080 (par exemple). C'est à prendre en compte pour les étapes suivantes.``
 
@@ -112,6 +120,8 @@ Le back est fait en Django, tu dois donc:
 
 ``Attention: ne pas ajouter de fichier non désiré dans l'image (par exemple le .env ou les node_modules s'il y en a).``
 
+> Hint: [https://docs.docker.com/samples/django/](https://docs.docker.com/samples/django/)
+
 #### 2.2.2 Tester l'image 
 Pour tester que le back fonctionne bien il va falloir d'abord remplir un **.env** dans le dossier du back:
   - Pensez à mettre `PRODUCTION` en `FALSE` pour utiliser du SQLite, les informations pour la BDD ne compte alors pas.
@@ -130,7 +140,7 @@ Pour tester le back, tu peux ausi utiliser le front en lançant les deux contene
 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.
 
-#### 2.2.4 Challenge supplémentaire (Facultatif et un peu dur ne pas hésiter à passer)
+#### 2.2.4 Challenge supplémentaire (Facultatif et un peu dur: passez et revenir après la formation)
 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.  
 
@@ -157,11 +167,20 @@ kubectl describe <objet> <nom de l'objet>
 
 Dans un premier temps, pour créer la BDD, on va faire tourner un simple pod _mysql_. Cette solution est loin d'être optimale mais va nous permettre de se familiariser avec **kubectl**.  
 
-Pour créer un pod _mysql_ c'est pas très compliqué, mais il y a pas mal de variables d'environnement à remplir:
+Pour créer un pod _mysql_ c'est pas très compliqué, mais il y a pas mal de variables d'environnement à remplir:  
+[https://hub.docker.com/_/mysql](https://hub.docker.com/_/mysql)
+
+La commande qui vous intéresse, c'est `kubectl run ...`
+
+<details>
+  <summary>Solution</summary>
+
 ```bash
 kubectl run mysql --image=mysql --port 3306 --env "MYSQL_USER=vroum" --env "MYSQL_PASSWORD=password" --env "MYSQL_DATABASE=vroum" --env "MYSQL_RANDOM_ROOT_PASSWORD=yes"
 ```
 
+</details>
+
 Vérifiez que votre **pod** tourne comme il faut avec:
 ```bash
 kubectl get pod mysql
@@ -175,7 +194,7 @@ kubectl exec -it mysql -- bash
 
 Vérifiez que vous pouvez vous connecter à la base de donnée:
 ```bash
-mysql -u vroum --database vroum -p
+mysql -u user --database database -p
 ```
 
 Regardez les logs de votre **pod** pour voir comment il se porte:
@@ -210,11 +229,11 @@ docker build . -t registry.viarezo.fr/formation-kube/<image>:<version>
 
 Il faut ensuite s'authentifier auprès du registry avec la commande `login`:
 ```bash
-# En utilisant les identifiants qui sont sur Bitwarden
+# En utilisant ton nom d'utilisateur VR et le secret qui est sur registry.viarezo.fr (En haut à droite dans `User Profile`)
 docker login registry.viarezo.fr
 ```
 
-Il suffit ensuite de _push_ l'image avec 
+Il faut ensuite  _push_ l'image avec 
 ```
 docker push registry.viarezo.fr/formation-kube/vroum-front:<un truc rigolo unique>
 ```
@@ -228,6 +247,8 @@ Maintenant les choses sérieuses commencent, on à enfin  affaire à du Kubernet
 ### 3.3 Déploiement
 
 L'unité de base de kubernetes c'est le **pod**. Un **pod** correspond à un ou plusieurs conteneurs gérés ensemble. Ils scalent ensemble et sont tués ensemble quand il faut.
+
+
 Il est possible de créer des pods directement (comme on l'a vu précédemment) mais en pratique c'est rarement fait. Habituellement on crée les pods au travers d'un **deployment**. Le **deployment** est une ressource qui permet de créer un **pods** et de gérer son cycle de vie: son nombre de répliques, la mise à jour de son image Docker, etc. Il s'assure qu'il y ait toujours le bon nombre de réplicats disponibles sur le cluster en récréant/supprimant des pods si besoin.  
 
 Le déploiement de base se décrit grace au template suivant (N'hésitez pas a installer l'extension kubernetes de vscode qui écrit les templates toute seule): 
@@ -249,25 +270,21 @@ spec:
       containers:
       - name: myapp
         image: <Image>
-        resources:
-          limits:
-            memory: "128Mi"
-            cpu: "500m"
         ports:
         - containerPort: <Port>
 ```
 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.
+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 soient différents, et que les labels dans _selector.matchLabels_ soient inclue dans les labels du template.
 
-Un label peut-être n'importe quel couple clef valeur, par exemple:
+Un label peut être n'importe quel couple clef valeur, par exemple:
 ```yaml
 type: front
 app: vroum
 demandé: non
 ratio: probablement
-patek: annulé
+supelec: 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/) !  
-- 
GitLab