Jak používat Ansible k nastavení monitorování systému pomocí Prometheus

V létě 2017 jsem napsal dva články o tom, jak používat Ansible. Po prvním článku jsem plánoval ukázat příklady copy , systemd , service , apt , yum , virt a user moduly. Ale rozhodl jsem se zpřísnit rozsah druhé části a zaměřit se na používání yum a user moduly. Vysvětlil jsem, jak nastavit základní server Git SSH, a prozkoumal jsem command , file , authorized_keys , yum a user moduly. V tomto třetím článku se zaměřím na používání Ansible pro monitorování systému s řešením Prometheus pro monitorování open source.

Pokud jste postupovali podle těchto prvních dvou článků, měli byste mít:

1. Nainstalovali jste hostitele ovládacího prvku Ansible
2. Vytvořil klíč SSH na hostiteli ovládacího prvku Ansible
3. Rozšířil klíč SSH do všech počítačů, které má Ansible spravovat
4. Omezený přístup SSH na všech počítačích
5. Nainstalován server Git SSH
6. Vytvořili git uživatele, který se používá k přihlášení a odhlášení kódu ze serveru Git SSH

Z obchodního hlediska nyní máte:

1. Zjednodušená správa hostitele
2. Vytvořili auditovatelný, opakovatelný a automatizovaný způsob správy těchto hostitelů
3. Začal jsem vytvářet cestu pro obnovu po havárii (prostřednictvím příruček Ansible)

Chcete-li vybudovat dovednosti, které podniky potřebují, musíte být schopni vidět trendy využití zdrojů v průběhu času. V konečném důsledku to znamená nastavit nějaký druh monitorovacího nástroje. Je z čeho vybírat, včetně Zabbix, Zenoss, Nagios, Prometheus a mnoha dalších. Se všemi těmito jsem pracoval; to, jaké řešení zvolíte, je z velké části závislé na:

• Rozpočet
• Čas
• Seznámení

Nástroje pro monitorování bez agentů, jako je Nagios, mohou používat něco jako SNMP k monitorování hostitelů a odhalování metrik. Tento přístup může mít mnoho výhod (například nemusíte instalovat agenta). Zjistil jsem však, že Prometheus, přestože je založen na agentech, se velmi snadno nastavuje a poskytuje mnohem více metrik hned po vybalení, takže to použiji v tomto článku.

Nastavení Promethea

Úvod do rolí

Více o Ansible

• Rychlý průvodce Ansible
• Cheat sheet Ansible
• Bezplatný online kurz:Základy Ansible
• Stáhněte si a nainstalujte Ansible
• eKniha:Automatizovaný podnik
• eKniha:Ansible pro DevOps
• Bezplatné elektronické knihy Ansible
• Nejnovější články Ansible

Bohužel pro Prometheus není k dispozici úložiště správce balíčků Linuxu (mimo úložiště Arch User Repository), nebo alespoň žádné není uvedeno na stránce stahování Prometheus. K dispozici je obraz Dockeru, který může být v některých případech žádoucí, ale vyžaduje spuštění dalších služeb, pokud Docker ještě není na cílovém počítači přítomen. V tomto článku nasadím předkompilované binární soubory do každého hostitele. Ve skutečnosti jsou k tomu potřeba pouze dva soubory:samotný binární soubor a systemd nebo upstart init souboru.

Z tohoto důvodu může být jedna instalační příručka Prometheus docela zahrnuta; proto by byl vhodný čas prodiskutovat přechod na Ansible Role. Jednoduše řečeno, dokud můžete mít jeden obrovský soubor YAML, role představují způsob, jak mít sbírku menších úkolů, které lze zahrnout do větší hraní . To se snadněji vysvětluje na příkladech. Řekněme například, že máte ID uživatele, které musí být na každém hostiteli, ale některé servery, které spravujete, vyžadují webový server, zatímco jiné mohou mít herní server. Možná máte dvě různé příručky, abyste to zvládli. Zvažte následující příručku:

Příklad 1:Create_user_with_ssh_key.yaml

- hostitelé:"{{ název hostitele }}"
  shromáždit_fakta:false
  úkoly:
    - jméno:vytvořit a/nebo změnit heslo uživatele {{ username}}
 uživatel:
        jméno:"{{ uživatelské jméno }}"
        heslo:<
    - jméno:kopie ssh klíčů
      autorizovaný_klíč:
        klíč:" {{ item }}"
        user:"{{ username }}"
        stav:přítomný
        exkluzivní:False
      with_file:
        - ../files/user1_ssh_key .pub
        - ../files/user2_ssh_key.pub

Při zvažování tohoto problému je k dispozici několik možností.

1. Zkopírujte tento kód na začátek každé příručky, která bude použita k vytvoření různých serverů
2. Spusťte tuto příručku ručně před spuštění příručky konfigurace serveru
3. Zapněte create_user_with_ssh_key.yaml do úkolu, který pak lze zahrnout do role pomocí standardní praxe Ansible

Možnost 1 není v měřítku zvládnutelná. Předpokládejme, že jste museli změnit heslo nebo uživatelské jméno, které jste vytvořili. Museli byste najít všechny příručky, které obsahují tento kód.

Možnost 2 je krokem správným směrem. Při každém vytvoření serveru však vyžaduje další ruční krok. V domácí laboratoři to může stačit. Nicméně v různorodém prostředí s potenciálem, že několik lidí bude následovat stejný proces vytváření serverů, spoléhá možnost 2 na administrátora, že zdokumentuje a správně provede všechny kroky potřebné k vytvoření fungujícího serveru podle přesných specifikací.

K odstranění těchto nedostatků využívá možnost 3 vestavěné řešení Ansible. Jeho výhodou je použití snadno reprodukovatelného procesu sestavení serveru. Také při auditu procesu sestavení (jste pomocí kontroly zdroje, kterou jsme nastavili dříve, že?), může auditor potenciálně otevřít jeden soubor, aby určil, jaké soubory úloh byly automaticky použity Ansible k vytvoření sestavení serveru. Nakonec to bude nejlepší dlouhodobý přístup a je dobré naučit se používat role a zvyknout si je používat brzy a často.

Uspořádání vašich rolí pomocí správné adresářové struktury je zásadní jak pro snadnou auditovatelnost, tak pro váš vlastní úspěch. Dokumentace Ansible obsahuje některé návrhy týkající se struktury adresářů a rozložení. Preferuji rozložení adresářů podobné tomuto:

└── produkce
    ├── příručky
    └── role
        ├── běžné 
          ├─   ├─ ─ výchozí soubory 
  ├ ─ ├“ Br /> │ ││─ Manipulátory 
 │ ├├├ Úkoly 
 │ └└── Vars 
 ├├─ git_server 
 │ ││├── files files files files 
 │ ├├─ ─ obslužné osoby
        │   ├── úkoly
        │   └── vars
        ├── sledování souborů
 ── br /> ── br />> │─ br 
 ── br /> ─ ─ br /> └ ─ br /> │─ ─ │   ├── úkoly
        │   ├── šablony
        │   └── vars

Systém Ansible pro navrhování rolí může být zpočátku trochu matoucí, zejména proto, že existuje více míst, kde lze definovat proměnné. V situaci výše, V této situaci výše bych mohl vytvořit group_vars adresář v production složka takto:

└── production/
    └── group_vars/
        └── vše/
            └── vars.yaml

Umístěním proměnných do tohoto souboru je zpřístupníte jakékoli roli, která je vložena do production složka. Můžete mít vars pod každou rolí (jako je git_server ) a mít je tak k dispozici všem úkolům pro danou roli:

└── prostředí/
    └── produkce/
        └── role/
        └── git_server/
  └── var/
  └─ ─ main.yaml

Nakonec můžete zadat proměnné v samotné hře. Ty mohou být lokálně vymezeny pro konkrétní úkol nebo pro samotnou hru (takže pokrývají více úkolů ve stejné hře).

Pro rekapitulaci můžete deklarovat proměnné:

1. Na úrovni role pro všechny úkoly v dané roli
2. Na úrovni příručky pro všechny úkoly ve hře
3. Uvnitř jednotlivých úkolů
4. Uvnitř souboru Ansible hosts (také znám jako inventář); toto se používá hlavně pro strojové proměnné a v této diskuzi není zahrnuto

Rozhodování o tom, jaký rozsah vytvořit proměnné může být obtížné, zvláště když je vyváženo snadnou údržbou. Všechny své proměnné můžete umístit na globální úroveň, což usnadňuje jejich nalezení, ale nemusí to být nejlepší nápad pro velká prostředí. Opakem toho je umístit všechny proměnné do jednotlivých úkolů, ale to může být skutečným bolehlavem, pokud máte mnoho proměnných. Stojí za to zvážit kompromisy ve vaší konkrétní situaci.

Vrátíme-li se zpět k malé příručce v příkladu 1 výše, můžeme naše soubory rozdělit takto:

├── produkce
│   ├── příručky
│   └── role
│       ├── běžné soubory 
│     ─ ─       ││├─ ├├─ User1_ssh_key.pub 
 │ │ │ │└─ user user─ │ │ │ │├─ Úkoly 
 │ │ │ ├├─ create_user.yaml 
 │ │ │ ├── copy_ssh_key.yaml

Obsah tasks soubory jsou totožné s řádky v jediném, monolitickém playbooku:

Příklad 2:create_user.yaml

- jméno:vytvořte a/nebo změňte heslo uživatele {{ username}}
  user:
    jméno:"{{ username }}"
    heslo:<> 

Příklad 3:copy_ssh_key.yaml

- jméno:kopie ssh klíčů
  autorizovaný_klíč:
    klíč:"{{ item }}"
    user:"{{ username }}"
    stav:přítomný
    exkluzivní:False
  with_file:
    - user1_ssh_key.pub
    - user2_ssh_key.pub

Co se však (potenciálně) změnilo, je způsob, jakým jsou proměnné předávány do Ansible. Stále můžete používat --extra-vars volba. Pro demonstraci jiného přístupu však použijeme vars/main.yaml soubor. Soubor vars/main.yaml soubor má následující obsah:

uživatelské jméno:'git'
heslo:6$cmYTU26zdqOArk5I$WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8xyp3.EZ3.EZ3. 

 Heslo by mělo být hash, nikoli heslo s čistým textem. Chcete-li vygenerovat hash ve většině verzí Linuxu, můžete spustit následující příkaz Pythonu:
 
python2.7 -c 'import crypt,getpass; print crypt.crypt(getpass.getpass(), "$1$awerwass")' 
 

 Ve výše uvedeném příkazu je heslo salt označeno v awerwass . Jsou to jen náhodné znaky, které jsem bušil do klávesnice. NEPOUŽÍVEJTE PŘI VÝROBĚ STEJNOU SŮL. 
 

 Aby tyto úlohy běžely společně, musíte vytvořit main.yaml v tasks adresář. Měl by mít následující obsah:
 
---
- include:create_user.yaml
- include:copy_ssh_key.yaml
 

 Nakonec vytvořte playbook s následujícím obsahem:
 
- hostitelé:git
  collect_facts:false
  role:
    43- role:../roles/common
 

 Vaše adresářová struktura by měla vypadat takto:
 
├── produkce
│   ├── příručky
│   │   ├── common.yaml
│   └── běžné role
└ br /   │ │ ├── soubory 
 │ │ │ ├── user1_ssh_key.pub 
 │ │ │ └── user2_ssh_key.pub 
 │ │ ├── manipulátory 
 │ │ │ └ ── main.yaml 
 │ │ ├│├ úkoly 
 │ │ │ │├─ copy_ssh_key.yaml 
 │ │ │ │ ├├─ create_user.yaml 
 │ │ │ ├├ ─ main.yaml
│       │   └── vars
│       │       └── main.yaml
 
Nastavení role pro Promethea
 

 Nyní, když jsme probrali základy vytváření role, zaměřme se na vytvoření role Prometheus. Jak již bylo zmíněno, pro spuštění každého agenta jsou vyžadovány pouze dva soubory:soubor služby (neboli upstart) a binární soubor Prometheus. Níže jsou uvedeny příklady každého z nich:
 
Příklad 4:soubor systemd prometheus-node-exporter.service
 
[Unit]
Description=Prometheus Exporter pro strojové metriky.
After=network.target

[Service]
ExecStart=/usr/bin/prometheus_node_exporter 

[Install]
WantedBy=multi-user.target
 
Příklad 5:počáteční init soubor
 
# Spustit prometheus_node_exporter

spustit při spuštění

script
/usr/bin/prometheus_node_exporter
ukončit skript
 
Příklad 6:soubor systemd prometheus.service (serverová služba)
 
[Služba]
Uživatel=prometheus
Skupina=prometheus
ExecStart=/usr/bin/prometheus -config.file=/etc/prometheus/prometheus.yaml -storage.local. cesta=/var/lib/prometheus/data -storage.local.retention=8928h -storage.local.series-file-shrink-ratio=0,3
ExecReload=/bin/kill -HUP $MAINPID
 
[Install]
WantedBy=multi-user.target
 

 V mém prostředí se stroji Ubuntu (s a bez system ) a velké množství strojů Red Hat a Arch jsem potřeboval napsat playbook, abych distribuoval správné spouštěcí skripty do příslušných krabic. Existuje několik způsobů, jak určit, zda nasadit upstart nebo systemd soubory služeb. Ansible má vestavěný fakt nazvaný ansible_service_mgr které lze použít k vyhledání příslušného správce služeb.
 

 Rozhodl jsem se však předvést, jak pomocí skriptů poskytnout Ansible fakta během Gather Facts etapa. Toto je známé jako Ansible Local Facts. Tato fakta jsou načtena z /etc/ansible/facts.d/ adresář. Soubory v tomto adresáři mohou být JSON, INI nebo spustitelné soubory vracející JSON. Musí mít také příponu souboru .fact . Jednoduchý Bash skript, který jsem napsal, kontroluje systemd PID, a pokud je nalezen, vrátí JSON s hodnotou true , jak je vidět v příkladu 7:
 
Příklad 7:systemd_check.fact
 
#!/bin/bash
# Zkontrolujte, zda je přítomen systemd return { 'systemd':'true' } 

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

 S ohledem na to můžeme začít budovat jednoduchý úkol, který pomůže nasadit agenta Prometheus. Chcete-li toho dosáhnout, použijte místní facts musí být zkopírován na každý server, musí být nasazeny binární a spouštěcí skripty a služba musí být restartována. Níže je uveden úkol, který nasadí systemd_check.fact skript.
 
Příklad 8:copy_local_facts.yaml
 
- name:Vytvořte adresář faktů, pokud neexistuje
  soubor:
    cesta:/etc/ansible/facts.d
    stav:adresář

- name:Zkopírujte soubor systemd facts
  copy:
    src:systemd_check.fact
    dest:/etc/ansible/facts.d/systemd_check.fact
    režim:0755
 

 Nyní, když byly nasazeny naše vlastní fakta, můžeme nyní nasadit potřebné binární soubory. Nejprve se však podívejme na soubor proměnných, který bude pro tyto úkoly sloužit. V tomto příkladu jsem se rozhodl použít vars/ adresář, který je lokalizován do jednotlivé role. Aktuálně to vypadá takto:
 
Příklad 9:vars/main.yaml
 
exporter_binary:'prometheus_node_exporter'
exporter_binary_dest:'/usr/bin/prometheus_node_exporter'
exporter_service:'prometheus-node-exporter.service'
exporter'/system_dest:/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.5.168.0 ':'192.168.195.9:9100'
    'ark':'192.168.195.2:9100'
    'kids-tv':'192.168.195.213:910   '
 /910 a-centre':'192.168.195.15:9100'
    'nas':'192.168.195.195:9100'
    'nextcloud':'192.168.199.01'  '192.168.195.126:9100'
    'nuc':'192.168.195.90:9100'
    'desktop':'192.168.195.18:9100'
 

 Prozatím můžete client_information_dict ignorovat; které vstoupí do hry později.
 
Příklad 10:tasks/setup_prometheus_node.yaml
 
---
- name:zkopírujte binární soubor do {{ exporter_binary_dest }}
  copy:
    src:"{{ exporter_binary }}"
    dest:"{{ exporter_binary_dest }}"
    režim:0755

- název:vložte soubor služby systemd na místo
  kopie:
    src:"{{ exporter_service }"
    cíl:"{{ exporter_service_dest }}"
  when:
    - ansible_local.systemd_check.systemd =='true'

- name:zkopírujte konfigurační soubor pro začátek do {{ exporter_upstart_dest }}
  copy:
    src:"{{ exporter_upstart }}"
    dest:"{{ exporter_upstart_dest }}"
  when:
    - ansible_local.systemd_check.systemd =='false'

- name:update systemd a restart exporter systemd
  systemd:
    daemon-reload:true
    enabled:true
    stav:restartováno
    name:"{{ exporter_service }}"
  když:
    - ansible_local.systemd_check.systemd =='true'
   
- name:start exporter sysv service 
  služba:
    název:"{{ exp orter_service }}"
    povoleno:true
    stav:restartováno
  když: 
    - ansible_local.systemd_check.systemd =='false'
 

 Nejdůležitější věcí, kterou je třeba poznamenat ve výše uvedené úloze, je, že odkazuje na ansible_local.systemd_check.systemd . To se dělí na následující konvenci pojmenování <how Ansible generates the fact> . <the name of the fact file> . <the key inside the fact to retrieve> . Bash skript systemd_check.fact se spouští během Gather Facts fázi a poté uloženy do ansible_local části všech Gather Facts . Abych se mohl rozhodnout na základě této skutečnosti, zkontroluji, zda je true nebo false . Klauzule Ansible When říká Ansible, aby provedla tento konkrétní úkol, pouze pokud jsou splněny určité podmínky. Zbytek tohoto úkolu by měl být poměrně jednoduchý. Používá moduly systemd i servisní moduly, aby zajistil, že příslušný správce služeb je nakonfigurován pro spuštění prometheus_node_exporter .
 

 Úkol pro nastavení serveru je velmi podobný:
 
Příklad 11:tasks/setup_Prometheus_server.yaml
 
---
- name:zkopírujte binární soubor serveru do {{ server_binary_dest }}
  copy:
    src:"{{ server_binary }}"
    dest:"{ { server_binary_dest }}"
    režim:0755
  when:
    - inventar_hostname ='prometheus'

- name:Ujistěte se, že /etc/prometheus existuje
 soubor:
    stav:adresář
    cesta:/etc/prometheus
    vlastník:"{{ prometheus_user }}"
    skupina:"{{ prometheus_user }}"
    režim :0755
  when:
    - inventar_hostname ='prometheus'

- name:place prometheus config
  template:
    src:prometheus.yaml.j2
    dest:/etc/prometheus/prometheus.yaml
  when:
    - inventar_hostname ='prometheus'

- name:create /var/lib/promtheus/data
  soubor:
    stav:adresář
    cesta:/var/lib/prometheus/data
    recurse:true
    vlastník:"{{ prometheus_user }"
 skupina:"{{ prometheus_user }}"
    režim:0755
  když:
    - v ventory_hostname ='prometheus'

- název:vložte soubor služby systemd na místo
  kopie:
    src:"{{ server_service }}"
    cíl:"{{ server_service_dest }}"
  když:
    - ansible_local.systemd_check.systemd =='true'
    - inventář_hostname ='prometheus'

- název:aktualizujte systemd a restartujte prometheus server systemd
  systemd:
    daemon-reload:true
    enabled:true
    stav:restartováno
    název:"{{ server_service }"
  kdy :
    - ansible_local.systemd_check.systemd =='true'
    - inventar_hostname ='prometheus'

  notify:restart_prometheus_server
 

 Bystrý pozorovatel si v úloze serveru všimne několika nových věcí.
 
 
notify: sekce
 
template: modul
 
 

 notify sekce je způsob, jak spustit konkrétní typy událostí, když jsou splněna určitá kritéria. Ansible Handlers se nejčastěji používají ke spuštění restartování služby (což je přesně to, co se děje výše). Handlery jsou uloženy v handlers adresář v rámci role. Můj ovladač je velmi jednoduchý:
 
Příklad 12:handler/main.yaml
 
- název:restart_iptables
  služba:
    název:iptables
    stav:restartováno
    povoleno:true

- název:restart_prometheus_server
 služba:
    název:"{{ server_service }}"
    stav:restartováno
    povoleno:true
 

 To mi jednoduše umožňuje restartovat prometheus.service na serveru Prometheus.
 

 Druhý bod zájmu v setup_prometheus_server.yaml je template: sekce. Šablony v Ansible nabízí některé velmi pěkné výhody. Ansible používá Jinja2 pro svůj šablonovací engine; avšak úplné vysvětlení Jinja je mimo rozsah tohoto návodu. V podstatě můžete použít šablonu Jinja2, abyste měli jeden konfigurační soubor s proměnnými, jejichž hodnoty se vypočítávají a nahrazují během hry Ansible. Šablona konfigurace Prometheus vypadá takto:
 
Příklad 13:templates/prometheus.yaml.j2
 
global:
  scrape_interval:    15s # Nastavte interval škrábání na každých 15 sekund. Výchozí hodnota je každou 1 minutu.
  evaluation_interval:15s # Vyhodnoťte pravidla každých 15 sekund. Výchozí nastavení je každou 1 minutu.

  external_labels:
      monitor:'codelab-monitor'

scrape_configs:
  # Název úlohy je přidán jako label `job=` do všech časových řad získaných z této konfigurace.
  - job_name:'prometheus'

    static_configs:
      - cíle:['localhost:9090'] 
  - job_name:'nodes'
    static_configs:
{% pro název hostitele, ip v client_information_dict.iteritems() %}
      - cíle:['{{ ip }}'] 
        labels:{'host':'{{ hostname }}' }
{% endfor %}
 

 Když je zpracována sekce šablony, .j2 přípona je automaticky odstraněna před umístěním souboru na vzdálený systém. Malá smyčka for-loop v šabloně iteruje přes client_information_dict , který jsem dříve definoval v mém souboru proměnných. Jednoduše vytvoří seznam virtuálních strojů, na kterých má Prometheus shromažďovat metriky.
 

 Poznámka:Pokud chcete, aby Prometheus zobrazoval názvy hostitelů a váš DNS je správně nastaven, použijte místo toho toto:
 
{% for hostname, ip in client_information_dict.iteritems() %}
      - targets:['{{ hostname }}:9100']
        labels:{'host':'{{ hostname }}' 
{% endfor %}
 

 K dokončení nastavení Promethea zbývá jen několik dokončovacích úprav. Potřebujeme vytvořit prometheus uživatel, (potenciálně) upravit iptables, spojit to všechno dohromady v main.yaml a vytvořte playbook ke spuštění.
 

 Nastavení Prometheus uživatel je poměrně přímočarý a bude to velmi známé, pokud budete postupovat podle mých předchozích článků Ansible:
 
Příklad 14:tasks/create_prometheus_user.yaml
 
---
- name:Ujistěte se, že uživatel prometheus existuje
  user:
    name:"{{ prometheus_user }}"
    shell:/bin/false 

 Jediný hlavní rozdíl je v tom, že nastavuji shell na /bin/false takže uživatel může spouštět služby, ale nemusí se přihlašovat.
 

 Pokud používáte iptables, budete se muset ujistit, že máte otevřený port 9100, aby mohl Prometheus získávat metriky od svých klientů. Zde je jednoduchý úkol:
 
Příklad 15:task/iptables.yaml
 
---
- název:Otevřený port 9100
  lineinfile:
    cíl:/etc/sysconfig/iptables
    insertbefore:"-A INPUT -j OS_FIREWALL_ALLOW"
    řádek:"-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT"
  upozornit:restart_iptables
  když:
    - ansible_os_family =="RedHat" 
 

 Poznámka:iptables spouštím pouze na své rodině virtuálních počítačů Red Hat. Pokud na všech svých virtuálních počítačích spouštíte iptables, odeberte when: sekce.
 

 Soubor main.yaml vypadá takto:
 
Příklad 16:task/main.yaml
 
--- 
- include:create_prometheus_user.yaml
- include:setup_prometheus_node.yaml
- include:setup_prometheus_server.yaml
- include:prometheus_iptables.yaml
 

 Posledním dílem je vytvořit herní příručku, která bude obsahovat role, které potřebujete k dokončení svého úkolu:
 
Příklad 17:playbooks/monitoring.yaml
 
- hostitelé:všichni
  role:
    - role:../roles/common
    - role:../roles/monitoring
 
Spojení všech dohromady
 

 Vím, že to vypadá, že je potřeba projít hodně textu, ale koncepty pro použití Ansible jsou poměrně přímočaré. Obvykle jde jen o to vědět, jak splnit úkol, který jste si stanovili, a pak najít vhodné moduly Ansible, které vám je pomohou splnit. Pokud jste postupovali podle tohoto návodu celou cestu, měli byste mít rozložení podobné tomuto:
 
├── příručky
│   ├── git_server.yaml
│   ├── monitoring.yaml
└── role
    │ ──> běžné ├├─ Soubory 
 │ │ ├├├─ SystemD_Check.Fact 
 │ │ │ ├├─ user_ssh_key.pub 
 │ │ │ └└── user user_ssh_key.pub 
 │ ├ ├├─ Handlers 
 │ │ │ └└─ MAIN.YAML 
 │ ├├─ úkoly 
 │ │ ││├─ copy_systemd_facts.yaml 
 │ │ ││├─ main.yaml 
 │ │ ├── push_ssh_key.yaml
    │   │   ├── root_ssh_key_only.yaml
    │    └── └── br
─ br
─ br
─ br
─ br
─ br
─ br
─ br
─ br
└  br
─ br
─ br
 │ │ ├├├ Prometheus 
 │ │ │ ├├─ Prometheus_node_Exporter 
 │ │ │ ├├─ Prometheus-uzel-exporter.conf 
 │ │ ├├─ prometheus-node-exporter.service
    │   │   ├── prometheus.service
    │   │   └── systemd_check.fact
   └── systemd_check.fact 
   └/─  .yaml
    │   ├── úkoly
    │   │   ├── create_prometheus_user.yaml
    │   │   ├ hlavní />    │   │   └── prometheus.yaml.j2
        └── vars
            └── main.yaml
 

 Chcete-li spustit svou příručku, zadejte:
 
[root@ansible-host production]# ansible-playbook -i <path to host file> playbooks/monitoring.yaml 
 
 

 Nyní byste měli být schopni vytvářet uživatele, tlačit ssh-keys, kontrolovat existenci systemd a nasaďte buď prometheus_node_exporter nebo binární soubor serveru Prometheus na příslušné servery. Prometheus by se měl inicializovat se základní konfigurací včetně seznamu hostitelů, kteří byli specifikováni v vars/main. yaml soubor v roli sledování.
 

 Gratulujeme! Nyní jste zautomatizovali instalaci a konfiguraci základního serveru Prometheus a nakonfigurovali své hostitele tak, aby začali přenášet data. Jako příjemný vedlejší efekt jste také efektivně zdokumentovali všechny kroky potřebné k dosažení vašich cílů.
  

 Dodatek:Když jsem koncipoval tuto sérii, chystal jsem se nainstalovat Prometheus do OpenShift; při kontrole dokumentace k instalačnímu programu Ansible pro OpenShift jsem však zjistil, že je již obsažen v playbooku a je volitelnou možností v instalačním programu.