Generator playbooka Ansible

Złóż playbook Ansible w YAML: apt update, narzędzia, Nginx, Docker, PostgreSQL i użytkownik z kluczem SSH.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Nazwa playbooka

Grupa hostów (hosts)

Zadania

Aktualizacja listy pakietów (apt update)

Podstawowe narzędzia (curl, git, htop)

Nginx

Docker

PostgreSQL

Użytkownicy i klucze SSH

Nazwa użytkownika do utworzenia

Klucz publiczny SSH na Twoim komputerze

Opcje

Użyj sudo (become)

Zbieraj fakty

Procedury (handlers)

playbook.yml

--- - name: Konfiguracja serwera hosts: webservers become: true gather_facts: true tasks: - name: Install Nginx ansible.builtin.apt: name: nginx state: present notify: Restart Nginx - name: Deploy Nginx configuration ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/sites-available/default notify: Restart Nginx - name: Install Docker ansible.builtin.apt: name: docker.io state: present - name: Enable the Docker service ansible.builtin.service: name: docker state: started enabled: true - name: Create the deploy user ansible.builtin.user: name: deploy groups: sudo append: true shell: /bin/bash - name: Add the SSH key ansible.posix.authorized_key: user: deploy key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" handlers: - name: Restart Nginx ansible.builtin.service: name: nginx state: restarted

1 040 znaków · 98 słów · 41 linii

Zadania

Handlery

Linie YAML

Uprawnienia (become)

Włączone

Co robi ten playbook
Zadanie	Moduł	Co robi
Install Nginx	ansible.builtin.apt	Instaluje serwer Nginx.
Deploy Nginx configuration	ansible.builtin.template	Wgrywa konfigurację z szablonu nginx.conf.j2.
Install Docker	ansible.builtin.apt	Instaluje pakiet docker.io.
Enable the Docker service	ansible.builtin.service	Uruchamia Dockera i włącza go przy starcie systemu.
Create the deploy user	ansible.builtin.user	Tworzy użytkownika "deploy" w grupie sudo (bez usuwania go z innych grup).
Add the SSH key	ansible.posix.authorized_key	Dodaje klucz publiczny z maszyny sterującej do authorized_keys użytkownika.
Restart Nginx (handler)	ansible.builtin.service	Restartuje Nginx po zmianie instalacji lub konfiguracji.

Playbook w praktyce

Jak uruchomić

Zapisz wynik jako playbook.yml. Najpierw sprawdź składnię i zrób przebieg próbny (--check --diff), dopiero potem uruchom naprawdę. Gdy sudo na serwerze pyta o hasło, dodaj -K.

Polecenia

ansible-playbook --syntax-check -i inventory.ini playbook.yml ansible-playbook --check --diff -i inventory.ini playbook.yml ansible-playbook -i inventory.ini playbook.yml

Idempotentność i handlers

Playbook Ansible to plik YAML opisujący pożądany stan serwera. Każde zadanie korzysta z modułu (np. apt, service, user) i jest idempotentne — wielokrotne uruchomienie nie psuje systemu. Sekcja handlers uruchamia się tylko wtedy, gdy zadanie zgłosi zmianę (np. restart Nginx po zmianie konfiguracji).

Zanim uruchomisz

Zadania używają apt, więc działają na Debianie i Ubuntu.
Szablon nginx.conf.j2 musi leżeć w katalogu templates/ obok playbooka.
Moduł authorized_key jest w kolekcji ansible.posix (jest w pakiecie ansible, w samym ansible-core trzeba ją doinstalować).
Klucz SSH jest czytany z komputera, z którego uruchamiasz Ansible.
W YAML wcięcia robi się spacjami, nie tabulatorami.

Ściąga: najważniejsze klucze playa
Klucz	Znaczenie	Uwaga
hosts	Grupa lub wzorzec hostów z inwentarza, na których działa play.	Wymagany. Bez niego play się nie uruchomi.
become	Wykonuje zadania z podwyższonymi uprawnieniami (sudo).	Domyślnie wyłączone. Bez niego apt, service i user zwykle kończą się błędem uprawnień.
gather_facts	Zbiera informacje o hoście (system, adresy IP) przed zadaniami.	Domyślnie włączone. Wyłączenie przyspiesza start, ale zmienne ansible_* nie będą dostępne.
tasks	Lista zadań wykonywanych po kolei, każde przez jeden moduł.	Wymagana, gdy play ma coś zrobić.
handlers	Zadania uruchamiane tylko po zgłoszeniu przez notify, na końcu bloku zadań.	Handler zgłoszony przez kilka zadań uruchomi się raz.

Oceń to narzędzie:

5,0 / 5 · 1 ocena

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator playbooka Ansible – konfiguracja serwera opisana w YAML

Generator playbooka Ansible składa gotowy plik YAML, w którym pojedynczy play opisuje pożądany stan serwera: grupę hostów, tryb become, listę zadań i sekcję handlers. Zaznaczasz, co ma się znaleźć na serwerze – aktualizacja listy pakietów, podstawowe narzędzia, Nginx, Docker, PostgreSQL, użytkownik z kluczem SSH – a narzędzie na bieżąco pokazuje kompletny playbook.yml. Kopiujesz go albo pobierasz jako plik i uruchamiasz poleceniem ansible-playbook.

Czym jest playbook i co dokładnie robi to narzędzie

Ansible zarządza serwerami bez agenta: łączy się przez SSH i wykonuje moduły Pythona na zdalnej maszynie. Playbook to plik YAML, który opisuje stan docelowy, a nie kolejne komendy. Podajesz nazwę playbooka i grupę hostów z inventory, wybierasz zadania i dostajesz strukturę: - name, hosts, become, gather_facts, tasks oraz – gdy trzeba – handlers. Grupa hostów jest wymagana: bez wpisu hosts Ansible nie wie, na czym uruchomić play, więc narzędzie zgłasza wtedy błąd zamiast tworzyć niekompletny plik. Puste pole nazwy zostaje zastąpione słowem Playbook.

Pod kodem widać podsumowanie: liczbę zadań, handlerów i linii YAML, stan become oraz tabelę z modułem i opisem każdego zadania. Moduły mają pełne nazwy (FQCN), np. ansible.builtin.apt zamiast samego apt, więc plik nie wywołuje ostrzeżeń reguły fqcn w ansible-lint.

Playbook to tylko jedna część wdrożenia. Listę serwerów opisuje inventory, które przygotujesz w generatorze inventory Ansible, obraz aplikacji zbudujesz w generatorze Dockerfile, a jeśli wdrażasz na klaster, manifest przygotujesz w generatorze deploymentu Kubernetes.

Presety: serwer www, host Docker, baza danych

Trzy przyciski szybkiego startu ustawiają nazwę, grupę hostów i zestaw zadań pod typowe role. Każdy dokłada też zadanie „Użytkownicy”, bo konto wdrożeniowe z kluczem SSH przydaje się na każdym serwerze.

Preset	hosts	Zadania
Serwer www	`webservers`	Nginx, użytkownicy
Host Docker	`dockers`	Docker, użytkownicy
Baza danych	`databases`	PostgreSQL, użytkownicy

Preset nie zmienia opcji become, gather_facts i handlerów ani nazwy użytkownika i ścieżki klucza. Po kliknięciu możesz dowolnie dołożyć lub odjąć zadania. Przykład: „Serwer www” przy domyślnych opcjach daje 4 zadania, 1 handler i 31 linii YAML.

Zadania w wygenerowanym playbooku

Zadanie	Moduły	Co ustawia
Aktualizacja listy pakietów	`apt`	`update_cache: true` z `cache_valid_time: 3600`, czyli `apt update` najwyżej raz na godzinę
Podstawowe narzędzia	`apt`	curl, git i htop jednym zadaniem, `state: present`
Nginx	`apt`, `template`	Instalacja pakietu `nginx` i wgranie szablonu `nginx.conf.j2` do `/etc/nginx/sites-available/default`
Docker	`apt`, `service`	Pakiet `docker.io`, usługa uruchomiona i włączona przy starcie (`enabled: true`)
PostgreSQL	`apt`, `service`	Pakiet `postgresql`, usługa uruchomiona i włączona przy starcie
Użytkownicy	`user`, `authorized_key`	Konto (domyślnie `deploy`) w grupie `sudo` z `append: true` i powłoką `/bin/bash` oraz klucz publiczny w `authorized_keys`

