Toute l'actualité devOps dans le média Stéphane ROBERT

Je continue le développement de ma configuration Devops 2022 et je viens de franchir le pas de la publication de ma première box sur le site vagrantUp. Pour rappel, cette boxe vagrant est construite sur la base d’une Ubuntu 21.10 et on y trouve préinstallé : Python v3.9.7 Docker version 20.10.14, build a224086 Vagrant 2.2.19 Libvirt / KVM / QEMU Arkade 0.8.14 Pour le moment, je n’ai pas encore intégré asdf mais comme le playbook actuel le fait, il est installé.

Les temps de build (compilation) sont du temps perdu surtout si on est dans des phases de développement où on relance souvent les mêmes commandes d’installation. Je vais prendre comme exemple le temps de déploiement d’Ansible dans les différents outils que j’utilise dans mon Home Lab Devops. Ansible est écrit en python qui est soit livré en package, soit via le repository pypi. Mais voilà pour les packages, ils sont souvent très en retard sur les versions et pour le repository pypi seules les codes sources en tar.

Maintenant que toutes les opérations s’enchaînent lors de la création d’une machine libvirt, je peux enfin tester le provider terraform powerdns. Pour rappel [powerDNS] fait partie des applications que je déploie dans mon home lab devops. Création du Token d’API dans PowerDNS Il suffit de se rendre dans la console de powerDNS admin et de cliquer sur le menu API Keys. Cliquer sur [ADD Key], prenez le role administrator et appuyer sur [Create Key].

Dans ma première utilisation de Renovate au sein de mon Home Lab Devops, je me limitais à la mise à jour des dépendances dans la construction des images docker. Mais voilà j’utilise pas mal de playbooks Ansible pour installer des applications sur des VM. J’ai ajouté le repository du playbook de rundeck, mais pas d’issue crée. Mais comment gérer ce versionning avec renovate ? Dans les dernières versions de Renovate les dépendances de type ansible sont directement pris en charge.

On trouve des providers Terraform pour pas mal de produits, mais j’ai été surpris d’en trouver un pour gérer les projets Rundeck. Ce provider permet de gérer les acls, les projets, les jobs et les clés SSH. Je vous propose de le tester sur le rundeck de mon home lab Devops. Création du token sur Rundeck La première chose a créé est le token autorisant terraform à se connecter à rundeck.

Dans le billet précédent, je vous montrais comment remonter les logs de k3s dans prometheus avec loki. Comme pour la surveillance, j’aimerais aussi centraliser les logs des serveurs Linux où tournent mes applications sur des machines virtuelles avec libvirt. Installation de promtail Comme d’habitude j’ai pris la documentation du produit et j’ai écrit le playbook ansible en conséquence. J’ai géré le changement de version. - hosts:libvirtgather_facts:yesbecome:truevars:promtail_version:2.4.1loki_url:https://loki.robert.local/loki/api/v1/pushtasks:- name:Create group promtailansible.builtin.group:name:promtailstate:present- name:Create user promtailansible.

Après avoir parlé de stern qui permettait de centraliser les logs dans la console, je suis parti en recherche d'un outil permettant de centraliser ses logs dans une interface WEB. On connaît tous ELK, mais je suis à la recherche de quelques choses de plus léger et de moins gourmand en ressources. Et je suis tombé sur loki, un outil développé par Grafana Labs. Découverte de la stack loki On retrouve :

Mon Home Lab Devops est composé à ce jour de 3 mini-pc dont un se fige de temps en temps (le plus vieux). J’ai donc mis en place le monitoring de leurs ressources avec Prometheus. Le plus compliqué a été de trouver où ajouter dans le fichier de valeurs du chart helm ces jobs de scraping. Mais avant cela voyons comment installer node-exporter sur les machines Linux. Installation de prometheus-node-exporter sur les machines Linux Pour installer node-exporter, il faudra tout installer à la main.

Je vous ai présenté il y a quelques semaines, octant, un produit open source qui permet de naviguer et de manager des clusters Kubernetes de manière visuelle. C’est au tour de Lens Desktop pour la sortie de sa version 5.4. Lens Desktop s’installe partout, car il existe des versions pour windows, linux et macos. Fonctionnalités de base On retrouve à peu près les mêmes fonctions qu’offre octant avec en plus :

Certaines des applications de mon Home Lab Devops sont installées sur le cluster k3s mono-noeud et nécessitent donc de créer des Ingress pour y accéder. Nous allons voir comment les créer avec les certificats autosignés créés avec mkcert. Nous allons prendre comme exemple celui permettant d’accéder à AWX. Création du certificat wildcard avec mkcert Plutôt que de créer autant de certificats que d’applications je vais utiliser un certificat wildcard, c’est-à-dire avec une '*'.

Maintenant que nous savons comment lancer le provisioning avec ansible automatiquement, il manque juste le resizing de l’image de type cloud en automatique. En effet, les images fournies sont souvent trop petites. Le plugin libvirt de Terraform intègre cette fonctionnalité, qui évite de le faire manuellement. Ajout d’un volume libvirt de base Lorsqu’on déclare un volume à partir d’une image téléchargée, on ne peut modifier sa taille. Pour le faire automatiquement, il suffit de créer un volume de base avec l’image téléchargée et de le dériver avec un autre volume en spécifiant la taille voulue.

Dans le premier billet consacré au couple Terraform / Libvirt, nous avions vu comment créer des ressources, mais pas comment enchaîner automatiquement le provisioning. Par provisioning j’entends l’utilisation des fonctions remote-exec et local-exec qui permettent par exemple de lancer des playbooks ansible ou des scripts. Je bloquais sur : Comment attendre que la machine provisionnée ait une adresse IP allouée par le serveur DHCP. Comment attendre la fin de la partie cloud-init Depuis j’ai pas mal bossé sur mon projet de Home Lab Devops ou je cherche à tout automatiser et j’ai fini par trouver les solutions à ces problèmes.