Ansible seit start, mar WireGuard draait noch op de âlde konfiguraasje
state: started lit in rinnende unit mei rêst, dus in weromskreaun wg0.conf wurdt nea tapast. Foegje in feroaringshandler ta en fergelykje dan it libbene apparaat mei it bestân.
De playbook-run einiget grien, de WireGuard-unit is aktyf, de handshake wurket, en de nije peer berikt noch altyd neat. In playbook sukses sjen melden wylst de server de konfiguraasje fan juster draait is bysûnder frustrearjend, want der is neat ferkeard oan de útfier. Ansible die krekt wat frege wie: it soarge derfoar dat de unit start wie, en de unit wie al start. In weromskreaun konfiguraasjebestân tapasse is in oare taak, en dat bart allinnich as eat de tsjinst seit it opnij te lêzen.
Sjoch wat in twadde run eins seit
Draai de playbook twaris mei de feroare konfiguraasje op syn plak en fergelykje de gearfetting. De twadde run moat de unittaak as ok sjen litte, net as changed, want in tsjinst dy't al draait wurdt neffens it ûntwerp gewurde litten. Dat is idempotinsje dy't goed wurket, en ek de reden dat it nije bestân nea de kernel berikt.
Foegje in kontrôlerun mei diff-útfier ta om te sjen hokker taken ea eat oanreitsje soene.
ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.confDe trije tiidstimpels fertelle it ferhaal foardat jo ien logrigel lêze. As it konfiguraasjebestân nijer is as it momint dat de unit aktyf waard, is de rinnende ynterface boud fan in âlder bestân, en elk folgjend symptoom komt dêrwei.
Dat is gjin fout fan Ansible. Itselde gedrach ferskynt by elk konfiguraasjebehear ark dat «soargje dat it draait» skiedt fan «soargje dat it dit draait». It ferskil liket pedant oant it jo in middei kostet.
Start is in steat, gjin werlade
state: started befêstiget in betingst oer de unit. It ûnthjit net dat de tsjinst syn yngongen opnij lêst, en it kin net witte dat in bestân dat it nea iepene hat feroare is. By in wg-quick-útrôl omfetsje de yngongen de ynterfacekonfiguraasje, de adressen, de rûtes, de DNS-ynskriuwingen en alle post-up-hooks.
Dêrom kin in bywurke bestân in nije peer, in oar adres of in feroare rûtingsdirektive befetsje wylst de libbene ynterface de âlde set blyft tsjinjen. De handshake slagget noch, want de laden kaaien en einpunten binne noch jildich. Krekt dat makket de flater min sichtber, en dêrom jeie minsken in oere efter DNS oan foardat se in tiidstimpel kontrolearje.
Twa oare module-opsjes wurde faak foar in oplossing oansjoen. daemon_reload lit systemd unitbestannen opnij lêze, wat net fan belang is foar in WireGuard-konfiguraasjebestân. state: reloaded freget de unit syn werlaadaksje út te fieren, en oft dy docht wat jo nedich hawwe hinget hielendal fan de unit ôf. Gjin fan beide ferfangt it witten hokker yngongen it rinnende proses eins lêzen hat.
Ynstallearje it bestân en ferwittigje dan in handler
It patroan dat idempotinsje behâldt en dochs feroarings tapast is it gewoane: de taak dy't it bestân skriuwt ferwittiget in handler, en de handler rint allinnich as it bestân eins feroare is. In twadde run sûnder bewurkings docht neat, en dat is wat jo wolle.
- 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: restartedHandlers rinne oan 'e ein fan 'e play, nei de taken dy't har ferwittige hawwe, dus in taak letter yn deselde play kin noch de âlde ynterface sjen. As de folchoarder fan belang is, leegje de handlers dan eksplisyt mei meta: flush_handlers foar de taak dy't fan de nije konfiguraasje ôfhinget.
Brûk restart yn stee fan reload, útsein as jo de werlaadaksje fan 'e unit ferifiearre hawwe. De upstream wg-quick-unit stipet der ien, en it syngronisearret de WireGuard-konfiguraasje, mar it fiert de ynstelling fan adressen, rûtes, DNS of hooks net opnij út. In reload nei it tafoegjen fan in rûtedirektive liket dêrom te slagjen en feroaret neat.
Fergelykje it libbene apparaat mei it bestân
De kontrôle dy't dizze klasse flaters slút is in fergeliking tusken wat de kernel hat en wat it bestân seit. Twa opdrachten jouwe ferlykbere útfier, en it ferskil is de ôfwiking.
sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)wg showconf prints it libbene apparaat, ynklusyf de privekaai, behannelje dy útfier dus as geheim en plak it net yn in ticket. wg-quick strip prints it bestân sûnder de wg-quick-eigen kaaien, en dêrom binne de twa uberhaupt ferlykber.
In ferskil yn 'e peer-list betsjut dat it bestân nea tapast is. In ferskil beheind ta kaaien of einpunten dy't jo ferwachte dat feroarje soene betsjut dat eat it foar in part tapast hat. Gjin ferskil betsjut dat de konfiguraasje aktueel is en de flater earne oars sit, wat op himsels in nuttich resultaat is.
Betelje de kosten fan it opnij starten bewust
It opnij starten fan 'e ynterface smyt de tunnel del, en as dy tunnel jo administraasjesesje ferfiert, einiget it opnij starten de sesje dy't dêrom frege. Set de handler efter in feroaringsfinster, of draai de playbook fan in behearspaad dat net fan it opnij starten fan 'e ynterface ôfhinget.
De kosten binne de reden dat minsken nei reload gripe. It is in ridlike ynstinkt, en it wurdt korrekt as jo witte hokker feroarings in reload eins tapast. Foar peer- en kaaiferoarings op 'e upstream wg-quick-unit is it genôch; foar adressearring, rûtering en hooks net. Dat ien kear útsykje is goedkeaper as it ûntdekke yn in feroaringsfinster.
De dokumintaasje fan 'e systemd_service-module leit it ferskil út tusken started, restarted en reloaded, en it is de muoite wurdich ien kear te lêzen yn stee fan it út in griene gearfetting ôf te lieden. Alles yn dizze rûnlieding folget út dat iene ferskil.