Zadania zawsze trafiają do pliku w stałej kolejności (aktualizacja apt, narzędzia, Nginx, Docker, PostgreSQL, użytkownicy), niezależnie od tego, w jakiej kolejności je zaznaczysz. Dzięki temu odświeżenie listy pakietów wykonuje się przed instalacją. Puste zaznaczenie to błąd: play bez zadań nic by nie zrobił, więc narzędzie pokazuje komunikat zamiast pliku.

Opcja append: true przy użytkowniku nie jest ozdobnikiem. Bez niej moduł user ustawia dokładnie grupy z listy groups i przy kolejnym uruchomieniu usunąłby konto z grup dodanych później ręcznie, np. z docker.

Nazwa użytkownika, klucz SSH i cytowanie w YAML

Pola użytkownika i klucza pojawiają się po zaznaczeniu zadania „Użytkownicy”. Nazwa konta zaczyna się małą literą lub podkreślnikiem i może zawierać małe litery, cyfry, _ oraz -, do 32 znaków. Ścieżka klucza wskazuje plik na komputerze, z którego uruchamiasz Ansible, np. ~/.ssh/id_ed25519.pub; dozwolone są litery, cyfry i znaki ~ . / _ -, bez spacji. Nazwa playa może mieć do 80 znaków, grupa hostów do 120 i żadna z nich nie może zawierać {{, {% ani {#, bo Ansible potraktowałby je jako początek szablonu Jinja2.

Wartości z formularza są cytowane, gdy wymaga tego YAML. Nazwa Serwer: www trafia do pliku jako 'Serwer: www' (dwukropek ze spacją zrobiłby z tekstu mapę), a yes czy off dostają apostrofy, żeby parser nie odczytał ich jako wartości logicznej. Wzorzec webservers:databases zostaje bez cudzysłowu, bo to poprawny zapis sumy dwóch grup w Ansible.

Idempotencja – dlaczego można uruchamiać wielokrotnie

Każdy moduł sprawdza aktualny stan i działa tylko wtedy, gdy trzeba. state: present instaluje pakiet, jeśli go nie ma, a przy kolejnym uruchomieniu nic nie zmienia. Podobnie cache_valid_time: 3600 pomija apt update, jeśli lista pakietów jest młodsza niż godzina. Dzięki temu ten sam playbook możesz odpalać wiele razy i serwer nie zmieni się „w drugą stronę”. To zasadnicza różnica względem skryptu powłoki, który przy powtórce często dubluje wpisy albo wywala się na już istniejących zasobach.

Handlery – restart tylko po realnej zmianie

Sekcja handlers to akcje uruchamiane wyłącznie wtedy, gdy zadanie zgłosi zmianę przez notify. W wygenerowanym pliku oba zadania Nginx (instalacja i wgranie konfiguracji) wołają handler Restart Nginx. Jeśli żadne nic nie zmieniło, handler się nie odpala i usługa działa bez przerwy; jeśli zmieniły się oba, restart nastąpi raz, na końcu bloku zadań. Narzędzie pilnuje spójności: handler i odsyłające do niego notify pojawiają się tylko razem i tylko przy zadaniu Nginx. Odznaczenie opcji handlerów usuwa oba wpisy naraz, więc w pliku nie zostanie notify wskazujący na nieistniejący handler – a to właśnie ten scenariusz kończy się błędem The requested handler was not found.

Jak uruchomić playbook Ansible

Zapisz wynik jako playbook.yml (przycisk „Pobierz playbook.yml”).
Przy zadaniu Nginx umieść własny szablon nginx.conf.j2 w katalogu templates/ obok playbooka.
Przygotuj plik inventory z hostami, np. grupę [webservers] odpowiadającą polu „grupa hostów”.
Sprawdź składnię: ansible-playbook --syntax-check -i inventory.ini playbook.yml. Wcięcia w YAML są znaczące i muszą być spacjami; plik możesz też wkleić do walidatora YAML.
Zrób próbę na sucho: ansible-playbook --check --diff -i inventory.ini playbook.yml pokaże planowane zmiany bez ich wprowadzania.
Uruchom właściwie: ansible-playbook -i inventory.ini playbook.yml. Gdy sudo na serwerze pyta o hasło, dodaj -K.

Zadanie „Użytkownicy” wczytuje klucz publiczny z maszyny sterującej przez lookup('file', ...), domyślnie z ~/.ssh/id_rsa.pub. Upewnij się, że wskazany plik istnieje i zawiera właściwy klucz, zanim odpalisz playbook. Moduł authorized_key należy do kolekcji ansible.posix: jest w pełnym pakiecie ansible, ale przy samym ansible-core trzeba ją doinstalować (ansible-galaxy collection install ansible.posix).

become, gather_facts i grupa hostów

Opcja become podnosi uprawnienia do roota (odpowiednik sudo) i jest potrzebna do instalacji pakietów, zarządzania usługami i tworzenia kont. W samym Ansible jest domyślnie wyłączona, w generatorze domyślnie włączona; po jej odznaczeniu podsumowanie ostrzega, że zadania apt, service i user zwykle wymagają roota. gather_facts włącza zbieranie informacji o zdalnej maszynie (system, wersje, interfejsy), dostępnych potem jako zmienne ansible_* w szablonach i warunkach; przy prostych playbookach można je wyłączyć dla szybszego startu. Grupa hostów łączy playbook z inventory – jeśli budujesz playbooki dla wielu ról, trzymaj spójne nazwy grup (webservers, dockers, databases) i te same nazwy odwzoruj w generatorze playbooków Ansible oraz w pliku inventory.

Najczęściej zadawane pytania

Czym jest inventory i skąd bierze się „grupa hostów”?

Inventory to plik z listą serwerów pogrupowanych w sekcje, np. [webservers]. Wartość z pola „grupa hostów” trafia do klucza hosts playbooka i musi pasować do nazwy grupy w inventory. Inventory może być statyczny (plik INI/YAML) albo dynamiczny (skrypt lub wtyczka zwracająca listę hostów z chmury).

Czy Ansible wymaga agenta na serwerze?

Nie. Ansible łączy się przez SSH i korzysta z Pythona obecnego na zdalnej maszynie. Nie instalujesz żadnej usługi po stronie serwera docelowego – cała logika działa z maszyny sterującej.

Czy ten playbook zadziała na CentOS albo Rocky Linux?

Nie bez zmian. Zadania korzystają z modułu apt, więc są przeznaczone dla Debiana i Ubuntu. Na systemach z dnf trzeba podmienić moduł i sprawdzić nazwy pakietów, które w tych dystrybucjach bywają inne.

Jak bezpiecznie przetestować playbook przed wdrożeniem?

Najpierw --syntax-check, potem przebieg z --check --diff, który pokazuje, co zostałoby zmienione, niczego nie zmieniając. Najbezpieczniej robić to na maszynie testowej lub z --limit zawężonym do jednego hosta.

Dlaczego usunięcie handlerów zabrało też wpisy notify?

Bo notify bez pasującego handlera przerywa wykonanie błędem „handler not found”. Narzędzie traktuje handler i odsyłające do niego notify jako parę: pojawiają się i znikają razem, i tylko przy zadaniu Nginx, które ten handler wywołuje.

Co oznacza „idempotentny” w kontekście Ansible?

Że wielokrotne uruchomienie tego samego playbooka daje ten sam stan serwera. Moduł najpierw sprawdza, czy zmiana jest potrzebna, i działa tylko wtedy, gdy jest. W podsumowaniu ansible-playbook drugie uruchomienie powinno pokazać changed=0.