Jak wyczyścić rzeczy z ról, które nie są już używane na serwerze?

Załóżmy, że mam hosta, który jest między innymi serwerem sieci Web, na którym instaluje się powiązana rola Ansible nginx, wykonuje niezbędną konfigurację /etc/nginxi otwiera porty 80 i 443 w zaporze.

W pewnym momencie chcę, aby ten konkretny host nie był już serwerem WWW, ponieważ z jakiegoś powodu przeniosłem tę usługę w inne miejsce. Samo usunięcie serwera z [webservers]ekwipunku pozostawiłoby śmieci na serwerze. Idealnie chciałbym odinstalować nginx, usunąć /etc/nginxkatalog (i niektóre inne katalogi) oraz zamknąć porty 80 i 443 w zaporze.

W Puppet mogę to zrobić. Host będący serwerem WWW będzie miał w swojej konfiguracji coś takiego:

class { 'nginx':
  ensure => present,
}

wszystko, co muszę zrobić, to zastąpić „obecny” na „nieobecny”. Jeśli nginxklasa jest dobrze napisana, cofnie wprowadzone zmiany. (Zazwyczaj administrator zamienia „obecny” na „nieobecny”, a później, gdy jest pewien, że wszyscy dotknięci hostami cofnęli konfigurację, usunie element z manifestu).

Co więcej, myślę, że moduł zapory ogniowej Puppet automatycznie usuwa reguły zapory ogniowej, których nie można już znaleźć w manifeście; więc myślę, że w przypadku zapory nie musisz nawet robić powyższej „nieobecnej” rzeczy, zapora i tak automatycznie się zamknie.

Jak mogę osiągnąć te rzeczy za pomocą Ansible?

ansible

— Antonis Christofides
źródło

Myślę, że hipotetyczne pytania nie są tutaj tak naprawdę na ten temat, chociaż samo twoje pytanie nie jest bez znaczenia. Zamiast „udawajmy…”, przepisz i powiedz na przykład: „W marionetce mogę zmienić rolę serwera i odinstalować nginx, który został wcześniej zainstalowany, zmieniając ensure => present na ensure => absentktóry również… Jak zrobić to samo z ansible” itp. Idealnie z przykładem wszystkiego, co już próbowałeś.

— HBruijn,

Twierdziłbym, że Ansible nie jest tak naprawdę przeznaczony do tego rodzaju rzeczy. Jest skierowany do odtwarzalnych, jednorazowych serwerów. Jeśli nie chcesz, aby maszyna była już serwerem sieciowym, po prostu wyczyść ją (lub zakończ, jeśli jest to instancja chmury), zamiast zmieniać jej przeznaczenie.

— ceejayoz

@ceejayoz najwięcej czytałem o Ansibles w Ender's Game i sekwencjach Orsona Scotta Card Card, ale to, co mówisz, ma sens w orkiestracji w chmurze

— HBruijn

@ceejayoz: Obecnie nie używam Ansible do konfiguracji na wielu serwerach, ale do konfigurowania małych autonomicznych serwerów. Myślę, że to jest poprawne użycie. Tak więc serwer może mieć nginx + django + PostgreSQL. Jeśli później zdecyduję się umieścić nginx lub nginx + django w innym miejscu, wymazanie całego serwera i konieczność przywrócenia PostgreSQL z kopii zapasowej wydawałoby się nieoptymalne (nie wspominając o przestoju).

— Antonis Christofides,

Odpowiedzi:

Dzięki Ansible nie zrobiłbyś tego inaczej niż w przypadku Puppet.

W twoim przykładzie, gdzie chcesz ustawić

class { 'nginx':
  ensure => absent,
}

polegasz na tym, że autor tego modułu marionetkowego napisał kod niezbędny do usunięcia wszystkiego. Nie każdy moduł lalek ma to.

Podobnie z Ansible możesz mieć role, które mają zarówno niezbędne kroki, aby zainstalować go, a także usunąć. Różnica polega tylko na tym, jak wywołać oba.

Jednym z podejść może być takie, w którym rola ujawnia zmienną do przełączania zachowania. Na przykład ta rola nginx może przyjmować zmienną, nginx_statektóra przyjmuje wartości installedi absent.

W tasks/main.ymlrolach autor roli może mieć coś podobnego do ...

- include: install.yml
  when: nginx_state|default('present') == "present"

- include: uninstall.yml
  when: nginx_state|default('present') == "absent"

..z odpowiednią logiką instalacji / dezinstalacji podzieloną między te dwa warunkowo dołączone pliki.

Odpowiednie role można również zagnieżdżać. Jako inny sposób na zrobienie tego samego, autor roli może na przykład podać rolę nginxz inną rolą w środku, zwaną uninstalled. Możesz wtedy zrobić:

- name: Uninstall nginx
  hosts: some_group
  roles:
    - nginx/uninstalled

Prawdopodobnie, w porównaniu do Puppet, zapewne ma mniej zasad i wskazówek dotyczących tego, jak należy to robić, więc praktyki na wolności różnią się nieco bardziej, ale obowiązują te same koncepcje.

— Nick Groenen
źródło

Chociaż technicznie możesz również przekazywać argumenty bezpośrednio do ról, zaleciłbym użycie roli zagnieżdżonej. Uważam, że to naprawdę dziwne widzieć w playbooku jakąś rolę, która faktycznie zostanie odinstalowana podczas wykonywania playbooka, ponieważ w zmiennych jest tak zdefiniowana. Wyraźne określenie roli zagnieżdżonej wydaje się o wiele czystsze. Technicznie możliwe jest przekazanie argumentów do roli ( - { role: nginx, state: absent }), ale wydaje mi się to bardzo szczegółowe. Jedyną wadą zagnieżdżonej roli, którą widziałem, było to, że musiałem połączyć domyślne zmienne od rodzica.

— bogdan.mustiata

Co musisz zrobić, aby coś takiego jak roles: -nginx/uninstalledpraca? Szukałem wszędzie, ale nie mogę znaleźć żadnej dokumentacji dotyczącej zagnieżdżania ról w sposób, który pozwoliłby mi to zrobić.

— zagregowano

Ponieważ masz swoją konfigurację / obsługę w Ansible, możesz po prostu zdmuchnąć cały serwer, ponownie zainstalować / udostępnić nowy i mieć przyjemny, czysty stan do pracy.

Jeśli rzeczywiście chcesz go „ponownie skonfigurować” do innych celów, musisz utworzyć nowy podręcznik, który wykona niezbędne zadania czyszczenia.

O ile mi wiadomo, wszystkie moduły opakowania Ansible obsługują, state=absentaby dany pakiet nie został zainstalowany na twoim serwerze. Dodatkowo aptmoduł ma purge=yesparametr, który wyczyści wszelkie pozostałe dostosowane pliki konfiguracyjne.

Można również utworzyć zadania potwierdzające, że port 80 jest zaporą ogniową. Ponieważ jednak nie będziesz mieć żadnych procesów uruchomionych na tym porcie, zapora ogniowa nie wpłynie na bezpieczeństwo twojego serwera.

— Mxx
źródło

Aby dodać do tego, założę się, że większość gier w tej roli mogła zostać state=absentdodana. Istnieje duża szansa, że usunie lub cofnie większość wprowadzonych zmian konfiguracji. W zależności od tego, jak duża jest ta rola, może to być prawdziwa PITA do przetestowania.

— Christopher Karel