Ansible javlja da je pokrenuto, a WireGuard i dalje radi po staroj konfiguraciji
state: started ne dira jedinicu koja već radi, pa se prepisani wg0.conf nikada ne primijeni. Dodajte handler za promjenu, zatim uporedite živi uređaj sa datotekom.
Playbook završi zeleno, WireGuard jedinica je aktivna, handshake radi, a novi peer ipak ne stiže nigdje. Gledati kako playbook javlja uspjeh dok server radi po jučerašnjoj konfiguraciji posebno je iritantno, jer u izlazu ništa nije pogrešno. Ansible je uradio tačno ono što je traženo: pobrinuo se da jedinica bude pokrenuta, a ona je već bila pokrenuta. Primjena prepisane konfiguracijske datoteke je drugi zadatak i dogodi se samo ako nešto kaže servisu da je ponovo pročita.
Pogledajte šta drugo pokretanje zaista javlja
Pokrenite playbook dvaput s izmijenjenom konfiguracijom na mjestu i uporedite sažetak. Drugo pokretanje treba prikazati zadatak jedinice kao ok, a ne changed, jer se servis koji već radi po dizajnu ostavlja na miru. To je ispravan rad idempotentnosti i ujedno razlog zašto nova datoteka nikada ne stigne do kernela.
Dodajte probno pokretanje s diff izlazom da vidite koji bi zadaci uopće nešto dotakli.
ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.confTri vremenske oznake ispričaju priču prije nego pročitate i jedan red loga. Ako je konfiguracijska datoteka novija od trenutka kada je jedinica postala aktivna, živi interfejs je izgrađen iz starije datoteke i svaki simptom dalje proizlazi iz toga.
To nije greška u Ansibleu. Isto ponašanje javlja se kod svakog alata za upravljanje konfiguracijom koji razdvaja „provjeri da radi“ od „provjeri da radi ovo“. Razlika izgleda pedantno dok vas ne košta jednog popodneva.
Pokrenuto je stanje, a ne ponovno učitavanje
state: started tvrdi uslov o jedinici. Ne obećava da će servis ponovo pročitati svoje ulaze i ne može znati da se datoteka koju nikad nije otvorio promijenila. Kod wg-quick postavljanja ulazi uključuju konfiguraciju interfejsa, adrese, rute, DNS unose i sve post-up kuke.
Zato ažurirana datoteka može sadržavati novi peer, drugu adresu ili izmijenjenu rutnu direktivu, dok živi interfejs nastavlja posluživati stari skup. Handshake i dalje uspijeva jer su učitani ključevi i krajnje točke još valjani. Upravo to čini kvar teško vidljivim i objašnjava zašto ljudi sat vremena jure DNS prije nego provjere vremensku oznaku.
Dvije druge opcije modula često se smatraju rješenjem. daemon_reload tjera systemd da ponovo pročita datoteke jedinica, što je nebitno za WireGuard konfiguraciju. state: reloaded traži da jedinica izvrši svoju radnju ponovnog učitavanja, a da li ona radi što vam treba zavisi isključivo od jedinice. Nijedna nije zamjena za znanje koje je ulaze pokrenuti proces stvarno pročitao.
Instalirajte datoteku, pa obavijestite handler
Obrazac koji čuva idempotentnost i ipak primjenjuje promjene je uobičajen: zadatak koji piše datoteku obavještava handler, a handler se izvršava samo kad se datoteka stvarno promijenila. Drugo pokretanje bez izmjena ne radi ništa i to je ono što ž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: restartedHandleri se izvršavaju na kraju predstave, nakon zadataka koji su ih obavijestili, pa zadatak kasnije u istoj predstavi može još vidjeti stari interfejs. Ako je redoslijed važan, eksplicitno ispraznite handlere pomoću meta: flush_handlers prije zadatka koji zavisi od nove konfiguracije.
Koristite restart, a ne reload, osim ako niste provjerili radnju ponovnog učitavanja jedinice. Nadređena wg-quick jedinica je podržava i sinkronizira WireGuard konfiguraciju, ali ne ponavlja postavljanje adresa, ruta, DNS-a ni kuka. Zato reload nakon dodavanja rutne direktive izgleda uspješno i ništa ne mijenja.
Uporedite živi uređaj s datotekom
Provjera koja zatvara ovu vrstu greške je poređenje onoga što drži kernel s onim što piše u datoteci. Dvije naredbe daju uporediv izlaz, a razlika je odstupanje.
sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)wg showconf ispisuje živi uređaj, uključujući privatni ključ, pa taj izlaz tretirajte kao tajnu i ne lijepite ga u tiket. wg-quick strip ispisuje datoteku bez ključeva svojstvenih wg-quicku, i zato su ta dva izlaza uopće uporediva.
Razlika na listi peerova znači da datoteka nikada nije primijenjena. Razlika samo u ključevima ili krajnjim točkama koje ste očekivali da se promijene znači da ju je nešto primijenilo djelimično. Nikakva razlika znači da je konfiguracija aktualna, a kvar je negdje drugdje, što je samo po sebi koristan rezultat.
Platite cijenu restarta svjesno
Restart interfejsa ruši tunel, a ako taj tunel nosi vašu administrativnu sesiju, restart prekida sesiju koja ga je zatražila. Stavite handler iza prozora za promjene ili pokrenite playbook s putanje upravljanja koja ne zavisi od restarta interfejsa.
Cijena je razlog zašto ljudi posežu za reloadom. To je razuman nagon i postaje ispravan kad znate koje promjene reload stvarno primjenjuje. Za promjene peera i ključeva na nadređenoj wg-quick jedinici dovoljan je; za adresiranje, rutiranje i kuke nije. Jednom to raščistiti jeftinije je nego otkriti tokom prozora za promjene.
Dokumentacija modula systemd_service objašnjava razliku između started, restarted i reloaded i vrijedi je jednom pročitati umjesto nagađanja iz zelenog sažetka. Sve u ovom vodiču proizlazi iz te jedne razlike.