Skip to content
Snippets Groups Projects
Select Git revision
  • 3aaa7ac4beb7a4e419374dc54a9ed818a0f68066
  • main default
2 results

formation-kubernetes

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Florentin Labelle authored
    3aaa7ac4
    History

    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

    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)

    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_RANDOM_ROOT_PASSWORD=yes -e MYSQL_USER=vroum -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=vroum -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