Powtarzalny proces automatyzacji Ansible opiera się na wersjonowanych plikach, uporządkowanym inventory, idempotentnych playbookach i rolach. Sekrety należy przechowywać w zaszyfrowanej formie, na przykład w Ansible Vault, a zmiany walidować w CI. Taki proces zastępuje pojedyncze polecenia wykonywane ad hoc i ułatwia ponowne wykorzystanie automatyzacji przez cały zespół.
Spis treści
Od czego zacząć: jedno repozytorium i jasny podział
Trzymaj playbooki, inventory, role i konfigurację procesu w jednym repozytorium kontroli wersji. Każda zmiana powinna mieć zapis w historii, aby zespół mógł sprawdzić, co zostało zmienione i przywrócić wcześniejszą wersję.
Rozdziel opis środowiska od czynności wykonywanych na hostach:
- inventory opisuje hosty i grupy serwerów,
- playbooki określają kolejność działań,
- role przechowują powtarzalne elementy konfiguracji,
- zmienne opisują wartości zależne od środowiska,
- sekrety są przechowywane oddzielnie i w postaci zaszyfrowanej.
Podział inventory na grupy i zmienne pozwala rozwijać układ poza jeden prosty plik lub jedno repozytorium. Praktyczne wzorce organizacji inventory dla większej liczby środowisk opisuje Stack Harbor Knowledge Base.
Jak uporządkować inventory
Inventory to lista hostów oraz ich grup. Grupy pozwalają kierować zadania do określonego rodzaju serwerów, na przykład do serwerów aplikacji, baz danych albo środowiska testowego.
Zacznij od rozdzielenia środowisk i funkcji hostów. Nazwy powinny wskazywać, gdzie i na czym zostaną wykonane zadania. Playbook nie powinien zawierać na stałe adresów hostów, jeśli tę informację można przechowywać w inventory.
- Utwórz grupy odpowiadające środowiskom lub rolom serwerów.
- Przypisz hosty do właściwych grup.
- Umieść zmienne wspólne dla grup w jednym miejscu.
- Oddziel wartości środowiskowe od zadań zapisanych w playbookach.
- Przed uruchomieniem sprawdź, czy playbook jest kierowany do właściwej grupy.
Inventory, playbooki i idempotencja są podstawowymi elementami automatyzacji Ansible opisanymi w opracowaniu ClassicDBA.
Jak pisać idempotentne playbooki
Idempotentny playbook doprowadza host do oczekiwanego stanu. Ponowne uruchomienie nie powinno wykonywać niepotrzebnych zmian, jeśli ten stan został już osiągnięty. Dzięki temu playbook można uruchamiać ponownie po przerwanym wdrożeniu lub w ramach regularnej kontroli konfiguracji.
Opisuj stan docelowy zamiast pojedynczych, ręcznych poleceń. Zadanie powinno sprawdzać aktualny stan i zmieniać host tylko wtedy, gdy jest to potrzebne. Unikaj logiki zależnej od jednorazowej kolejności komend, jeśli tę samą konfigurację można zapisać jako deklaratywny stan.
- Podziel konfigurację na małe, nazwane zadania.
- Stosuj zmienne zamiast powtarzać wartości w wielu plikach.
- Uruchamiaj ponownie te same zadania w środowisku testowym.
- Sprawdzaj, czy drugie uruchomienie nie powoduje kolejnych, nieplanowanych zmian.
Jak tworzyć role wielokrotnego użytku
Rola grupuje powtarzalną konfigurację, na przykład przygotowanie określonego rodzaju usługi. Zamiast kopiować podobne zadania do wielu playbooków, wywołuj jedną rolę z odpowiednimi zmiennymi.
Wydziel rolę wtedy, gdy zestaw zadań ma własny cel i może być użyty w więcej niż jednym miejscu. Playbook powinien łączyć role i określać kolejność ich użycia, a szczegóły konfiguracji powinny pozostać w roli.
- Nadaj roli nazwę opisującą jej funkcję.
- Przenieś do niej zadania dotyczące jednego obszaru konfiguracji.
- Wyodrębnij wartości zmienne od logiki zadań.
- Wywołuj rolę z playbooków dla odpowiednich grup inventory.
- Testuj rolę niezależnie, zanim użyjesz jej w większym wdrożeniu.
Oficjalna dokumentacja Ansible opisuje role jako sposób ponownego używania i organizowania zawartości playbooków: Roles w dokumentacji Ansible.
Jak przechowywać sekrety z Ansible Vault
Dane uwierzytelniające i inne sekrety przechowuj za pomocą Ansible Vault. Nie wpisuj ich bezpośrednio do zwykłych playbooków, inventory ani plików zmiennych przeznaczonych do wspólnej pracy.
- Wydziel sekrety od zwykłych wartości konfiguracyjnych.
- Zaszyfruj plik zawierający sekrety przy użyciu Ansible Vault.
- Przechowuj w repozytorium tylko zaszyfrowaną postać tego pliku.
- Przekazuj hasło lub sposób odblokowania Vault wyłącznie do procesu, który musi uruchomić automatyzację.
- Nie zapisuj hasła Vault w playbooku ani w logach CI.
Jak bezpiecznie testować zmiany
Najpierw uruchamiaj zmiany na środowisku testowym lub ograniczonej grupie hostów. Sprawdź wynik oraz logi, a dopiero później rozszerz wykonanie na pozostałe grupy. Przed zmianą konfiguracji zachowaj możliwość powrotu do poprzedniej wersji plików i ustawień.
Ważnym testem idempotencji jest ponowne uruchomienie tego samego playbooka. Jeśli konfiguracja jest już zgodna ze stanem docelowym, kolejne wykonanie nie powinno wprowadzać nowych zmian. Taki sposób pracy jest wskazywany jako jedna z podstaw automatyzacji Ansible w materiale ClassicDBA.
Jak włączyć Ansible do potoku CI
Potok CI powinien sprawdzać zmiany przed ich użyciem w środowisku docelowym. Wersjonowany proces ogranicza sytuacje, w których automatyzacja działa tylko na komputerze jednej osoby.
- Uruchom walidację składni i struktury zmienionych plików.
- Sprawdź playbooki na środowisku testowym.
- Zweryfikuj role i ich ponowne użycie.
- Udostępnij zaszyfrowane sekrety tylko etapom, które ich potrzebują.
- Zatrzymaj potok, gdy walidacja lub test zakończy się błędem.
- Uruchom wdrożenie dopiero po przejściu wcześniejszych etapów.
Role, uporządkowane inventory i praktyki pracy z playbookami pomagają skalować automatyzację poza pojedynczy projekt. Zestawienie takich praktyk przedstawia opracowanie Teach me Ansible.
Co zrobić, jeśli automatyzacja staje się trudna w utrzymaniu
- Jeśli playbook zawiera powtarzające się zadania, wydziel je do roli.
- Jeśli zmiany dotyczą tylko jednego środowiska, przenieś wartości do właściwej części inventory.
- Jeśli kolejne uruchomienia wprowadzają zmiany, sprawdź idempotencję zadań.
- Jeśli sekret pojawił się w zwykłym pliku, usuń go z konfiguracji i przechowuj przez Ansible Vault.
- Jeśli zmiana omija testy, dodaj ją do potoku CI przed wdrożeniem.
Powtarzalny workflow Ansible powinien prowadzić od zmiany w repozytorium, przez walidację i testy, do kontrolowanego wdrożenia. Inventory opisuje środowisko, role zapewniają ponowne użycie, idempotentne playbooki ograniczają nieplanowane zmiany, a Ansible Vault chroni sekrety używane przez proces CI.