Od Zera do Bohatera - Krok po kroku konfiguracja i zarządzanie AWX
W tym filmie wyjaśniam, jak skonfigurować AWX.
Rozpoczęcie pracy z AWX, otwartą wersją Ansible Tower, wymaga kilku kroków, aby skonfigurować i uruchomić pierwsze zadanie (job). Oto szczegółowy przewodnik krok po kroku, który pomoże Ci osiągnąć Twój cel:
Krok 1: Instalacja AWX
Zakładam, że AWX jest już zainstalowany w systemie. Jeśli nie, najlepiej postępować zgodnie z oficjalną dokumentacją AWX, aby uzyskać najbardziej aktualne instrukcje instalacji. Możesz również zapoznać się z moim samouczkiem: Jak zainstalować AWX przy użyciu Ansible playbook
Krok 2: Konfiguracja AWX
Po zainstalowaniu AWX, musisz go skonfigurować do użytku. Oto podstawowe kroki:
-
Logowanie do AWX: Użyj przeglądarki, aby przejść do interfejsu użytkownika AWX i zaloguj się przy użyciu domyślnych danych logowania (zazwyczaj
admin
/password
, chyba że zostały zmienione podczas instalacji). -
Tworzenie organizacji: W AWX, wszystko, w tym użytkownicy, zespoły i projekty, jest uporządkowane w organizacjach.
- Przejdź do zakładki „Organizations” i utwórz nową organizację klikając „Add”.
-
Dodawanie użytkowników i zespołów: W ramach organizacji możesz dodawać użytkowników i tworzyć zespoły.
- Użyj zakładek „Users” i „Teams” w menu organizacji, aby dodać nowych użytkowników i zespoły według potrzeb.
Krok 3: Konfiguracja projektu Ansible w AWX
-
Tworzenie nowego projektu:
- Przejdź do zakładki „Projects” i kliknij „Add”.
- Nazwij swój projekt i wybierz metodę pobierania „SCM Type” jako „Manual”.
- Kliknij „Save”.
-
Czekaj na synchronizację projektu: AWX automatycznie zsynchronizuje projekt z repozytorium Git. Możesz obserwować postęp w zakładce „Projects”.
Krok 4: Dodawanie inventory
- Tworzenie nowego inventory:
- Przejdź do zakładki „Inventories” i kliknij „Add”.
- Nazwij swoje inventory i zdefiniuj je według potrzeb.
- W inventory możesz dodać grupy i hosty, które będą celem Twoich playbooków Ansible.
Krok 5: Tworzenie Job Template
- Tworzenie szablonu zadania (Job Template):
- Przejdź do zakładki „Templates” i kliknij „Add” → „Job Template”.
- Nadaj nazwę szablonowi, wybierz wcześniej utworzony projekt oraz playbook, który chcesz uruchomić.
- Wybierz inventory, którego użyjesz.
- W sekcji „Credentials” dodaj poświadczenia niezbędne do łączenia się z Twoimi serwerami (np. SSH keys).
- Zapisz szablon.
Krok 6: Uruchamianie Job Template
- Uruchomienie zadania:
- Znajdź swój Job Template na liście i kliknij przycisk „Launch” obok niego, aby uruchomić zadanie.
- Możesz śledzić postęp wykonania zadania w czasie rzeczywistym.
Dodatkowe wskazówki
- Automatyzacja: Rozważ wykorzystanie funkcji AWX do automatyzacji uruchamiania zadań, np. przez harmonogramy lub webhooki.
- Dokumentacja i pomoc: Oficjalna dokumentacja AWX jest doskonałym źródłem wiedzy na temat zaawansowanych funkcji i rozwiązywania problemów.
Aby zaktualizować systemy używające różnych menedżerów pakietów takich jak apt
przy użyciu Ansible, możesz napisać scenariusz (playbook), który wykrywa system operacyjny (lub jego rodzinę) i stosuje odpowiednią komendę aktualizacji. Poniżej znajduje się przykładowy scenariusz, który realizuje to zadanie.
|
|
Wyjaśnienie:
- hosts: all: Określa, że scenariusz będzie uruchamiany na wszystkich hostach zdefiniowanych w twoim inwentarzu.
- become: yes: Podnosi uprawnienia do roota (podobnie do sudo), co jest wymagane do zarządzania pakietami.
- tasks: Sekcja zadań, gdzie każde zadanie aktualizuje systemy z różnymi menedżerami pakietów w zależności od rodziny systemu operacyjnego.
- when: Warunek, który sprawdza typ systemu operacyjnego hosta, aby wykonać odpowiednią komendę aktualizacji.
- ansible.builtin.<moduł>: Moduł Ansible odpowiedzialny za zarządzanie pakietami na różnych systemach operacyjnych.
- moduł stat: Używany do sprawdzania obecności pliku
/var/run/reboot-required
w systemach opartych na Debianie, który jest tworzony, gdy aktualizacja wymaga restartu. - moduł reboot: Wywołuje restart systemu, jeśli jest to potrzebne. Możesz dostosować ten moduł, dodając parametry takie jak
msg
dla komunikatu restartu,pre_reboot_delay
dla opóźnienia przed restartem itp. - register: Przechowuje wynik komendy lub sprawdzenia w zmiennej, która może być później użyta w warunkach (
when
).
Notatki:
- update_cache: Dla menedżerów pakietów, które tego wymagają (
apt
), ta opcja odświeża lokalną pamięć podręczną pakietów przed próbą aktualizacji. - upgrade: no: Zapewnia, że sprawdzenie faktycznie nie aktualizuje żadnych pakietów.
- cache_valid_time: Zapobiega aktualizacji pamięci podręcznej, jeśli została zaktualizowana niedawno (3600 sekund w tym przykładzie).
- changed_when: Ta niestandardowa warunkowość jest używana do określenia, czy aktualizacje są faktycznie dostępne. Dla
apt
, sprawdza wynik komendy. - upgrade: Dla
apt
, opcjadist
oznacza pełną aktualizację dystrybucji.
Dostosowanie:
Możesz dostosować ten scenariusz, dodając dodatkowe zadania lub modyfikując istniejące, aby spełniały konkretne wymagania twojego środowiska, takie jak dodanie restartu systemu po aktualizacjach lub filtrowanie aktualizacji dla określonych pakietów.
Ważne uwagi:
- Zaleca się testowanie tego scenariusza w kontrolowanym środowisku przed uruchomieniem go w produkcji, szczególnie sekcje odpowiedzialne za restarty systemów, aby upewnić się, że wszystkie zadania działają zgodnie z oczekiwaniami i nie powodują niezamierzonych przerw w usługach.
Te wstępne zadania zapewniają, że aktualizacje systemu i potencjalne restarty są wykonywane tylko wtedy, gdy dostępne są nowe aktualizacje pakietów, oszczędzając czas i redukując niepotrzebne zmiany w zarządzanych środowiskach.