Playbook keyrslan endar græn, WireGuard einingin er virk, handshake virkar, og nýja peer-ið nær samt hvergi. Að sjá playbook tilkynna árangur á meðan þjónninn keyrir uppsetninguna frá í gær er sérstaklega svekkjandi, því ekkert í úttakinu er rangt. Ansible gerði nákvæmlega það sem beðið var um: það tryggði að einingin væri ræst, og hún var þegar ræst. Að beita endurskrifaðri stillingarskrá er annað verkefni, og það gerist aðeins ef eitthvað segir þjónustunni að lesa hana aftur.

Sjáðu hvað önnur keyrsla greinir í raun frá

Keyrðu playbook tvisvar með breyttu uppsetningunni og berðu saman samantektina. Önnur keyrslan ætti að sýna einingarverkefnið sem ok, ekki changed, því þjónusta sem þegar keyrir er látin í friði samkvæmt hönnun. Það er idempotence sem virkar rétt, og líka ástæðan fyrir því að nýja skráin nær aldrei í kjarnann.

Bættu við prófunarkeyrslu með diff-úttaki til að sjá hvaða verkefni myndu yfirhöfuð snerta eitthvað.

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

Þrjú tímasetningargildin segja söguna áður en þú lest eina log-línu. Ef stillingarskráin er nýrri en augnablikið sem einingin varð virk, var keyrandi viðmótið byggt úr eldri skrá, og hvert eftirfarandi einkenni leiðir af því.

Þetta er ekki galli í Ansible. Sama hegðun kemur fram hjá hverju stillingastjórnunartóli sem aðgreinir „gakktu úr skugga um að það keyri“ frá „gakktu úr skugga um að það keyri þetta“. Munurinn virðist smámunalegur þar til hann kostar þig síðdegi.

Ræst er staða, ekki endurhleðsla

state: started fullyrðir skilyrði um eininguna. Það lofar ekki að þjónustan lesi inntak sitt aftur, og getur ekki vitað að skrá sem það opnaði aldrei hafi breyst. Í wg-quick uppsetningu eru inntökin viðmótsstillingin, vistföngin, slóðirnar, DNS-færslurnar og allar post-up krókar.

Þess vegna getur uppfærð skrá innihaldið nýtt peer, annað vistfang eða breytta beiningu um leiðsögn á meðan lifandi viðmótið þjónar enn gamla safninu. Handshake tekst enn því lyklarnir og endapunktarnir sem hlaðnir voru eru enn gildir. Einmitt það gerir bilunina illa sýnilega, og hvers vegna fólk eltir DNS í klukkustund áður en það skoðar tímasetningargildi.

Tveir aðrir valkostir módulsins eru oft taldir lausn. daemon_reload lætur systemd lesa einingarskrár aftur, sem er óviðkomandi fyrir WireGuard stillingarskrá. state: reloaded biður eininguna að keyra endurhleðsluaðgerð sína, og hvort hún gerir það sem þú þarft fer algjörlega eftir einingunni. Hvorugt kemur í staðinn fyrir að vita hvaða inntak keyrandi ferlið las í raun.

Settu skrána upp og tilkynntu síðan handler

Mynstrið sem varðveitir idempotence og beitir samt breytingum er hið venjulega: verkefnið sem skrifar skrána tilkynnir handler, og handler keyrir aðeins þegar skráin breyttist í raun. Önnur keyrsla án breytinga gerir ekkert, og það er það sem þú vilt.

- 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

Handlerar keyra í lok playsins, eftir verkefnin sem tilkynntu þá, svo verkefni seinna í sama playi getur enn séð gamla viðmótið. Ef röðin skiptir máli skaltu tæma handlerana sérstaklega með meta: flush_handlers áður en verkefnið sem reiðir sig á nýju stillinguna byrjar.

Notaðu restart í stað reload nema þú hafir staðfest endurhleðsluaðgerð einingarinnar. Upprunaeiningin wg-quick styður eina og samstillir WireGuard stillinguna, en keyrir ekki vistfang, slóð, DNS eða krókauppsetningu aftur. Endurhleðsla eftir að beiningu um slóð er bætt við virðist því takast og breytir engu.

Berðu saman lifandi tækið og skrána

Prófið sem lokar þessum gallaflokki er samanburður á því sem kjarninn heldur og því sem skráin segir. Tvær skipanir gefa samanburðarhæft úttak, og munurinn er frávikið.

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

wg showconf prentar lifandi tækið, þar á meðal einkalykilinn, svo meðhöndlaðu það úttak sem leyndarmál og límdu það ekki í miða. wg-quick strip prentar skrána án lykla sem eru sérstakir fyrir wg-quick, og þess vegna eru þau tvö yfirhöfuð samanburðarhæf.

Munur í peer-listanum þýðir að skránni var aldrei beitt. Munur sem takmarkast við lykla eða endapunkta sem þú bjóst við að breyttust þýðir að eitthvað beitti henni að hluta. Enginn munur þýðir að stillingin er í gildi og gallinn er annars staðar, sem er sjálft gagnleg niðurstaða.

Greiddu kostnaðinn af endurræsingu viljandi

Endurræsing viðmótsins fleygir göngunum, og ef þau ganga bera stjórnunarsetuna þína endar endurræsingin setuna sem bað um hana. Settu handlerinn bak við breytingarglugga, eða keyrðu playbook frá stjórnunarslóð sem er ekki háð endurræsingu viðmótsins.

Kostnaðurinn er ástæðan fyrir því að fólk grípur til reload. Það er skynsamlegt eðli, og verður rétt þegar þú veist hvaða breytingum reload beitir í raun. Fyrir peer- og lyklabreytingar á upprunaeiningunni wg-quick nægir það; fyrir vistföng, leiðsögn og króka ekki. Að fá þetta á hreint einu sinni er ódýrara en að uppgötva það í breytingarglugga.

Skjölun systemd_service módulsins útskýrir muninn á started, restarted og reloaded, og það er þess virði að lesa hana einu sinni í stað þess að álykta hann úr grænni samantekt. Allt í þessari leiðsögn leiðir af þeim eina mun.

Tengdir greinar