mplx

README

Introduction

Le résultat est encore assez brouillon (saisir les bonnes pratiques d’ansible n’est pas évident…). Aussi, il ne s’agit pas d’une solution clé en main, à vos risques et périls…

Infrastructure, prérequis et manques

Les valeurs de configuration ainsi que quelques fichiers sensibles sont stoqués dans un dépot séparé (à recréer vous-mêmes). Il contient les répertoires suivant: - inventory (liste des hôtes et valeurs) - files (contient des clés ssh) - vars

Une bonne idée est d’utiliser LUKS pour chiffrer à la fois l’hôte, les conteneurs LXC, et les éventuelles partitions de données utilisateurs.

L’infrastructure doit encore être travaillée pour la rendre cohérente. Notamment, pour le moment, absence ou rien d’abouti côté LDAP, dnsmasq, SGBD, etcd…

Prérequis: python

Pour dérouler les playbooks ansible :

  • python3-distutils

Conteneurisation

La solution privilégiée pour le déploiement est LXC. Les playbooks sont prévus pour des systèmes Debian fraîchement créés.

La partie « gestion des conteneurs LXC» n’a pas encore été écrite mais fait partie des priorités. Pour le moment il faut donc créer les conteneurs LXC soi-même, et s’arranger pour qu’ils soient joignables (ou pas) depuis l’extérieur ou depuis votre LAN.

Comptes utilisateurs et accès au service

Les comptes utilisateurs sont renseignés dans un fichier users.yaml.

L’authentification est prévue pour se faire par clé publique SSH.

Voir : Bastion SSH

Ansible

Inventaire des hôtes

Vous devrez renseigner vos hôtes dans l’inventaire Ansible.

Configuration des services

Il faudra sans doute envisager plusieurs méthodes pour configurer un service, selon la nature de ce service.

Copies de fichiers

C’est adapté lorsqu’un utilisateur a déjà une configuration écrite pour son logiciel. Il suffit de copier cette configuration.

On pourrait s’amuser à entreposer ces configurations dans un git qui devrait être privé du fait des éventuels mots de passe stockés dans ces fichiers de config.

Templates

Le cas le plus courant, qui se prète bien aux services systèmes (tournant dans un unique compte utilisateur) est le template.

On inscrit dans un fichier YAML des variables et leurs valeurs qui viennent alimenter des templates Jinja2, qui génèrent les fichiers de configuration d’un service.

Il peut être fastidieux de proposer toutes les possibilités des fichiers de configuration originaux. On s’en tiendra donc parfois à renseigner les variables qui répondent aux cas les plus courants.

Fichiers Yaml

L’intérêt d’un fichier YAML avec Ansible est qu’il peut non seulement produire des fichiers de config (avec les templates) mais aussi déterminer quelles actions doivent être entreprises.

Cette solution n’est pas toujours simple à élaborer, car il faut décider d’une structure pour le fichier Yaml, qui répond aux cas de figures que l’on souhaite couvrir, et dont les rôles Ansible dépendent pour mener à bien leur tâche.

Conclusion

Actuellement, les variables YAML sont renseignées via les hostvars, mais c’est peu intuitif donc elles seront sans doute inscrites dans un fichier séparé que le rôle ansible pourra utiliser.

Pour ce qui est des fichiers de configuration à copier, la copie est pour le moment manuelle (afin de ne pas écraser la config existante à chaque appel de playbook).

Une fois ces variables renseignées, vous pouvez passer au déploiement.

Déploiement

Ansible prend le relai pour ce qui est de configurer le conteneur (mise à jour des paquets, configuration des locales, ajustements concernant APT…), puis d’installer et configurer ces services.

Côté orchestrateur, il vous faudra décider quel(s) service(s) installer sur quels conteneurs. Pour cela, on indiquera dans un playbook ansible : l’hôte auquel il s’applique, ainsi que le rôle à éxécuter qui correspond à la mise en place du service.

Ansible plus en détails

Ansible.cfg

Le fichier ansible.cfg doit être situé dans le même répertoire que les playbooks. A moins de configurer ANSIBLE_CONFIG, les playbooks doivent être éxécutés depuis ce répertoire.

Je ne fais pas usage des Ansible Facts, donc il est conseillé de positionner gathering = explicit pour gagner un peu de temps d’execution. J’ai aussi viré les “retry”, il peut être plus simple de limiter le champ d’exécution via les paramètres -l ou –tags passés à ansible-playbook.

Données sensibles

J’ai abandonné l’idée d’utiliser ansible vault, en faveur de passwordstore. La solution passwordstore a quelques avantages pratiques (chiffremeng par GPG, pas besoin de passer –ask-pass en paramètre). Le mot de passe maître de passwordstore est demandé automatiquement lors de l’exécution du playbook dès qu’il rencontre cette instruction.

Il y a quelques .gitignore dont il faut tenir compte.

  • celui dans host_vars n’est pas utilisé
  • dans le rôle de création des utilisateurs, les clés publiques et privées sont ignorées
  • le répertoire fetched (actuellement non utilisé) peut stocker des fichiers récupérés depuis les hôtes distants