Comment utiliser Ansible pour configurer la surveillance du système avec Prometheus

À l'été 2017, j'ai écrit deux articles pratiques sur l'utilisation d'Ansible. Après le premier article, j'avais prévu de montrer des exemples de la copy , systemd , service , apt , yum , virt , et user modules. Mais j'ai décidé de resserrer la portée de la deuxième partie pour me concentrer sur l'utilisation du yum et user modules. J'ai expliqué comment configurer un serveur Git SSH de base et exploré la command , file , authorized_keys , yum , et user modules. Dans ce troisième article, j'aborderai l'utilisation d'Ansible pour la surveillance du système avec la solution de surveillance open source Prometheus.

Si vous avez suivi ces deux premiers articles, vous devriez avoir :

1. Installation d'un hôte de contrôle Ansible
2. Création d'une clé SSH sur l'hôte de contrôle Ansible
3. Propagation de la clé SSH à toutes les machines que vous souhaitez qu'Ansible gère
4. Accès SSH restreint sur toutes les machines
5. Installation d'un serveur Git SSH
6. Créé le git utilisateur, qui est utilisé pour vérifier le code entrant et sortant du serveur Git SSH

D'un point de vue commercial, vous avez maintenant :

1. Gestion simplifiée des hôtes
2. Produit un moyen auditable, reproductible et automatisé de gérer ces hôtes
3. Début de la création d'un chemin pour la reprise après sinistre (via les playbooks Ansible)

Pour développer les compétences dont les entreprises ont besoin, vous devez être en mesure de voir les tendances d'utilisation des ressources au fil du temps. En fin de compte, cela signifie mettre en place une sorte d'outil de surveillance. Il y a beaucoup de choix, y compris Zabbix, Zenoss, Nagios, Prometheus et bien d'autres. J'ai travaillé avec tout cela; la solution que vous choisissez dépend en grande partie de :

• Budget
• Heure
• Connaissance

Les outils de surveillance sans agent tels que Nagios peuvent utiliser quelque chose comme SNMP pour surveiller les hôtes et exposer les métriques. Cette approche peut présenter de nombreux avantages (par exemple, ne pas avoir à installer d'agent). Cependant, j'ai constaté que Prometheus, bien que basé sur des agents, est très facile à configurer et fournit beaucoup plus de métriques prêtes à l'emploi, c'est donc ce que j'utiliserai dans cet article.

Configurer Prometheus

Introduction aux rôles

En savoir plus sur Ansible

• Guide de démarrage rapide d'Ansible
• Aide-mémoire Ansible
• Cours en ligne gratuit :les bases d'Ansible
• Télécharger et installer Ansible
• eBook :L'entreprise automatisée
• Livre électronique :Ansible pour DevOps
• Livres numériques Ansible gratuits
• Derniers articles Ansible

Malheureusement, il n'y a pas de référentiel de gestionnaire de packages Linux disponible pour Prometheus (en dehors du référentiel d'utilisateurs Arch), ou du moins aucun n'est répertorié sur la page de téléchargement de Prometheus. Une image Docker est disponible, ce qui peut être souhaitable dans certains cas, mais elle nécessite l'exécution de services supplémentaires si Docker n'est pas déjà présent sur la machine cible. Pour cet article, je vais déployer les binaires pré-compilés sur chaque hôte. Il n'y a vraiment que deux fichiers nécessaires pour cela :le binaire lui-même et un systemd ou upstart fichier init.

Pour cette raison, un seul manuel d'installation de Prometheus peut être assez complexe ; ce serait donc le bon moment pour discuter de la transition vers un rôle Ansible. Pour faire simple, pendant que vous pouvez avoir un fichier YAML géant, les rôles sont un moyen d'avoir une collection de petites tâches qui peuvent être incluses dans un plus grand jeu . Cela s'explique plus facilement par des exemples. Par exemple, supposons que vous ayez un ID utilisateur qui doit être sur chaque hôte, mais que certains des serveurs que vous gérez nécessitent un serveur Web, tandis que d'autres peuvent avoir un serveur de jeu sur eux. Vous pourriez avoir deux playbooks différents pour gérer cela. Considérez le playbook suivant :

Exemple 1 : Create_user_with_ssh_key.yaml

- hôtes :"{{ hostname }}"
  rassemble_facts : false
  tâches :
   - nom :créer et/ou modifier le mot de passe de {{ username}}
 utilisateur :
        nom :"{{ nom d'utilisateur }}"
        mot de passe :<
     - nom :copier les clés ssh
      clé_autorisée :
        clé :" {{ item }}"
        user :"{{ username }}"
        state :present
        exclusif :False
      with_file :
        - ../files/user1_ssh_key .pub
        - ../files/user2_ssh_key.pub

Il existe quelques options disponibles lors de l'examen de ce problème.

1. Copiez ce code au début de chaque playbook qui sera utilisé pour créer les différents serveurs
2. Exécuter ce playbook manuellement, avant exécuter le playbook de configuration du serveur
3. Tournez le create_user_with_ssh_key.yaml dans une tâche, qui peut ensuite être incluse dans un rôle en utilisant la pratique Ansible standard

L'option 1 n'est pas gérable à grande échelle. Supposons que vous deviez changer le mot de passe ou le nom d'utilisateur que vous étiez en train de créer. Vous devrez trouver tous les playbooks qui incluent ce code.

L'option 2 est un pas dans la bonne direction. Cependant, cela nécessite une étape manuelle supplémentaire chaque fois que vous créez un serveur. Dans un laboratoire à domicile, cela peut suffire. Cependant, dans un environnement diversifié avec la possibilité que plusieurs personnes suivent le même processus pour créer des serveurs, l'option 2 repose sur l'administrateur pour documenter et suivre correctement toutes les étapes nécessaires pour produire un serveur fonctionnel selon des spécifications exactes.

Pour compenser ces lacunes, l'option 3 utilise la solution intégrée d'Ansible. Il a l'avantage d'utiliser un processus de construction de serveur facilement reproductible. De plus, lors de l'audit du processus de construction (vous êtes en utilisant le contrôle de source que nous avons configuré plus tôt, n'est-ce pas ?), l'auditeur peut potentiellement ouvrir un seul fichier pour déterminer quels fichiers de tâche ont été automatiquement utilisés par Ansible pour produire une version de serveur. En fin de compte, ce sera la meilleure approche à long terme, et c'est une bonne idée d'apprendre à utiliser les rôles et de prendre l'habitude de les utiliser tôt et souvent.

L'organisation de vos rôles avec une structure de répertoire appropriée est essentielle à la fois pour une auditabilité facile et pour votre propre succès. La documentation Ansible contient quelques suggestions concernant la structure et la disposition des répertoires. Je préfère une disposition de répertoire similaire à celle-ci :

└── production
    ├── playbooks
    └── rôles
        ├── commun
        │   ├── valeurs par défaut
        │   ─── fichiers
 │ ├── Manuandeurs 
 │── Tâches 
 │── vars 
 Git_Server 
 Fichiers <├── ─ gestionnaires
        │   ├── tâches
        │   └── vars
        ├── surveillance
        │   ├── fichiers
          │ │ │   ├── tâches
        │   ├── modèles
        │   └── vars

Le système Ansible pour la conception des rôles peut être un peu déroutant au début, d'autant plus qu'il existe plusieurs endroits où les variables peuvent être définies. Dans la situation ci-dessus, dans cette situation ci-dessus, je pourrais créer un group_vars répertoire dans le répertoire production dossier comme ceci :

└── production/
    └── group_vars/
        └── all/
            └── vars.yaml

Placer des variables dans ce fichier les rendra accessibles à tout rôle placé dans la production dossier. Vous pourriez avoir vars sous chaque rôle (comme git_server ) et ainsi les mettre à disposition de toutes les tâches pour un rôle donné :

└── environnements/
    └── production/
        └── rôles/
        └── git_server/
            └── vars/
             ─ ─ main.yaml

Enfin, vous pouvez spécifier des variables dans le jeu lui-même. Ceux-ci peuvent être limités localement à la tâche spécifique ou au jeu lui-même (couvrant ainsi plusieurs tâches dans le même jeu).

Pour récapituler, vous pouvez déclarer des variables :

1. Au niveau du rôle pour toutes les tâches d'un rôle donné
2. Au niveau du playbook pour toutes les tâches d'un play
3. Dans les tâches individuelles
4. Dans le fichier d'hôtes Ansible (alias inventaire) ; ceci est utilisé principalement pour les variables machine et n'est pas couvert dans cette discussion

Décider quelle portée créer des variables peut être difficile, en particulier lorsqu'il est mis en balance avec la facilité de maintenance. Vous pouvez mettre toutes vos variables au niveau global, ce qui les rend faciles à trouver mais n'est peut-être pas la meilleure idée pour les grands environnements. L'inverse consiste à placer toutes les variables dans des tâches individuelles, mais cela peut devenir un véritable casse-tête si vous avez beaucoup de variables. Cela vaut la peine de considérer les compromis dans votre situation spécifique.

Pour en revenir au petit playbook de l'exemple 1 ci-dessus, nous pourrions diviser nos fichiers comme ceci :

├── production
│   ├── playbooks
│   └── rôles
│       ├── communs
│       │   ├── fichiers
│       │ │ ├── user1_ssh_key.pub 
 ││ ││ └├├ ├─── ├├ ││ ││ ││ ││ ││ ││ ││ ││ │││ ├── copy_ssh_key.yaml

Le contenu des tasks les fichiers sont identiques aux lignes du playbook unique et monolithique :

Exemple 2 :create_user.yaml

- nom :créer et/ou modifier le mot de passe de {{ nom d'utilisateur}}
  utilisateur :
    nom :"{{ nom d'utilisateur}}"
    mot de passe :<> 

Exemple 3 :copy_ssh_key.yaml

- nom :copier les clés ssh
  clé_autorisée :
    clé :"{{ élément }}"
    utilisateur :"{{ nom d'utilisateur }}"
    état :présent
    exclusif :Faux
  with_file :
    - user1_ssh_key.pub
    - user2_ssh_key.pub

Cependant, ce qui a changé (potentiellement), c'est la manière dont les variables sont transmises à Ansible. Vous pouvez toujours utiliser le --extra-vars option. Cependant, pour démontrer une autre approche, nous utiliserons le vars/main.yaml dossier. Le vars/main.yaml le fichier a le contenu suivant :

nom d'utilisateur :'git'
mot de passe :6$cmYTU26zdqOArk5I$WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8b3.Z3EmyxyvEZt8.OpCCN0

Le mot de passe doit être un hachage et non un mot de passe en clair. Pour générer un hachage sur la plupart des versions de Linux, vous pouvez exécuter la commande Python suivante :

python2.7 -c 'import crypt,getpass; print crypt.crypt(getpass.getpass(), "$1$awerwass")' 

Dans la commande ci-dessus, le mot de passe salt est noté dans awerwass . Ce ne sont que des caractères aléatoires que j'ai martelés sur le clavier. NE PAS UTILISER LE MÊME SEL DANS LA PRODUCTION.

Pour que ces tâches s'exécutent ensemble, vous devez créer un main.yaml dans les tasks annuaire. Il doit avoir le contenu suivant :

---
- inclure :create_user.yaml
- inclure :copy_ssh_key.yaml

Enfin, créez un playbook avec le contenu suivant :

- hôtes :git
  rassemble_facts : false
  rôles :
     43- rôle :../roles/common

Votre structure de répertoire devrait ressembler à ceci :

├── production
│   ├── playbooks
│   │   ├── common.yaml
│   └── rôles
│       ├── common
 │ │── Fichiers 
 ││ ││ ││ ││ └── Les gestionnaires 
 ││ └── ── Main.YAML 
 ││ │── ││ ││ ││ ││ ││ ││ ││ │─── ° C créer_user.yaml 
 │ │ │ ─ main.yaml
│       │   └── vars
│       │       └── main.yaml

Configuration d'un rôle pour Prometheus

Maintenant que nous avons couvert les bases de la création d'un rôle, concentrons-nous sur la création d'un rôle Prometheus. Comme mentionné précédemment, seuls deux fichiers sont nécessaires pour que chaque agent s'exécute :un fichier de service (ou upstart) et le binaire Prometheus. Vous trouverez ci-dessous des exemples de chacun :

Exemple 4 :fichier systemd prometheus-node-exporter.service

[Unit]
Description=Prometheus Exporter for machine metrics.
After=network.target

[Service]
ExecStart=/usr/bin/prometheus_node_exporter 

[Installer]
WantedBy=multi-user.target

Exemple 5 :fichier init upstart

# Exécuter prometheus_node_exporter

start on startup

script
/usr/bin/prometheus_node_exporter
end script

Exemple 6 :fichier systemd prometheus.service (le service serveur)

[Service]
User=prometheus
Group=prometheus
ExecStart=/usr/bin/prometheus -config.file=/etc/prometheus/prometheus.yaml -storage.local. path=/var/lib/prometheus/data -storage.local.retention=8928h -storage.local.series-file-shrink-ratio=0.3
ExecReload=/bin/kill -HUP $MAINPID
 
[Installer]
WantedBy=multi-user.target

Dans mon environnement, avec des machines Ubuntu (avec et sans system ) et un grand nombre de machines Red Hat et Arch, j'avais besoin d'écrire un playbook pour distribuer les scripts de démarrage corrects aux boîtes respectives. Il existe plusieurs façons de déterminer s'il faut déployer le upstart ou systemd fichiers de services. Ansible a un fait intégré appelé ansible_service_mgr qui peut être utilisé pour identifier le gestionnaire de service approprié.

Cependant, j'ai décidé de montrer comment utiliser des scripts pour fournir des faits à Ansible pendant le Gather Facts organiser. Ceci est connu sous le nom de Ansible Local Facts. Ces faits sont lus à partir du /etc/ansible/facts.d/ annuaire. Les fichiers de ce répertoire peuvent être des fichiers JSON, INI ou exécutables renvoyant du JSON. Ils doivent également avoir l'extension de fichier .fact . Le simple script Bash que j'ai écrit vérifie le systemd PID, et s'il est trouvé, renvoie un JSON avec la valeur true , comme dans l'exemple 7 :

Exemple 7 :systemd_check.fact

#!/bin/bash
# Vérifier systemd si présent return { 'systemd':'true' } 

systemd_pid=`pidof systemd` 
if [ - z "$systemd_pid" ] ; then
  echo '{ "systemd":"false" }'
else
  echo '{ "systemd":"true" }'
fi

Dans cet esprit, nous pouvons commencer à créer une tâche simple pour aider à déployer l'agent Prometheus. Pour ce faire, les facts locaux Le fichier doit être copié sur chaque serveur, les scripts binaires et de démarrage doivent être déployés et le service doit être redémarré. Vous trouverez ci-dessous une tâche qui déploiera le systemd_check.fact script.

Exemple 8 :copy_local_facts.yaml

- nom :créer le répertoire des faits s'il n'existe pas
  fichier :
    chemin :/etc/ansible/facts.d
     état :répertoire

- nom :copiez le fichier de faits systemd
  copie :
    src :systemd_check.fact
    dest :/etc/ansible/facts.d/systemd_check.fact
     mode :0755

Maintenant que nos faits personnalisés ont été déployés, nous pouvons maintenant déployer les binaires nécessaires. Mais d'abord, regardons le fichier variable qui sera utilisé pour ces tâches. Dans cet exemple, j'ai choisi d'utiliser le vars/ répertoire localisé dans le rôle individuel. Il ressemble actuellement à ceci :

Exemple 9 :vars/main.yaml

exporter_binary :'prometheus_node_exporter'
exporter_binary_dest :'/usr/bin/prometheus_node_exporter'
exporter_service :'prometheus-node-exporter.service'
exporter_service_dest :'/etc/systemd/system /prometheus-node-exporter.service'
exporter_upstart :'prometheus-node-exporter.conf'
exporter_upstart_dest :'/etc/init/prometheus-node-exporter.conf'

server_binary :'prometheus'
server_binary_dest :'/usr/bin/prometheus'
server_service :'prometheus.service'
server_service_dest :'/etc/systemd/system/prometheus.service' 

prometheus_user :'prometheus'
prometheus_server_name :'prometheus'

client_information_dict :
    'conan' :'192.168.195.124:9100'
    'confluence' :'192.168.195.170:9100'
    'smokeping' :'192.168.195.120:9100'
    '7-repo' :'192.168.195.157:9100'
    'serveur ' :'192.168.195.9:9100'
    'ark' :'192.168.195.2:9100'
    'kids-tv' :'192.168.195.213:9100'
    'medi a-centre' :'192.168.195.15:9100'
    'nas' :'192.168.195.195:9100'
    'nextcloud' :'192.168.199.117:9100'
    'git' :'192.168.195.126:9100'
    'nuc' :'192.168.195.90:9100'
    'bureau' :'192.168.195.18:9100'

Pour l'instant, vous pouvez ignorer le client_information_dict; cela entrera en jeu plus tard.

Exemple 10 :tâches/setup_prometheus_node.yaml

---
- nom :copier le binaire dans {{ exporter_binary_dest }}
  copier :
    src :"{{ exporter_binary }}"
    dest :"{{ exporter_binary_dest }}"
    mode :0755

- nom :mettre le fichier de service systemd en place
  copie :
    src :"{{ exporter_service }}"
    dest :"{{ exporter_service_dest }}"
  when :
    - ansible_local.systemd_check.systemd =='true'

- name :copiez la conf upstart vers {{ exporter_upstart_dest }}
  copie :
    src :"{{ exporter_upstart }}"
    dest :"{{ exporter_upstart_dest }}"
  when :
    - ansible_local.systemd_check.systemd =='false'

- nom :mettre à jour systemd et redémarrer l'exportateur systemd
  systemd :
    daemon-reload :vrai
    activé :vrai
    état :redémarré
    nom :"{{ exporter_service }}"
  quand :
    - ansible_local.systemd_check.systemd =='true'
   
- nom :démarrer le service sysv de l'exportateur 
  service :
    nom :"{{ exp orter_service }}"
    activé :vrai
    état :redémarré
  lorsque : 
    - ansible_local.systemd_check.systemd =='false'

La chose la plus importante à noter dans la tâche ci-dessus est qu'elle fait référence à ansible_local.systemd_check.systemd . Cela se décompose en la convention de dénomination suivante <how Ansible generates the fact> . <the name of the fact file> . <the key inside the fact to retrieve> . Le script Bash systemd_check.fact est exécuté pendant le Gather Facts stage puis stocké dans le ansible_local section de tous les Gather Facts . Pour prendre une décision basée sur ce fait, je vérifie s'il est true ou false . La clause Ansible When indique à Ansible d'exécuter cette tâche spécifique uniquement si certaines conditions sont remplies. Le reste de cette tâche devrait être assez simple. Il utilise à la fois les modules systemd et service pour s'assurer que le gestionnaire de service approprié est configuré pour démarrer le prometheus_node_exporter .

La tâche de configuration du serveur est très similaire :

Exemple 11 :tâches/setup_Prometheus_server.yaml

---
- nom :copier le binaire du serveur dans {{ server_binary_dest }}
  copier :
    src :"{{ server_binary }}"
    dest :"{ { server_binary_dest }}"
    mode :0755
  lorsque :
    - Inventory_hostname ='prometheus'

- nom :Assurez-vous que /etc/prometheus existe
 fichier :
    état :répertoire
    chemin :/etc/prometheus
    propriétaire :"{{ prometheus_user }}"
    groupe :"{{ prometheus_user }}"
     mode :0755
 quand :
     - nom_hôte_inventaire ='prometheus'

- nom :placez la configuration de prometheus
  modèle :
    src :prometheus.yaml.j2
    dest :/etc/prometheus/prometheus.yaml
  quand :
    - nom_hôte_inventaire ='prometheus'

- nom :créer /var/lib/promtheus/data
  fichier :
     état :répertoire
     chemin :/var/lib/prometheus/data
     recurse :vrai
    propriétaire :"{{ prometheus_user }}"
 groupe :"{{ prometheus_user }}"
    mode :0755
  quand :
    - dans ventory_hostname ='prometheus'

- nom :mettre le fichier de service systemd en place
  copie :
    src :"{{ server_service }}"
    dest :"{{ server_service_dest }}"
  quand :
    - ansible_local.systemd_check.systemd =='true'
    - Inventory_hostname ='prometheus'

- nom :mettre à jour systemd et redémarrer serveur prometheus systemd
  systemd :
    daemon-reload :vrai
    activé :vrai
    état :redémarré
    nom :"{{ service_serveur }}"
  lorsque :
    - ansible_local.systemd_check.systemd =='true'
    - Inventory_hostname ='prometheus'

  notifier :restart_prometheus_server

L'observateur avisé remarquera quelques nouveautés dans la tâche serveur.

1. La notify: rubrique
2. Le modèle template: modules

La notify est un moyen de déclencher des types d'événements spécifiques lorsque certains critères sont remplis. Les gestionnaires Ansible sont utilisés le plus souvent pour déclencher des redémarrages de service (ce qui est exactement ce qui se passe ci-dessus). Les gestionnaires sont stockés dans un handlers répertoire au sein du rôle. Mon gestionnaire est très basique :

Exemple 12 :gestionnaire/main.yaml

- nom :restart_iptables
  service :
    nom :iptables
     état :redémarré
    activé :vrai

- nom :restart_prometheus_server
 service :
    nom :"{{ server_service }}"
    état :redémarré
    activé :vrai

Cela me permet simplement de redémarrer le prometheus.service sur le serveur Prometheus.

Le deuxième point d'intérêt dans le setup_prometheus_server.yaml est le template: section. La création de modèles dans Ansible offre de très beaux avantages. Ansible utilise Jinja2 pour son moteur de templates; cependant, une explication complète de Jinja sort du cadre de ce didacticiel. Essentiellement, vous pouvez utiliser un modèle Jinja2 pour avoir un fichier de configuration avec des variables dont les valeurs sont calculées et remplacées lors d'une lecture Ansible. Le modèle de configuration Prometheus ressemble à ceci :

Exemple 13 :modèles/prometheus.yaml.j2

global :
  scrape_interval :    15s # Définissez l'intervalle de récupération sur toutes les 15 secondes. La valeur par défaut est toutes les 1 minute.
  evaluation_interval :15s # Évalue les règles toutes les 15 secondes. La valeur par défaut est toutes les 1 minute.

  external_labels :
      monitor :'codelab-monitor'

scrape_configs :
  # Le nom de la tâche est ajouté en tant que étiquette `job=` à toute série temporelle extraite de cette configuration.
  - nom_travail :'prometheus'

    static_configs :
      - cibles :['localhost:9090'] 
  - nom_travail :'nodes'
    static_configs :
{% pour le nom d'hôte, ip dans client_information_dict.iteritems() %}
      - cibles :['{{ ip }}'] 
        Libellés :{'host' :'{{ hostname }}' }
{% endfor %}

Lorsque la section de modèle est traitée, le .j2 est automatiquement supprimée avant de mettre le fichier en place sur le système distant. La petite boucle for du modèle itère sur le client_information_dict , que j'ai défini précédemment dans mon fichier de variables. Il crée simplement une liste de machines virtuelles sur lesquelles je souhaite que Prometheus collecte des métriques.

Remarque :Si vous souhaitez que Prometheus affiche les noms d'hôte et que votre DNS est correctement configuré, utilisez plutôt ceci :

{% for hostname, ip in client_information_dict.iteritems() %}
      - cibles :['{{ hostname }}:9100']
        labels :{'host' :'{{ hostname }}' }
{% endfor %}

Il ne reste que quelques touches finales pour terminer la configuration de Prometheus. Nous devons créer le prometheus utilisateur, ajustez (potentiellement) iptables, liez le tout dans le main.yaml , et créez un playbook à exécuter.

La configuration du Prometheus user est assez simple, et il vous sera très familier si vous avez suivi mes précédents articles Ansible :

Exemple 14 :tâches/create_prometheus_user.yaml

---
- nom :Assurez-vous que l'utilisateur prometheus existe
  utilisateur :
    nom :"{{ prometheus_user }}"
    shell :/bin/false 

 La seule différence majeure ici est que je règle le shell sur /bin/false afin que l'utilisateur puisse exécuter des services, mais pas se connecter.
 

 Si vous utilisez iptables, vous devrez vous assurer d'ouvrir le port 9100 afin que Prometheus puisse collecter les métriques de ses clients. Voici une tâche simple pour le faire :
 
Exemple 15 :tâches/iptables.yaml
 
---
- name :Open port 9100
  lineinfile :
    dest :/etc/sysconfig/iptables
    insertbefore :"-A INPUT -j OS_FIREWALL_ALLOW"
    ligne :"-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT"
  notifier :restart_iptables
  quand :
    - ansible_os_family =="RedHat" 
 

 Remarque :je n'exécute iptables que sur ma famille de machines virtuelles Red Hat. Si vous exécutez iptables sur toutes vos machines virtuelles, supprimez le when: rubrique.
 

 Le main.yaml ressemble à ceci :
 
Exemple 16 :tâches/main.yaml
 
--- 
- inclure :create_prometheus_user.yaml
- inclure :setup_prometheus_node.yaml
- inclure :setup_prometheus_server.yaml
- inclure :prometheus_iptables.yaml
 

 La dernière étape consiste à créer un playbook qui englobe les rôles dont vous avez besoin pour accomplir votre tâche :
 
Exemple 17 :playbooks/monitoring.yaml
 
- hôtes :tous
  rôles :
    - rôle :../roles/common
    - rôle :../roles/monitoring
 
Tout lier ensemble
 

 Je sais que cela ressemble à beaucoup de texte à parcourir, mais les concepts d'utilisation d'Ansible sont assez simples. Il s'agit généralement de savoir comment accomplir la tâche que vous vous êtes fixée, puis de trouver les modules Ansible appropriés pour vous aider à les accomplir. Si vous avez suivi cette procédure pas à pas jusqu'au bout, vous devriez avoir une mise en page semblable à celle-ci :
 
├── playbooks
│   ├── git_server.yaml
│   ├── monitoring.yaml
└── rôles
    ├── common
    │ ├── Fichiers 
 │ ├── Systemd_Check.fact 
 │── User1_ssh_key.pub user2_ssh_key.pub 
 ├── br />    │   │   └── main.yaml
    │   ├── tâches
     │   │   ├── copy_systemd_facts.yaml
    │   │    │── main. ├── push_ssh_key.yaml
      │   │   ├── root_ssh_key_only.yaml
    │   └── vars
    │   └── main.yaml
      ├surveillance─ ─ Fichiers ├── Français 
 Prométhée 
 Prometheue_node_exporter 
 ││ ├── FROMETHEUS-NODE-Exporter.conf <─── prometheus-node-exporter.service
    │   │   ├── prometheus.service
    │   │   └── systemd_check.fact
    │   ├── gestionnaires
     │    │  │ .yaml
    │   ├── tâches
    │   │   ├── create_prometheus_user.yaml
    │   │   ├── Main.yaml 
 Prometheus_IPTABables.YAML 
 ││ ├──.yaml 
 │ │ └──P />    │   │   └── prometheus.yaml.j2
        └── vars
            └── main.yaml
 

 Pour exécuter votre playbook, saisissez :
 
[root@ansible-host production]# ansible-playbook -i <path to host file> playbooks/monitoring.yaml 
 
 

 Vous devriez maintenant pouvoir créer des utilisateurs, pousser des clés ssh, vérifier l'existence de systemd , et déployez soit le prometheus_node_exporter ou le binaire du serveur Prometheus aux serveurs appropriés. Prometheus doit s'initialiser avec une configuration de base comprenant la liste des hôtes spécifiés dans vars/main. yaml fichier dans le rôle de surveillance.
 

 Toutes nos félicitations! Vous avez maintenant automatisé l'installation et la configuration d'un serveur Prometheus de base et configuré vos hôtes pour qu'ils commencent à transmettre des données. Comme effet secondaire agréable, vous avez également documenté efficacement toutes les étapes nécessaires pour atteindre vos objectifs.
 
 

 Addendum :Lorsque j'ai conçu cette série, j'allais travailler sur l'installation de Prometheus dans OpenShift ; cependant, en examinant la documentation du programme d'installation d'Ansible pour OpenShift, j'ai découvert qu'il était déjà contenu dans un playbook et qu'il s'agissait d'une option dans le programme d'installation.