Le guide ultime de Kubernetes à ViaRézo
L'objectif est de déployer un site complexe par petits groupes de 2 ou 3 et d'en apprendre un maximum sur comment on fait du Kubernetes à ViaRézo.
0. Installer le nécessaire
Il va falloir mettre en place quelque utilitaires de base pour pouvoir réaliser cette formation:
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:
ssh 138.195.139.40 "sudo cp ~root/.kube/config ."
scp 138.195.139.40:config ~/.kube/config
Vérifie que tous marche bien avec.
kubectl get nodes
Un petit conseil pour les utilisateurs de OhMyZsh: n'hésitez pas à activer les plugins associées à ces applications.
omz plugin enable docker
omz plugin enable kubectl
omz plugin enable helm
Ça permet de faire de l'auto-complétion et pour les plus aventureux il y a des alias sympa.
Un petit conseil pour ceux qui n'utilisent pas OhMyZsh: installer ohmyzsh.
Vérifie que tout marche bien avant de continuer
-
Je peux lancer un
kubectl get nodes
-
Je peux lancer un
helm version
-
Je peux lancer un conteneur
docker run hello-world
1. Créer un namespace pour le groupe
Un namespace, c'est une façon d'isoler des resources entre elles. On va donc créer un namespace pour le groupe, c'est dans ce namespace que vous allez travailler.
Pour un seul des membres du groupe uniquement:
kubectl create namespace <le nom de mon équipe géniale>
On définit ensuite ce namespace comme namespace par défaut (Pour tous les membres du groupe):
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.
2. Il est temps de construire l'application elle-même
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
2.1 Le Front
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.
2.1.2 Tester l'image
Test ton image Docker:
docker run -p 8080:80 vroum-front
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.
2.2 Le Back
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, tu dois donc:
- partir d'une image python
- installer les dépendences nécessaires avec pip
- lancer le serveur python dans l'entrypoint
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
Puis faire tourner le back:
docker run -p 8000:8000 --env-file .env vroum-back
Attention à bien remplir le .env avec les bonnes valeur pour se connecter à la BDD.
Faire des curl pour tester que tout marche à peu près bien.
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.
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.
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.
Kubernetes fonctionne sur un mode de déclaration des ressources. On écrit ce qu'on veux dans des fichiers yaml et il suffit de lancer la commande
kubectl apply -f <myfile.yaml>
Pour deployer sur le cluster l'objet décrit.
Une fois l'objet déployé on peux obtenir la liste de ces objets avec la commande:
kubectl get <objet>
On peux aussi obtenir des détails sur l'objet:
kubectl describe <objet> <nom de l'objet>
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é:
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:
kubectl get pod mysql
(Ça peut prendre un peu de temps)
Récupère un shell dans le pod avec:
kubectl exec -it mysql -- bash
Vérifie que tu peux te connecter à la base de donnée:
mysql --protocol=tcp -u username --database vroum -p
Regarde les logs de ton pod pour voir comment il se porte:
kubectl logs mysql
Récupère un peu plus d'information pour ton pod
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", cela donne donc:
La commande pour tagger une image est tag
:
docker tag <image> registry.viarezo.fr/formation-kube/<image>:<version>
Il faut ensuite s'authentifier au près du registry avec la commande login
:
# En utilisant Bitwarden
docker login registry.viarezo.fr
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.
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):
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
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.
Un label peut-être n'importe quel couple clef valeur, par exemple:
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 !
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_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...
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 :
apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
selector:
app: myapp
ports:
- port: <Port>
targetPort: <Target Port>
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
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: <nom>
spec:
entryPoints:
- websecure
routes:
- kind: Rule
match: Host(`<nom de domaine>`)
services:
- kind: Service
name: <nom du service>
port: <port>
tls:
secretName: <secrte du certificat>
Afin d'avoir du https il faut créer un certificat:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: <nom du certificat>
spec:
secretName: <nom du secret du certificat>
dnsNames:
- <nom de domaine>
issuerRef:
name: letsencrypt
kind: ClusterIssuer
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 apparaisse bien sur https://traefik.test.viarezo.fr
A ce point de la formation vous devez avoir les fichiers suivants.
deploiement_front.yaml
deploiement_back.yaml
service_front.yaml
service_back.yaml
ingress_front.yaml
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.
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 suit:
VROUM
│ Chart.yaml
│ values.yaml
│
└───templates
│ deploiment_front.yaml
│ deploiment_backt.yaml
| service_front.yaml
| service_back.yaml
| ingress_front.yaml
| ingress_back.yaml
Le fichier Chart.yml décrit l'application. Il s'écrit sous la forme :
apiVersion: v2
name: <nom>
description: <description>
type: application
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.deployment.name}}
Cette chaine de caractère va être remplacé par la valeur donnée dans le values.yaml :
front:
deployment:
name: coucou
Pour verifier et tester votre charte helm vous pouvez utiliser :
helm template <nom_de_la_chart>
Pour vérifier les fichiers générés par helm depuis le template. 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. Vous pouvez ensuite désinstaller votre chart avec
helm uninstall <nom_de_l'installation>
avant de passer à la suite.
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
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):
helm repo add bitnami https://charts.bitnami.com/bitnami
Crééz le fichier values.yaml qui contient
auth:
rootPassword: verystrongpassword
username: username
database: vroum
password: password
Installe mysql avec
helm install mysql bitnami/mysql
Récupère le nom du service mysql
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
helm uninstall mysql
Modifie ton Chart.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
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,
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 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. (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
ArgoCD fontionne avec des resources appelées Applications chauque applications gère une chart. Vous pouvez créer des applications depuis l'interface.
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 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:
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 )
6. Pour aller plus loin
Appeler un staffeur et demander lui de vous parler de:
- SealedSecrets
- ArgoCD Image Updater