Suite et fin de cette série sur 2048 (eh oui, il paraît que toutes les bonnes choses ont une fin). 😜
Vous vous souvenez à la fin de la deuxième partie, j’avais évoqué un outil permettant d’automatiser encore plus nos déploiements Kube !
Cet outil en question c’est ArgoCD, un outil que je trouve particulièrement puissant pour gérer les déploiements de nos applications. 💪
Alors, prêt à lancer une dernière game ?
Nouveau Perso : ArgoCD
ArgoCD est un outil déclaratif de livraison continue GitOps pour Kubernetes.
Super, merci. Mais je n’ai rien compris…
Ok ok, reprenons. Imaginez ArgoCD un peu comme le chef d’orchestre de votre cluster. Il tire profit de l’approche dite “GitOps” en utilisant Git comme source de vérité. C’est-à-dire que chaque aspect de votre configuration est versionnée dans un repo. ça va nous assurer une cohérence et une traçabilité lorsque l’on va déployer nos applications.
Le truc super cool avec cet outil, c’est que l’on ne va pas décrire comment déployer notre appli. Non non, ce que l’on va faire c’est déclarer l’état désiré.
En gros un peu comme au resto. On va simplement commander une pizza, on ne va pas dire au serveur comment faire une pizza et nous la servir. 🍕
Et du coup, ArgoCD, s’assure de faire correspondre en permanence l’état désiré avec l’état de l’appli qui est déployée sur notre cluster. Le fait de se baser sur git nous garantit que tous les changements effectués et poussés vont être déployés. ça permet aussi de rollback trèèèèèès facilement avec les commits (et ça c’est stylé 😎).
Il prend en charge plusieurs types de manifestes Kube’ que ce soit des fichiers YAML ou des Charts Helm (par exeeeeemple, je dis ça comme ça 😉😉).
Pour résumer, il va aussi nous simplifier la vie en automatisant les déploiements, en gérant les mises à jour et la synchronisation avec git. Chaque commit poussé ou chaque tag créé (ça marche aussi pour les branches) va déclencher le processus de déploiement.
Si vous voulez creuser un peu plus, je vous recommande de ouf cette vidéo de la chaîne TechWorld with Nana :
Okok trève de blabla, mettons toutes ces belles paroles en action ! 🎬
Prise en main du ptit nouveau
Pour tester ArgoCD (et jouer à 2048), nous allons avoir besoin d’un cluster Kube et du Chart Helm de la partie 2. On va également installer ArgoCD sur notre cluster (et oui sinon ça marchera un peu moins bien 😅).
Rien de plus simple, pour le cluster je vous laisse lire ou relire la partie 1, pour helm rendez-vous dans la partie 2 et pour ArgoCD, on va suivre la doc
Deux commandes suffisent pour avoir ArgoCD fonctionnel sur notre cluster. Commençons par créer le namespace argocd :
$ kubectl create namespace argocdPuis on applique le manifest qui va se charger de l’installation :
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml⚠️ Pour votre sécurité (du moins celle de votre cluster), je vous recommande de ne JAMAIS d’appliquer un manifest comme ça à l’aveugle ! Regardez toujours son contenu en amont 👀.
Regardons si tout s’est bien déployé en listant les pods et les services présents dans notre namespace argocd :
$ kubectl get po -n argocd
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 5m20s
argocd-applicationset-controller-5478c64d7c-lfnnj 1/1 Running 0 5m20s
argocd-dex-server-6fcfc6f94d-49g46 1/1 Running 0 5m20s
argocd-notifications-controller-5f6c747849-n8s96 1/1 Running 0 5m20s
argocd-redis-66d9777b78-wjfg4 1/1 Running 0 5m20s
argocd-repo-server-5c7d64b8bf-bmknm 1/1 Running 0 5m20s
argocd-server-56f7986dff-2sxv4 1/1 Running 0 5m20s
$ kubectl get svc -n argocd
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argocd-applicationset-controller ClusterIP 10.111.166.40 <none> 7000/TCP,8080/TCP 5m41s
argocd-dex-server ClusterIP 10.108.169.152 <none> 5556/TCP,5557/TCP,5558/TCP 5m40s
argocd-metrics ClusterIP 10.108.229.139 <none> 8082/TCP 5m40s
argocd-notifications-controller-metrics ClusterIP 10.110.213.232 <none> 9001/TCP 5m40s
argocd-redis ClusterIP 10.109.188.154 <none> 6379/TCP 5m40s
argocd-repo-server ClusterIP 10.96.89.214 <none> 8081/TCP,8084/TCP 5m40s
argocd-server ClusterIP 10.103.128.196 <none> 80/TCP,443/TCP 5m40s
argocd-server-metrics ClusterIP 10.96.60.67 <none> 8083/TCP 5m40sça m’a l’air pas maaaaal tout ça ! Maintenant, accédons à l’interface web, que je trouve très cool au passage 😎.
Pour ça, il va falloir faire un port-forward (ça va nous permettre d’accéder à notre l’appli depuis l’extérieur du cluster) :
$ kubectl port-forward -n argocd svc/argocd-server 8080:443
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080On peut désormais se rendre à l’adresse https://127.0.0.1:8080 (dans mon cas, adaptez l’adresse à votre environnement) et arriver sur cette page :
Cool, maintenant il faut chopper le mot de passe qui est dans un secret kubernetes (le username est admin):
$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
ULYThRta5CuTHjR4%Normalement ça vous donne directement le password décodé. Attention, le % ne fait pas partie du mot de passe ! 😉
Voyons ce qu’il a dans le ventre
Maintenant que tout est fonctionnel, il nous manque juste de quoi jouer à 2048. 🕹️
On va repartir de notre Chart Helm.
Petite info, suite à la partie 2, on m’a remonté des problèmes avec les PV/PVC qui vident le répertoire /usr/share/nginx.html ce qui fait que l’appli n’existe plus… J’ai l’impression que cela concerne les clusters kube’ locaux (Docker Desktop, minikube…). Pour que tout le monde puisse faire sa ptite game de 2048, j’ai décidé de ne pas utiliser de volumes persistants pour cette dernière partie.
Aparté fait, retournons à nos moutons. 🐑🐑
Il va falloir préparer notre fichier YAML pour créer une application ArgoCD. C’est elle qui va se charger de déployer notre Chart Helm et de faire en sorte qu’elle soit toujours en accord avec l’état désiré (celui qui est dans notre repo git).
Vous suivez toujours ? (je sais que la réponse est oui, vous êtes trop forts 💪)
Du coup, voici notre fichier :
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: game2048
namespace: argocd
spec:
project: default
source:
repoURL: https://gitlab.com/Gribhb/project2048.git
path: part3/game2048
destination:
server: "https://kubernetes.default.svc"
namespace: game2048
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
selfHeal: true
prune: trueJe nomme mon application “game2048” dans le namespace “argocd”. Elle est configurée pour récupérer le code depuis mon repo GitLab à l’URL spécifiée, dans le répertoire part3/game2048. Elle déploie l’application sur mon cluster Kube dans le namespace “game2048”. La politique de synchronisation me permet de créer automatiquement le namespace s’il n’existe pas, j’active le self healing et la suppression automatique des ressources.
On me dit dans l’oreillette que c’est le moment de déployer ! 🚀
Bon… c’est parti… 3 … 2 … 1 … kubectl applyyyyyy
$ kubectl apply -f application.ymlSi tout se passe bien 🤞, dans la console ArgoCD nous devons voir notre application :
Ouiiiiiiii 😍
Je vous cache pas que j’ai galéré, ça n’a pas fonctionné du premier du coup mdr. Pour cause, je déclarais un helm repo alors que mon Chart est dans un git repo 🙃 (cf ce commit).
Boooon maintenant, est ce que nos ressources se sont bien déployées ? Allons voir ça tout de suite en cliquant sur notre application :
Let’s gooooo, toutes mes ressources sont bien présentes 😍😍 (il y a juste mon ingress qui reste bloqué en processing, mais il est bien déployé 🤷♂️).
Conclusion
Bon, si on fait un petit récap’ ArgoCD c’est le fire non ? 🔥
Le premier gros avantage que l’on a pu exploiter c’est d’avoir toute notre configuration kubernetes (ici notre chart helm) défini sous forme de code au sein de notre repo git. Comme ça, plus besoin d’appliquer tout manuellement depuis nos laptops (cf les parties 1 et 2).
On a pu voir également que ça nous permet de déployer trèèèès rapidement, il nous suffit de commit et de push. ArgoCD va regarder les changements et les appliquer tout seul, comme un grand, en comparant la config désirée dans notre repo git avec l’état actuel du cluster kube. On a du coup la garantie que tout ce qui est sur git est notre source de vérité. Et puis on bénéficie des autres avantages comme d’avoir du code versionné, d’un historique de tous nos changements…
🌈 C’est ça, le GitOps 🌈
L’autre gros avantage, c’est que l’on est plus obligé de donner des accès au cluster kube. Mais on va privilégier les autorisations au niveau du repo git. En mode, les dev vont faire des Merge Requests avant qu’un autre membre de l’équipe approuve et Merge le code. Niveau sécu je trouve ça génial, plus besoin de donner aux dev’ des accès aux clusters. Tout se fait via le repo git directement ! 😍
C’est ici que notre aventure “Jouer à 2048 avec Kubernetes” prend fin. J’ai adoré faire cette série. J’ai appris pas mal de choses mine de rien. C’était la première fois que je créais un chart helm de zéro et une première avec ArgoCD également 😅.
J’espère que vous avez kiffé tout autant que moi ! 💪