Ansible ziņo, ka palaists, bet WireGuard joprojām darbojas ar veco konfigurāciju

state: started atstāj jau strādājošu unit mierā, tāpēc pārrakstītais wg0.conf nekad netiek piemērots. Pievienojiet izmaiņu handler un pēc tam salīdziniet aktīvo ierīci ar failu.

Playbook izpilde beidzas zaļā krāsā, WireGuard unit ir aktīvs, handshake darbojas, un jaunais peer tomēr nekur nenonāk. Redzēt playbook ziņojam par panākumiem, kamēr serveris darbojas ar vakardienas konfigurāciju, ir īpaši kaitinoši, jo izvadē nekas nav nepareizi. Ansible izdarīja tieši to, ko lūdza: pārliecinājās, ka unit ir palaists, un tas jau bija palaists. Pārrakstīta konfigurācijas faila piemērošana ir cits uzdevums, un tas notiek tikai tad, ja kaut kas pasaka servisam to pārlasīt.

Paskatieties, ko otrā izpilde patiešām ziņo

Palaidiet playbook divas reizes ar mainīto konfigurāciju un salīdziniet kopsavilkumu. Otrajā izpildē unit uzdevums jāparāda kā ok, nevis changed, jo jau strādājošs serviss pēc projekta tiek atstāts mierā. Tas ir pareizi strādājošs idempotentums, un tas ir arī iemesls, kāpēc jaunais fails nekad nenonāk līdz kernel.

Pievienojiet pārbaudes izpildi ar diff izvadi, lai redzētu, kuri uzdevumi vispār kaut ko aiztiktu.

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

Trīs laika zīmes izstāsta stāstu pirms vienas log rindas izlasīšanas. Ja konfigurācijas fails ir jaunāks par brīdi, kad unit kļuva aktīvs, strādājošā saskarne tika veidota no vecāka faila, un visas turpmākās pazīmes izriet no tā.

Tas nav Ansible defekts. Tāda pati uzvedība parādās jebkurā konfigurācijas pārvaldības rīkā, kas atdala «pārliecinies, ka tas darbojas» no «pārliecinies, ka tas darbojas tieši šādi». Atšķirība šķiet pedantiska, līdz tā izmaksā pēcpusdienu.

Palaists ir stāvoklis, nevis pārlāde

state: started apgalvo nosacījumu par unit. Tas nesola, ka serviss pārlasīs savus ievades datus, un nevar zināt, ka fails, ko tas nekad nav atvēris, ir mainījies. wg-quick izvietojumā ievades ietver saskarnes konfigurāciju, adreses, maršrutus, DNS ierakstus un jebkurus post-up hook.

Tāpēc atjauninātā failā var būt jauns peer, cita adrese vai mainīta maršrutēšanas direktīva, kamēr strādājošā saskarne turpina apkalpot veco kopu. Handshake joprojām izdodas, jo ielādētās atslēgas un galapunkti vēl ir derīgi. Tieši tas padara kļūmi grūti pamanāmu, un tāpēc cilvēki stundu dzenas pakaļ DNS pirms laika zīmes pārbaudes.

Divas citas moduļa opcijas bieži tiek uzskatītas par risinājumu. daemon_reload liek systemd pārlasīt unit failus, kas WireGuard konfigurācijas failam nav svarīgi. state: reloaded lūdz unit izpildīt tā pārlādes darbību, un vai tā dara to, kas jums vajadzīgs, pilnībā atkarīgs no unit. Neviena neaizstāj zināšanu, kādus ievades datus strādājošais process faktiski nolasīja.

Instalējiet failu, pēc tam paziņojiet handler

Modelis, kas saglabā idempotentumu un tomēr piemēro izmaiņas, ir parastais: uzdevums, kas raksta failu, paziņo handler, un handler darbojas tikai tad, kad fails patiešām ir mainījies. Otra izpilde bez labojumiem neko nedara, un tas ir tas, ko vēlaties.

- 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

Handler darbojas play beigās, pēc uzdevumiem, kas tos paziņoja, tāpēc vēlāks uzdevums tajā pašā play vēl var redzēt veco saskarni. Ja secība ir svarīga, skaidri iztukšojiet handler ar meta: flush_handlers pirms uzdevuma, kas ir atkarīgs no jaunās konfigurācijas.

Izmantojiet restart, nevis reload, ja vien neesat pārbaudījis unit pārlādes darbību. Upstream wg-quick unit to atbalsta un sinhronizē WireGuard konfigurāciju, bet tas atkārtoti neizpilda adrešu, maršrutu, DNS vai hook iestatīšanu. Tāpēc reload pēc maršruta direktīvas pievienošanas šķiet sekmīgs un neko nemaina.

Salīdziniet aktīvo ierīci ar failu

Pārbaude, kas aizver šo kļūdu klasi, ir salīdzinājums starp to, ko tur kernel, un to, ko saka fails. Divas komandas dod salīdzināmu izvadi, un atšķirība ir novirze.

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

wg showconf izdrukā aktīvo ierīci, tostarp privāto atslēgu, tāpēc uzskatiet šo izvadi par noslēpumu un neielīmējiet to biļetē. wg-quick strip izdrukā failu bez wg-quick raksturīgajām atslēgām, un tāpēc abus var salīdzināt.

Atšķirība peer sarakstā nozīmē, ka fails nekad nav ticis piemērots. Atšķirība tikai atslēgās vai galapunktos, kurus gaidījāt maināmies, nozīmē, ka kaut kas to ir piemērojis daļēji. Ja atšķirības nav vispār, konfigurācija ir aktuāla un kļūme ir citur, kas pats par sevi ir noderīgs rezultāts.

Samaksājiet restart izmaksu apzināti

Saskarnes restart pārtrauc tuneli, un, ja šis tunelis pārvadā jūsu administratīvo sesiju, restart beidz sesiju, kas to pieprasīja. Novietojiet handler aiz izmaiņu loga vai palaidiet playbook no pārvaldības ceļa, kas nav atkarīgs no saskarnes restarta.

Izmaksas ir iemesls, kāpēc cilvēki ķeras pie reload. Tas ir saprātīgs instinkts, un tas kļūst pareizs, kad zināt, kādas izmaiņas reload faktiski piemēro. Upstream wg-quick unit peer un atslēgu izmaiņām ar to pietiek; adresēšanai, maršrutēšanai un hook nepietiek. Vienreiz to noskaidrot ir lētāk nekā atklāt izmaiņu loga laikā.

systemd_service moduļa dokumentācija izskaidro atšķirību starp started, restarted un reloaded, un to ir vērts vienreiz izlasīt, nevis minēt no zaļa kopsavilkuma. Viss šajā ceļvedī izriet no šīs vienas atšķirības.

Saistītie raksti