Ansible thotë u nis, por WireGuard ende punon me konfigurimin e vjetër

Ekzekutimi i playbook përfundon gjelbër, unit-i i WireGuard është aktiv, handshake funksionon, dhe peer-i i ri përsëri nuk arrin asgjë. Të shohësh një playbook që raporton sukses ndërsa serveri punon me konfigurimin e djeshëm është veçanërisht frustrations, sepse asgjë në dalje nuk është e gabuar. Ansible bëri pikërisht atë që iu kërkua: u sigurua që unit-i të ishte nisur, dhe unit-i ishte tashmë i nisur. Zbatimi i një skedari konfigurimi të rishkruar është detyrë tjetër dhe ndodh vetëm nëse diçka i thotë shërbimit ta rilexojë atë.

Shiko çfarë raporton vërtet ekzekutimi i dytë

Ekzekuto playbook dy herë me konfigurimin e ndryshuar dhe krahaso përmbledhjen. Ekzekutimi i dytë duhet ta shfaqë detyrën e unit-it si ok, jo si changed, sepse një shërbim që tashmë punon lihet i qetë sipas projektimit. Kjo është idempotenca që punon saktë, dhe është gjithashtu arsyeja pse skedari i ri nuk arrin kurrë në kernel.

Shto një ekzekutim kontrolli me dalje diff për të parë cilat detyra do të preknin ndonjë gjë.

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

Tre vulat kohore e tregojnë historinë përpara se të lexosh një rresht log. Nëse skedari i konfigurimit është më i ri se momenti kur unit-i u bë aktiv, ndërfaqja që punon është ndërtuar nga një skedar më i vjetër, dhe çdo simptomë pasuese rrjedh prej andej.

Ky nuk është defekt i Ansible. E njëjta sjellje shfaqet në çdo mjet të menaxhimit të konfigurimit që ndan «sigurohu që punon» nga «sigurohu që punon pikërisht këtë». Diferenca duket pedante derisa të kushtojë një pasdite.

I nisur është një gjendje, jo një rimbushje

state: started pohon një kusht për unit-in. Nuk premton që shërbimi do t'i rilexojë hyrjet e tij, dhe nuk mund ta dijë se një skedar që nuk e ka hapur kurrë ka ndryshuar. Në një vendosje wg-quick hyrjet përfshijnë konfigurimin e ndërfaqes, adresat, rrugët, shënimet DNS dhe çdo hook post-up.

Prandaj një skedar i përditësuar mund të përmbajë një peer të ri, një adresë tjetër ose një direktivë të ndryshuar rrugëtimi, ndërsa ndërfaqja e gjallë vazhdon të shërbejë grupin e vjetër. Handshake ende ka sukses sepse çelësat dhe pikat fundore të ngarkuara janë ende të vlefshme. Pikërisht kjo e bën dështimin të vështirë për t'u parë, dhe pse njerëzit ndjekin DNS për një orë përpara se të kontrollojnë një vulë kohore.

Dy opsione të tjera të modulit shpesh merren për zgjidhje. daemon_reload e bën systemd të rilexojë skedarët e unit-it, gjë që është e parëndësishme për një skedar konfigurimi WireGuard. state: reloaded i kërkon unit-it të ekzekutojë veprimin e rimbushjes, dhe nëse ai bën atë që ju nevojitet varet tërësisht nga unit-i. Asnjëra nuk zë vendin e të diturit cilat hyrje procesi që punon ka lexuar vërtet.

Instalo skedarin, pastaj njofto një handler

Modeli që ruan idempotencën dhe prapë aplikon ndryshimet është ai i zakonshëm: detyra që shkruan skedarin njofton një handler, dhe handler-i punon vetëm kur skedari ka ndryshuar vërtet. Ekzekutimi i dytë pa redaktime nuk bën asgjë, dhe kjo është ajo që dëshironi.

- 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-ët punojnë në fund të play-it, pas detyrave që i njoftuan, prandaj një detyrë më vonë në të njëjtin play mund të shohë ende ndërfaqen e vjetër. Nëse rendi ka rëndësi, zbraz handler-ët në mënyrë eksplicite me meta: flush_handlers përpara detyrës që varet nga konfigurimi i ri.

Përdor restart në vend të reload, përveç nëse e ke verifikuar veprimin e rimbushjes së unit-it. Unit-i wg-quick upstream e mbështet një dhe sinkronizon konfigurimin e WireGuard, por nuk riekzekuton konfigurimin e adresave, rrugëve, DNS ose hook-eve. Prandaj një reload pas shtimit të një direktive rruge duket i suksesshëm dhe nuk ndryshon asgjë.

Krahaso pajisjen e gjallë me skedarin

Kontrolli që e mbyll këtë klasë gabimesh është një krahasim mes asaj që mban kernel-i dhe asaj që thotë skedari. Dy komanda prodhojnë dalje të krahasueshme, dhe diferenca është devijimi.

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

wg showconf printon pajisjen e gjallë, duke përfshirë çelësin privat, prandaj trajto atë dalje si sekret dhe mos e ngjit në një tiketë. wg-quick strip printon skedarin pa çelësat specifikë të wg-quick, dhe për këtë arsye të dyja janë të krahasueshme.

Një diferencë në listën e peer-ëve do të thotë që skedari nuk u aplikua kurrë. Një diferencë e kufizuar në çelësat ose pikat fundore që prisnit të ndryshonin do të thotë që diçka e aplikoi pjesërisht. Asnjë diferencë do të thotë që konfigurimi është aktual dhe defekti është diku tjetër, gjë që në vetvete është rezultat i dobishëm.

Paguaj koston e rinisjes me qëllim

Rinisja e ndërfaqes e rrëzon tunelin, dhe nëse ai tunel mbart sesionin tënd administrativ, rinisja e përfundon sesionin që e kërkoi. Vendos handler-in pas një dritareje ndryshimesh, ose ekzekuto playbook nga një rrugë administrimi që nuk varet nga rinisja e ndërfaqes.

Kostoja është arsyeja pse njerëzit i drejtohen reload. Është instinkt i arsyeshëm, dhe bëhet i saktë kur e dini cilat ndryshime reload aplikon vërtet. Për ndryshime peer-ësh dhe çelësash në unit-in wg-quick upstream mjafton; për adresim, rrugëtim dhe hook-e jo. Ta sqarosh një herë është më lirë sesa ta zbulosh gjatë një dritareje ndryshimesh.

Dokumentacioni i modulit systemd_service shpjegon ndryshimin mes started, restarted dhe reloaded, dhe ia vlen ta lexosh një herë në vend që ta hamendësosh nga një përmbledhje e gjelbër. Çdo gjë në këtë udhëzues rrjedh nga ai ndryshim i vetëm.