Ansible sê gestart, maar WireGuard hardloop steeds die ou konfigurasie

Die playbook-loop eindig groen, die WireGuard-eenheid is aktief, die handskud werk, en die nuwe peer bereik steeds niks. Dit is besonder frustrerend om ’n suksesvolle playbook te sien terwyl die bediener gister se konfigurasie gebruik, want niks in die uitset is verkeerd nie. Ansible het presies gedoen wat gevra is: dit het die eenheid laat begin, en die eenheid was reeds aan die gang. Om ’n herskrewe konfigurasielêer toe te pas is ’n ander taak, en dit gebeur net as iets die diens sê om dit weer te lees.

Kyk wat ’n tweede loop werklik rapporteer

Hardloop die playbook twee keer met die gewysigde konfigurasie en vergelyk die opsomming. Die tweede loop moet die eenheidtaak as ok wys, nie as changed nie, want ’n diens wat reeds loop, word doelbewus alleen gelaat. Dit is idempotensie wat korrek werk, en dit is ook die rede waarom die nuwe lêer nooit die kernel bereik nie.

Voeg ’n kontroleloop met diff-uitset by om te sien watter take enigiets sou raak.

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

Die drie tydstempels vertel die verhaal voordat jy ’n enkele logreël lees. As die konfigurasielêer nuwer is as die oomblik waarop die eenheid aktief geword het, is die lopende koppelvlak uit ’n ouer lêer gebou, en elke simptoom daarna volg daaruit.

Dit is nie ’n fout in Ansible nie. Dieselfde gedrag verskyn by enige konfigurasiebestuurnutsmiddel wat die vraag «loop dit?» skei van «loop dit met hierdie opstelling?». Die onderskeid lyk pedanties totdat dit jou ’n middag kos.

Gestart is ’n toestand, nie ’n herlaai nie

state: started bevestig ’n voorwaarde oor die eenheid. Dit belowe nie dat die diens sy insette weer lees nie, en dit kan nie weet dat ’n lêer wat hy nooit oopgemaak het, verander het nie. By ’n wg-quick-ontplooiing sluit die insette die koppelvlakkonfigurasie, adresse, roetes, DNS-inskrywings en enige post-up-hooks in.

Daarom kan ’n bygewerkte lêer ’n nuwe peer, ’n ander adres of ’n gewysigde roetevoorskrif bevat terwyl die lewende koppelvlak die ou stel bly bedien. Die handskud slaag steeds, want die sleutels en eindpunte wat gelaai is, is nog geldig. Dit is presies wat die fout moeilik sigbaar maak, en waarom mense ’n uur lank DNS agtervolg voordat hulle ’n tydstempel nagaan.

Twee ander module-opsies word dikwels vir ’n oplossing aangesien. daemon_reload laat systemd eenheidslêers weer lees, wat irrelevant is vir ’n WireGuard-konfigurasielêer. state: reloaded vra die eenheid om sy herlaaiaksie uit te voer, en of dit doen wat jy nodig het, hang heeltemal van die eenheid af. Nie een is ’n plaasvervanger daarvoor om te weet watter insette die lopende proses werklik gelees het nie.

Installeer die lêer en stel dan ’n handler in kennis

Die patroon wat idempotensie behou en tog veranderinge toepas, is die gewone een: die taak wat die lêer skryf, stel ’n handler in kennis, en die handler loop net wanneer die lêer werklik verander het. ’n Tweede loop sonder wysigings doen niks, en dit is wat jy wil hê.

- 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

Handlers loop aan die einde van die play, ná die take wat hulle in kennis gestel het, so ’n taak later in dieselfde play sien dalk nog die ou koppelvlak. As die volgorde saak maak, spoel die handlers eksplisiet uit met meta: flush_handlers voordat die taak wat van die nuwe konfigurasie afhang, loop.

Gebruik herbegin eerder as herlaai, tensy jy die eenheid se herlaaiaksie geverifieer het. Die upstream wg-quick-eenheid ondersteun wel een, en dit sinchroniseer WireGuard-konfigurasie, maar dit voer nie adres-, roete-, DNS- of hook-opstelling weer uit nie. ’n Herlaai ná die byvoeging van ’n roetevoorskrif lyk dus suksesvol en verander niks.

Vergelyk die lewende toestel met die lêer

Die kontrole wat hierdie klas foute sluit, is ’n vergelyking tussen wat die kernel hou en wat die lêer sê. Twee opdragte lewer vergelykbare uitset, en die verskil is die afwyking.

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

wg showconf druk die lewende toestel uit, insluitend die private sleutel, so behandel daardie uitset as geheim en plak dit nie in ’n kaartjie nie. wg-quick strip druk die lêer uit met wg-quick-eie sleutels verwyder, en daarom is die twee hoegenaamd vergelykbaar.

’n Verskil in die peer-lys beteken die lêer is nooit toegepas nie. ’n Verskil beperk tot sleutels of eindpunte wat jy verwag het sou verander, beteken iets het dit gedeeltelik toegepas. Geen verskil beteken die konfigurasie is aktuuel en die fout lê elders, wat op sigself ’n nuttige resultaat is.

Betaal die herbegin-koste doelbewus

Om die koppelvlak te herbegin, laat die tonnel val, en as daardie tonnel jou administratiewe sessie dra, beëindig die herbegin die sessie wat dit aangevra het. Sit die handler agter ’n veranderingsvenster, of hardloop die playbook vanaf ’n bestuurspad wat nie van die herbegin van die koppelvlak afhang nie.

Die koste is waarom mense na herlaai gryp. Dit is ’n redelike instink, en dit word korrek sodra jy weet watter veranderinge ’n herlaai werklik toepas. Vir peer- en sleutelveranderinge op die upstream wg-quick-eenheid is dit genoeg; vir adressering, roetering en hooks nie. Om dit een keer uit te sorteer is goedkoper as om dit tydens ’n veranderingsvenster te ontdek.

Die dokumentasie van die systemd_service-module verduidelik die verskil tussen started, restarted en reloaded, en dit is die moeite werd om dit een keer te lees eerder as om dit uit ’n groen opsomming af te lei. Alles in hierdie deurloop volg uit daardie een onderskeid.