Archives mensuelles : mars 2021

AWK et sa fonction system tellement pratique

Hello les ami(e)s !!! J’espère que vous allez bien dans cette période difficile à l’approche d’un durcissement de confinement. Difficile de pouvoir reprendre une vie normale alors que nos hôpitaux se remplissent.

Cependant il faut continuer à garder le moral et alles de l’avant. Certes le soleil nous donne un peu plus envie d’aller dehors mais il redonne tout de même une belle dose d’espérance.

Bref aujourd’hui parlons ou reparlons de awk. C’est souvent un outil méconnu ou tout du moins que l’on connaît pour faire des choses très simples et on se limite dans son utilisation grâce aux facilités apportées par la ligne de commandes (pipe etc).

AWK la simplicité à l’état pur

Je vous rappelle que j’avais fait il y a pas loin de 2 ans quelques tutos en guise de formation à awk. Ce petit cours de awk se limite à du petit oneline mais il permet déjà de faire des choses supers sympas je trouve :

  • élimination des doublons
  • compteurs
  • analyse de logs
  • conditions
  • génération de sql

Vous pouvez retrouver tout cela dans la playlist dédiée au scripting saison 1.

Mais parfois avec un petit rien en plus et on peut faire vraiment beaucoup plus. Je ne vous parle pas là de créer un vrai script AWK, multiligne. Non on reste dans le oneline avec encore un gros degré de simplicité.

Alors pour la démo prenons la CLI kubectl pour manipuler les pods. Je pars de cette commande mais vous pouvez partir de tout ce que vous souhaitez, l’idée est de manipuler la CLI.

Donc prenons la liste des pods avec un petit filtre pour afficher qu’une colonne.

kubectl get pods -o wide | awk '{print $6}'

Collectons la colonne des ip des pods (d’où le $6). Et maintenant pour manipuler un peu plus nous pouvons par exemple filtrer sur le statut des pods et leurs ips.

kubectl get pods -o wide | awk '($3 ~ "Running") && ($6 ~ "10.233.64.1.*") { print $6}'

Et notre commande system ?

On combine donc deux conditions. avec && et on applique un ~ pour la recherche sur base de regex.

C’est déjà pas mal mais là on se dit ça serait kool de lister tous les pods et de leur appliquer une commande system.

Concentrons nous juste sur un ping par exemple :

kubectl get pods -o wide | awk '($3 ~ "Running") && ($6 ~ "10.233.64.1.*") {print $1;system("ping -c 1 "$7)}'

Et on oubliera pas l’option -c1 pour ne pas boucler sur ping et ne réaliser qu’un seul ping (on pourrait définir un timeout plus approprié).

Nous avons simplement utilisé la fonction system de awk pour passer une commande… système. Simple est kool. On retrouve finalement ce que sait très bien faire xargs.

Alors avec notre kubectl on peut faire finalement quelque chose d’utile comme par exemple supprimé tous les pods en état evicted :

kubectl get pods -o wide | awk '($3 ~ "Evicted") {print "\n Drop >> "$1;system("kubectl delete pods "$1)}'

Et oui on retrouve là toute la facilité de awk car en plus vous le remarquez, on se permet même d’écrire une ligne avant. On pourrait en écrire une après ou encore faire un compteur pour dire le nombre de pods traités. Simple non ?

Bref AWK dans ce cas de figure permet de faire du personnalisable avec très peu de chose et sa fameuse commande system.

Alors si vous aimez ce genre de choses ou ces thématiques, venez vous joindre à la communauté Xavki. Vous pouvez aussi vous abonner pour ne pas manquer les prochaines vidéos.

L’objectif de la chaine est simple : se former et progresser ensemble

Enfin si vous voulez vous faire la main avec bash et si vous disposez de légères notions avec docker, vous pouvez vous rendre sur cette série de vidéos. Une formation qui vous conduira à réaliser un script bash permettant d’instancier des conteneurs docker avec systemd et ssh.

