Zarządzanie konfiguracją i idempotencja — dlaczego ręczne SSH to dług

Wyobraź sobie taką sytuację: jest wtorek, godzina 3:15 nad ranem. System produkcyjny pada. Zespół SRE loguje się na serwer, żeby sprawdzić, co się stało. Okazuje się, że trzy miesiące temu, podczas awarii, jeden z administratorów zalogował się przez SSH i "na szybko" zmienił jedną linię w pliku /etc/nginx/nginx.conf, żeby obejść problem z certyfikatem. Nikt nie zapisał tej zmiany w Git, nikt nie stworzył na jej podstawie playbooka. Ta zmiana "żyje" tylko na tym jednym serwerze.

Właśnie stworzyłeś Snowflake Server (serwer-płatka śniegu). Jest unikalny, niepowtarzalny i – co najgorsze – niemożliwy do odtworzenia w razie awarii. To jest właśnie moment, w którym zaczyna się techniczny dług, który prędzej czy później spłaci się z ogromnymi odsetkami w postaci przestojów i chaosu.

Configuration Drift: Cicha śmierć infrastruktury

W środowiskach, gdzie konfiguracja jest wprowadzana ręcznie, występuje zjawisko Configuration Drift (dryf konfiguracji). Polega ono na tym, że serwery, które teoretycznie powinny być identyczne (np. trzy węzły w klastrze webowym), z czasem zaczynają się od siebie różnić.

Różnice powstają przez: * Ręczne poprawki "na gorąco". * Niewłaściwie zakończone aktualizacje pakietów. * Różne wersje bibliotek zainstalowane w różnych odstępach czasu.

Jeśli Twoim jedynym sposobem na zarządzanie serwerami jest pętla w Bashu, która wysyła komendy przez SSH, nie zarządzasz konfiguracją – Ty jedynie wykonujesz polecenia. To ogromna różnica.

Imperatywność vs Deklaratywność

Aby zrozumieć, dlaczego Ansible jest potężny, musisz zrozumieć różnicę między podejściem imperatywnym a deklaratywnym.

Podejście imperatywne (Skrypt Bashowy): Mówisz systemowi, JAK ma coś zrobić. To lista kroków.

# Skrypt bashowy - podejście imperatywne
ssh user@server "apt-get update && apt-get install -y nginx && echo 'worker_processes 4;' >> /etc/nginx/nginx.conf"

Ten skrypt jest niebezpieczny. Jeśli uruchomisz go drugi raz, dopisze kolejną linię worker_processes 4; do pliku, niszcząc konfigurację. Jeśli pakiet nginx już jest zainstalowany, może to nie być problemem, ale jeśli chcesz zmienić wersję, skrypt może nie obsłużyć zależności. Musiałbyś dopisać dziesiątki instrukcji if [ ! -f ... ], aby skrypt był bezpieczny.

Podejście deklaratywne (Ansible): Mówisz systemowi, CO ma być osiągnięte. Opisujesz stan końcowy.

# Playbook Ansible - podejście deklaratywne
- name: Ensure Nginx is installed and configured
  ansible.builtin.package:
    name: nginx
    state: present

- name: Configure nginx worker processes
  ansible.builtin.lineinfile:
    path: /etc/nginx/nginx.conf
    regexp: '^worker_processes'
    line: 'worker_processes 4;'

W tym przypadku nie obchodzi Cię, czy Nginx już jest. Ansible sprawdzi stan systemu, porówna go z Twoim opisem i podejmie tylko niezbędne działania.

Idempotencja: Kontrakt, który ratuje życie

Kluczowym pojęciem w Ansible jest idempotencja. W matematyce i informatyce operacja jest idempotentna, jeśli jej wielokrotne wykonanie daje ten sam rezultat, co wykonanie jednokrotne.

W kontekście Ansible, idempotencja to obietnica: "Nieważne, ile razy uruchomisz ten playbook, stan końcowy Twojej infrastruktury będzie dokładnie taki, jak opisałeś w kodzie".

To nie jest tylko teoretyczna definicja. To mechanizm bezpieczeństwa. Dzięki idempotencji możesz uruchamiać swoje playbooki co 15 minut (np. przez crona lub narzędzia typu AWX/Tower), aby upewnić się, że żaden "płatka śniegu" nie odchylił się od normy. Jeśli ktoś ręcznie zmieni konfigurację, Ansible przy kolejnym uruchomieniu to wykryje i przywróci stan pożądany.

Zrozumienie statusów: Co mówi Ci Ansible?

Podczas uruchamiania playbooka, Ansible nie tylko wykonuje zadania, ale raportuje ich wynik. Musisz umieć czytać te statusy, bo to one mówią Ci, czy Twoja infrastruktura jest stabilna, czy właśnie "płonie".

ok: Zadanie zostało wykonane, ale nie wprowadzono żadnych zmian. System już znajduje się w stanie, który opisałeś. To sygnał, że Twoja infrastruktura jest zgodna z kodem (brak dryfu).
changed: Ansible wykrył, że stan faktyczny różni się od opisanego i podjął działanie, aby go naprawić. Jeśli widzisz changed przy każdym uruchomieniu tego samego playbooka, to znaczy, że nie jest on idempotentny (prawdopodobnie napisałeś źle zadanie lub używasz komend typu shell).
failed: Coś poszło nie tak. Zadanie nie zostało wykonane, a stan końcowy nie jest gwarantowany. To moment, w którym musisz interweniować.
skipped: Zadanie zostało pominięte. Zazwyczaj dzieje się to, gdy używasz warunków (when: ...). To normalny stan, o ile pominięcie było zamierzone.

Pułapka produkcyjna: Wielu początkujących myśli, że jeśli playbook kończy się statusem ok, to znaczy, że "wszystko jest super". To błąd. ok oznacza tylko, że Ansible nie musiał nic robić. Jeśli jednak Twoim celem było wdrożenie nowej wersji aplikacji, a Ansible raportuje ok zamiast changed, oznacza to, że Twoja zmiana nie została wprowadzona, bo Ansible uznał, że stan już jest poprawny (mimo że w rzeczywistości nie jest).

Zasada do zapamiętania: Automatyzuj stan, a nie kroki. Jeśli Twój skrypt wymaga instrukcji "jeśli nie ma pliku, to stwórz", to nie jest to zarządzanie konfiguracją, tylko pisanie skomplikowanego i podatnego na błędy kodu.