Ansible pravi, da je zagnano, a WireGuard še vedno teče s staro konfiguracijo

state: started pusti že delujočo enoto pri miru, zato se prepisan wg0.conf nikoli ne uporabi. Dodajte handler spremembe in nato primerjajte živo napravo z datoteko.

Izvajanje playbooka se konča zeleno, enota WireGuard je aktivna, handshake deluje, novi peer pa vseeno ne doseže ničesar. Gledati playbook, ki poroča o uspehu, medtem ko strežnik teče s včerajšnjo konfiguracijo, je posebej frustrirajoče, ker v izpisu ni nič narobe. Ansible je naredil točno to, kar je bilo zahtevano: poskrbel je, da je enota zagnana, in enota je bila že zagnana. Uporaba prepisane konfiguracijske datoteke je druga naloga in se zgodi le, če nekaj storitvi reče, naj jo znova prebere.

Poglejte, kaj drugo izvajanje v resnici poroča

Zaženite playbook dvakrat s spremenjeno konfiguracijo in primerjajte povzetek. Drugo izvajanje mora nalogo enote prikazati kot ok, ne kot changed, ker se že delujoča storitev po zasnovi pusti pri miru. To je idempotentnost, ki deluje pravilno, in obenem razlog, da nova datoteka nikoli ne pride v jedro.

Dodajte preizkusno izvajanje z izpisom diff, da vidite, katere naloge bi se sploh česa dotaknile.

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

Trije časovni žigi povedo zgodbo, preden preberete eno samo vrstico dnevnika. Če je konfiguracijska datoteka novejša od trenutka, ko je enota postala aktivna, je bilo delujoče vmesnik zgrajeno iz starejše datoteke in vsi nadaljnji simptomi izhajajo iz tega.

To ni napaka v Ansibleu. Enako vedenje se pojavi pri vsakem orodju za upravljanje konfiguracije, ki ločuje »poskrbi, da deluje« od »poskrbi, da deluje točno to«. Razlika se zdi pedantna, dokler vas ne stane popoldneva.

Zagnano je stanje, ne ponovno nalaganje

state: started trdi pogoj o enoti. Ne obljublja, da bo storitev znova prebrala svoje vhode, in ne more vedeti, da se je datoteka, ki je nikoli ni odprla, spremenila. Pri namestitvi wg-quick vhodi vključujejo konfiguracijo vmesnika, naslove, poti, zapise DNS in vse post-up kavlje.

Zato lahko posodobljena datoteka vsebuje nov peer, drug naslov ali spremenjeno usmerjevalno direktivo, medtem ko živi vmesnik še naprej streže stari nabor. Handshake še vedno uspe, ker so naloženi ključi in končne točke še veljavni. Prav to naredi napako težko vidno in zato ljudje eno uro lovijo DNS, preden preverijo časovni žig.

Dve drugi možnosti modula se pogosto razumeta kot rešitev. daemon_reload prisili systemd, da znova prebere datoteke enot, kar za konfiguracijsko datoteko WireGuard ni pomembno. state: reloaded od enote zahteva, da izvede svoje dejanje ponovnega nalaganja, in ali to naredi, kar potrebujete, je popolnoma odvisno od enote. Nobena ne nadomesti vedenja, katere vhode je delujoč proces dejansko prebral.

Namestite datoteko, nato obvestite handler

Vzorec, ki ohrani idempotentnost in vseeno uveljavi spremembe, je običajen: naloga, ki piše datoteko, obvesti handler, in handler se izvede le, ko se datoteka res spremeni. Drugo izvajanje brez urejanja ne naredi ničesar, in to je tisto, kar želite.

- 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

Handlerji se izvedejo na koncu playa, po nalogah, ki so jih obvestile, zato lahko poznejša naloga v istem playu še vidi stari vmesnik. Če je vrstni red pomemben, handlerje izrecno izpraznite z meta: flush_handlers pred nalogo, ki je odvisna od nove konfiguracije.

Uporabite restart namesto reloada, razen če ste preverili dejanje ponovnega nalaganja enote. Nadrejena enota wg-quick ga podpira in sinhronizira konfiguracijo WireGuarda, vendar znova ne izvede nastavitve naslovov, poti, DNS ali kavljev. Zato reload po dodajanju usmerjevalne direktive izgleda uspešno in ničesar ne spremeni.

Primerjajte živo napravo z datoteko

Preverjanje, ki zapre ta razred napak, je primerjava med tem, kar drži jedro, in tem, kar pravi datoteka. Dva ukaza dajeta primerljiv izpis, razlika pa je odstopanje.

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

wg showconf izpiše živo napravo, vključno z zasebnim ključem, zato ta izpis obravnavajte kot skrivnost in ga ne lepite v zahtevek. wg-quick strip izpiše datoteko brez ključev, značilnih za wg-quick, in zato sta oba izpisa sploh primerljiva.

Razlika na seznamu peerv pomeni, da datoteka ni bila nikoli uporabljena. Razlika le v ključih ali končnih točkah, za katere ste pričakovali, da se bodo spremenile, pomeni, da jo je nekaj uporabilo delno. Brez razlike pomeni, da je konfiguracija aktualna in je napaka drugje, kar je samo po sebi koristen rezultat.

Plačajte ceno ponovnega zagona zavestno

Ponovni zagon vmesnika prekine tunel, in če ta tunel prenaša vašo skrbniško sejo, ponovni zagon konča sejo, ki ga je zahtevala. Handler postavite za okno sprememb ali zaženite playbook z upravljalne poti, ki ni odvisna od ponovnega zagona vmesnika.

Cena je razlog, da ljudje posežejo po reloadu. To je razumen instinkt in postane pravilen, ko veste, katere spremembe reload dejansko uveljavi. Pri spremembah peerv in ključev na nadrejeni enoti wg-quick zadošča; pri naslavljanju, usmerjanju in kavljev ne. Enkrat to razčistiti je ceneje kot odkriti med oknom sprememb.

Dokumentacija modula systemd_service pojasnjuje razliko med started, restarted in reloaded in vredno jo je enkrat prebrati, namesto ugibati iz zelenega povzetka. Vse v tem vodiču izhaja iz te ene razlike.

Sorodni članki