AI i Ansible: czy warto generować
playbooki modelami językowymi?

Ansible automatyzuje coś znacznie ważniejszego niż generowanie plików YAML. Zmienia stan infrastruktury.

Jeden playbook może:

Dlatego generowanie playbooków za pomocą modeli językowych jest jednocześnie bardzo atrakcyjne i potencjalnie niebezpieczne. AI potrafi w kilkanaście sekund przygotować rolę Ansible, handler, template albo fragment konfiguracji. Szerzej o tym, gdzie AI ma dziś sens w pracy administratora, piszemy w artykule AI w administracji IT: 7 obszarów, które warto automatyzować.

Problem zaczyna się wtedy, gdy kod wygląda poprawnie na tyle, że ktoś przestaje go dokładnie czytać. YAML się parsuje. ansible-playbook --syntax-check przechodzi. Kod wygląda profesjonalnie.

Gdzie AI rzeczywiście pomaga przy Ansible?

Modele językowe najlepiej sprawdzają się tam, gdzie wynik można szybko i tanio zweryfikować.

1. Tworzenie pierwszego szkicu roli

Załóżmy, że potrzebujemy roli konfigurującej nginx. Możemy ręcznie przygotować strukturę:

roles/
  nginx/
    defaults/
    handlers/
    tasks/
    templates/
    meta/

następnie tworzyć taski, zmienne i handlery. Możemy też przekazać modelowi wymagania i poprosić o pierwszą wersję. To jest bardzo dobre zastosowanie AI. Administrator nie traci czasu na mechaniczne tworzenie struktury, ale nadal decyduje:

• › jakie moduły zostaną użyte,
• › jakie będą wartości domyślne,
• › gdzie potrzebne jest become,
• › kiedy wykona się handler,
• › jak ograniczyć zakres zmian.

2. Zamiana wymagania na szkic YAML

Administrator może opisać cel:

Model prawdopodobnie przygotuje sensowny punkt wyjścia. To dużo szybsze niż szukanie składni każdego modułu. Ale rezultat należy traktować jak draft pull requestu, a nie gotową automatyzację produkcyjną.

3. Refaktor istniejących playbooków

To jedno z lepszych zastosowań LLM. W wielu firmach istnieją stare playbooki, które przez lata rosły razem ze środowiskiem. Efekt: site.yml na 1800 linii, a w środku:

AI może pomóc znaleźć powtarzające się fragmenty i zaproponować podział na role, task files, handlery, defaults i templates. Tu również trzeba jednak uważać. Mechaniczne rozbicie pliku na role jest proste. Znacznie trudniejsze jest zrozumienie, które elementy rzeczywiście mają wspólną odpowiedzialność. To nadal wymaga człowieka znającego środowisko. Z takimi repozytoriami spotykamy się często przy przejmowaniu administracji IT po poprzednim dostawcy.

4. Review istniejącego playbooka

Czasem AI jest bardziej użyteczne jako reviewer niż autor. Możemy przekazać playbook i zapytać:

Model może przygotować listę rzeczy do sprawdzenia. Administrator następnie ocenia, które uwagi są rzeczywiście poprawne.

5. Tworzenie dokumentacji

AI bardzo dobrze radzi sobie również z przygotowaniem pierwszej wersji:

Ale również tutaj obowiązuje review. Błędna dokumentacja infrastruktury może być równie niebezpieczna jak błędny kod, jeżeli ktoś wykorzysta ją później podczas awarii.

Gdzie zaczynają się problemy?

Model językowy nie rozumie infrastruktury w taki sam sposób jak administrator. Generuje wynik na podstawie otrzymanego kontekstu i wzorców. Jeżeli kontekstu brakuje, zaczyna zgadywać. A zgadywanie podczas zarządzania produkcją jest kosztowne.

Problem 1. Shell zamiast modułu Ansible

Model bardzo łatwo wygeneruje:

- name: Install nginx
  ansible.builtin.shell: apt-get install -y nginx

Technicznie może to zadziałać. Ale poprawniejszy zapis to:

- name: Ensure nginx is installed
  ansible.builtin.apt:
    name: nginx
    state: present

Dlaczego? Moduł rozumie stan systemu. Wie, czy pakiet już istnieje. Raportuje zmiany w sposób zrozumiały dla Ansible. Może również lepiej współpracować z check mode.

Problem 2. Idempotencja

Jedna z najważniejszych właściwości dobrej automatyzacji Ansible brzmi:

Oficjalna dokumentacja Ansible opisuje większość modułów jako projektowane właśnie w taki sposób, ale podkreśla również, że nie wszystkie moduły i playbooki muszą zachowywać się idempotentnie. Model może wygenerować na przykład:

