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
Pour commencer tu peux cloner ce repo et ses dépendences:
git clone --recurse-submodules git@gitlab.viarezo.fr:ViaRezo/Kubernetes/formation-kubernetes
Il va ensuite 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:
mkdir ~/.kube
ssh 138.195.139.40 "sudo cp ~root/.kube/config ."
scp 138.195.139.40:config ~/.kube/config
Vérifie que tout 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 ressources entre elles. On va donc créer un namespace pour le groupe, dans lequel 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 option 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.
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é.
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).
Si vous avez un petit trou de mémoire sur Docker, n'hésitez pas à lire cette petite fiche ou alors à aller sur internet.
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)
- partir d'une image node
- installer les dépendences (
npm install
) - puis build le frontend (
npm run build
)
- Stage 1: Servir le site avec une image Nginx.
- juste copier le build de l'étape précédence dans le bon dossier. (
Ne vous embếtez pas à modifier la conf nginx, c'est une perte de temps
)
- juste copier le build de l'étape précédence dans le bon dossier. (
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.
Hint:
docker exec -it vroum-front ...
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.
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 (
pip install -r ...
) - Dans l'entrypoint, faire les migrations puis lancer le serveur.
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 remplir un .env dans le dossier du back:
- Pensez à mettre
PRODUCTION
enFALSE
pour utiliser du SQLite, les informations pour la BDD ne compte alors pas. - Tu peux aller récupérer les clientid et secret du client OAuth
VRoum Formation Kubernetes
.
Puis faire lancer le back:
docker run -p 8000:8000 --env-file .env vroum-back
Faire des curl pour tester que tout marche à peu près bien.
Pour tester le back, tu peux ausi utiliser le front en lançant les deux conteneurs simultanément, dans ce cas, pense à bien configurer BACK_ROOT et FRONT_ROOT en accord avec REACT_APP_API_URL et REACT_APP_CLIENT_URL.
2.2.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.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 avec des fonctionnalités plutôt sympa comme notamment le redémarrage des conteneurs qui ont crashé ou la gestion dynamique du nombre de répliques de ces conteneurs.
Kubernetes fonctionne sur un mode de déclaration des ressources. On écrit ce qu'on veut 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 mysql c'est pas très compliqué, mais il y a pas mal de variables d'environnement à remplir:
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"
Vérifiez que votre pod tourne comme il faut avec:
kubectl get pod mysql
(Ça peut prendre un peu de temps)
Récupèrez un shell dans le pod avec:
kubectl exec -it mysql -- bash
Vérifiez que vous pouvez vous connecter à la base de donnée:
mysql -u vroum --database vroum -p
Regardez les logs de votre pod pour voir comment il se porte:
kubectl logs mysql
Récupère un peu plus d'information sur ton pod
kubectl get pod mysql -o wide
Vous pouvez notamment voir l'adresse du pod au sein du cluster, tu en auras besoin pour configurer ton back et qu'il se connecte à la BDD.
3.2 Pousser les images sur le registry
Un registry c'est un serveur qui stocke et distribue des images Docker, il va ici servir au cluster Kubernetes comme point d'accès pour récupérer les images que vous avez construites. La première étape va donc être de push vos images sur le registry. Pour cela il faut d'abord renommer nos images Docker afin d'indiquer a Docker où les push. La forme du tag du docker doit être :
<registry>/<project>/<image>:<tag>
Le tag sert à définir plusieurs versions de la même image, c'est un peu l'analogue des branche git mais en Docker.
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 déjà construite est tag
:
docker tag <image> registry.viarezo.fr/formation-kube/<image>:<version>
Une alternative est de construire directement l'image avec le bon tag
:
docker build . -t registry.viarezo.fr/formation-kube/<image>:<version>
Il faut ensuite s'authentifier auprès du registry avec la commande login
:
# En utilisant les identifiants qui sont sur Bitwarden
docker login registry.viarezo.fr
Il suffit ensuite de push 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 disponible avec le
tag
:correction. Pour le front, il faudra le build vous même avec le Dockerfile donné en solution (2.1.3).
Maintenant les choses sérieuses commencent, on à enfin affaire à du Kubernetes. On va donc successivement déployer des ressources nécessaire au bon fonctionnement de notre application, à 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 à 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éé les pods au travers d'un deployment. Le deployment est une resource qui permet de créer un pods et de gérer son cycle de vie: son nombre de réplique, la mise à jour de son image Docker, etc. 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 (J'ai créé un client dédié VRoum Formation Kubernetes
), tandis que les variables de la base de données sont à récupérer à l'étape n-2.
N'hésite pas à mettre plusieurs **replicas** dans tes déploiements (2–3 pas 18 non plus) pour voir un peu comment kubernetes gère la création de plusieurs répliques
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...
Attention
Si vous vous êtes trompé dans votre image Docker et que vous avez du vous y prendre à deux fois, vous vous rendrez compte que par défaut, Kubernetes ne re-pull pas l'image du registry même si vous supprimer le deployment et le recréez. Le trick, c'est de changer l'imagePullPolicy dans le template du pod. C'est pas top de le faire en production, car les pods mettent plus de temps à se créer, mais en testing c'est souvent pratique.
3.4 Secret
Vous avez du voir qu'il y a quelque informations sensibles dans nos fichier yaml (surtout celui du deployment du back), il faut donc que vous créiez un secret qui les contient et que vous l'utilisiez pour définir vos variable d'environnement.
Voici un exemple de secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
username: ouioui
password: taxi123
Et vous pouvez référencer un secret dans votre déploiement avec ce bout de yaml ci-dessous:
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
Un secret n'est en soit pas plus secret qu'une autre resource, il obéit simplement à des règles de contrôle d'accès qui sont différentes, néanmoins dans certaines configuration de clusters il peut être chiffré avant écriture sur le disque.
Pensez bien à tester votre déploiement avec le secret.
3.5 Service
Un service est une entitée qui permet aux pods de communiquer entre eux au sein du cluster, Il s'occupe notamment du load balancing entre les différents 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, il permet de séléctionner les pods qui appartiennent à ce service. Les labels qui sont dedans doivent donc correspondre aux labels que vous avez mis dans votre deployment.
Le targetPort correspond au port que vous avez choisi d'exposer dans votre déploiement (le champs containerPort), et le port correspond au port sur lequel vous aimeriez bien joindre ce service (pour les service http c'est donc souvent 80).
3.6 Exposer un service vers l'exterieur
Avec notre service nous avons exposé notre app au sein du cluster. Maintenant nous allons l'exposer vers le moooooooonde. Pour cela nous allons 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, à ViaRézo, nous utilisons des IngressRoutes gérés par l'IngressController Traefik. Traefik est un logiciel qui s'occupe de gérer toutes les routes décrites dans des IngressRoutes.
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é faite pour vous, prenez juste un nom de domaine en .kube.test.viarezo.fr
# ingressroute_front/back.yaml
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: <nom>
spec:
entryPoints:
- websecure
routes:
- kind: Rule
match: Host(`<nom de domaine>`) && PathPrefix(`/path`)
services:
- kind: Service
name: <nom du service>
port: <port>
tls:
secretName: <secret du certificat>
Afin d'avoir du https signé par letsencrypt, il faut aussi créer un certificate:
# certificate.yaml
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 certificate va être automatiquement être signé par Letsencrypt grace à certmanager un utilitaire installé sur les clusters.
Attention, pensez à mettre le même nom de domaine pour le back et le front et à filter sur le PathPrefix pour le back (/api), pour éviter les problèmes de CORS, et à rebuild l'image du front si nécessaire pour bien mettre les bonnes REACT_APP_CLIENT_URL et REACT_APP_API_URL
Pour l'auth, il faut que tu ajoutes **mondomaine/api/auth/callback** dans les URIs de redirection du client Auth **VRoum Formation Kubernetes**
Si ça ne fonctionne pas, on n'oublie pas les outils classique de débug sur kubernetes:
kubectl get certificate
kubectl get ingressroute
kubectl describe certificate
kubectl describe ingressroute
Et ne pas hésiter à aller check les erreurs dans la console du navigateur.
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 !.
A ce point de la formation vous devez avoir les fichiers suivants.
deployment_front.yaml
deployment_back.yaml
service_front.yaml
service_back.yaml
ingressroute_front.yaml
ingressroute_back.yaml
certificate.yaml
Afin d'éviter de rentrer en conflit avec la suite, pensez à supprimer vos ressources avant de passer à la suite.
Vous pouvez le faire avec la commande suivante.
kubeclt delete -f le_dossier_qui_contient_tous_mes_manifestes
3.7 Helm le ansible de kubernetes
C'est bien sympatique tout ça mais si on veut changer le nom de l'application (vroum en vroum-vroum par exemple), il faut le changer à au moins une dizaine d'endroite et c'est loooong. Heureusement Helm est là pour nous aider à faire un peu de templating. Helm permet de templatiser les fichiers kubernetes. Une application Helm s'appelle une chart. Une chart s'organise comme suit:
vroum
├── Chart.yaml
├── templates
│ ├── certificate.yaml
│ ├── deployment_back.yaml
│ ├── deployment_front.yaml
│ ├── ingressroute_back.yaml
│ ├── ingressroute_front.yaml
│ ├── service_back.yaml
│ └── service_front.yaml
└── values.yaml
Le fichier Chart.yml permet de décrire l'application :
# Chart.yaml
apiVersion: v2
name: <nom>
description: <description>
type: application
version: 0.0.0
appVersion: "<version>"
Le values.yaml permet de passer en argument des variables aux templates. Les variables dans le template s'écrivent avec des double crochets:
Pour accéder aux variables du values.yaml
:
{{ .Values.<yaml path> }}
Ainsi
{{ .Values.front.deployment.name }}
devient
coucou
avec les values suivantes
front:
deployment:
name: coucou
On peut utiliser les valeurs du Chart.yaml avec:
{{ .Chart.<yaml path> }}
Pour verifier les manifestes générés par helm ,vous pouvez utiliser :
helm template <nom_de_la_chart>
Vous pouvez ensuite lancer un
helm install <nom de l'application> <chemin vers la charte>
pour installer votre application.
Si vous avez besoin de modifier votre charte puis de réappliquer des changements, il faudra utiliser la commande upgrade
:
helm upgrade <nom de l'application> <chemin vers la charte>
Normalement à ce moment votre VRoum est disponible sur son nom de domaine.
Bon bah voilà on a terminé ? Presque encore un petit bout de chemin pour proprifier tous ça.
Vous pouvez désinstaller votre charte avec
helm uninstall <nom_de_l'installation>
avant de passer à la suite.
Vous l'aurez remarqué, Helm permet de définir une chart, de l'installer, de la désinstaller et de la mettre à jours. Dans ce sens, Helm s'apparente à un gestionnaire de paquets pour Kubernetes.
4. Helm le apt de kubernetes
4.1 Helm install mysql
Helm est aussi très pratique pour installer des trucs mis à disposition par d'autres utilisateurs.
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
Dans un premier temps on va crééer un secret qui contient nos credentials pour MySQL:
apiVersion: v1
kind: Secret
metadata:
name: mysql-credentials
type: Opaque
stringData:
mysql-root-password: verystrongpassword
mysql-password: password
Puis crééz le fichier values.yaml qui contient
auth:
existingSecret: mysql-credentials
username: vroum
database: vroum
Finalement installez mysql avec
helm install mysql bitnami/mysql -f values.yaml
Lorsque l'on passe en argument un values.yaml
comme cela, seul les variables qui sont redéfinies dedans sont changées par rapport au variables par défaut.
Récupérez le nom du service mysql
kubectl get services
Modifiez les variables d'environnement du déploiement de votre 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
Glisse le secret de l'étape précédente dans tes templates et ajoute dans ton values.yaml
mysql:
auth:
existingSecret: mysql-credentials
username: vroum
database: vroum
N'hésite pas à modifier tes templates pour ne pas avoir de valeurs en double dans ton values.yaml, voir même avoir un seul secret au lieu de deux
Désormais, lorsque tu déploiera VRoum comme à l'étape précédente, ton application sera déployé avec sa base de donnée MySQL.
MySQL peut prendre pas mal de temps à se lancer et ton back, va probablement redémarrer plusieurs fois avant de démarrer correctement, il risque même de CrashLoopBackoff
et donc de ne pas tenter de redémarrer pendant 1 minute.
Si tu n'as pas envie d'attendre, tu peux le relancer à la main:
kubectl rollout restart deployment vroum-back
Pour le tester,
helm dependency build vroum
helm install vroum vroum/
Pour la prochaine étape, tu peux supprimer le Chart.lock
et le dossier Chart/
qui a été généré par le helm dependency build
.
Tu disposes désormais d'une application que tu peux installer et désinstaller facilement, en https, avec une bdd, etc... C'est plutôt cool non ? Mais bon il faut encore déployer l'appli à la main et c'est un peu contraignant.
5. Le GitOps
Nous ce qu'on aime bien faire sur Kubernetes c'est du GitOps, ça veut dire que l'on veut piloter notre cluster à partir d'un repo git de façon déclarative. Cela a plusieurs avantages:
- Le repo git est toujours synchronisé avec le cluster
- Un déploiement, c'est simplement un merge sur main
-
git revert
pour rollback une update qui a cassé - ...
On va donc s'empresser de mettre notre charte sur un repo git, mais pour l'instant on ne peut pas car on a encore des informations sensibles qui sont en clair dans cette charts, il va falloir les chiffré un peu à la manière d'ansible vault avant de les push
5.1 SealedSecrets
SealedSecrets c'est un opérateur qui tourne sur le cluster et dispose d'une clé privée pour déchiffrer les SealedSecrets que vous allez créer et en faire des Secrets Kubernetes.
Pour créer ce SealedSecret à partir du secret de votre charte, on va utiliser un utilitaire qui s'appelle kubeseal
, que vous pouvez télécharger sur leur Github (! Prenez bien l'architecture qui correspond à votre système.), puis avec un coup de tar
et en mettant l'executable dans votre path
, vous devriez pouvoir lancer un kubeseal --version
.
Commence par exporter ces variables d'environnements pour configurer kubeseal
:
export SEALED_SECRETS_CONTROLLER_NAMESPACE=sealed-secrets
export SEALED_SECRETS_CONTROLLER_NAME=testing-sealed-secrets
export SEALED_SECRETS_FORMAT=yaml
export SEALED_SECRETS_SCOPE=cluster-wide
Tu peux désormais créer un SealedSecret à partir de ton Secret:
cat my_un_encrypted_secret.yaml | kubeseal > my_encrypted_secret.yaml
Puis le glisser dans ta charte à la place du secret chiffré.
Retente d'installer ta charte avec ce nouveau SealedSecret à la place.
5.2 ArgoCD
Il ne vous reste plus qu'a automatiser le déploiement de VRoum. 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. (Attention à bien gitignore
le secret en clair).
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, chaque Applications gère une charte helm et la déploie sur le cluster. 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 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
- Configure tous ce qui est propre à ta charte.
- 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.
Si tu te balade sur ArgoCD, tu te rendra compte qu'il y a pas mal d'outil pour debogguer et que notamment presque toutes les information que tu peux avoir avec des kubectl ...
sont disponibles dessus au clickodrome.
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
Appelez un staffeur et demandez-lui de vous parler de:
- ArgoCD Image Updater