Un bon moyen de joindre l’utile à l’agréable avec un poil de docker et à la sortie la possiblité d’utiliser des conteneurs comme des machines virtuelles avec un gros gain de temps au provisionning.

Se prendre au jeu de AWK

Enfin si vous avez du temps et que vous êtes du genre curieux. Vous pouvez poursuivre sur le chemin de awk. En scriptant bien sûr et en utilisant des évolutions de ce langage comme le gawk ou encore le mawk. Ce dernier m’a été évoqué en parlant de performance. Il semblerait le plus rapide pour processer de la données réparties sur différents fichiers. Un article fait un petit focus sur les performances du mawk ici.

Cependant après avoir fait quelques tests maisons je ne parviens pas à des resultats explicites pour pouvoir en faire une réelle démonstration.

Toujours sur la performance en matière de processer du fichier text, vous pouvez aussi vous reporter à cet article. Celui-ci fait une analyse comparative entre le nawk, gawk et mawk assez intéressante. Il s’agit de faire un comparatif sur l’utilisation de la mémoire par ses derniers.

Formation SSH, les bases…

Si vous utilisez linux (et potentiellement windows) au quotidien et que vous êtes amenés à travailler avec des serveurs, vous ne pouvez vous passer de ssh. Certes, une bonne automatisation d’infrastructure peut vous permettre de limiter son utilisation mais rare est une journée sans ssh.

Mais finalement qu’est-ce que SSH ? le connait-on vraiment assez ? Voilà ce que je vous propose de découvrir dans la formation SSH. Cet ensemble de tutoriels permet pour les débutants de mieux comprendre leur environnement de travail et pour d’autres peut être de reposer les bases ou encore découvrir des astuces.

Qu’est-ce que SSH ?

C’est trivial mais il faut bien repartir de quelque chose. SSH cela signifie Secure Shell… comme on dit ça casse pas 3 pattes à un canard mais pourtant c’est terriblement utile et efficace.

Il faut voir d’où l’on vient et à quelle époque nous sommes. Dans un passé informatique plus lointain, la communication avec les serveurs se faisait avec des outils non sécurisés ou peu sécurisés comme par exemple telnet ou encore rsh (remote shell). Désormais, on utilise telnet rarement pour des tests simples comme la vérification d’ouverture de ports ou encore le test l’envoi de mail via un serveur smtp.

Ces outils non sécurisés sont de nos jours à éviter voir à bannir. Les pirates informatiques n’ont plus besoin que nous leur ouvrions les portes déjà assez difficiles à maintenir fermées.

Bref la sécurité informatique commence dès l’installation d’un serveur et à tous les niveaux.

Pour cela, SSH se base bien sûr sur de la cryptographie assez poussée. C’est d’ailleurs pour cela que tout le monde l’utilise et que toute brèche ne traîne pas à être patchée. Il se base sur la bonne vieille mais efficace méthode de client/serveur.

SSH a deux objectifs principaux :

  • lutter contre l’interception : c’est à dire qu’une personne qui écoute la communication entre un client et un serveur puisse accéder à ses informations
  • lutter contre l’usurpation : pour éviter que le client se fasse passer le serveur et inversement

Du coup on parle souvent de tunnel SSH avec ce sentiment d’assurer une communication sécurisée entre deux protagonistes avec une isolation totale.

Pour son chiffrement, SSH utilise deux phases :

  • un chiffrement asymétrique : avantage sa sécurité et inconvénient sa rapidité
  • un chiffrement symétrique : avantage sa rapidité et inconvénient la sécurité

Le déroulé d’une communication est la suivante :

Communication SSH :

  1. Client > Serveur : TCP – initie la connexion – poignée de main (handshake) SYNchronize
  1. Serveur > Client : TCP – réponse handshake SYN/ACKnowledge
  1. Client > Serveur : TCP – confirmation handshake ACK
  1. Client > Serveur : SSH – Version serveur
  1. Serveur > Client : SSH – Version client

…initialisation de la clef

  1. Client > Serveur : SSH – requête Diffie Hellman (objectif définir clef symétrique)
  1. Serveur > Client : SSH – envoi de la clef symétrique chiffré par la clef publique asymétrique
  1. Client > Serveur : SSH – début des échanges par le chiffrement de la clef symétrique

L’installation d’un serveur SSH

Dans mon cas je parlerai pour debian mais sur redhat et sa famille, le principe est le même :

sudo apt install openssh-server

sudo systemctl start sshd

Désormais votre serveur écoute avec le port par défaut à savoir le port 22 sur vos interfaces et donc toutes ses ips.

Ensuite, la configuration passe par le fichier /etc/ssh/sshd_config

Sans rentrer dans d’importants détails, voici l’interprétation de différents paramètres (je vous recommande vivement en cas de modification de paramètres ssh de toujours ouvrir 2 sessions en cas d’erreur cela vous permettra de revenir dessus) :

AcceptEnv : fixer les variables d'env pouvant être importées via le client

AllowAgentForwarding : permet de conserver votre clef (ex : rebond)

AllowGroups / DenyGroups : limiter les groupes à se connecter via ssh

AllowUsers / DenyUsers : limiter les users

Banner : ajouter une bannière à la connexion ssh

Password : mettre les deux à no pour disable password

ChallengeResponseAuthentication - RFC 4256 > poser des questions à l'utilisateurs (password..) > plus sécurisé

PasswordAuthentication - RFC 4252 > specific au password

ChrootDirectory : spécifier au chroot pour users/groups (utilisé avec match généralement)

Ciphers : combinaison des algorithmes d'échange

ClientAliveCountMax : le nombre connexion sans réponse avant cloture de la connexion

ClientAliveInterval : durée de la connexion ssh sans activité (envoi une requête si sans réponse = déconnexion)

Compression : defaut yes

DisableForwarding : supprime les fowarding agent, x11...

ExposeAuthInfo : permet d'afficher des informations l'authentification (path du fichier dans SSH_USER_AUTH)

FingerprintHash : type de hash pou rle fingerprint

ForceCommand : commande exécutée à la connexion (bypass les commandes clientes)

GatewayPorts : désactivation du port forwarding possible (no)

HostbasedAcceptedKeyTypes : type de clefs accepté : edcsa, rsa...

HostbasedAuthentication : authentification sur la clef par host (pas par user)

HostKey / HostCertificate : localisation des fichiers de clefs ou certificatss

IPQoS : limitation de service via débit et/ou délai

Kerberos Authentication : activation de l'authentification via kerberos

ListenAddress : interface/ip d'écoute

LoginGraceTime : délai pour s'authentifier (120 secondes par défaut)

LogLevel : niveau de logs

Match : permet de conditionner une liste d'acions sous condition

MaxSessions : connexions permisses par connexion réseau

PermitEmptyPasswords : permettre un password vide

PermitOpen : quel port forwarding est autorisé

PermitRootLogin : autorisé la connexion en tant que root via ssh (défaut prohibit-password)

PermitUserRC : permettre l'utilisation d'un ssh rc (~/.ssh/rc) = similaire à profile

Port : spécifier le port d'écoute du serveur ssh

PrintLastLog : spécifie la denrière connexion réalisé sur le serveur à la connexion suivante

PrintMotd : affichage d'un message d'accueil (similaire à banner)

PubkeyAcceptedKeyTypes : type de clefs publiques autorisées

PubkeyAuthentication : autoriser ou non l'authentification par clef

StrictModes : vérifie les fichiers et directories avant d'accepter la connexion

SyslogFacility : format des logs

UsePAM (Pluggable Authentication Module) : utilisation du module PAM

X11Forwarding : authoriser le forward x11 (serveur graphique)

A savoir qu’une partie de ces paramètres peuvent être spécifiques à certains utilisateurs ou groupes. Attention pour réaliser ce cas d’utilisation vous devez utiliser 2 Match. Le premier pour spécifier votre bloc aux caractéristiques particulières, le second pour revenir à ALL c’est à dire applicable à tous les utilisateurs.

Match User xavki
Banner /etc/banner.txt
X11Forwarding no
Match All

Je le répète si vous modifiez une configuration SSH ouvrez toujours deux sessions. Cela vous évitera de vous couper la patte et en cas d’erreur de revenir en arrière.

Une fois la modification réalisée vous pouvez redémarrer le service systemd qui le gère :

sudo systemctl restart sshd

Ne vous inquiétez pas, le restart maintient les connexions actives.

Connexion avec un client

Là encore très simplement on va utiliser apt notre gestionnaire de paquets :

sudo apt install openssh-client

Ensuite c’est très facile de vous connecter à un serveur ssh. Si celui-ci accepte une connexion avec le mot de passe du user distant vous pouvez tester et que le port ssh (22) accepte les connexions externes (ou au moins la votre) :

ssh myuser@monhost

Bien sûr il n’est pas recommandé d’utiliser le mot de passe pour vous connecter. En général on autorise peu d’utilisateurs à se connecter avec un mot de passe sur un serveur ssh (voir pas du tout).

Nous apprendrons dans un prochain article comment créer ce que l’on appelle une clef ssh qui finalement repose sur deux clefs : publique et privée.

N’hésitez pas à regarder les tutoriels de la chaine xavki ;). Vous pouvez aussi me soutenir en devenant membre de celle-ci ou encore simplement liker et partager ces vidéos.

Se recentrer sur la formation et les tutorials…

Hey ! Bonjour à tous !!

J’espère que vous allez bien ? Moi ça va plutôt bien et je vous propose aujourd’hui de faire un petit point sur la chaine et les évènements passés et à venir.

Maîtriser son temps

Vous le savez l’activité de la chaine youtube (et autour de celle-ci) demande plutôt pas mal de temps. En moyenne on peut dire autour de 3,4,5 heures par jour. C’est une charge assez importante en parallèle de mon job et de ma vie de famille.

Et souvent, en tant que devops, j’aime bien prendre du recul. Et en tant que SRE, j’aime bien avoir quelque chose que je maîtrise.

En prenant du recul, voilà ce que j’ai noté comme éléments dans le cadre de cette remise en question :

  • la chaine demande du temps (cqfd)
  • la présence sur les réseaux sociaux demande du temps
  • le forum discord demande également du temps
  • mon plaisir est la production de tutos et l’amélioration de ces formations
  • je ne cherche pas la notoriété ou l’influence
  • je veux garder de la liberté et donc je veux pas chercher du sponsoring
  • les visites venant de discord et de twitter sont très faibles (moins que ce blog)

En outre, j’ai fait le constat que mon temps passé à regarder le forum et le compte twitter n’apportait pas d’éléments à ma veille et n’influençait pas mes projets de production de contenus.

Bref, malgré 6700 followers sur twitter, je me suis dit je supprime le compte. Je préfère la suppression plutôt qu’avoir un compte fantôme (vide sans personne derrière).

Pour le discord je me suis posé pas mal de questions :

  • délégué le forum : j’avoue que ce n’est pas évident. Il faut trouver des gens avec qui on a les mêmes affinités et contrairement à ce que l’on pense ce n’est pas si facile. Chacun a son caractère, moi le premier.
  • supprimer : c’est une fin triste et cela ne me permettra pas de fédérer la communauté autour de la chaine. Néanmoins l’activité sur le forum n’est pas très dense et le taux de participation reste peu élevé (30 personnes tous les jours sur plus de 1500 membres).

Compte tenu de tout cela j’ai choisi de supprimer le forum. Et toujours la même chose, je veux passer du temps à faire du tuto et à former les gens débutants ou moins. Les discussions peuvent sembler intéressantes par discord ou twitter mais finalement l’impact est limité, on touche moins de personnes ramené au temps passé.

