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

Personnellement la veille technique est un rituel que je pratique régulièrement. Si je détecte une nouvelle version majeure d’un outil voir l’apparition d’un nouvel outil je me renseigne rapidement dessus avec comme objectif premier de trouver si son utilisation va apporter quelque chose à mon travail. Je vous propose de découvrir avec quels outils je la réalise et quelles sont mes sources. Qu’est-ce que la veille technologique ? S’il y a bien un domaine qui est en constante évolution, c’est bien celui des outils informatiques et en particulier ceux gravitant autour de la sphère DevOps.

Table des matières Introduction Le langage de Puppet Les manifests Les classes Les modules Apprendre Puppet avec Vagrant Ecriture d’un simple manifest Utilisation de modules de la puppetForge Ecriture d’un simple module Utilisation des facts Utilisation de variables et paramètres Utilisation de template Plus loin avec Puppet Je n’ai jamais utilisé puppet, mais voilà dans le cadre de mon travail, je dois transposer ce qui était fait avec puppet en utilisant Ansible.

Diagrams sont deux librairies, une en Python l'autre en Go, permettant de créer rapidement des schémas d'architecture. Le gros avantage est qu'il n'a pas besoin de recourir à un éditeur pour les créer, si ce n'est la présence de Graphviz sur votre poste de travail. On peut aussi imaginer d'ajouter un petit bout de code dans votre CI pour les générer automatiquement à chaque détection de sa modification. Diagrams permet de créer des schémas pour la plupart des systèmes de Cloud : AWS, Azure, GCP, AlibabaCloud,… mais aussi pour le On-Premise et même pour les clusters Kubernetes.

R2DevOps est un outil complet qui a pour objectif de vous aider à construire votre pipeline CI/CD en partant de zéro. Table des matières Introduction Découverte de R2DevOps Initialisation de mon projet de test On génère le pipeline avec R2DevOps En utilisant le générateur de pipelines CICD En passant par le hub Création de Jobs Conclusion Maj du 10/10/22 Introduction Cette solution, open source et collaborative, s’adresse surtout aux développeurs qui ne maîtrisent pas encore la construction de pipelines CI/CD sur Gitlab et Github.

Je vous propose sur ce billet la liste de tous les outils Linux que je juge indispensables. Ces outils sont principalement utilisés depuis la ligne de commande shell. Comme d’habitude ce billet va évoluer au fil de mes découvertes, donc revenez de temps en temps Table des matières Introduction Aide en ligne tldr Installation cheatsh Utilisation de curl Installation locale de cht.sh Actions sur les fichiers bat Installation de bat ripgrep Installation de rigrep Conteneurs et Orchestrateurs k9s Installation de k9s Utilisation de k9s LazyDocker asdf Multiplexeurs de terminaux zellij Installation de zellij Quelques Raccourcis Plus d’infos Diagram as Code Introduction Pourquoi est-ce-que je les trouve indispensables ?

Table des matières Introduction Installation de glab S’authentifier avec glab Quelques commandes glab Gestion des repository Gestion des releases Création d’une release Lister les releases Afficher le contenu d’une release Ajouter des assets Télécharger les assets d’une release Effacer une release Gestion des pipelines Lister les pipelines Effacer des pipelines Plus loin avec Glab Plus d’infos Introduction S’il y a bien quelque chose qui me manquait dans mes pipelines de CI/CD sous gitlab, c’est bien une CLI.

Pour éviter de réécrire toujours le même code dans vos playbooks Ansible, je vous conseille d’écrire des rôles. Les rôles Ansible permettent de créer l’équivalent des librairies que l’on rencontre sur les langages de programmation. Table des matières Introduction La structure des répertoires de rôles Ansible Passons à la pratique Spécification d’arguments pour les rôles Ansible. Publier vos rôles sur Ansible Galaxy Le fichier meta/main.yml. La publication Utilisation de vos rôles dans vos playbooks Quelques recommandations sur l’écriture des rôles Plus loin Introduction Nous allons voir ici comment écrire des rôles ainsi que quelques recommandations pour faciliter leur utilisation.

C’est avec joie que je vous annonce l’arrivée d’Ansible-Gendoc. Cet outil, python, permet de générer la documentation de vos roles automatiquement en s’appuyant sur un template Jinja et alimenté par le contenu des déclarations du rôle: default, vars et meta. Un exemple de documentation généré avec cet outil : par là Installation d’ansible-gendoc Le package est disponible sur Pypi.org. Bien sûr, je vous conseille de l’installer dans un environnement virtuel :

Je viens de découvrir un autre outil de scan de vulnérabilités qui va peut-être remplacer voir compléter le travail fourni par trivy. Cet outil répond au nom de grype. Il permet comme trivy de scanner des images de containers, des filesystems, mais aussi des SBOM (Software Bill of Materials). Ces SBOM sont générés avec un autre outil du même éditeur et répondant lui au nom de syft. Pour rappel, certaines entreprises et administrations commencent à exiger de fournir ces SBOM.

Github permet de personnaliser son profil avec un simple fichier Readme. Pour l’activer rien de plus simple, il suffit juste de créer un repository portant le même nom que votre compte github. Par exemple, mon compte github se nomme stephrobert, il a suffit donc que je crée un repository stephrobert et d’y déposer un fichier Readme:MD dedans. Dans ce fichier, vous pouvez mettre du contenu au format markdown ou html.

Localstack une pépite ? Certainement. LocalStack est un container simulant une grande partie des services AWS. Il permet de développer et de tester ses déploiements, lambda, code terraform…. Installation LocalStack est écrit en python et intègre beaucoup de librairies dont bien sûr celle d’AWS. Donc pour éviter d’éventuels conflits, je vous conseille de l’installer dans un environnement virtuel. python3 -m venv ~/localstack . ~/localstack/bin/activate pip install localstack awscli-local Démarrage de localstack Maintenant que tout est prêt, nous pouvons lancer le provisionnement de la stack :

Ansible—later est comme ansible-lint un outil qui va scanner votre code Ansible à la recherche de portion de code ne respectant pas les meilleures pratiques. Cela se révèle indispensable si vous souhaitez partager vos rôles Ansible avec votre équipe et pourquoi pas avec la communauté Ansible en les publiant sur Ansible-Galaxy. Il scanne le code des fichiers d’inventaire, des fichiers de rôle, du code python (modules, plugins) et des playbooks Ansible.