Nigdy nie korzystałem z Ansible, ale od kilku tygodni staram się dowiedzieć, co może być dobry Ansible w porównaniu do skrawków powłok - co dowodzi, przynajmniej w moim przypadku, że kampanie reklamowe, które prowadzą, są skuteczne! Po wielu nieudanych próbach - co dowodzi, że ich dokumentacja nie odpowiada na jedno z najbardziej oczywistych pytań - myślę, że w końcu to dostałem:
Teraz obejrzyjmy wideo wprowadzające i przejdźmy losowo jako potencjalny nowy użytkownik poprzez materiał wprowadzający do Ansible i porównajmy to z tym, co wykwalifikowany programista powłoki może wyprodukować od razu.
Doszedłem do wniosku, że w porównaniu ze skryptami powłoki, Ansible zasadniczo oferuje 1. Możliwość sprawdzenia, czy system zgadza się z pożądanym stanem, 2. zdolność do integracji z Ansible Tower, który jest systemem płatnym, który wydaje się obejmować funkcje monitorowania. W niektórych ważnych przypadkach, takich jak implementacja niezmiennego wzorca serwera, punkt 1 jest prawdopodobnie mało przydatny, więc lista jest raczej cienka.
Doszedłem do wniosku, że korzyści oferowane przez Ansible w porównaniu ze skryptami powłoki, jakie prezentują dokumentacja, mogą być sensowne w kilku garści optymistycznych przypadków dobrze opisanych przez dostępne moduły, ale są niewielkie lub nawet hipotetyczne w ogólnym przypadku. Prawdopodobnie dla wykwalifikowanego programisty powłoki korzyści te są najprawdopodobniej zrównoważone przez inne aspekty kompromisu.
Ale może to tylko dowodzi, jak zły jest materiał wprowadzający!
Film Szybki start:
Jest wideo szybkiego startu . Zaczyna się od strony, która twierdzi, że… cóż, to nie są tak naprawdę twierdzenia, są to listy wypunktowane, artefakt powszechnie używany do zawieszania krytycznego osądu w prezentacjach (ponieważ logiki nie pokazano, nie można jej krytykować!)
1. Odpowiedź jest prosta:
1.1 Automatyzacja czytelna dla człowieka - Specyfikacje to dokumenty techniczne, w jaki sposób
name: upgrade all packages
yum:
name: '*'
state: latest
być łatwiejsze do odczytania niż odpowiednie wywołanie yum znalezione w skrypcie powłoki? Co więcej, każdy, kto miał kontakt z AppleScript, umiera ze śmiechu, gdy czyta „automatyzację czytelną dla człowieka”.
1.2 Nie są wymagane specjalne umiejętności kodowania - co to jest kodowanie, jeśli nie pisanie formalnych specyfikacji? Mają warunkowe, zmienne, więc jak to nie koduje? I dlaczego miałbym potrzebować czegoś, czego nie mogę zaprogramować, co odtąd byłoby nieelastyczne? Oświadczenie jest na szczęście niedokładne!
1.3 Zadania wykonywane w kolejności - być może niektórzy miłośnicy kodegolfów znają języki, które wykonują zadania w nieładzie, ale wykonywanie zadań w kolejności prawie nie wygląda wyjątkowo.
1.4 Szybka wydajność - wykwalifikowani programiści powłoki są teraz wydajni. Ten kontrargument jest równie poważny jak argument początkowy.
2. Ansible jest potężny
Popularną sztuczką sprzedawców, aby sprzedawać artefakty, jest oszukiwanie ludzi w przekonanie, że zdobędą „moc” tych artefaktów. Historia reklamy samochodów lub napojów izotonicznych powinna dostarczyć przekonującej listy przykładów.
W tym przypadku Ansible może wykonać „wdrożenie aplikacji” - ale skrypt powłoki na pewno tak robi, „zarządzanie konfiguracją”, ale jest to zwykłe określenie celu narzędzia, a nie funkcji i „organizacji przepływu pracy”, która wygląda nieco pretensjonalnie, ale nie ma takiego przykładu poza tym, co potrafi GNU Parallel .
3. Ansible jest bezagentowy
Aby wypełnić tę kolumnę, napisali na trzy różne sposoby, że wymaga to tylko ssh, co, jak wszyscy wiedzą, jest demonem i nie ma nic wspólnego z tymi agentami przenikającymi zarządzanie konfiguracją świata!
Reszta wideo
Pozostała część filmu przedstawia inwentaryzacje, które są statycznymi listami zasobów (jak serwery) i pokazuje, jak wdrożyć Apache na trzech serwerach jednocześnie. To naprawdę nie pasuje do mojego sposobu pracy, w którym zasoby są bardzo dynamiczne i można je wyliczyć za pomocą narzędzi wiersza polecenia dostarczonych przez mojego dostawcę chmury i zużyte przez moje funkcje powłoki za pomocą |operatora potoku . Ponadto nie wdrażam Apache jednocześnie na trzech serwerach, buduję obraz instancji nadrzędnej, którego używam do uruchomienia 3 instancji, które są dokładnymi replikami jednego z nich. Zatem „aranżująca” część argumentacji nie wydaje się bardzo trafna.
Losowa dokumentacja krok 1: Integracja z EC2
EC2 jest usługą komputerową firmy Amazon, interakcja z nią jest obsługiwana przez moduł Ansible . (Zapewniani są także inni popularni dostawcy usług w chmurze):
# demo_setup.yml
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
Odpowiedni skrypt powłoki byłby zasadniczo identyczny z YAML zastąpionym przez JSON:
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --image-id …
}
lub wersja JSON
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}
provision_a_set_of_instances__json()
{
cat <<EOF
{
"ImageId": …
}
EOF
}
Obie wersje są zasadniczo identyczne, większość ładunku to wyliczenie wartości inicjalizacyjnych w strukturach YAML lub JSON.
Losowa dokumentacja krok 2: Ciągła dostawa i stopniowe aktualizacje
Największa część tego przewodnika nie wyświetla żadnej naprawdę interesującej funkcji: wprowadza zmienne (IIRC, skrypty powłoki również mają zmienne) !, a moduł Ansible obsługuje mysql, więc jeśli zamiast szukać po „jak utworzyć użytkownika mysql z uprawnieniami na XY ”i kończą się czymś takim
# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
wyszukujesz po „jak utworzyć użytkownika mysql z uprawnieniami na XY w ansible ” i skończyć z
- name: Create Application DB User
mysql_user: name={{ dbuser }} password={{ upassword }}
priv=*.*:ALL host='%' state=present
Różnica nadal prawdopodobnie nie jest zbyt znacząca. Na tej stronie odkrywamy również, że Ansible ma szablonowy język programowania
{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}
Kiedy to widzę, naprawdę znajduję się w mojej strefie komfortu. Ten rodzaj prostego metaprogramowania dla języków deklaratywnych jest dokładnie tym samym paradygmatem teoretycznym, co pliki makefile BSD! Które zdarzyło mi się intensywnie zaprogramować. Ten fragment pokazuje nam, że obietnica pracy z plikiem YAML jest zerwana (więc nie mogę uruchamiać swoich podręczników za pomocą parsera YAML, np .). Pokazuje nam również, że Ansible musi omówić subtelną sztukę porządku oceny: musimy zdecydować, czy zmienne są rozwijane w „deklaratywnej części” języka, czy w „imperatywnej” meta-części języka. Tutaj programowanie w powłoce jest prostsze, nie ma meta-programowania, oprócz jawnego eval lub zewnętrznego pozyskiwania skryptów. Byłby to hipotetyczny ekwiwalent skorupy
enumerate_group 'monitoring' | {
while read host; do
…
done
}
którego złożoność w porównaniu z wariantem Ansible jest prawdopodobnie możliwa do zaakceptowania: po prostu wykorzystuje proste, nudne konstrukcje z języka.
Losowa dokumentacja krok 3: Strategie testowania
Na koniec spotykamy coś, co okazuje się pierwszą naprawdę interesującą cechą Ansible: „Zasoby Ansible to modele stanu pożądanego. W związku z tym nie powinno być konieczne testowanie uruchamiania usług, instalowania pakietów ani innych podobnych rzeczy. Ansible to system, który zapewni, że te rzeczy są deklaratywnie prawdziwe. Zamiast tego zaznacz te rzeczy w swoich podręcznikach. ”Teraz zaczyna to być trochę interesujące, ale:
Oprócz garstki standardowych sytuacji, które są łatwo wdrażane przez dostępne moduły, będę musiał samodzielnie wprowadzić bity implementujące test, co prawdopodobnie będzie wymagało niektórych poleceń powłoki.
Sprawdzanie zgodności instalacji może nie być bardzo istotne w kontekście, w którym implementowany jest niezmienny wzorzec serwera: gdzie wszystkie działające systemy są zwykle spawnowane z obrazu głównego (na przykład obrazu instancji lub obrazu dokera) i nigdy nie są aktualizowane - są one zastępowane przez nowy zamiast.
Niepokojone obawy: łatwość konserwacji
Materiał wprowadzający z Ansible ignoruje kwestię łatwości konserwacji. Zasadniczo bez systemu typów, skrypty powłoki mają łatwą w utrzymaniu obsługę JavaScript, Lisp lub Python: rozległe refaktoryzacje można osiągnąć z powodzeniem tylko za pomocą obszernego zautomatyzowanego oprogramowania testowego - lub przynajmniej projektów umożliwiających łatwe interaktywne testowanie. To powiedziawszy, podczas gdy skryptowanie powłoki jest lingua franca od konfiguracji systemu i konserwacji, prawie każdy język programowania ma interfejs do powłoki. Jest zatem całkowicie wykonalne wykorzystanie przewagi łatwości konserwacji w zaawansowanych językach, używając ich do sklejenia różnych bitów bitów konfiguracji powłoki. Dla OCaml napisałem Rashell co zasadniczo zapewnia zestaw wspólnych wzorców interakcji dla podprocesów, co sprawia, że tłumaczenie skryptów konfiguracyjnych na OCaml jest w zasadzie banalne.
Po stronie Ansible, bardzo słaba struktura podręczników i obecność funkcji metaprogramowania sprawiają, że sytuacja jest tak samo zła, jak w przypadku skryptów powłoki, z minusami, że nie jest oczywiste, jak pisać testy jednostkowe dla Ansible , a argumentu wprowadzenia ad-hoc języka wyższego poziomu nie można naśladować.
Idempotencja kroków konfiguracji
Dokumentacja Ansible zwraca uwagę na konieczność napisania idempotentnych kroków konfiguracji. Dokładniej, kroki konfiguracji należy zapisać, aby sekwencję kroków aba można uprościć do ab , tzn. Nie musimy powtarzać kroku konfiguracji. To jest silniejszy warunek niż idempotencja. Ponieważ Ansible pozwala podręcznikom używać dowolnych poleceń powłoki, sam Ansible nie jest w stanie zagwarantować, że ten silniejszy warunek zostanie spełniony. To zależy tylko od dyscypliny programisty.
Kiedy ujmujesz to w ten sposób, nawet jeśli Ansible ma pewne nieodłączne zalety, korzyści z używania znanych narzędzi (w tym przypadku skryptów powłoki) muszą zostać zrównoważone. Nie sądzę, że istnieje jednoznaczna odpowiedź na to pytanie.
Jeśli zespół jest w stanie osiągnąć rzeczy, które oferuje Ansible za pomocą powłoki:
wtedy prawdopodobnie mogliby trzymać się tego, co wiedzą.
W końcu możesz wprowadzić „strażników” w BASH. Możesz znaleźć wiele istniejących BASH-ów, aby rozwiązać różnorodne zadania związane z konfiguracją serwera (zasadniczo każdy plik Docker zawiera 90% kodu instalacyjnego bash). Możesz zbliżyć się do tego, co oferuje Ansible / Salt / Chef-Zero, bez konieczności przenoszenia całego istniejącego rozwiązania na te narzędzia.
Jest to balansowanie między tendencjami NIH (nie wymyślonymi tutaj) a wyrzucaniem dobrych, ustalonych skryptów na rzecz bardziej niezawodnego rozwiązania.
Jeszcze jedna uwaga do zapamiętania: jak Twój stos technologii mierzy się, gdy próbujesz rekrutować więcej osób do zespołu. Znalezienie osób, które mają doświadczenie w Ansible, jest o wiele łatwiejsze niż znalezienie osób, które mają doświadczenie w konkretnym domowym narzędziu skryptowym CM. To nie jest kwestia czysto techniczna, bardziej kulturowa. Czy chcesz być dziwną organizacją, która wymyśla własną Ansible, czy też chcesz być rozsądną organizacją, która znajdzie odpowiednie narzędzie do pracy? Te decyzje wpływają na twoją zdolność przyciągania talentów.
źródło
Powyższa odpowiedź obejmuje jej część, ale pomija jeden z ważnych elementów: projekt zbieżny. Niedawno napisałem o tym kilka słów w kontekście szefa kuchni na https://coderanger.net/thinking/, ale w krótkiej wersji skrypt bash jest zestawem instrukcji, podczas gdy instrukcja Ansible (lub przepis szefa kuchni, sól stan itp.) to opis pożądanego stanu. Dokumentując stan, który chcesz, a nie kroki, które chcesz podjąć, aby go osiągnąć, możesz poradzić sobie z większą liczbą stanów początkowych. To było sedno teorii promise przedstawionej w CFEngine dawno temu, a projekt, który my (narzędzia do zarządzania konfiguracją) właśnie kopiujemy.
tl; dr Kod Ansible mówi, co chcesz, kod bash mówi, jak coś zrobić.
źródło
Jedną rzeczą wartą odnotowania jest to, że będziesz mieć mniej problemów z uruchamianiem ansbooków na zdalnych hostach. Ponieważ jest to główny powód uruchomienia ansible. Kiedy używasz skryptów powłoki, nadal musisz mieć sposób na skrypty scp'ing do zdalnego hosta.
źródło
Jest rok 2019 i właśnie spędziłem kilka dni na krzywej uczenia się ansible i oto absolutna prawda: Ansible nie jest warte kłopotów.
nie jest ukończony, nie działa w systemie Windows, a połączenie konfiguracji YAML i mylących komunikatów o błędach spowoduje krwawienie oczu. Wydaje się to prawie celowo okropne i mam na myśli to poważnie. Wyraźnie jest to efekt sfrustrowanego projektu dewelopera redhat sysadmins. Prawdopodobnie hipster.
Jeśli nie potrzebujesz żadnych jego funkcji poza obsługą administracyjną, a tylko w jednym systemie operacyjnym. Na litość boską napisz porządny shell.script.
W tej chwili cały projekt przypomina mi wczesne fora linuksowe, na których informowano RTFM o Noobach i wyśmiewano go, pytając, dlaczego ktoś nie może napisać GUI do konfiguracji ustawień graficznych. Po prostu tego nie rozumiesz, prawda? Powinieneś przykleić się do okien ... być może ja się połączę ... szczęśliwego VI-inga.
Użyj Dockera. W przeciwieństwie do czegokolwiek. Docker jest niezwykle prosty i potężny.
Ale co, jeśli absolutnie musisz zapewnić istniejącą puszkę? Jakie są prawdziwe alternatywy?
Cóż ... jeszcze ich nie ma. Ale obiecuję ci to, chyba że odpowiedź stanie się lepsza, będzie wkrótce. Ponieważ bez względu na to, jak mocno kibice popychają go i wybaczają jego błędy ... to 5 na 10 za wysiłek.
SCP uruchom skrypt bash i oszczędzaj sobie kłopotów.
źródło