Merge branch 'master' into solution/etape1

# Conflicts:
#	etape 1/lab-survey/docker-compose.yml

1 - Build de l'image et test local sur docker.md

@@ -1,6 +1,6 @@
 # Build de l'image et test local sur docker
 
-Nous partons sur le projet Lab survey ([https://github.com/Riges/lab-survey/tree/dotnet-core-proxy](https://github.com/Riges/lab-survey/tree/dotnet-core-proxy)). Cela va nous permettre d'avoir un front et son api dissocié du stockage qui sera un Redis.
+Nous partons sur le projet Lab survey ([https://github.com/Riges/lab-survey/tree/dotnet-core-proxy](https://github.com/Riges/lab-survey/tree/dotnet-core-proxy)). Cela va nous permettre d'avoir un front et son api dissociés du stockage qui sera un Redis.
 
 ## Definition des services 📝
 
@@ -22,7 +22,7 @@ lab-survey-redis:
 
 #### Le Dockerfile
 
-Pour construire l'image, nous aurons besoin d'un 'Dockerfile', un fichier permettant de définir le processus de construction de l'image. Le programme étant en .Net Core et comme Microsoft nous fournis tous les outils, nous ferons un _multi-stage build_ permettant d'avoir une partie de build de l'application sur une image dédier au build lors d'une étape. Puis nous récupérons le résultat du build pour lancer l'application sur une image dédiée à l'hébergement de cette application.
+Pour construire l'image, nous aurons besoin d'un 'Dockerfile', un fichier permettant de définir le processus de construction de l'image. Le programme étant en .Net Core et comme Microsoft nous fournit tous les outils, nous ferons un _multi-stage build_ permettant d'avoir une partie de build de l'application sur une image dédiée au build lors d'une étape. Puis nous récupérerons le résultat du build pour lancer l'application sur une image dédiée à l'hébergement de cette application.
 
 Pour la partie build de l'application nous utiliserons l'image **microsoft/aspnetcore-build:2.0.6-2.1.101** que nous nommerons **build-env** et nous travaillerons dans le répertoire **/src**. Comme les dépendances changent moins que le code source d'une application, nous nous en occuperons en premier afin que cette partie de l'image reste en cache. Pour pouvoir restaurer les dépendances grâce à la commande 'dotnet restore', nous copierons le fichier **lab-survey-front.csproj** dans l'image. Une fois cela fait, nous copierons le reste des sources dans l'image et nous utiliserons la commande 'dotnet publish' en spécifiant que nous voulons la configuration **Release** et que le répertoire de sortie sera nommé **out**.
 
@@ -48,7 +48,7 @@ ENTRYPOINT ["dotnet", "lab-survey-front.dll"]
 
 #### La définition de la configuration
 
-Pour ce conteneur, on voudra le nommer **lab-survey-front** et on exposera le port **5000** du conteneur sur le port **8080** de l'hôte. On va aussi définir une variable d'environnement portant la clef **REDIS** et qui contiendra le nom du conteneur du redis (**lab-survey-redis**) afin de pouvoir l'appeler depuis l'application et une autre clef **ASPNETCORE_ENVIRONMENT** permettant de stipuler pour quel type d'environnement est buildée l'image (**Production**). Pour l'image, nous ne partons pas d'une existante. C'est pourquoi, nous devons la builder depuis le fichier 'Dockerfile' du dossier de l'application. Pour cela, nous allons définir un paramètre **build** et lui donner le chemin du dossier parent de ce Dockerfile précédemment créer : **./lab-survey-front**. Pour nommer l'image, nous prendrons **lab-survey-front** dans le but de s'en servir à nouveau sans la builder à nouveau.
+Pour ce conteneur, on voudra le nommer **lab-survey-front** et on exposera le port **5000** du conteneur sur le port **8080** de l'hôte. On va aussi définir une variable d'environnement portant la clef **REDIS** et qui contiendra le nom du conteneur du redis (**lab-survey-redis**) afin de pouvoir l'appeler depuis l'application et une autre clef **ASPNETCORE_ENVIRONMENT** permettant de stipuler pour quel type d'environnement est buildée l'image (**Production**). Pour l'image, nous ne partons pas d'une existante. C'est pourquoi, nous devons la builder depuis le fichier 'Dockerfile' du dossier de l'application. Pour cela, nous allons définir un paramètre **build** et lui donner le chemin du dossier parent de ce Dockerfile précédemment créé : **./lab-survey-front**. Pour nommer l'image, nous prendrons **lab-survey-front** dans le but de s'en servir à nouveau sans la builder à nouveau.
 
 En prenant tout cela en compte, on devrait avoir une configuration ressemblant à :
 
@@ -164,7 +164,7 @@ Sur ce retour, nous remarquons deux informations importantes :
 
 ### Deployer localement 🚢
 
-Pour déployer localement, il faut utiliser la commande **up** suivi du paramètre **-d** afin de détacher les conteneurs du terminal qui a lancé la commande et ainsi éviter que la commande ne se termine pas une fois le terminal fermé.
+Pour déployer localement, il faut utiliser la commande **up** suivie du paramètre **-d** afin de détacher les conteneurs du terminal qui a lancé la commande et ainsi éviter que la commande ne se termine pas une fois le terminal fermé.
 
 `docker-compose up -d`
 
@@ -184,10 +184,10 @@ Creating lab-survey-redis ... done
 Creating lab-survey-front ... done
 ```
 
-Si tout c'est bien passé, vous devriez voir un retour comme ci-dessus. Cependant, pour vérifier que les conteneurs sont bien lancés, deux solutions s'offrent à vous :
+Si tout s'est bien passé, vous devriez voir un retour comme ci-dessus. Cependant, pour vérifier que les conteneurs sont bien lancés, deux solutions s'offrent à vous :
 
 * aller sur [http://localhost:8080](http://localhost:8080) ![preview de l'application](assets/etape-1-lab-survey-preview.png)
-* lancer une commande 'docker ps --filter name=lab-survey' afin de voir les conteneurs lancés actuellement en filtrant par leur nom.
+* lancer une commande 'docker ps --filter name=lab-survey' afin de voir les conteneurs lancés actuellement en filtrant par leurs noms.
 
 ```sh
 > docker ps --filter name=lab-survey
@@ -198,4 +198,4 @@ e75852c926aa redis "docker-entrypoint.s…" 33 minutes ag
 
 ## Félicitation, vous avez déployé votre application. 🎊🏆🎉
 
-Voilà maintenant, vous savez comment construire un **DockerFile**, un fichier \*_docker-compose_, ainsi que builder et deployer des conteneurs.
+Voilà maintenant, vous savez comment construire un **DockerFile**, un fichier _docker-compose_, ainsi que builder et deployer des conteneurs.

2 - Registry et Kubernetes.md

@@ -1,10 +1,10 @@
 # Registry et Kubernetes
 
-Maintenant que l'application est prête nous allons voir comment héberger les images ainsi que les déployés sur le cluster Kubernetes.
+Maintenant que l'application est prête nous allons voir comment héberger les images ainsi que les déployer sur le cluster Kubernetes.
 
 ## Docker Repository
 
-Pour héberger nos images, nous nous servirons de la registry docker hub, qui est celle par défaut fourni par Docker.
+Pour héberger nos images, nous nous servirons de la registry docker hub, qui est celle par défaut fournie par Docker.
 
 ### Identification
 
@@ -57,7 +57,7 @@ Pour vérifier, allez sur [https://hub.docker.com](https://hub.docker.com). Vous
 
 ## Kubernetes Dashboard
 
-Le projet Kubernetes Dashboard est un exemple d'implémentation de dashboard web, fournis par les équipes de Kubernetes, qui vous sera très pratique afin de suivre l'avancer des déploiements et du cycle de vie de l'application pendant notre session.
+Le projet Kubernetes Dashboard est un exemple d'implémentation de dashboard web, fourni par les équipes de Kubernetes, qui vous sera très pratique afin de suivre l'avancer des déploiements et du cycle de vie de l'application pendant notre session.
 
 Pour cela, on va **appliquer** un manifeste fourni par le projet afin de déployer les ressources nécessaires au bon fonctionnement du dashboard en précisant que nous voulons appliquer un fichier (**-f**) comme suit : `kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml`
 
@@ -90,7 +90,7 @@ metadata:
  namespace: kube-system
 ```
 
-Une fois le compte créé, il lui faudra crée une ressource de type **ClusterRoleBinding** qui permettra de déclarer les droits à associer au compte **admin-user**. Comme le dashboard nécessite de pouvoir gérer le cluster on déclarera un droit de type **ClusterRole** qui se nome **cluster-admin**.
+Une fois le compte créé, il faudra lui créer une ressource de type **ClusterRoleBinding** qui permettra de déclarer les droits à associer au compte **admin-user**. Comme le dashboard nécessite de pouvoir gérer le cluster on déclarera un droit de type **ClusterRole** qui se nomme **cluster-admin**.
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -119,7 +119,7 @@ serviceaccount "admin-user" created
 clusterrolebinding "admin-user" created
 ```
 
-Maintenant que nous avons créé le compte, il nous faut récupérer le token. Pour cela nous listeront les ressources de type **secret** avec la commande **get**. Si vous vous souvenez bien, le compte a été crée dans le namespace **kube-system**, il faut donc le préciser grâce au paramètre -n. Cela donnerait `kubectl -n kube-system get secret`.
+Maintenant que nous avons créé le compte, il nous faut récupérer le token. Pour cela nous listeront les ressources de type **secret** avec la commande **get**. Si vous vous souvenez bien, le compte a été créé dans le namespace **kube-system**, il faut donc le préciser grâce au paramètre -n. Cela donnerait `kubectl -n kube-system get secret`.
 
 ```sh
 > kubectl -n kube-system get secret
@@ -142,7 +142,7 @@ kube-dns-token-9ww4v kubernetes.io/service-account-t
 kube-proxy-token-b7jlw kubernetes.io/service-account-token 3 5d
 ```
 
-Il faut chercher le secret qui commence par `admin-user` (**admin-user-token-5mctg** dans notre exemple) puis nous utiliserons la commande **describe** afin de connaitre le token. Pour cette commande, on doit préciser le type de resource, **secret** dans notre cas, ainsi que du nom de la ressource. Pour cette exemple, cela donnerait `kubectl -n kube-system describe secret admin-user-token-5mctg`
+Il faut chercher le secret qui commence par `admin-user` (**admin-user-token-5mctg** dans notre exemple) puis nous utiliserons la commande **describe** afin de connaître le token. Pour cette commande, on doit préciser le type de resource, **secret** dans notre cas, ainsi que du nom de la ressource. Pour cette exemple, cela donnerait `kubectl -n kube-system describe secret admin-user-token-5mctg`
 
 ```sh
 > kubectl -n kube-system describe secret admin-user-token-5mctg
@@ -173,7 +173,7 @@ Pour le déployment on donnera comme metadata :
 
 * un nom **lab-surbey-redis** afin d'identifier le back.
 
-La partie **spec** correspond aux configurations de votre pod, par le champ **replicat** qui permettra de définir le nombre d'instance qu'y devront être déployé par l'orchestrateur et le champs **template** qui, un peu comme un docker-compose, définit l'application.
+La partie **spec** correspond aux configurations de votre pod, par le champ **replicat** qui permettra de définir le nombre d'instance qu'y devront être déployées par l'orchestrateur et le champs **template** qui, un peu comme un docker-compose, définit l'application.
 
 Ce **template** comporte des **metadata**, permettant de donner un label qui permettra au service de matcher avec le pod, et à nouveau un champs **spec** où on pourra définir le container. En prenant exemple sur le docker compose, nous le nommerons **lab-surbey-redis**. On prendra l'image **redis** et on précisera qu'on expose le **port** de redis (**6379**) du container grâce à **containerPort: 6379**.
 
@@ -201,9 +201,9 @@ spec:
 
 ### Exposé le back
 
-Pour pouvoir exposer cette application de manière public, ou entre deux pods, il faut lui déclarer un service. Pour ce faire, il faut déclarer un _kind_ de type **service**, puis lui donner un nom **lab-survey-redis**. Ensuite, nous définirons les **spec** du service :
+Pour pouvoir exposer cette application de manière publique, ou entre deux pods, il faut lui déclarer un service. Pour ce faire, il faut déclarer un _kind_ de type **service**, puis lui donner un nom **lab-survey-redis**. Ensuite, nous définirons les **spec** du service :
 
-* les port exposés, **6379**.
+* le port exposé, **6379**.
 * Il faut aussi définir quel service utiliser. Avec Kubernetes la bonne manière est de se baser sur les labels afin de matcher les services à une application. Dans ce cas, il faut utiliser le paramètre **selector** et nous lui donnerons donc simplement la règle **app: lab-survey-redis** qui est celle définie dans notre déploiement.
 
 Le service par défaut sur Kubernetes est le _ClusterIP_, cela permet d'exposer un ou des pods (par répartition de charge) à d'autre à l'intérieur du cluster.
@@ -304,7 +304,7 @@ service "lab-survey-front" created
 
 ### Test du deploiement
 
-Dans un cas plus "normal", nous aurions déclarer le service front en _type_ **loadbalancer** afin de rendre accessible l'application en dehors du cluster. Mais malheureusement, par défaut Kubernetes ne fournit pas ce type de ressource sur un cluster "local". Si vous installez cela sur un cluster géré par un Rancher Labs, ou un cloud provider (Google Cloud Plateforme, Azure, AWS, ...) il vous suffirait de rajouter l'information de type au manifeste du service et vous auriez une ip externe pour tester votre application. À défaut de meilleure solution, nous allons voir comment tester cela grâce à la commande **proxy**.
+Dans un cas plus "normal", nous aurions déclaré le service front en _type_ **loadbalancer** afin de rendre accessible l'application en dehors du cluster. Mais malheureusement, par défaut Kubernetes ne fournit pas ce type de ressource sur un cluster "local". Si vous installez cela sur un cluster géré par un Rancher Labs, ou un cloud provider (Google Cloud Plateforme, Azure, AWS, ...) il vous suffirait de rajouter l'information de type au manifeste du service et vous auriez une ip externe pour tester votre application. À défaut de meilleure solution, nous allons voir comment tester cela grâce à la commande **proxy**.
 
 Pour cela, si votre commande `kubectl proxy` tourne toujours, il vous suffit d'utiliser la syntaxe : http://localhost:8001/api/v1/proxy/namespaces/default/services/**SERVICE-NAME**:**SERVICE-PORT-NAME-OU-NUMEROS-DE-PORT**/