Et réduire les tamagotchis…

Je ne sais pas si vous êtes dans la même situation que moi mais nous disposons de beaucoup d’applications sur notre téléphone. Trop à mon goût.

Et bien souvent, toujours en prenant du recul, on constate que ces applis sont de vraies tamagotchis.

Pourquoi ? tout simplement car on est tenté en permanence d’aller regarder si on a rien de nouveau, si on a pas plus de followers, si quelques choses n’a pas bougé… L’inconvénient c’est que ça limite notre concentration sur les choses essentielles et plus utiles. On perd de fait en efficacité.

Les tutoriels en cours et à venir

Parlons un peu des sujets qui intéressent souvent.

Pour ce qui est en cours, je suis en train de terminer la formation ansible. Actuellement la playlist est composée de 120 vidéos. Je pense qu’il en manque encore une vingtaine. Après je ferais une pause sur cette playlist que j’ai commencé en septembre dernier. J’ai vraiment cherché à atteindre un niveau qui me semble proche d’un cours ou d’une formation ansible digne de ce nom. Cela donne au final environ 60h de vidéos assez exhaustive pour donner la capacité à débuter sereinement avec ansible. Seuls les éléments réseaux n’auront pas été évoqués dans cette formation. Un jour peut être un retour dessus.

Il me reste encore à aborder des choses comme : vagrant, collections, développement de modules, debugs…

Autre sujet que j’ai commencé c’est la formation dédiée à Helm. Un formidable outil qui est parfois méconnu. Là encore je vais chercher à me rapprocher du niveau d’un cours sur cette technologie.

Les vidéos de type 2 minutes marchent très bien aussi. On va donc poursuivre un peu avec un axe plus dédié à Linux ou des choses que je ne pourrais pas placer dans une playlist. Donc c’est encourageant.

Dans ce qui est à venir ?

  • saltstack : pas forcément avec un niveau aussi élevé que ansible car je n’ai pas assez de recul dessus
  • couchbase : une superbe base de données nosql et assez polyvalente avec de grosses performances
  • rabbitmq : un classique pour débuter dans le domaine de queues
  • terraform : pour y mettre quelques exemples d’utilisation dans le cloud car je l’ai un peu mise de côté
  • kubernetes : beaucoup de chose encore à voir dans ce domaine (on en finira jamais)
  • GCP : après avoir fait de la découverte de AWS il me semble bien de voir d’autres cloud
  • refaire un peu de packer
  • et de nombreux autres sujets et idées sous réserve de temps

Réduire mon exposition

Globalement, vous l’avez compris je cherche à me recentrer sur la chaine Xavki. Je ne veux pas m’exposer ou en tout cas tenter de le faire à minima. Pour linkedin je n’envisage pas la suppression. Cela serait assez compliqué pour moi.

Je ne cherche pas à être connu, je cherche à ce que les gens qui en ont besoin connaissent la chaine. Je ne cherche pas à faire en sorte que la chaine soit une activité professionnelle. Les recettes dégagées pour la chaine sont soigneusement mis de côté pour un projet à caractère social (du vrai).

Débuter avec Flux sur Kubernetes

Lors d’un précédent article, nous avions découvert l’intérêt de Helm. On peut le résumer à un outil de templating et de packaging dédié à Kubernetes. On dipose d’un bon outil pour industrialiser vos déploiement l’orchestrateur de conteneurs.

Cependant, Helm ne dispose pas de capacités nécessaires pour déployer ses charts ou plus simplement ses déploiements. Il lui faut donc un outil pour l’aider à accomplir une tâche plus complète de CI/CD.

Ainsi, Flux fait partie de ses outils complémentaires à Helm. Cet outil créé par Weave permet de gérer le déploiement à partir d’un dépôt (qu’il vienne de github ou de gitlab…).

Ainsi la combinaison de ces deux outils permet la répartition des tâches suivantes :

  • helm : via les charts, vous pouvez décrire et templatiser les différentes ressources kubernetes pour vos déploiements
  • flux : permet de synchroniser à fréquence régulière des dépôts (pouvant être des charts helm mais pas nécessairement). Flux permet également de gérer les mises à jour d’images (docker).

Flux est donc un outil important pour la mise en oeuvre d’une stratégie de gitops à partir d’un mode pull. En effet, flux, une fois installé, tire les éléments dans le cluster.

Principales fonctions de flux

Les principales fonctionnalités de flux sont les suivantes :

  • scrutation à fréquence régulière d’un dépôt git (5min par défaut)
  • définition de branches ou tags à prendre en compte
  • déployable sous forme d’opérateur dans k8s
  • mise à disposition d’un client fluxctl pour gérer les interactions avec l’opérateur (gestion des version, rollback…)
  • capacité de garbage collector pour nettoyer les ressources n’existants plus dans le dépôt
  • mise à disposition d’un provider terraform pour flux (et pour helm)

Installation de flux

Comme de nombreux outils associés à k8s, flux se base sur le kubeconfig local. Ainsi il peut rapidement et facilement se connecter à un cluster et éventuellement passer sur un autre cluster.

Comment l’installer ? Commençons par installer le client qui pourra ensuite installer l’opérateur pour vous.

Si vous utilisez ubuntu et snap

sudo snap install fluxctl

Sinon vous pouvez installer directement le binaire de cette manière :

wget https://github.com/fluxcd/flux/releases/download/1.21.0/fluxctl_linux_amd64
sudo mv fluxctl_linux_amd64 /usr/local/bin/fluxctl
sudo chmod 755 /usr/local/bin/fluxctl

Maintenant que le client est installé, il est en mesure d’utiliser votre kubeconfig. Vous pouvez donc passer la commande suivante (à adapter à votre situation).

kubectl create ns fluxcd

fluxctl install --git-email=moi@moi.com --git-url=git@gitlab.com:xavki/testflux.git --git-path=workloads --namespace=fluxcd | kubectl apply -f -

Nous créons donc un namespace dédié à flux et nommé fluxcd.

Puis nous lançons la commande fluxctl install en précisant :

  • –git-email : le mail (sans incidence)
  • –git-url : la localisation du dépôt à synchroniser en utilisant une connexion ssh
  • –git-path : le ou les répertoires à synchroniser
  • –namespace : le namespace où l’opérateur sera installé
  • et enfin on pipe la sortie dans un kubectl apply

A partir de cette étape flux est installé et dispose d’une clef privée. Nous devons donc ajouter la clef publique pour donner à flux la permission d’utiliser le dépôt git en question. Vous pouvez récupérer cette clef publique avec cette commande :

fluxctl identity --k8s-fwd-ns fluxcd

Voilà ! Nous venons de faire nos premiers pas et flux est installé. Il commence déjà à synchroniser les fichiers de ressources kubernetes contenues dans ce répertoire.

Si vous souhaitez en savoir plus sur Helm, je vous invite à regarder la formation Helm disponible dans cette playlist.

Stat et Register, indispensables pour commencer avec ansible

Le cours ansible en ligne avance petit à petit car j’ai réalisé un peu plus de 115 vidéos tutoriels pour le moment ( et c’est pas fini 😉 ). Cette formation est disponible en totalité pour les membres vip pour le moment. Mais ces vidéos deviennent disponible publiquement au fur et à mesure des mois et des semaines. Devenir membre permet de soutenir la chaine xavki.

La dernière vidéo publiée s’adresse plutôt aux débutants avec 2 éléments utiles au quotidien dans vos développements ansible : le register et le module stat. J’ai trouvé cela intéressant de les associer car on le fait cela souvent dans la pratique.

Le module stat de ansible

Idéal pour commencer, ce module ansible permet de vérifier notamment l’existence ou non de fichiers ou de répertoires. Mais pas seulement, le module stat s’apparente aux données accessibles via la commande stat sous linux.

