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:

• docker
• kubectl
• helm

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

Le Front

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

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

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

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.

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.

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.

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

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>

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".

Il suffit ensuite de pousser l'image avec

docker push

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

docker login

pour s'identifier auprès du registry.

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épicalt 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.

kubectl port-forward <nom_du_pod> <port_du_pod>:<port_où_exposer>

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>

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>`)
    priority: 30
    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 autaumatiquement ê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

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.

Helm le apt 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:

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 permet aussi d'inclure d'autre charts en dépendance de la notre. Il s'écrit sous la forme :

apiVersion: v2
name: <nom>
description: <description>
type: application
version: 0.1.1
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}}

Cette chaine de caractère va être remplacé par la valeur donnée dans le value.yaml :

front:
  deployment:
    name: coucou

Cleanup

Stop the local kind cluster:

./scripts/teardown.sh

Once you are done with this exercise, be sure to delete the containers you created:

docker ps --quiet | xargs docker stop
docker ps --quiet --all | xargs docker rm

I hope you had fun and learned something!