Czym różni się Ansible od zwykłego uruchamiania powłoki bashowej w Vagrant?


39

Zespół sysadminów IT, którzy mają doświadczenie w używaniu skryptów powłoki do rozwiązywania swoich problemów, rozważa rozpoczęcie korzystania z Ansible.

Czy istnieją znaczne różnice i dobre powody, aby zacząć używać Ansible vs. kontynuować pisanie skryptów powłoki?

Odpowiedzi:


29

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:

  1. 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.

  2. 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.


To wygląda jak instrukcja ... imponująca!
Pierre.Vriens

4
Nie mogłem się więcej zgodzić. Używamy Ansible od ponad roku i teraz używamy kontenerów Docker, zbudowanych z dobrych, prostych, starych skryptów bash. Zdefiniowanie stanu jest również moim zdaniem zdecydowanie najciekawszą funkcją, ale jak już wspomniałeś - jest tak wiele usług, które nie mają odpowiedniego modułu Ansible, więc zawsze musisz wracać do poleceń bash. I tak, wdrażamy tylko niezmienne kontenery na serwerach, więc zdefiniowanie stanu nie jest w tym przypadku żadną korzyścią.
Andreas

1
Po dokładnym użyciu ansible mogę potwierdzić wszystkie punkty, które uczyniłem a priori. Idempotencja jest możliwa, ale nie wymuszona przez ansible (patrz moduł vmware_guest dla złego obywatela), praca z ich systemem makro jest prawdziwym bólem i niezwykle trudno jest wykonać nawet najbardziej podstawowe zabiegi na ustrukturyzowanych danych, niektóre podstawowe rzeczy są po prostu złe (format podręcznika nie może zjadać trybu plików Uniksa bez terapii), a jedyną dobrą rzeczą jest ładunek przydatnych funkcji napisanych dla ansible. Więc gdyby nie Red Hat pchający ten produkt, nie rozumiem szerokiej adopcji.
Michael Le Barbier Grünewald

1
@Andreas Zgadzam się, że wciąż masz wiele przypadków, w których musisz polegać na powłoce lub modułach poleceń, co nie oznacza, że ​​twoja gra w trybie ansible nie może być idempotentna. Same moduły podstawowe utrzymują idempotencję, po prostu sprawdzając, czy należy wykonać akcję. Możesz zrobić to samo z powłoką lub modułem poleceń, najpierw uruchamiając zadanie, które sprawdza, czy coś należy zrobić, i rejestrując jego wyniki, a następnie warunkowo wykonując drugie zadanie na podstawie danych wyjściowych z pierwszego zadania.
Levi

1
@ MichaelLeBarbierGünewald, muszę się ogólnie zgodzić, kiedy pracowałem z Ansible, to był prawdziwy ból, aby uruchomić i jego praca zajmuje tygodnie, aby zebrać podręcznik, aby połączyć się z infrastrukturą w mojej byłej firmie działającej w chmurze, zapewnić Linuksa dystrybucja, zainstaluj LAMP / LEMP lub cokolwiek innego. Po jej ukończeniu zaoszczędził nam czas, ale uruchomienie go zajęło miesiąc. Żadne z nas nie było mistrzami skryptów bash, więc nie była to alternatywa.
Daniel

22

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:

  1. Deklaratywne, idempotentne zarządzanie konfiguracją
  2. Dostęp do fragmentów wielokrotnego użytku (tj. Podręczników) dla popularnych usług w branży.
  3. Niezawodne zarządzanie zdalnym wykonywaniem, z ponawianiem, logiką kroczącą itp.

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.


4
Podobała mi się twoja odpowiedź; Chciałbym również wspomnieć, że jeśli zespół bash dąży do idempotencji, zarządzania wykonaniem i ponownego użycia, w zasadzie pisząc własną strukturę zarządzania konfiguracją, wiąże się to z kosztami i wszyscy wiemy, że może to być naprawdę nieprzyjemne dla projektów wewnętrznych .
ᴳᵁᴵᴰᴼ

