Wpis z mikrobloga

@skim: Hmm... Domyślam się, że chcesz ansibla wynieść na wyższy poziom. Przede wszystkim testy pisz, do tego zainstaluj sobie AWX do odpalania i jakiś prosty CI, żeby Ci odpalał testy.
@yggdrasil: ok coś doczytam ( ͡° ͜ʖ ͡°) Ja dopiero startuję z Ansiblem- używam od 2 miesięcy tylko do patchowania starych serwerów, usług, zmian konfiguracji. Nowe środowiska mamy na Puppecie.
Jak będę miał jakieś pytania, to się zgłoszę ( ͡° ͜ʖ ͡°) Póki co zastanawiam się jak najlepiej zrobić weryfikację czy dany playbook wykonał się na danym serwerze. Chciałbym uruchamiać np. 1 dziennie
@maslokm: Hmm to jest trochę antypattern, powinieneś zrobic tak, ze playbooki są indenpotent. Jak masz w inventory hosty to odpalasz sobie z jenkinsa na przykład raz dziennie i działa. Nie potrzebujesz do tego zbiorczego playbooka. Rozumiem ze robić include dla każdego hosta osobno?
@yggdrasil: nie, hosty dostaję z Rundecka. Playbooki są 'indenpotent' - mogę je odpalać i 10 razy na tym samym hoście- nic to nie zmienia.
Problem w tym, że część hostów może być niedostępna przez jakiś czas (np. padł VPN do danego klienta), stąd potrzeba odpalania playbooków co jakiś czas na wszystkich hostach i weryfikowanie czy dany playbook był już zastosowany dla danego hosta (to rozwiązałem przez plik kontrolny, np. /opt/ansiblepatches/playbook-121212
@maslokm: Skoro playbooki są indenpotent to po co Tworzysz plik? Po prostu przejdzie i nic nie zrobi, a odchodzi Ci konieczność weryfikacji tego pliku. Skoro host ma spoko config to ansible tylko przejedziedzie i będziesz miał same OK.
Jeżeli chcesz używać ansible tak jak puppeta to może zrób puppeta? IMO podejście puppetowe mi osobiście bardziej odpowiada i uważam, że jest lepsze jeżeli chodzi o konfiguracje maszyn.
@yggdrasil:

Skoro playbooki są indenpotent to po co Tworzysz plik? Po prostu przejdzie i nic nie zrobi, a odchodzi Ci konieczność weryfikacji tego pliku.

Robię tak dlatego, że w większości playbooków mam dużo kroków i bez sensu za każdym razem je przechodzić jeżeli playbook już raz został uruchomiony na danym hoście i zakończył się pozytywnie. Czas przejścia np. 10 playbooków skraca się do kilku sekund z kilku minut.
Tak jak pisałem-
Jak zabezpiecasz się przed tym, że jakiś serwer może być w danej chwili niedostępny?


@maslokm: Nie zabezpieczam się, dla mnie to awaria i naprawiam. Mam Jenkinsa i sobie puszcza co jakiś czas, czasami sfailuje, bo jakaś maszyna leży. Ja podchodzę do tego jak do puppeta, puszczam co jakiś czas i w jakimś skończonym czasie wszystko będzie działało. :)
@maslokm: Nie, nie do końca. Mam jednego playbooka, który jest master playbookiem i importuje wszystkie pozostałe. Każdy playbook ma skonfigurowaną grupę hostów na której się odpala. Hosty są w inventory.
Np. mam playbooka, który konfiguruje serwery baz danych i w nim mam hosts: db i w inventory mam:
[db]
server1
server2

Jak odpalam master playbooka to odpalam wszystkie i on sam wie co gdzie odpalić. Jak chcę odpalić więcej to dodaje
@yggdrasil: No to podobnie, tylko inaczej ustawiamy hosty. Ja w playbookach mam 'all', a za dobór hostów odpowiadają grupy w Rundecku. Hosty importuję z Zabbiksa, a grupy to szablony Z. przypisane do serwerów ( ͡° ͜ʖ ͡°). Ten mój 'master playbook' includuje odpowiednie dla grupy playbooki. Dla każdej z grup np. web, db utworzę osobny 'master playbook'.