Skip to content
Snippets Groups Projects
Commit e9ff2f12 authored by Florentin Labelle's avatar Florentin Labelle
Browse files

Update README.md

parent 15c1a4f2
Branches
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
Showing
with 35 additions and 18 deletions
README.md
+ 35
− 18
View file @ e9ff2f12
......@@ -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.
......@@ -158,10 +168,19 @@ 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:
[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/) !
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment