Az Ansible azt mondja, elindult, a WireGuard mégis a régi konfigurációval fut

A playbook futása zölden ér véget, a WireGuard unit aktív, a handshake működik, az új peer mégsem ér el semmit. Különösen frusztráló playbookot sikerjelentéssel látni, miközben a szerver a tegnapi konfigurációval fut, mert a kimenetben semmi sem hibás. Az Ansible pontosan azt tette, amire kérték: biztosította, hogy a unit elinduljon, és már el is indult. Az újraírt konfigurációs fájl alkalmazása más feladat, és csak akkor történik meg, ha valami szól a szolgáltatásnak, hogy olvassa újra.

Nézze meg, mit jelent valójában egy második futás

Futtassa a playbookot kétszer a módosított konfigurációval, és hasonlítsa össze az összefoglalót. A második futásnak a unit feladatát ok-ként kell mutatnia, nem changed-ként, mert a már futó szolgáltatást a tervezés szerint békén hagyja. Ez az idempotencia helyes működése, és ez az oka annak is, hogy az új fájl soha nem ér el a kernelig.

Adjon hozzá egy diff-kimenetű ellenőrző futást, hogy lássa, mely feladatok érintenének egyáltalán valamit.

ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.conf

A három időbélyeg elmondja a történetet, mielőtt egyetlen naplósort olvasna. Ha a konfigurációs fájl újabb, mint az a pillanat, amikor a unit aktívvá vált, a futó interfész egy régebbi fájlból épült fel, és minden további tünet ebből következik.

Ez nem az Ansible hibája. Ugyanez a viselkedés jelenik meg minden olyan konfigurációkezelő eszköznél, amely elválasztja a »győződj meg róla, hogy fut« és a »győződj meg róla, hogy ezt futtatja« kérdését. A különbség pedánsnak tűnik, amíg egy délutánba nem kerül.

Az elindult egy állapot, nem újratöltés

state: started egy feltételt állít a unitról. Nem ígéri, hogy a szolgáltatás újraolvassa a bemeneteit, és nem tudhatja, hogy egy fájl, amelyet soha nem nyitott meg, megváltozott. Egy wg-quick telepítésnél a bemenetek közé tartozik az interfész konfigurációja, a címek, az útvonalak, a DNS-bejegyzések és az esetleges post-up hookok.

Ezért egy frissített fájl tartalmazhat új peert, más címet vagy módosított útvonal-irányelvet, miközben az élő interfész továbbra is a régi készletet szolgálja ki. A handshake továbbra is sikerül, mert a betöltött kulcsok és végpontok még érvényesek. Pont ez teszi nehezen láthatóvá a hibát, és ezért kergetik az emberek egy órán át a DNS-t, mielőtt ellenőriznének egy időbélyeget.

Két másik modulbeállítást gyakran megoldásnak gondolnak. A daemon_reload újraolvastatja a systemddel a unit fájlokat, ami egy WireGuard konfigurációs fájl szempontjából irreleváns. A state: reloaded arra kéri a unitot, hogy futtassa a reload műveletét, és hogy ez megteszi-e, amire szüksége van, teljesen a unittól függ. Egyik sem helyettesíti annak ismeretét, hogy a futó folyamat valójában mely bemeneteket olvasta.

Telepítse a fájlt, majd értesítsen egy handlert

Az a minta, amely megőrzi az idempotenciát és mégis alkalmazza a változásokat, a szokásos: a fájlt író feladat értesít egy handlert, és a handler csak akkor fut, ha a fájl valóban megváltozott. Egy szerkesztés nélküli második futás semmit nem tesz, és ezt akarja.

- name: write the interface configuration
  ansible.builtin.template:
    src: wg0.conf.j2
    dest: /etc/wireguard/wg0.conf
    owner: root
    mode: "0600"
  notify: apply wg0

- name: ensure the interface unit is enabled
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    enabled: true
    state: started

- name: apply wg0
  listen: apply wg0
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    state: restarted

A handlerek a play végén futnak, az őket értesítő feladatok után, így egy későbbi feladat ugyanabban a playben még a régi interfészt láthatja. Ha a sorrend számít, ürítse ki a handlereket kifejezetten a meta: flush_handlers használatával az új konfigurációtól függő feladat előtt.

Használjon restartot reload helyett, hacsak nem ellenőrizte a unit reload műveletét. Az upstream wg-quick unit támogat egyet, és szinkronizálja a WireGuard konfigurációt, de nem futtatja újra a címek, útvonalak, DNS vagy hookok beállítását. Ezért egy útvonal-irányelv hozzáadása utáni reload sikeresnek tűnik, és semmit nem változtat.

Hasonlítsa össze az élő eszközt a fájllal

Az ezt a hibacsoportot lezáró ellenőrzés a kernelben lévő és a fájlban állított állapot összehasonlítása. Két parancs összehasonlítható kimenetet ad, és a különbség az eltérés.

sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)

A wg showconf kinyomtatja az élő eszközt, beleértve a privát kulcsot, ezért kezelje ezt a kimenetet titokként, és ne illessze be jegybe. A wg-quick strip a fájlt a wg-quick-specifikus kulcsok nélkül nyomtatja ki, és ezért hasonlítható össze a kettő egyáltalán.

A peerlistán látható eltérés azt jelenti, hogy a fájlt soha nem alkalmazták. Ha az eltérés csak azokra a kulcsokra vagy végpontokra korlátozódik, amelyekről tudta, hogy változni fognak, akkor valami részben alkalmazta. Ha nincs eltérés, a konfiguráció naprakész, és a hiba máshol van, ami önmagában is hasznos eredmény.

Fizesse meg az újraindítás árát tudatosan

Az interfész újraindítása eldobja az alagutat, és ha az az alagút a rendszergazdai munkamenetét szállítja, az újraindítás véget vet a munkamenetnek, amely kérte. Tegye a handlert egy változási ablak mögé, vagy futtassa a playbookot olyan kezelési útvonalról, amely nem függ az interfész újraindításától.

Az ár az oka, amiért az emberek a reloadhoz nyúlnak. Ez ésszerű ösztön, és akkor válik helyessé, ha tudja, milyen változásokat alkalmaz valójában a reload. Az upstream wg-quick uniton peer- és kulcsváltozásokhoz elég; a címzéshez, az útvonalválasztáshoz és a hookokhoz nem. Egyszer tisztázni olcsóbb, mint egy változási ablak közben felfedezni.

A systemd_service modul dokumentációja elmagyarázza a különbséget a started, a restarted és a reloaded között, és érdemes egyszer elolvasni ahelyett, hogy egy zöld összefoglalóból következtetnénk. Ebben az útmutatóban minden ebből az egy különbségből következik.