Ansible ಪ್ರಾರಂಭವಾಗಿದೆ ಎನ್ನುತ್ತದೆ, ಆದರೆ WireGuard ಇನ್ನೂ ಹಳೆಯ ಕಾನ್ಫಿಗ್ನಲ್ಲೇ ಚಲಿಸುತ್ತಿದೆ

state: started ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ unit ಅನ್ನು ಬಿಟ್ಟಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಮತ್ತೆ ಬರೆದ wg0.conf ಎಂದಿಗೂ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ. ಬದಲಾವಣೆಗೆ handler ಸೇರಿಸಿ, ನಂತರ ಲೈವ್ ಸಾಧನವನ್ನು ಫೈಲಿನೊಂದಿಗೆ ಹೋಲಿಸಿ.

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

ಮೂರು ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ಗಳು ಒಂದು ಸಾಲಿನ ಲಾಗ್ ಓದುವ ಮೊದಲೇ ಕಥೆಯನ್ನು ಹೇಳುತ್ತವೆ. ಕಾನ್ಫಿಗ್ ಫೈಲ್ unit ಸಕ್ರಿಯವಾದ ಕ್ಷಣಕ್ಕಿಂತ ಹೊಸದಾಗಿದ್ದರೆ, ಚಾಲನೆಯಲ್ಲಿರುವ ಇಂಟರ್ಫೇಸ್ ಹಳೆಯ ಫೈಲಿನಿಂದ ನಿರ್ಮಾಣವಾಗಿದೆ, ಮತ್ತು ಮುಂದಿನ ಎಲ್ಲ ಲಕ್ಷಣಗಳು ಅಲ್ಲಿಂದ ಬರುತ್ತವೆ.

ಇದು Ansible ದೋಷವಲ್ಲ. «ಅದು ಚಲಿಸುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ» ಮತ್ತು «ಅದು ಇದನ್ನೇ ಚಲಾಯಿಸುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ» ಎಂದು ಬೇರ್ಪಡಿಸುವ ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣಾ ಸಾಧನದಲ್ಲಿ ಇದೇ ವರ್ತನೆ ಕಾಣುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವು ಒಂದು ಮಧ್ಯಾಹ್ನವನ್ನು ಕಳೆದುಕೊಳ್ಳುವವರೆಗೆ ಕ್ಷುಲ್ಲಕವೆನಿಸುತ್ತದೆ.

ಪ್ರಾರಂಭವಾದದ್ದು ಒಂದು ಸ್ಥಿತಿ, ಮರುಲೋಡ್ ಅಲ್ಲ

state: started unit ಬಗ್ಗೆ ಒಂದು ಷರತ್ತನ್ನು ಹೇಳುತ್ತದೆ. ಸೇವೆ ತನ್ನ ಇನ್ಪುಟ್ಗಳನ್ನು ಮತ್ತೆ ಓದುತ್ತದೆ ಎಂದು ಭರವಸೆ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ತಾನು ಎಂದಿಗೂ ತೆರೆಯದ ಫೈಲ್ ಬದಲಾಗಿದೆ ಎಂದು ತಿಳಿಯಲಾರದು. wg-quick ನಿಯೋಜನೆಯಲ್ಲಿ ಇನ್ಪುಟ್ಗಳಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಕಾನ್ಫಿಗ್, ವಿಳಾಸಗಳು, ರೂಟ್ಗಳು, DNS ನಮೂದುಗಳು ಮತ್ತು ಯಾವುದೇ post-up hooks ಸೇರಿವೆ.

ಆದ್ದರಿಂದ ನವೀಕರಿಸಿದ ಫೈಲ್ನಲ್ಲಿ ಹೊಸ peer, ಬೇರೆ ವಿಳಾಸ ಅಥವಾ ಬದಲಾದ ರೂಟಿಂಗ್ ಸೂಚನೆ ಇರಬಹುದು, ಆದರೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಇಂಟರ್ಫೇಸ್ ಹಳೆಯ ಗುಂಪನ್ನೇ ನೀಡುತ್ತಿರುತ್ತದೆ. handshake ಇನ್ನೂ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಲೋಡ್ ಆದ ಕೀಗಳು ಮತ್ತು ಎಂಡ್ಪಾಯಿಂಟ್ಗಳು ಇನ್ನೂ ಮಾನ್ಯವಾಗಿವೆ. ಇದೇ ವೈಫಲ್ಯವನ್ನು ನೋಡಲು ಕಷ್ಟವಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಜನರು ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಒಂದು ಗಂಟೆ DNS ಬೆನ್ನಟ್ಟುವುದಕ್ಕೆ ಕಾರಣ.

ಮಾಡ್ಯೂಲ್ನ ಇನ್ನೆರಡು ಆಯ್ಕೆಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಪರಿಹಾರ ಎಂದು ಭಾವಿಸಲಾಗುತ್ತದೆ. 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 ಅಥವಾ hook ಸೆಟಪ್ ಅನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ರೂಟ್ ಸೂಚನೆ ಸೇರಿಸಿದ ನಂತರದ 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 ಮತ್ತು ಕೀ ಬದಲಾವಣೆಗಳಿಗೆ ಅದು ಸಾಕು; ವಿಳಾಸ, ರೂಟಿಂಗ್ ಮತ್ತು hook ಗಳಿಗೆ ಸಾಲದು. ಒಮ್ಮೆ ಇದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವುದು ಬದಲಾವಣೆ ವಿಂಡೋದಲ್ಲಿ ಕಂಡುಹಿಡಿಯುವುದಕ್ಕಿಂತ ಅಗ್ಗ.

systemd_service ಮಾಡ್ಯೂಲ್ ದಸ್ತಾವೇಜು started, restarted ಮತ್ತು reloaded ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಹಸಿರು ಸಾರಾಂಶದಿಂದ ಊಹಿಸುವ ಬದಲು ಒಮ್ಮೆ ಓದುವುದು ಒಳ್ಳೆಯದು. ಈ ಇಡೀ ಚರ್ಚೆ ಆ ಒಂದೇ ವ್ಯತ್ಯಾಸದಿಂದ ಬರುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು