Ansible ამბობს, რომ გაშვებულია, მაგრამ WireGuard კვლავ ძველი კონფიგურაციით მუშაობს

Playbook-ის გაშვება მწვანედ მთავრდება, WireGuard-ის unit აქტიურია, handshake მუშაობს, ახალი peer კი მაინც ვერაფერს აღწევს. იმის ყურება, როგორ აცხადებს playbook წარმატებას, სანამ სერვერი გუშინდელი კონფიგურაციით მუშაობს, განსაკუთრებით გულსატკენია, რადგან გამოსავალში არაფერია არასწორი. Ansible-მა ზუსტად ის გააკეთა, რაც სთხოვეს: დარწმუნდა, რომ unit გაშვებულია, და unit უკვე გაშვებული იყო. გადაწერილი კონფიგურაციის ფაილის გამოყენება სხვა ამოცანაა და ხდება მხოლოდ მაშინ, როცა რაღაც ეუბნება სერვისს, რომ ის ხელახლა წაიკითხოს.

ნახეთ, რას აცხადებს სინამდვილეში მეორე გაშვება

გაუშვით playbook ორჯერ შეცვლილი კონფიგურაციით და შეადარეთ შეჯამება. მეორე გაშვებამ unit-ის ამოცანა უნდა აჩვენოს როგორც ok და არა changed, რადგან უკვე მომუშავე სერვისი დიზაინით ხელუხლებლად რჩება. ეს არის სწორად მომუშავე 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 hook-ს.

ამიტომ განახლებული ფაილი შეიძლება შეიცავდეს ახალ 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-ის უფრო გვიანდელმა ამოცანამ შეიძლება ჯერ კიდევ დაინახოს ძველი ინტერფეისი. თუ რიგი მნიშვნელოვანია, ცხადად დააცარიელეთ handler-ები meta: flush_handlers-ით ახალ კონფიგურაციაზე დამოკიდებული ამოცანის წინ.

გამოიყენეთ restart და არა reload, თუ არ შეამოწმეთ unit-ის გადატვირთვის მოქმედება. 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-ს შორის და ღირს ერთხელ წაკითხვა იმის ნაცვლად, რომ მწვანე შეჯამებიდან გამოიტანოთ დასკვნა. ამ სახელმძღვანელოში ყველაფერი ამ ერთი განსხვავებიდან გამომდინარეობს.