[{"content":"Vous utilisez peut-être SOPS pour gérer vos secrets dans vos dépôts Git, peut-être même déjà avec Ansible ? Mais est-ce que vous vous simplifiez vraiment la vie ? Je vais vous présenter une structure de projet et une méthode qui tend vers une logique GitOps.\nStructure du projet Avec Ansible, il y a des structures recommandées pour les fichiers et moi je vous recommande la version alternative : cela permet en spécifiant juste le dossier d\u0026rsquo;inventaire d\u0026rsquo;utiliser les bons hosts et les variables qui vont avec :\ninventories/ production/ hosts # inventory file for production servers group_vars/ group1.yaml # here we assign variables to particular groups group2.yaml host_vars/ hostname1.yaml # here we assign variables to particular systems hostname2.yaml staging/ hosts # inventory file for staging environment group_vars/ group1.yaml # here we assign variables to particular groups group2.yaml host_vars/ stagehost1.yaml # here we assign variables to particular systems stagehost2.yaml library/ module_utils/ filter_plugins/ site.yaml webservers.yaml dbservers.yaml roles/ common/ webtier/ monitoring/ fooapp/ La structure alternative recommandée par Ansible\nConfiguration pour intégrer SOPS à Ansible Si vous voulez utiliser des fichiers de variables chiffrés avec SOPS, il va vous falloir plusieurs choses :\nInstaller de la collection communautaire Ansible, qui contient community.sops.sops : ansible-galaxy collection install community.general Activer le plugin community.sops.sops dans le fichier de configuration ansible.cfg : # ansible.cfg [defaults] vars_plugins_enabled = host_group_vars,community.sops.sops # Au passage je definis mon environnement par défaut, le dev inventory = ./environments/dev Un fichier .sops.yaml à la racine du projet :\n# .sops.yaml creation_rules: - path_regex: \u0026#34;environments/prod/.*.sops.yaml\u0026#34; key_groups: - age: - \u0026#34;agekey_user1\u0026#34; - path_regex: \u0026#34;environments/dev/.*.sops.yaml\u0026#34; key_groups: - age: - \u0026#34;agekey_user1\u0026#34; - \u0026#34;agekey_user2\u0026#34; - path_regex: \u0026#34;environments/common/.*.sops.yaml\u0026#34; key_groups: - age: - \u0026#34;agekey_user1\u0026#34; - \u0026#34;agekey_user2\u0026#34; Info Là j\u0026rsquo;ai fais le choix d\u0026rsquo;utiliser des clés age pour le chiffrement/déchiffrement, mais vous pouvez utiliser GPG ou encore un vault.\nPourquoi ne pas stocker directement les secrets dans un vault ? Cela me permet d\u0026rsquo;avoir une seule source de vérité pour mon infra. Si je dois rollback quelque chose cela m\u0026rsquo;évite de modifier de la configuration en plusieurs endroits (c\u0026rsquo;est à peu presque du GitOps).\nSi vous voulez générer une nouvelle paire de clés et qu\u0026rsquo;elle soit utilisée par SOPS, une fois age installé :\nmkdir -p $HOME/.config/sops/age/ echo \u0026#39;# name: my new age key\u0026#39; \u0026gt;\u0026gt; $HOME/.config/sops/age/keys.txt age-keygen | tee \u0026gt;\u0026gt; $HOME/.config/sops/age/keys.txt Vous pourrez ensuite créer votre structure de dossier comme ceci :\nenvironments/ dev/ hosts group_vars/all/ main.yaml main.sops.yaml prod/ hosts group_vars/all/ main.yaml main.sops.yaml En utilisant sops environments/dev/group_vars/all/main.sops.yaml pour les fichiers chiffrés.\nLe fichier hosts est votre inventaire dans le format de votre choix (ça peut même être un inventaire dynamique)\nJ\u0026rsquo;ai appelé les fichiers de variables main, mais vous pouvez les nommer comme bon vous semble, faites juste attention à respecter vos règles de création définies dans .sops.yaml\nVariables communes à plusieurs environnements Dans .sops.yaml, vous avez vu la référence à un dossier common.\nC\u0026rsquo;est pratique pour définir des variables partagées entre tous les environnements.\nJe vais donc créer un dossier common avec dedans deux fichier, un chiffré un en clair.\nmkdir -p environments/common/group_vars/all/ touch environments/common/group_vars/all/000_common.yaml sops environments/common/group_vars/all/000_common.sops.yaml Conseil Le préfixe 000 garantit que ces fichiers sont lus en premier par Ansible (ordre alphanumérique : 0→9→a→z).\nEnsuite, je veux que ces fichiers soient pris en compte dans mes autres environnements, je vais avoir recours à des liens symboliques !\nln -sf environments/common/group_vars/all/* environments/dev/group_vars/all/ ln -sf environments/common/group_vars/all/* environments/prod/group_vars/all/ Et voilà à quoi va ressembler la structure finale :\nenvironments/ common/ group_vars/all/ 000_common.yaml 000_common.sops.yaml dev/ hosts group_vars/all/ 000_common.yaml --\u0026gt; `../../../common/group_vars/all/000_common.yaml` 000_common.sops.yaml `../../../common/group_vars/all/000_common.sops.yaml` main.yaml main.sops.yaml prod/ hosts group_vars/all/ 000_common.yaml --\u0026gt; `../../../common/group_vars/all/000_common.yaml` 000_common.sops.yaml `../../../common/group_vars/all/000_common.sops.yaml` main.yaml main.sops.yaml Vous pouvez ensuite utiliser le dossier au complet avec vos playbooks !\n# Déployer en dev (par défaut, ansible.cfg) ansible-playbook deploy.yml # Déployer en production ansible-playbook -i environments/prod deploy.yml Conclusion Il existe mille façons d\u0026rsquo;organiser un projet Ansible et d\u0026rsquo;utiliser SOPS. J\u0026rsquo;aime cette approche car elle est simple : un dossier = un environnement.\nLibre à vous ensuite de :\ncréer plus de dossiers par groupe de machines séparer par brique applicative ou affiner par rôle Bref, adaptez selon vos besoins 😗\n","permalink":"https://blog.tachy.dev/posts/devops/2025_08_08_ansible_sops/","summary":"\u003cp\u003eVous utilisez peut-être \u003cstrong\u003eSOPS\u003c/strong\u003e pour gérer vos secrets dans vos dépôts Git, peut-être même déjà avec \u003cstrong\u003eAnsible\u003c/strong\u003e ?\nMais est-ce que vous vous simplifiez \u003cem\u003evraiment\u003c/em\u003e la vie ? Je vais vous présenter une structure de projet et une méthode\nqui tend vers une logique GitOps.\u003c/p\u003e\n\u003ch2 id=\"structure-du-projet\"\u003eStructure du projet\u003c/h2\u003e\n\u003cp\u003eAvec Ansible, il y a des \u003ca href=\"https://docs.ansible.com/ansible/2.8/user_guide/playbooks_best_practices.html#directory-layout\"\u003estructures recommandées pour les fichiers\u003c/a\u003e\net moi je vous recommande la version alternative : cela permet en spécifiant juste le dossier d\u0026rsquo;inventaire d\u0026rsquo;utiliser les bons hosts et les variables qui vont avec :\u003c/p\u003e","title":"Utiliser Ansible avec SOPS"},{"content":" DevOps depuis maintenant 10 ans, je touche surtout à Ansible, Terraform, Kubernetes.\nJ\u0026rsquo;écris ici pour me souvenir et partager des choses, histoire de rendre un peu à la communauté OpenSource.\nMême si j\u0026rsquo;ai passé beaucoup de temps sous Windows du fait que c\u0026rsquo;était le seul OS accessible au jeux vidéos, depuis très longtemps je crapahute sur Linux et je suis familier de Ubuntu/Debian/Fedora.\nEn référence au Droit à la paresse, ouvrage de Paul Lafargue paru en 1880. Lafargue y défend l\u0026rsquo;idée que le progrès passe par la réduction du temps de travail, la réappropriation du temps libre et la libération des individus de l\u0026rsquo;aliénation productive.\nJ\u0026rsquo;ai découvert que je voulais faire de l\u0026rsquo;administration système par cet article de l\u0026rsquo;association Framasoft : 12 bonnes raisons d\u0026rsquo;être un administrateur systèmes fainéant.\nEn attendant d\u0026rsquo;abolir le travail, on va l\u0026rsquo;automatiser.\n","permalink":"https://blog.tachy.dev/about/","summary":"\u003cimg\n  src=\"pp_small.png\"\n  alt=\"Profil pic\"\n  style=\"max-width:100%; width:200px; height:auto;\"\n/\u003e\n\n\u003cp\u003eDevOps depuis maintenant 10 ans, je touche surtout à Ansible, Terraform, Kubernetes.\u003c/p\u003e\n\u003cp\u003eJ\u0026rsquo;écris ici pour me souvenir et partager des choses, histoire de rendre un peu à la communauté OpenSource.\u003c/p\u003e\n\u003cp\u003eMême si j\u0026rsquo;ai passé beaucoup de temps sous Windows du fait que c\u0026rsquo;était le seul OS accessible au jeux vidéos,\ndepuis très longtemps je crapahute sur Linux et je suis familier de Ubuntu/Debian/Fedora.\u003c/p\u003e\n\u003cp\u003eEn référence au \u003cstrong\u003eDroit à la paresse\u003c/strong\u003e, ouvrage de \u003cstrong\u003ePaul Lafargue\u003c/strong\u003e paru en 1880.\nLafargue y défend l\u0026rsquo;idée que le progrès passe par la réduction du temps de travail,\nla réappropriation du temps libre et la libération des individus de l\u0026rsquo;aliénation productive.\u003c/p\u003e","title":"À propos"}]