- name: Restart application
  ansible.builtin.service:
    name: app
    state: restarted

Ten task zrestartuje usługę podczas każdego przebiegu. Czasami właśnie tego chcemy. Często jednak prawidłowy model wygląda tak:

- name: Deploy application configuration
  ansible.builtin.template:
    src: app.conf.j2
    dest: /etc/app/app.conf
    owner: root
    group: root
    mode: "0644"
  notify: Reload application

Handler wykona się tylko wtedy, gdy konfiguracja rzeczywiście się zmieni.

Problem 3. state: latest

Często można spotkać wygenerowany kod:

ansible.builtin.apt:
  name: nginx
  state: latest

Nie oznacza to automatycznie, że task jest nieidempotentny. Po osiągnięciu najnowszej wersji dostępnej w repozytorium kolejne wykonanie może niczego nie zmienić. Problem jest inny: wynik zależy od zawartości repozytorium w momencie wykonania playbooka. Dzisiaj latest może oznaczać wersję X. Za tydzień wersję Y.

Dlatego w środowiskach, gdzie ważna jest kontrola wersji i przewidywalność zmian, state: present albo jawna wersja pakietu mogą być właściwsze. Co ciekawe, ansible-lint wykrywa instalację pakietów w trybie latest jako potencjalny problem.

Problem 4. Model nie zna inventory

To jeden z najważniejszych problemów. AI może wygenerować hosts: all. Ale nie wie, że nasze inventory wygląda tak:

production
  web
  api
  database

staging
  web
  api
  database

Nie wie również, że:

To nie są informacje wynikające ze składni Ansible. To wiedza o architekturze.

Problem 5. Blast radius

Największym problemem błędnego playbooka nie zawsze jest sam błąd. Czasami problemem jest liczba maszyn, które błąd obejmie.

Ansible pozwala ograniczać zakres wykonania między innymi przez serial. Dokumentacja opisuje ten mechanizm jako sposób na rolling updates partiami zamiast wykonywania zmian na całej grupie naraz. Przykładowo:

- name: Configure web servers
  hosts: web
  serial: 2

Dzięki temu play nie wykonuje się na całej grupie naraz. To nie zastępuje testów, ale ogranicza potencjalny blast radius.

Problem 6. Uprawnienia

Model może wygenerować become: true dla całego playa. Nie zawsze jest to błędem. Jeżeli wszystkie zadania rzeczywiście wymagają roota, takie rozwiązanie może być uzasadnione. Problem pojawia się wtedy, gdy pełne uprawnienia zostają nadane "na wszelki wypadek". Lepszą zasadą jest używanie minimalnych uprawnień potrzebnych do wykonania operacji.

- name: Gather application status
  ansible.builtin.command:
    cmd: /usr/local/bin/app-status
  changed_when: false

- name: Install nginx
  ansible.builtin.apt:
    name: nginx
    state: present
  become: true

Problem 7. Sekrety

Tego obszaru AI nie powinno komplikować. Sekret nie powinien trafiać do promptu tylko dlatego, że modelowi łatwiej będzie wygenerować playbook. Dotyczy to haseł, kluczy prywatnych, tokenów, zawartości Vault, credentiali AWX i connection strings.

Playbook powinien odnosić się do mechanizmu przechowywania sekretów, a nie zawierać sekretu. Może to być:

--syntax-check to dopiero początek

ansible-playbook site.yml --syntax-check

Playbook przechodzi. Świetnie. To oznacza tylko tyle, że przeszliśmy jedną z bramek. Syntax check nie odpowiada jeszcze na pytania:

• › czy konfiguracja ma sens,
• › czy wybrany host jest właściwy,
• › czy handler nie zrobi restartu całego klastra,
• › czy playbook jest idempotentny,
• › czy zmienna produkcyjna ma właściwą wartość,
• › czy aplikacja po zmianie będzie działać.

Dlatego pipeline powinien mieć kilka warstw.

Bezpieczny workflow dla playbooków generowanych przez AI

Dobry proces może wyglądać tak:

Im wcześniej wykryjemy błąd, tym taniej go poprawić.

--check również ma ograniczenia

ansible-playbook site.yml --check --diff

To polecenie jest niezwykle przydatne. Ale nie jest magicznym sandboxem. Dokumentacja Ansible jasno zaznacza, że check mode jest symulacją. Moduły, które go obsługują, próbują przewidzieć zmiany bez ich wykonania. Moduły bez wsparcia mogą nie wykonać operacji ani nie zwrócić użytecznego wyniku. Problematyczne mogą być również zadania zależne od danych zarejestrowanych przez wcześniejsze taski.