Ainsi une commande stat fournie les principales informations fournies par les inodes. On pourrait résumer cela aux metadatas de votre filesystem.

oki@doki ~/playground/centreserver $ ▶ stat deploy.sh
File: deploy.sh
Size: 3710 Blocks: 8 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 11274196 Links: 1
Access: (0755/-rwxr-xr-x) Uid: (1001/ oki) Gid: (1001)
Access: 2021-03-09 15:49:37.803546224 +0100
Modify: 2021-02-09 18:29:07.371956532 +0100
Change: 2021-02-09 18:29:07.371956532 +0100
Birth: -

Je vous propose donc de créer un fichier avec ansible et lancer dessus le mode stat en deuxième task.

  - name: création d'un fichier
    file:
      path: /tmp/xavki.txt
      state: touch
      owner: xavki

puis lançons le module stat :

  - name: check avec stat
    stat:
      path: /tmp/xavki.txt

Les paramètres de ce module ansible sont :

  • path : chemin du fichier ou répertoire
  • follow : suivre les liens symboliques
  • get_checksum : récupérer la checksum
  • checksum_algorithm : type de checksum (md5, etc)
  • get_mime: récupération du type de données

Mais une fois que l’on a fait cela on ne dispose pas encore des données collectées par le module. Pour cela nous avons besoin d’utiliser le register.

Le register, un ami pour vos modules

Si on devait résumer le register, on pourrait dire qu’il s’agit d’un créateur de variables. Il permet de récupérer les outputs/sorties des modules. En effet de nombreux modules permettent de récupérer des informations lorsqu’ils sont exécutés. Par exemple, le module ec2 de aws va permettre de récupérer toutes les métadatas de l’instance créée.

Pour le module stat de ansible, il va récupérer les informations du fichier ou du répertoire en question.

Pour l’utiliser c’est très simple, il suffit de rajouter register et le nom de la variable créée qui contiendra le contenu de la sortie. Attention à l’indentation avec ansible, il s’agit de mettre le register au même niveau que le nom du module.

Ainsi nous pourrions avoir une succession de tâches suivantes :

  tasks:
  - name: création d'un fichier
    file:
      path: /tmp/xavki.txt
      state: touch
      owner: root
    when: xavki_file is defined
  - name: check avec stat
    stat:
      path: /tmp/xavki.txt
    register: __fichier_xavki
  - name: debug
    debug:
      var: __fichier_xavki

La première pour la création du fichier.

La seconde pour passer un stat sur le fichier xavki.txt avec le register (création de la variable __fichier_xavki).

Et enfin pour visualiser le contenu de la variable obtenue, nous utilisons le module debug.

Bonne pratique : j’ai pour habitude de préfixer ce type de variables par un double underscore. Cela me permet d’une part de les identifier plus rapidement et d’autres part d’utiliser plus rapidement l’autocomplétion (par exemple dans vscode).

Dans le cas de stat, vous pouvez ensuite parcourir le contenu de cette variable ansible. Ainsi pour utiliser la valeur de stat et de la clef « exists » voici comment faire :

__fichier_xavki.stat.exists

Maintenant nous sommes donc en mesure de vérifier l’existence d’un fichier ou d’un répertoire et de conditionner la tache suivante à cela.

  - name: création répertoire xavki
    file:
      path: /tmp/xavki
      state: directory
    when: __fichier_xavki.stat.exists and xavki_file is defined

Mais je vous invite à vérifier le contenu de l’output en totalité et vous verrez que nous disposons des mêmes éléments que si nous avions lancé la commande linux.

Retrouvez les tutoriels ansible ici et abonnez-vous si vous souhaitez ne pas manquer les prochains articles ou vidéos.

Formation et cours complet Helm, c’est parti !!!

Kubernetes est un sujet qui passionne les foules. Je le vois tous les jours avec la playlist k8s. C’est pourquoi j’ai décidé de me centrer sur quelques outils assez courants pour les personnes qui administrent ou utilisent le célèbre orchestrateur de conteneurs. Même si je continue encore la formation ansible, je commence en parallèle une série de tutoriels dédiés à Helm.

Là encore un cours complet pour se former à son rythme que ce soit pour débuter ou aller plus loin. Pour cela on va reprendre toutes les bases pour monter petit à petit en niveau.

Aujourd’hui c’est la première donc du coup on va commencer par poser la première brique à savoir l’introduction à Helm et essayer de répondre à quelques questions : pourquoi ? comment ? intérêts ?…

L’instanciation, une problématique kubernetes

A l’heure actuelle, beaucoup d’entreprises passe à tort ou à raison sur kubernetes. Un bel outil qui permet de lancer des services en décrivant des ressources. L’outil étant assez élaboré, pour lancer une petite application, il est souvent nécessaire d’installer différents objets. En outre nous devons souvent coordonner les objets les uns par rapport aux autres à défaut de variables mutualisées en dehors des configmaps.

Or il est assez courant d’avoir une infrastructure plus ou moins à base de microservices, ces derniers se ressemblant fortement voir appelant de même lignes de codes/images ou nécessitant un déploiement similaire. Mais alors faut-il faire des copier/coller de toutes ces ressources avecs de répertoires et faire évoluer tout cela ensemble avec des difficultés pour modifier dans des manifestes communs plusieurs fois le même élément.

Prenons un exemple avec wordpress, pour créer une instance wordpress, il faut :

  • 2 deployments
  • 1 ingress
  • 2 pvc/pv
  • 2 services…

Créons ensuite une deuxième instance… rebelote et ainsi de suite. Faire cela dans un outil comme kubernetes cela nous fait penser que l’on a loupé quelque chose. Vaut mieux arrêter de travailler et compter les mouches, surtout le jour où il faudra faire évoluer tout ça.

C’est un des points majeurs que Helm permet de corriger.

Helm permet de templatiser des ressources et de stocker toutes les variables définies dans un seul fichier : Values.yaml.

On a donc fait un grand pas.

Mais ce n’est pas le seul intérêt pour Helm

Bien sûr Helm va bien plus loin que cela.

Finalement, une fois que l’on commence à templatiser, on s’aperçoit que l’on dispose de briques cohérentes de ressources. Il ne manque qu’une chose c’est la possibilité de les partager et faciliter leur installation et leur versionning.

Du coup, imaginons que Helm puisse être un gestionnaire de paquets façon apt, yum ou autres. Avec des dépôts distants, cela peut permettre de partager ces packages que l’on appelle simplement des Charts.

Et comme tous les packages, Helm permet de versionner tout cela pour garder des briques cohérentes, éviter les bugs et faciliter l’installation des objets kubernetes. Intéressant n’est-ce pas ?

Ajoutons à cela que Helm a su évoluer d’une version 2 un peu plus complexe vers une version 3 qui permet de se connecter facilement à votre cluster kubernetes.

Conclusion sur Helm

Bref se former à Helm ou l’adopter c’est un bon point pour votre carrière car vous serez peut être amené à le rencontrer et pourquoi pas le tester pour le faire entrer dans votre société. Donc suivre une formation Helm est certainement un bon investissement de votre temps.

Nous en reparlerons plus tard mais un dépôt Helm peut se limiter à un dépôt git assez épuré.

Ainsi vous pourrez trouver des intérêts :

  • meilleures capacités d’itération
  • amélioration du travail en équipe pour vos déploiements
  • utilisation de charts déjà développées par la communauté

Après ne nous cachons pas qu’il faut une petite période d’adaptation. Mais comme vous êtes là c’est que vous voulez apprendre à utiliser Helm et vous former donc je ne me fais pas de soucis pour vous.

Se former est une approche importante pour adopter ou devenir devops. Et n’oubliez pas de vous abonner à la chaine xavki 😉