Dans ce chapitre, nous allons passer en revue les options de configuration qui peuvent être intéressantes pour optimiser notre serveur de management Ansible.
Quelques options de configuration intéressantes à évoquer :
forks: par défaut à 5, il s'agit du nombre de processus qu'Ansible lancera en parallèle pour communiquer avec les hôtes. Plus ce nombre est élevé, plus Ansible pourra gérer de clients en même temps, et donc accélérer le traitement. La valeur que vous pouvez définir dépend des ressources de CPU/RAM de votre serveur de management. Notez que la valeur par défaut, 5, est très faible, la documentation Ansible indique que de nombreux utilisateurs la fixent à 50, voire 500 ou plus.
gathering : cette variable modifie la politique de collecte des "facts". Par défaut, la valeur est implicit, ce qui implique que les "facts" seront collectés systématiquement. Modifier cette variable à smart permet de collecter les "facts" uniquement s'ils n'ont pas déjà été collectés. Associée a un "facts cache" (voir ci-dessous), cette option permet de considérablement augmenter la performance.
host_key_checking : Attention à la sécurité de votre serveur de Management ! Cependant, si vous avez le contrôle total de votre environnement, il peut être intéressant de désactiver le contrôle des clés des serveurs distants et de gagner du temps à la connexion. Vous pouvez aussi, sur les serveurs distants, désactiver l'utilisation du DNS du serveur SSH (dans le fichier /etc/ssh/sshd_config, option UseDNS no), cette option fait perdre du temps à la connexion et n'est, la plupart du temps, utilisée que dans les logs de connexion.
ansible_managed : Cette variable, contenant Ansible managed par défaut, est généralement utilisée dans les templates de fichiers qui sont déployés sur les serveurs distants. Elle permet d'informer les administrateurs que le fichier est automatiquement mis à jour par Ansible et que les changements qu'ils apporteront seront potentiellement perdus. Il peut être intéressant de présenter des messages plus exhaustifs aux administrateurs. Attention toutefois, si vous modifiez cette variable, cela peut provoquer le redémarrage des services (via les "handlers" associés aux templates).
ssh_args = -C -o ControlMaster=auto -o ControlPersist=300s -o PreferredAuthentications=publickey : spécifie les options de connexion ssh. En désactivant toutes les méthodes d'authentification autre que les clés publiques, vous pouvez économiser beaucoup de temps. Vous pouvez aussi augmenter le ControlPersist pour améliorer la performance (la documentation suggère qu'une valeur équivalente à 30 minutes peut être appropriée). La connexion à un client reste ouverte plus longtemps et peut être réutilisée lors d'une reconnexion au même serveur, ce qui représente un gain de temps considérable.
control_path_dir : Indiquer le chemin d'accès aux sockets de connexion. Un path trop long peut causer des problèmes. Considérez le fait de le changer pour quelque chose de plus court, comme /tmp/.cp.
pipelining : La définition de cette valeur à True augmente les performances en réduisant le nombre de connexions SSH nécessaires lors de l'exécution de modules distants. Vous devez d'abord vous assurer que l'option requiretty est désactivée dans les options sudoers (voir documentation).
La collecte des "facts" est un processus qui peut prendre un certain temps. Il peut être intéressant de désactiver cette collecte pour les playbooks qui n'en ont pas besoin (via l'option gather_facts) ou de garder ces faits en mémoire dans un cache pendant une certaine durée (par exemple 24H).
Ces "facts" peuvent être facilement stockés dans une base de données redis :
Les différents mots de passe et secrets ne peuvent pas être stockés en clair avec le code source d'Ansible, que ce soit localement sur le serveur de Management ou sur un éventuel dépôt de code source.
Ansible propose d'utiliser un gestionnaire de chiffrement : ansible-vault.
Le principe est de chiffrer une variable ou un fichier entier avec la commande ansible-vault.
Ansible pourra déchiffrer ce fichier au moment de l'exécution en récupérant la clé de chiffrement dans le fichier (par exemple) /etc/ansible/ansible.cfg. Ce dernier peut également être un script python ou autre.