Rys. 1. Ansible wykonuje zadania i kończy pracę; wszystko, co wymaga ciągłego stanu lub planu zmian, potrzebuje innego narzędzia.

Ansible ma niski próg wejścia, dlatego często staje się pierwszym i potem jedynym narzędziem automatyzacji w zespole. To zwykle działa dobrze przez pierwszy rok, a potem coraz gorzej, bo narzędzie jest stosowane do zadań, do których nie było projektowane. Poniżej zestawienie, które pomaga zdecydować, zanim playbook urośnie do trzech tysięcy linii.

Do czego Ansible nadaje się dobrze

Konfiguracja systemów operacyjnych i usług. Pakiety, pliki konfiguracyjne, użytkownicy, usługi systemd, reguły firewalla. To jest rdzeń Ansible i tu sprawdza się bez zastrzeżeń. Moduły są idempotentne, a playbook czyta się jak dokumentacja.

Zadania operacyjne wykonywane na wielu maszynach. Rotacja certyfikatów, aktualizacja pakietów w kontrolowanej kolejności, zebranie faktów z całej floty, jednorazowa zmiana w konfiguracji. Brak agenta oznacza, że działa wszędzie, gdzie jest SSH lub WinRM.

Integracja procesów. Ansible dobrze łączy się z narzędziami zewnętrznymi przez API: rejestr obrazów, system zgłoszeń, platforma CI. Workflow, który po zgłoszeniu w systemie ITSM przygotowuje środowisko i raportuje wynik, to naturalne zastosowanie.

Środowiska Windows. Moduły win_* i WinRM pozwalają zarządzać Windows Server tam, gdzie polityki grupowe nie sięgają lub są zbyt sztywne. Dla zespołu, który ma jednocześnie Linux i Windows, jedno narzędzie do obu to realna oszczędność.

Do czego Ansible nadaje się źle

Utrzymywanie stanu w czasie. Ansible wykonuje playbook i kończy pracę. Nie monitoruje, czy stan się utrzymał. Jeśli potrzebujesz ciągłego uzgadniania, tak jak w Kubernetes, potrzebujesz kontrolera, nie playbooka uruchamianego co godzinę z crona.

Zarządzanie zasobami w Kubernetes. Moduł kubernetes.core.k8s działa, ale opisuje zasoby imperatywnie, bez wykrywania dryfu i bez historii w repozytorium. Manifesty w Gicie i kontroler GitOps są tu lepszym narzędziem. Ansible może przygotować klaster, ale nie powinien go na co dzień prowadzić.

Skomplikowana logika. Pętle w pętlach, warunki zależne od wyników poprzednich zadań, transformacje danych w Jinja2. Da się to napisać, ale nie da się tego potem czytać ani testować. Jeśli playbook zaczyna przypominać program, lepiej napisać program, na przykład w Pythonie, i wywołać go z playbooka jako jedno zadanie.

Provisioning infrastruktury. Tworzenie maszyn wirtualnych, sieci i wolumenów jest możliwe, ale narzędzia zaprojektowane do tego, takie jak Terraform czy OpenTofu, robią to z planem zmian, stanem i wykrywaniem różnic. Ansible tego nie ma.

Zasady, które pomagają utrzymać playbooki

  • Role zamiast długich playbooków. Rola ma jedno zadanie, własne zmienne domyślne i własny plik README. Playbook tylko składa role.
  • Zmienne w inventory, nie w zadaniach. Zadanie powinno być takie samo dla każdego środowiska. Różnice opisuje inventory.
  • check_mode musi działać. Playbook, którego nie da się uruchomić na sucho, nie nadaje się do produkcji.
  • Sekrety poza repozytorium. Vault lub zewnętrzny menedżer sekretów. Zaszyfrowany plik w repozytorium to minimum, nie cel.
  • Testy na czystym systemie. Playbook, który działa tylko na maszynie już częściowo skonfigurowanej, nie jest idempotentny, tylko przypadkowo zbieżny.

Podsumowanie

Ansible jest narzędziem do konfiguracji i orkiestracji zadań, nie do utrzymywania stanu ani do programowania. Używane w swojej roli pozostaje czytelne latami. Rozciągane na obszary, do których nie było projektowane, staje się kolejnym systemem, którego nikt nie chce dotykać.