Blog

Nous travaillons tous sur de nombreux projets, chacun utilisant des versions différentes des CLI Devops. Par exemple, vous travaillez pour un client qui utilise Kubernetes 1.23 et Terraform 1.1.4. Ensuite, on vous met sur un nouveau projet client qui lui utilise Kubernetes 1.25 et Terraform 1.3.6. Si vous ne gérez pas vos versions correctement cela peut vite tourner au drame avec des incompatibilités ou du code non pris en charge au moment de la livraison de celui-ci.

De part mon activité de blogger, je suis obligé de pouvoir changer de PC pour travailler rapidement sur mon homelab par exemple. Pour éviter un nombre incalculable de branchements et de débranchements, j’ai fait l’acquisition d’un petit KVM avec deux entrées et deux sorties.

Je vous propose de découvrir monkeyble, une collection Ansible qui peut vous aider à tester vos playbooks mais pas que. En effet, il permet aussi de combler un manque au mode check, qu’il fonctionne dans tous les cas via un mode patching. Voyons cela en détail

Je vous propose de découvrir caradoc, un callback Ansible qui peut vous aider à déboguer vos playbooks. Il n’est pas sans rappeler ARA, qui permet de stocker les traces de vos exécutions dans une base de données sqlite locale, voir sur un serveur distant.

Jusqu’à maintenant, je n’utilisais que les drivers docker et vagrant pour provisionner des machines de tests avec molecule lors de mes développements de roles et collections Ansible. Comme je n’ai plus assez de ressources à la maison pour les provisionner, je me suis dit pourquoi utiliser des instances AWS EC2. Après avoir tâtonnè longtemps, j’ai fini par réussir, j’ai décidé de vous en faire profiter.

Lors de ma veille technique, je scrute souvent les change-logs de mes outils préférés sur GitHub. Et lors de l’une d’elle, j’ai remarqué que Trivy avait ajouté pas mal de fonctionnalités dont le scan des comptes AWS mais aussi des images de VM.

Cet article est la suite de celui consacrer à la maintenance des collections et des rôles Ansible avec Renovate. Aujourd’hui, nous allons voir comment durcir vos rôles avec l’aide d’OpenScap.

Il y a quelques mois, je vous expliquais comment installer et upgrader AWX via l’utilisation de l’opérateur Kubernetes AWX. Mais voilà lors d’un upgrade et je suis impardonnable, j’ai perdu le secret stockant le mot de passe de connexion à la base de données Postgres en effaçant le namespace AWX. Donc j’ai décidé d’utiliser une base de données installée sur un autre serveur. Voyons comment procéder.

Kubernetes prend une place de plus en plus importante dans les infrastructures, même s’il est assez facile de déployer et de garantir la disponibilité des applications, sa mécanique est réellement complexe. Et comme on dit souvent “sans maîtrise, la puissance n’est rien”. En effet, installé et configuré par défaut un cluster kubernetes est vulnérable aux attaques.

Dans un précédent billet, je vous ai présenté

Les extensions de nos éditeurs peuvent réellement augmenter notre productivité, mais aussi à augmenter la qualité du code produit. Je vous partage la liste des extensions que j’utilise essentiellement dans mes activités de développement de code d’Infrastructure As Code (DevOps) et d’écriture de documents au format Markdown pour mon blog et pour les documentations.

Dans la démarche DevOps, on parle bien d’automatisation pour éliminer les tâches chronophages et sans valeurs ajoutées pour pouvoir se concentrer sur celles qui donnent de la valeur à notre produit.