Zgadzam się również z twoją odpowiedzią, zwłaszcza po zbilansowaniu dostępnych doświadczeń. Mam dwóch małych krytyków: pierwszy to idempotencja Jest to oczywiście ważny aspekt systemów konfiguracyjnych, ale ponieważ możliwe jest użycie dowolnych poleceń powłoki w odpowiadających podręcznikach, system może co najwyżej zachęcić do używania idempotencji. (Właściwie chcemy czegoś potężniejszego niż idempotencja aba = ab .) Po drugie, niezawodne zarządzanie zdalnym wykonywaniem może być całkowicie nieistotne w niektórych ważnych przypadkach, np. Podczas implementacji niezmiennego wzorca serwera za pomocą obrazów instancji.
Michael Le Barbier Grünewald

13

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ć.


2
Czy możesz również dodać jakieś odniesienie do „teorii obietnicy”, na przykład książek lub artykułów, i innych cennych materiałów, jeśli ktoś chce się o niej dowiedzieć?
Evgeny

1
Właśnie o tym wspomniałem, kiedy powiedziałem, że możesz napisać idempotentny kod bashowy (tzn. Że można go uruchomić w dowolnym momencie, uruchamiać wiele razy i konwertować do pożądanego stanu). Ale twoja odpowiedź wyjaśniła.
Assaf Lavie

Tak, idempotencja jest ważną właściwością systemów konwergentnych, ale te dwa nie zawsze są bezpośrednio połączone :) jeśli chodzi o materiały na temat teorii promise, Mark Burgess (twórca CFEngine) ma kilka książek, mogę znaleźć linki, kiedy wrócę laptop.
coderanger


3

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.


Czy Ansible nie jest w tym sensie tylko opakowaniem wokół ssh?
Evgeny

Zasadniczo tak. Robi ssh, zdalnie kopiuje skrypty python i je uruchamia. Oznacza to, btw, że jeśli moduł ansible zależy od biblioteki Pythona, biblioteka ta powinna w pewnych okolicznościach być obecna na komputerze zdalnym.
Assaf Lavie

1
A jeśli popsujesz konfigurację ssh, zostaniesz zablokowany na swoim komputerze, co jest zwykle wadą push vs. pull.
Tensibai,

1

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.


Najpierw działa w systemie Windows za pośrednictwem Win_RM lub SSH. Po drugie, składnia yaml jest bardzo ładna i może być generowana programowo, a podczas gdy niektóre błędy mogą wprowadzać w błąd, nie różni się niczym od Javy lub Pythona, które wystukiwały swoje wyjątki. Po trzecie, po prostu SCPing skryptu na serwer nie ma zastosowania w wysoce dynamicznych środowiskach chmurowych. Który serwer? Serwery mogą zmieniać się każdego dnia. Ansible umożliwia łatwe do skonfigurowania wtyczki zasobów reklamowych z łatwymi sposobami grupowania serwerów i przypisywania im zmiennych. Nie sądzę, żeby Ansible nie był tego wart. Myślę, że to przesada dla twojego środowiska.
Levi

@Levi tak. To wszystko moja wina, że ​​ansible nie działa w systemie Windows, ma konfigurację, która nie ma schematu, i ma dłuższą krzywą uczenia się i wyższe koszty utrzymania niż jakakolwiek inna metoda realizacji tego samego zadania.
Richard

W środowiskach chmurowych istnieją inne podejścia do rodzajów dużych przedsiębiorstw, które mogą uzasadniać krzywą uczenia się. Rozumiem, co robi ansible. Po prostu nie widzę jego niszy.
Richard

Nisza to łatwa w użyciu struktura automatyzacji dla wielu maszyn. Nie jest tak świetny dla systemu Windows, jak dla systemu Linux. Nie jest też świetny dla MSDOS i Netware. Jest rok 2019, serwery Windows są obecnie małą bezużyteczną niszą.
dyasny
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.