Ansible

Otwartoźródłowe narzędzie do automatyzacji konfiguracji i provisioningu infrastruktury. Działa bezagentowo, komunikując się z serwerami przez SSH.

Ansible to otwartoźródłowe narzędzie do automatyzacji: konfiguracji serwerów, instalacji oprogramowania, wdrażania aplikacji i provisioningu infrastruktury. Jego znak rozpoznawczy to bezagentowość — nie musisz instalować żadnego dodatkowego procesu na maszynach, którymi zarządzasz. Ansible łączy się z nimi po zwykłym SSH (a w przypadku Windows przez WinRM), więc wystarczy, że masz dostęp i Pythona po drugiej stronie. Projekt powstał w 2012 roku, a od 2015 należy do Red Hata.

Zamiast klikać po dziesięciu serwerach i ręcznie powtarzać te same komendy, opisujesz pożądany stan w pliku YAML zwanym playbookiem. Mówisz w nim „ma być zainstalowany nginx, ma działać i ma startować przy bootcie” — a Ansible sam sprawdza, czy tak już jest, i robi tylko to, co trzeba. To zasada idempotentności: uruchom playbook raz albo dziesięć razy, efekt końcowy jest ten sam, nic się nie psuje przy powtórzeniu.

Jak to działa w praktyce

Lista maszyn siedzi w pliku inventory, pogrupowana (np. webservers, databases). Ansible działa w modelu push: odpalasz polecenie z własnego laptopa albo z serwera kontrolnego, a ono rozsyła zadania na hosty. Logikę wykonują moduły (np. apt, copy, service), a powtarzalne zestawy zadań pakujesz w role, którymi można się dzielić przez Ansible Galaxy.

Szybki przykład — bez pisania playbooka, w trybie ad-hoc zrestartujesz nginx na całej grupie:

ansible webservers -m service -a "name=nginx state=restarted" --become

A pełny scenariusz odpalisz tak: ansible-playbook -i inventory deploy.yml. Dodaj --check, żeby zobaczyć, co Ansible zamierza zmienić, zanim faktycznie cokolwiek ruszy.

Częste pułapki i mity

Po pierwsze: YAML jest wrażliwy na wcięcia. Jedna spacja za dużo i dostajesz cryptic error zamiast działającego playbooka — używaj spacji, nigdy tabów. Po drugie: „bezagentowy” nie znaczy „bez zależności” — host docelowy potrzebuje Pythona, a Ty musisz mieć skonfigurowane klucze SSH. Po trzecie: nie wrzucaj haseł i kluczy API jawnie do playbooków — od tego jest ansible-vault do szyfrowania sekretów. I jeszcze jedno — Ansible nie jest najszybszy przy setkach hostów (SSH ma swój narzut), ale dla większości projektów to nieistotne, a prostota wygrywa.

Pojęcia powiązane: Infrastructure as Code (IaC), Terraform (provisioning chmury, dobrze gra w parze z Ansible), Puppet i Chef (konkurenci działający agentowo), idempotentność, YAML, CI/CD oraz DevOps jako cała filozofia, w którą Ansible się wpisuje.