Ansible தொடங்கியது என்கிறது, ஆனால் WireGuard இன்னும் பழைய கட்டமைப்பிலேயே இயங்குகிறது

playbook இயக்கம் பச்சையாக முடிகிறது, WireGuard unit செயலில் உள்ளது, handshake வேலை செய்கிறது, ஆனால் புதிய peer எங்கும் சென்றடையவில்லை. சேவையகம் நேற்றைய கட்டமைப்பில் இயங்கும்போது playbook வெற்றியைத் தெரிவிப்பதைப் பார்ப்பது சிறப்பான எரிச்சல், ஏனெனில் வெளியீட்டில் எதுவும் தவறில்லை. Ansible கேட்டதைச் சரியாகச் செய்தது: unit தொடங்கப்பட்டுள்ளதை உறுதிசெய்தது, அது ஏற்கனவே தொடங்கப்பட்டிருந்தது. மீண்டும் எழுதப்பட்ட கட்டமைப்பு கோப்பைப் பயன்படுத்துவது வேறு வேலை, ஏதோ சேவையிடம் அதை மீண்டும் படிக்கச் சொன்னால் மட்டுமே நடக்கும்.

இரண்டாவது இயக்கம் உண்மையில் என்ன தெரிவிக்கிறது என்று பாருங்கள்

மாற்றப்பட்ட கட்டமைப்புடன் playbook ஐ இரண்டு முறை இயக்கி சுருக்கத்தை ஒப்பிடுங்கள். இரண்டாவது இயக்கத்தில் unit பணி changed அல்ல, ok எனக் காட்டப்பட வேண்டும், ஏனெனில் ஏற்கனவே இயங்கும் சேவை வடிவமைப்பின்படி அமைதியாக விடப்படுகிறது. இதுவே சரியாக வேலை செய்யும் idempotence, புதிய கோப்பு ஒருபோதும் kernel ஐ அடையாததற்கான காரணமும் இதுவே.

diff வெளியீட்டுடன் சரிபார்ப்பு இயக்கத்தைச் சேர்த்து, எந்தப் பணிகள் எதையாவது தொடும் எனப் பாருங்கள்.

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

மூன்று நேர முத்திரைகள் ஒரு வரி log படிப்பதற்கு முன்பே கதையைச் சொல்கின்றன. கட்டமைப்பு கோப்பு unit செயலில் வந்த தருணத்தை விட புதியதாக இருந்தால், இயங்கும் இடைமுகம் பழைய கோப்பிலிருந்து கட்டப்பட்டது, அதற்குப் பிந்தைய அனைத்து அறிகுறிகளும் அங்கிருந்தே வருகின்றன.

இது Ansible இன் குறைபாடு அல்ல. «அது இயங்குகிறது என உறுதிசெய்» என்பதையும் «அது இதையே இயக்குகிறது என உறுதிசெய்» என்பதையும் பிரிக்கும் எந்த கட்டமைப்பு மேலாண்மை கருவியிலும் இதே நடத்தை காணப்படும். இந்த வேறுபாடு ஒரு பிற்பகலை இழக்கும் வரை மிக நுட்பமானதாகத் தெரியும்.

தொடங்கியது ஒரு நிலை, மீள்ஏற்றம் அல்ல

state: started unit பற்றிய நிபந்தனையைக் கூறுகிறது. சேவை தன் உள்ளீடுகளை மீண்டும் படிக்கும் என உறுதியளிக்கவில்லை, தான் ஒருபோதும் திறக்காத கோப்பு மாறியதை அறியவும் முடியாது. wg-quick பயன்பாட்டில் உள்ளீடுகளில் இடைமுக கட்டமைப்பு, முகவரிகள், வழித்தடங்கள், DNS பதிவுகள் மற்றும் எந்த post-up கொக்கிகள் அடங்கும்.

எனவே புதுப்பிக்கப்பட்ட கோப்பில் புதிய peer, வேறு முகவரி அல்லது மாற்றப்பட்ட வழிசெலுத்தல் கட்டளை இருக்கலாம், அதே நேரம் இயங்கும் இடைமுகம் பழைய தொகுப்பையே வழங்குகிறது. handshake இன்னும் வெற்றியடைகிறது, ஏனெனில் ஏற்றப்பட்ட விசைகளும் முனைப்புள்ளிகளும் இன்னும் செல்லுபடியாகும். இதுவே தோல்வியைக் காணக் கடினமாக்குகிறது, மக்கள் நேர முத்திரையைச் சரிபார்க்கும் முன் ஒரு மணி நேரம் DNS பின்னால் ஓடுவதற்கான காரணமும் இதுவே.

மற்ற இரண்டு module விருப்பங்கள் பெரும்பாலும் தீர்வாகக் கருதப்படுகின்றன. daemon_reload systemd ஐ unit கோப்புகளை மீண்டும் படிக்கச் செய்கிறது, இது WireGuard கட்டமைப்பு கோப்புக்கு பொருந்தாது. state: reloaded unit ஐ அதன் மீள்ஏற்ற செயலை இயக்கச் சொல்கிறது, அது உங்களுக்குத் தேவையானதைச் செய்கிறதா என்பது முழுவதும் unit ஐப் பொறுத்தது. எதுவும் இயங்கும் செயல்முறை உண்மையில் எந்த உள்ளீடுகளைப் படித்தது என்பதை அறிவதற்கு மாற்றாகாது.

கோப்பை நிறுவி, பின்னர் handler க்குத் தெரிவியுங்கள்

idempotence ஐத் தக்கவைத்து மாற்றங்களைப் பயன்படுத்தும் முறை வழக்கமானது: கோப்பை எழுதும் பணி handler க்குத் தெரிவிக்கிறது, கோப்பு உண்மையில் மாறியிருந்தால் மட்டுமே handler இயங்கும். திருத்தமின்றி இரண்டாவது இயக்கம் எதுவும் செய்யாது, நீங்கள் விரும்புவதும் அதுவே.

- 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 கள் play இன் முடிவில், அவற்றுக்குத் தெரிவித்த பணிகளுக்குப் பின் இயங்குகின்றன, எனவே அதே play இல் பிற்பட்ட பணி இன்னும் பழைய இடைமுகத்தைக் காணலாம். வரிசை முக்கியம் எனில், புதிய கட்டமைப்பைச் சார்ந்த பணிக்கு முன் meta: flush_handlers மூலம் handler களை வெளிப்படையாகக் காலி செய்யுங்கள்.

unit இன் மீள்ஏற்றச் செயலைச் சரிபார்க்காத வரை reload க்குப் பதிலாக restart பயன்படுத்துங்கள். upstream wg-quick unit ஒன்றை ஆதரிக்கிறது, WireGuard கட்டமைப்பை ஒத்திசைக்கிறது, ஆனால் முகவரி, வழித்தடம், DNS அல்லது கொக்கி அமைப்பை மீண்டும் இயக்குவதில்லை. எனவே வழித்தடக் கட்டளையைச் சேர்த்த பிறகு reload வெற்றியாகத் தெரிகிறது, எதையும் மாற்றுவதில்லை.

நேரடி சாதனத்தை கோப்புடன் ஒப்பிடுங்கள்

இந்த வகை பிழைகளை மூடும் சரிபார்ப்பு kernel வைத்திருப்பதற்கும் கோப்பு சொல்வதற்கும் இடையிலான ஒப்பீடு. இரண்டு கட்டளைகள் ஒப்பிடத்தக்க வெளியீட்டைத் தருகின்றன, வேறுபாடே விலகல்.

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

wg showconf தனிப்பட்ட விசையுடன் நேரடி சாதனத்தை அச்சிடுகிறது, எனவே அந்த வெளியீட்டை ரகசியமாகக் கருதி டிக்கெட்டில் ஒட்டாதீர்கள். wg-quick strip wg-quick க்கு உரிய விசைகளை நீக்கி கோப்பை அச்சிடுகிறது, அதனால்தான் இரண்டையும் ஒப்பிட முடிகிறது.

peer பட்டியலில் வேறுபாடு என்பது கோப்பு ஒருபோதும் பயன்படுத்தப்படவில்லை என்பதாகும். மாறும் என நீங்கள் எதிர்பார்த்த விசைகள் அல்லது முனைப்புள்ளிகளில் மட்டும் வேறுபாடு என்பது ஏதோ அதைப் பகுதியாகப் பயன்படுத்தியது. வேறுபாடே இல்லாவிட்டால் கட்டமைப்பு தற்போதையது, பிழை வேறெங்கோ உள்ளது, அதுவும் பயனுள்ள முடிவே.

மறுதொடக்கத்தின் விலையை வேண்டுமென்றே செலுத்துங்கள்

இடைமுகத்தை மறுதொடக்கம் செய்வது சுரங்கப்பாதையை அறுக்கும், அது உங்கள் நிர்வாக அமர்வை எடுத்துச் சென்றால், மறுதொடக்கம் அதைக் கோரிய அமர்வை முடிக்கும். handler ஐ மாற்ற சாளரத்திற்குப் பின் வையுங்கள், அல்லது இடைமுக மறுதொடக்கத்தைச் சாராத நிர்வாக பாதையிலிருந்து playbook ஐ இயக்குங்கள்.

இந்த விலையே மக்களை reload நோக்கி இழுக்கிறது. அது நியாயமான உணர்வு, reload உண்மையில் எந்த மாற்றங்களைப் பயன்படுத்துகிறது எனத் தெரிந்ததும் அது சரியாகிறது. upstream wg-quick unit இல் peer மற்றும் விசை மாற்றங்களுக்கு அது போதும்; முகவரி, வழிசெலுத்தல், கொக்கிகளுக்கு போதாது. இதை ஒருமுறை தெளிவுபடுத்துவது மாற்ற சாளரத்தில் கண்டுபிடிப்பதை விட மலிவு.

systemd_service module ஆவணம் started, restarted, reloaded இடையிலான வேறுபாட்டை விளக்குகிறது, பச்சை சுருக்கத்திலிருந்து ஊகிப்பதை விட ஒருமுறை படிப்பது நல்லது. இந்த முழு விவாதமும் அந்த ஒரே வேறுபாட்டிலிருந்து வருகிறது.