Ansible inasema imeanzishwa, lakini WireGuard bado inaendesha usanidi wa zamani

Uendeshaji wa playbook huisha kijani, unit ya WireGuard iko hai, handshake inafanya kazi, na peer mpya bado haifikii chochote. Kuona playbook ikiripoti mafanikio wakati seva inaendesha usanidi wa jana ni kero ya pekee, kwa sababu hakuna kitu kibaya kwenye matokeo. Ansible ilifanya hasa kile kilichoombwa: ilihakikisha unit imeanzishwa, na unit ilikuwa imeanzishwa tayari. Kutumia faili ya usanidi iliyoandikwa upya ni kazi nyingine, na hutokea tu ikiwa kitu kitaiambia huduma kuisoma tena.

Angalia uendeshaji wa pili unaripoti nini hasa

Endesha playbook mara mbili na usanidi uliobadilishwa na ulinganishe muhtasari. Uendeshaji wa pili unapaswa kuonyesha kazi ya unit kama ok, si changed, kwa sababu huduma inayokwisha kufanya kazi inaachwa kwa utulivu kwa mujibu wa muundo. Hiyo ni idempotence inayofanya kazi ipasavyo, na pia ni sababu faili mpya haifikii kernel kamwe.

Ongeza uendeshaji wa ukaguzi wenye matokeo ya diff ili kuona kazi zipi zingegusa kitu chochote.

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

Alama tatu za muda zinasimulia hadithi kabla ya kusoma mstari mmoja wa log. Ikiwa faili ya usanidi ni mpya zaidi ya wakati unit ilipokuwa hai, kiolesura kinachofanya kazi kilijengwa kutoka faili ya zamani, na kila dalili inayofuata inatokana na hilo.

Hii si kasoro ya Ansible. Tabia hiyo hiyo inaonekana katika chombo chochote cha usimamizi wa usanidi kinachotenganisha «hakikisha inafanya kazi» na «hakikisha inaendesha hii». Tofauti hiyo inaonekana kuwa ya kuchokonoa hadi ikugharimu mchana.

Imeanzishwa ni hali, si upakiaji upya

state: started inathibitisha sharti kuhusu unit. Haiahidi kwamba huduma itasoma tena maingizo yake, na haiwezi kujua kwamba faili ambayo haijawahi kuifungua imebadilika. Katika usambazaji wa wg-quick maingizo yanajumuisha usanidi wa kiolesura, anwani, njia, maingizo ya DNS na hook yoyote ya post-up.

Ndiyo sababu faili iliyosasishwa inaweza kuwa na peer mpya, anwani tofauti au maelekezo ya uelekezaji yaliyobadilika wakati kiolesura hai kinaendelea kuhudumia seti ya zamani. Handshake bado inafanikiwa kwa sababu funguo na vituo vya mwisho vilivyopakiwa bado ni halali. Hilo ndilo linalofanya kosa kuwa gumu kuonekana, na kwa nini watu hufukuza DNS kwa saa moja kabla ya kuangalia alama ya muda.

Chaguo mbili nyingine za moduli mara nyingi huchukuliwa kama suluhisho. daemon_reload hulifanya systemd kusoma tena faili za unit, jambo ambalo haliendani na faili ya usanidi wa WireGuard. state: reloaded linaomba unit ifanye kitendo chake cha upakiaji upya, na ikiwa kinafanya kile unachohitaji hutegemea kabisa unit. Hakuna hata moja inachukua nafasi ya kujua ni maingizo gani mchakato unaoendesha uliyasoma hasa.

Sakinisha faili, kisha mjulishe handler

Mchoro unaohifadhi idempotence na bado unatumia mabadiliko ni ule wa kawaida: kazi inayoandika faili inamjulisha handler, na handler hufanya kazi tu wakati faili imebadilika kweli. Uendeshaji wa pili bila hariri haufanyi chochote, na ndivyo unavyotaka.

- 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 hufanya kazi mwishoni wa play, baada ya kazi zilizowajulisha, kwa hivyo kazi ya baadaye katika play hiyo hiyo inaweza bado kuona kiolesura cha zamani. Ikiwa mpangilio ni muhimu, wafungue handler kwa uwazi kwa meta: flush_handlers kabla ya kazi inayotegemea usanidi mpya.

Tumia restart badala ya reload, isipokuwa umethibitisha kitendo cha upakiaji upya cha unit. Unit ya wg-quick ya upstream inaunga mkono kimoja, na inasawazisha usanidi wa WireGuard, lakini haifanyi tena usanidi wa anwani, njia, DNS au hook. Kwa hivyo reload baada ya kuongeza maelekezo ya njia huonekana kufanikiwa na haibadilishi chochote.

Linganisha kifaa hai na faili

Ukaguzi unaofunga aina hii ya hitilafu ni ulinganisho kati ya kile kernel inachoshikilia na kile faili inachosema. Amri mbili hutoa matokeo yanayolinganishwa, na tofauti ndiyo mkengeuko.

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

wg showconf huchapisha kifaa hai, ikiwa ni pamoja na ufunguo wa faragha, kwa hivyo chukulia matokeo hayo kama siri na usiyabandike kwenye tiketi. wg-quick strip huchapisha faili bila funguo mahususi za wg-quick, na ndiyo sababu mbili hizo zinaweza kulinganishwa.

Tofauti kwenye orodha ya peer inamaanisha faili haikutumika kamwe. Tofauti iliyozuiliwa kwa funguo au vituo vya mwisho ulivyotarajia kubadilika inamaanisha kitu kiliitumia kwa sehemu. Hakuna tofauti inamaanisha usanidi ni wa sasa na hitilafu iko mahali pengine, jambo ambalo lenyewe ni matokeo muhimu.

Lipa gharama ya kuanzisha upya kwa makusudi

Kuanzisha upya kiolesura huvunja handaki, na ikiwa handaki hiyo inabeba kipindi chako cha utawala, kuanzisha upya humaliza kipindi kilichoiomba. Weka handler nyuma ya dirisha la mabadiliko, au endesha playbook kutoka njia ya usimamizi isiyotegemea kuanzisha upya kiolesura.

Gharama ndiyo sababu watu hukimbilia reload. Ni silika ya busara, na inakuwa sahihi mara unapojua mabadiliko gani reload hutumia kweli. Kwa mabadiliko ya peer na funguo kwenye unit ya wg-quick ya upstream inatosha; kwa anwani, uelekezaji na hook haitoshi. Kuweka hili wazi mara moja ni nafuu kuliko kuligundua wakati wa dirisha la mabadiliko.

Nyaraka za moduli ya systemd_service zinaeleza tofauti kati ya started, restarted na reloaded, na inafaa kusoma mara moja badala ya kukisia kutoka muhtasari wa kijani. Kila kitu katika mwongozo huu kinatokana na tofauti hiyo moja.