To kolejna bramka. Nie ostateczny test.

Molecule i test idempotencji

Dla ról Ansible warto rozważyć Molecule lub podobny mechanizm automatycznych testów. Dokumentacja Molecule opisuje standardową sekwencję molecule test, która obejmuje między innymi:

Test idempotencji ponownie wykonuje converge i oczekuje, że drugi przebieg nie będzie raportował zmian tam, gdzie konfiguracja powinna być idempotentna. To świetny mechanizm właśnie przy kodzie generowanym przez AI. Model może napisać coś, co wygląda poprawnie. Test pokaże changed=6 również podczas drugiego wykonania. I od razu mamy pytanie: dlaczego?

AI powinno znać standard projektu

Napisz rolę Ansible konfigurującą nginx.

Przygotuj szkic roli Ansible do konfiguracji nginx.

Wymagania:

- używaj FQCN
- używaj tylko kolekcji z requirements.yml
- unikaj shell i command, jeśli istnieje moduł
- nie umieszczaj sekretów w kodzie
- używaj handlers dla zmian wymagających reload
- state: present zamiast latest, jeśli nie ma
  konkretnego powodu do aktualizacji
- nie używaj hosts: all
- nie zakładaj struktury inventory
- zaznacz miejsca wymagające decyzji administratora

Jeszcze lepiej, jeśli model otrzyma przykłady istniejących ról z tego samego repozytorium. Wtedy dostosowuje się do lokalnego stylu: nazw tasków, struktury zmiennych, tagów, sposobu używania handlerów, organizacji defaults i konwencji projektu.

FQCN ma znaczenie

Zamiast apt: warto stosować ansible.builtin.apt:. Oficjalna dokumentacja Ansible rekomenduje FQCN, ponieważ moduły o tej samej krótkiej nazwie mogą znajdować się w różnych kolekcjach. Analogicznie community.general.ufw: jednoznacznie określa źródło modułu.

To szczególnie ważne przy kodzie generowanym przez model, który może założyć inną kolekcję niż ta dostępna w środowisku. FQCN nie chroni jednak przed wyborem złego modułu. Ułatwia tylko sprawdzenie, skąd dany moduł pochodzi.

Pinuj środowisko, nie tylko prompt

Dobra automatyzacja powinna określać:

Dodatkowo warto uważać na stare przykłady znalezione w internecie lub w pamięci modelu. W nowszych wersjach Ansible zmieniają się zachowania, usuwane są przestarzałe elementy i pojawiają się nowe wymagania kompatybilności. Przykładowo ansible-core 2.19 wprowadził istotne zmiany w templatingu, dla których dokumentacja zaleca weryfikację istniejących playbooków i ról przed aktualizacją.

Przykład: playbook wygenerowany bez odpowiedniego kontekstu

Model może przygotować:

- name: Configure nginx
  hosts: all
  become: true

  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: latest

    - name: Deploy configuration
      ansible.builtin.copy:
        content: |
          server {
            listen 80;
          }
        dest: /etc/nginx/sites-available/default

    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

    - name: Configure firewall
      ansible.builtin.shell:
        cmd: ufw allow 80

To może nawet zadziałać. Ale review powinno natychmiast wywołać pytania:

To właśnie jest prawdziwe review Ansible. Nie: "YAML wygląda ładnie".

Lepszy punkt wyjścia

Po review wersja może wyglądać tak:

- name: Configure nginx web servers
  hosts: web
  serial: 2

  tasks:
    - name: Ensure nginx is installed
      ansible.builtin.apt:
        name: nginx
        state: present
      become: true

    - name: Deploy nginx virtual host
      ansible.builtin.template:
        src: default.conf.j2
        dest: /etc/nginx/sites-available/default
        owner: root
        group: root
        mode: "0644"
      become: true
      notify: Reload nginx

    - name: Ensure nginx is enabled and running
      ansible.builtin.service:
        name: nginx
        enabled: true
        state: started
      become: true

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded
      become: true

Czy to jest gotowy playbook produkcyjny? Nie. Nadal trzeba odpowiedzieć między innymi:

• › jaka wersja nginx jest wspierana?
• › czy potrzebujemy TLS?
• › jak wygląda aktywacja virtual hosta?
• › czy konfiguracja powinna przejść nginx -t przed wdrożeniem?
• › czy dwa hosty jednocześnie to właściwy batch?
• › czy serwery znajdują się za load balancerem i czy trzeba je czasowo wyjąć z puli?

Review playbooka wygenerowanego przez AI

Przed zatwierdzeniem PR warto przejść krótką checklistę.

Testy, które warto przejść przed merge:

