Zarządzanie Łatkami

Ponieważ aktualizacja systemu rzadko ogranicza się do yum update -y, zarządzaniełatkami to rola Ansible, która ułatwia zarządzanie procesem aktualizacji oraz związanymi z tym zadaniami dla serwerów działających na systemach operacyjnych RedHat, CentOS, Debian lub Ubuntu.

Podczas zarządzania łatkami, jeśli chcesz:

• ustawić docelowy serwer w trybie konserwacji w swoim systemie monitorowania
• wysłać wiadomość na początku lub końcu procesu
• reagować na awarie
• itp.

ta rola ułatwi Ci życie.

W każdym przypadku pamiętaj, aby nigdy nie łączyć się z serwerem w celu przeprowadzenia jego aktualizacji.

Wymagania

Nic szczególnego.

Funkcje

• Zbieranie danych o systemie - adres IP i trasy, uruchomione procesy, punkty montowania (do rozwiązywania problemów! Nie zapomnij o tym!)
• Wykonywanie niestandardowych zadań dla wszystkich serwerów (patrz zmienna pm_before_update_tasks_file)
• Wykonywanie niestandardowych zadań dla docelowego serwera (patrz rozdział z przykładem playbooka)

Naszym głównym celem:

• Aktualizacja serwera za pomocą apt lub yum

A po tym:

• Ustawienie faktów Ansible z bieżącą datą i opcjonalnie zmienną środowiskową.
• Wykonywanie niestandardowych zadań dla docelowego serwera (patrz rozdział z przykładem playbooka)
• Wykonywanie niestandardowych zadań dla wszystkich serwerów (patrz zmienna pm_after_update_tasks_file)

Zmienne Roli

• pm_restart_after_update: domyślnie true

Czy docelowy serwer ma się zrestartować po zarządzaniu łatkami? To zapewnia, że aktualne jądro jest uruchomione i że serwer oraz jego usługi mogą się ponownie uruchomić. Rozważ regularne wykonywanie tego kroku.

• pm_logpath: domyślnie /etc/ansible/facts.d/PM.log

Gdzie przechowywać dane o pomyślnych lub nieudanych aktualizacjach.

• pm_date_format: domyślnie "{{ ansible_date_time.date }}-{{ ansible_date_time.time }}"

Jak formatować datę w faktach i ścieżce logu?

• pm_fact_name: domyślnie pm

Jak nazywa się fakt, który chcemy?

• pm_set_env_variable: domyślnie true
• pm_env_file_path: domyślnie /etc/profile.d/last_pm_date.sh

Czy ustawiamy zmienną środowiskową z datą ostatniej aktualizacji i gdzie przechowywać ten skrypt?

• pm_manage_yum_clean_all: domyślnie true

Czy uruchomić yum clean all przed aktualizacją? Powinieneś ustawić na false, jeśli na przykład pobrałeś wcześniej RPM-y.

• pm_manage_apt_clean: domyślnie true

Czy uruchomić apt clean przed aktualizacją?

• pm_manage_apt_autoremove: domyślnie true

Automatyczne usuwanie pakietów deb.

• pm_apt_verbose_package_list: domyślnie false

Czy wyświetlić listę wyników apt?

• pm_before_update_tasks_file:

Na przykład custom_tasks/pm_before_update_tasks_file.yml. Możesz skonfigurować rolę tak, aby uruchomiła ten plik z zadaniami przed aktualizacją serwera. Każde zadanie w docelowym pliku zostanie wykonane.

Rozważ dodanie zadań, takich jak wysłanie wiadomości, zrobienie zrzutu, ustawienie trybu konserwacji itp.

• pm_after_update_tasks_file:

Na przykład custom_tasks/pm_after_update_tasks_file.yml. Możesz skonfigurować rolę tak, aby uruchomiła ten plik z zadaniami po zaktualizowaniu serwera. Każde zadanie w docelowym pliku zostanie wykonane.

Przykład Playbooka

Konfiguracja playbooka jest dość prosta, jak widać:

    - name: Rozpocznij Zarządzanie Łatkami
      hosts: serwery
      vars:
        pm_before_update_tasks_file: custom_tasks/pm_before_update_tasks_file.yml
        pm_after_update_tasks_file: custom_tasks/pm_after_update_tasks_file.yml
      tasks:
        - name: "Dołącz zarządzanie łatkami"
          include_role:
            name: "alemorvan.patchmanagement"

Oprócz tego playbooka możesz stworzyć 2 inne pliki z zadaniami dla poszczególnych serwerów, które będą wykonywane przed i po ich aktualizacji. Jest to przydatne, na przykład, do usunięcia węzła z równoważenia obciążenia, czyszczenia pamięci podręcznej, ponownego uruchamiania usług itp.

W przeciwieństwie do zmiennych pm_before_update_tasks_file i pm_after_update_tasks_file (które dotyczą plików z zadaniami dla wszystkich celów), te pliki koncentrują się na działaniach specyficznych dla pojedynczego serwera.

W katalogu playbooka stwórz katalog custom_tasks oraz pliki o nazwach before_pm_{{ inventory_hostname_short }}_custom_tasks.yml i after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.

    - name: Wykonaj niestandardowe zadanie dla tego serwera zdefiniowane w pliku after_pm_{{ inventory_hostname_short }}_custom_tasks.yml.
      debug:
        msg: "To zadanie to niestandardowe zadanie zdefiniowane w pliku after_pm_{{ inventory_hostname_short }}_custom_tasks.yml"

Testowanie Molecule

Możesz przetestować tę rolę za pomocą Molecule i Dockera:

    $ molecule test

Zobacz molecule/default/converge.yml, aby zobaczyć dobry przykład, jak użyć tej roli.

Licencja

MIT

Informacje o Autorze

Ta rola została pierwotnie napisana przez Antoine Le Morvana dla Vivalto Sante, oparta na pracy Nicolasa Martina oraz zespołu Ansible w Claranet France / BU RMP (Ismaël Ouattara i EliE Deloumeau).