Ansiblek abiatuta dio, baina WireGuardek oraindik konfigurazio zaharra darabil
state: started egoerak martxan dagoen unitatea ukitu gabe uzten du, beraz berridatzitako wg0.conf ez da inoiz aplikatzen. Gehitu aldaketarako handler bat eta gero alderatu zuzeneko gailua fitxategiarekin.
Playbook exekuzioa berdean amaitzen da, WireGuard unitatea aktibo dago, handshakeak funtzionatzen du, eta peer berriak ez du ezer lortzen. Playbookak arrakasta jakinaraztea zerbitzaria atzoko konfigurazioarekin dabilela ikustea bereziki frustragarria da, irteeran ezer oker ez dagoelako. Ansibleri egin ziona eskatutakoa izan zen: unitatea abiatuta zegoela ziurtatu zuen, eta jada abiatuta zegoen. Berridatzitako konfigurazio-fitxategia aplikatzea beste zeregin bat da, eta zerbitzuari berriro irakurtzeko esaten dion zerbait gertatzen denean baino ez da gertatzen.
Begiratu zer jakinarazten duen bigarren exekuzioak
Exekutatu playbooka bitan konfigurazio aldatua lekuan duela eta alderatu laburpena. Bigarren exekuzioak unitatearen zeregina ok gisa erakutsi behar du, ez changed, jada dabilen zerbitzua diseinuz bakean uzten delako. Hori da idempotentzia ondo funtzionatzen, eta hori da fitxategi berria inoiz kernelera iristen ez den arrazoia.
Gehitu egiaztapen-exekuzio bat diff irteerarekin, zein zereginek zerbait ukituko luketen ikusteko.
ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.confHiru denbora-markek istorioa kontatzen dute log lerro bat irakurri aurretik. Konfigurazio-fitxategia unitatea aktibo bihurtu zen unetik berriagoa bada, martxan dagoen interfazea fitxategi zaharrago batetik eraiki zen, eta ondorengo sintoma guztiak hortik datoz.
Ez da Ansibleren akats bat. Portaera bera agertzen da «ziurtatu dabilena» eta «ziurtatu hau darabilela» bereizten dituen konfigurazio-kudeaketarako edozein tresnatan. Bereizketa pedantea dirudi arratsalde bat kostatzen dizun arte.
Abiatuta egoera da, ez birkarga
state: started unitateari buruzko baldintza bat baieztatzen du. Ez du agintzen zerbitzuak bere sarrerak berriro irakurriko dituenik, eta ezin du jakin inoiz ireki ez zuen fitxategi bat aldatu denik. wg-quick ezarpenetan sarrerak interfazearen konfigurazioa, helbideak, ibilbideak, DNS erregistroak eta post-up hookak dira.
Horregatik fitxategi eguneratu batek peer berria, beste helbide bat edo ibilbide-direktiba aldatua izan dezake, zuzeneko interfazeak multzo zaharra zerbitzatzen jarraitzen duen bitartean. Handshakeak oraindik arrakasta du, kargatutako gakoak eta muturrak oraindik baliozkoak direlako. Hori da hutsegitea ikusteko zaila egiten duena, eta jendeak ordu bat DNS atzetik ibili ondoren denbora-marka bat egiaztatzen duelako.
Beste bi modulu aukera soluziotzat hartzen dira askotan. daemon_reload systemd unitate-fitxategiak berriro irakurtzera behartzen du, WireGuard konfigurazio-fitxategiarentzat garrantzirik ez duena. state: reloaded unitateari birkarga-ekintza exekutatzeko eskatzen dio, eta horrek behar duzuna egiten duen unitatearen araberakoa da erabat. Batak ere ez du ordezkatzen martxan dagoen prozesuak benetan zein sarrera irakurri dituen jakitea.
Instalatu fitxategia eta gero jakinarazi handler bati
Idempotentzia mantentzen eta aldaketak aplikatzen dituen eredua ohikoa da: fitxategia idazten duen zereginak handler bat jakinarazten du, eta handlerra fitxategia benetan aldatu denean baino ez da exekutatzen. Aldaketarik gabeko bigarren exekuzioak ez du ezer egiten, eta hori da nahi duzuna.
- 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: restartedHandlerrak playaren amaieran exekutatzen dira, jakinarazi zituzten zereginen ondoren, beraz play bereko geroagoko zeregin batek interfaze zaharra ikus dezake oraindik. Ordena garrantzitsua bada, hustu handlerrak modu esplizituan meta: flush_handlers erabiliz konfigurazio berriaren mende dagoen zereginaren aurretik.
Erabili restart reload ordez, unitatearen birkarga-ekintza egiaztatu ez baduzu. Upstream wg-quick unitateak bat onartzen du eta WireGuard konfigurazioa sinkronizatzen du, baina ez ditu berriro exekutatzen helbide, ibilbide, DNS edo hook ezarpenak. Beraz, ibilbide-direktiba bat gehitu ondoren reloada arrakastatsua dirudi eta ez du ezer aldatzen.
Alderatu zuzeneko gailua fitxategiarekin
Akats mota hau ixten duen egiaztapena kernelak duenaren eta fitxategiak dioenaren arteko alderaketa da. Bi komandok irteera alderagarria ematen dute, eta aldea desbideratzea da.
sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)wg showconf zuzeneko gailua inprimatzen du, gako pribatua barne, beraz tratatu irteera hori sekretutzat eta ez itsatsi ticket batean. wg-quick strip fitxategia inprimatzen du wg-quick-eko gakoak kenduta, eta horregatik dira biak alderagarriak.
Peer zerrendan aldea egoteak fitxategia inoiz aplikatu ez zela esan nahi du. Aldea gako edo muturretan soilik egotea, aldatzea espero zenuenetan, zerbait-ek partzialki aplikatu zuela esan nahi du. Aldaketarik ez egoteak konfigurazioa eguneratua dela eta akatsa beste nonbait dela esan nahi du, eta hori emaitza erabilgarria da bere horretan.
Ordaindu berrabiaraztearen kostua nahita
Interfazea berrabiarazteak tunela erortzen du, eta tunel horrek zure administrazio-saioa eramaten badu, berrabiarazteak saio hori amaitzen du. Jarri handlerra aldaketa-leiho baten atzean, edo exekutatu playbooka interfazea berrabiaraztearen mende ez dagoen kudeaketa-bide batetik.
Kostua da jendeak reloadera jotzen duen arrazoia. Sen ona da, eta zuzena bihurtzen da reloadak zein aldaketa aplikatzen dituen dakizunean. Upstream wg-quick unitatean peer eta gako aldaketetarako nahikoa da; helbideratze, ibilbide eta hooketarako ez. Behin argitzea aldaketa-leiho batean aurkitzea baino merkeagoa da.
systemd_service moduluaren dokumentazioak started, restarted eta reloaded arteko aldea azaltzen du, eta behin irakurtzea merezi du laburpen berde batetik ondorioztatu beharrean. Ibilbide honetako guztia bereizketa horretatik dator.