--check --diff ma sens tam, gdzie wykorzystywane moduły dobrze obsługują check mode, a Molecule tam, gdzie testowanie roli ma zastosowanie.

Minimalny pipeline CI

Nie musi być skomplikowany.

Dla bardziej krytycznych zmian można dołożyć:

AWX oraz Ansible Automation Platform pozwalają budować workflow z elementami wymagającymi zatwierdzenia użytkownika przed przejściem do kolejnego etapu.

AI nie powinno omijać istniejącego procesu zmian

To najważniejsza zasada całego artykułu. Jeżeli playbook napisany przez administratora wymaga pull requestu, review, pipeline, testu i zatwierdzenia, to playbook napisany przez AI musi przejść dokładnie tę samą drogę. A na początku nawet bardziej rygorystyczną.

Wynik AI, podobnie jak każdą inną zmianę, warto później zweryfikować w ramach regularnego przeglądu środowiska, o którym piszemy w artykule comiesięczna checklista utrzymania IT. Tam też szukamy driftu, czyli ręcznych zmian, które rozjechały się z kodem.

Czy AI może generować playbooki do systemów krytycznych?

Może przygotować szkic. To nie jest to samo co automatyczne wdrożenie. Im większa konsekwencja błędu, tym bardziej rygorystyczny powinien być proces. Szczególną ostrożność zachowałbym przy:

Model może pomóc przygotować propozycję, wskazać ryzyka, wykonać review i przygotować testy. Ale wynik powinien zostać szczególnie dokładnie przeanalizowany przez osobę rozumiejącą daną technologię.

serial nie jest dekoracją

Ansible domyślnie może wykonywać play równolegle na hostach należących do wskazanego wzorca. Jeżeli zmiana może powodować krótką niedostępność usługi, warto świadomie sterować rolloutem.

Dokumentacja Ansible opisuje również max_fail_percentage, który pozwala zatrzymać dalszy rollout po przekroczeniu określonego poziomu błędów w aktualnym batchu. AI może zasugerować te parametry. Administrator musi zdecydować, jakie wartości mają sens dla konkretnej aplikacji.

Shadow AI przy Ansible jest realnym problemem

Playbook zawiera bardzo dużo informacji o środowisku. Może zdradzać:

Inventory może zawierać jeszcze więcej. Dlatego nie warto bezrefleksyjnie wklejać całych repozytoriów do przypadkowego publicznego narzędzia AI. Przed wykorzystaniem zewnętrznego modelu trzeba wiedzieć:

AI może powodować erozję kompetencji

To jeden z mniej oczywistych problemów. Junior dostaje zadanie: "Napisz rolę Ansible instalującą PostgreSQL."

Dlatego review kodu generowanego przez AI powinno czasami zawierać proste pytanie: dlaczego ten task wygląda właśnie tak? Jeżeli odpowiedź brzmi "nie wiem, ChatGPT tak zrobił", to kod nie jest jeszcze gotowy do merge. Szerzej o tym problemie piszemy w artykule czy AI zastąpi administratora systemów.

Nie mierz czasu do wygenerowania YAML

To zły KPI. Model przygotował rolę w 45 sekund. Brzmi świetnie. Ale później:

AI może nadal być szybsze. Ale mierzyć należy właściwą rzecz.

Kiedy AI daje największy zysk?

Jak podchodzimy do AI i Ansible w PRO-Admin?

AI może bardzo dobrze przyspieszyć pracę administratora. Nie powinno jednak omijać standardów, które obowiązują przy normalnej automatyzacji. Dlatego dobry workflow nadal powinien opierać się na:

Jeżeli AI przygotuje 70% roli w minutę, świetnie. Ale pozostałe 30% może być właśnie tą częścią, która decyduje, czy podczas wdrożenia nic się nie wydarzy, zrestartuje się jedna usługa, czy przestanie działać 40 serwerów.

FAQ - AI i Ansible

Podsumowanie

Tak, AI i Ansible to bardzo dobre połączenie. Pod warunkiem, że właściwie podzielimy odpowiedzialność. AI może pisać pierwsze wersje tasków, generować strukturę ról, pomagać w refaktorze, analizować playbooki, przygotowywać dokumentację i sugerować testy. Ale powinno istnieć kilka niezależnych bramek:

Model językowy może bardzo szybko nauczyć się składni Ansible. Nie zna jednak automatycznie:

Dlatego największą wartością AI nie jest możliwość stworzenia playbooka bez administratora. Największą wartością jest możliwość stworzenia go szybciej razem z administratorem.

A najważniejsza zasada pozostaje taka sama niezależnie od tego, kto napisał YAML: nie wdrażaj automatyzacji, której skutków nie rozumiesz.