Ansible kontra marionetka

Dzisiejsi specjaliści od zarządzania systemami i devopsami muszą zarządzać średnio znacznie większą liczbą serwerów hostujących znacznie większą liczbę aplikacji, niż ich odpowiedniki jeszcze z lat 90-tych. Obwiniaj za to wykładniczy wzrost mocy obliczeniowej w organizacjach w połączeniu z pojawieniem się nowych technologii, takich jak wirtualizacja i przetwarzanie w chmurze.

W związku z tym narzędzia takie jak Puppet i Ansible szybko stają się niezbędnymi komponentami do zarządzania dużą liczbą serwerów, na przykład w centrum danych. Są one powszechnie nazywane narzędziami do zarządzania konfiguracją (CM) i zdalnego wykonywania (RE) i często pokrywają się z narzędziami do aprowizacji lub orkiestracji. Te mega przydatne aplikacje pozwalają administratorowi, na przykład, wykonywać działania na kilku serwerach jednocześnie, wdrażać wiele aplikacji za pomocą jednego kliknięcia i ogólnie znacznie ułatwiają konfigurację i utrzymanie dziesiątek, setek, a nawet tysięcy serwerów.

Ansible kontra marionetka: przegląd

Puppet to jedna z największych marek na rynku CM. Istnieje najdłużej, bo od 2005 roku, co dla narzędzi CM jest jak bycie z nami od zarania ludzkości. Kilku znanych klientów prowadzi swoje centra danych za pomocą Puppet - Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs i Stanford University; Posiadanie takich klientów na pokładzie zawsze nadaje produktowi pewien poziom wiarygodności. Puppet może się również pochwalić najbardziej dojrzałym interfejsem i działa na wszystkich głównych systemach operacyjnych - Linux, Windows, Unix, a nawet Mac OS X. Podążając za modelem stworzonym przez różne wersje Linuksa, jest to aplikacja typu open source (opracowana przy użyciu Ruby), ale istnieje również duża, ugruntowana firma wsparcia i sponsora o nazwie PuppetLabs, która oferuje profesjonalne wsparcie i komercyjną wersję oprogramowania dla przedsiębiorstw. Puppet oferuje również prostą procedurę instalacji i kilka narzędzi do zadań, takich jak szybkie wdrażanie na serwerach klienckich. Oprócz graficznego interfejsu użytkownika istnieje interfejs wiersza polecenia oparty na Ruby; w rzeczywistości w przypadku najbardziej zaawansowanych zadań najprawdopodobniej będziesz musiał polegać na CLI, przy czym GUI jest interfejsem do przeglądania, zarządzania i monitorowania. Oznacza to, że oprócz pracy administratora systemu, musisz również nauczyć się Ruby.

W tym momencie możesz pomyśleć: "Wszystko to brzmi świetnie! Czy są jakieś wady, czy mogę kupić Puppet już teraz? Cóż, na forach dyskusyjnych CM mówi się, że Puppet, podobnie jak wielu innych gigantów oprogramowania, stał się ofiarą własnego sukcesu i wielkości. "Zwinny" i "zwinny" to nie są słowa, których można użyć do opisania Puppet - takie rzeczy, jak naprawianie zgłoszonych błędów i ignorowanie próśb o nowe funkcje. Pojawiają się również narzekania na to, że PuppetLabs agresywnie popycha swoich klientów w kierunku przyjęcia wersji komercyjnej. I wreszcie, chociaż Puppet obsługuje zarówno czysty Ruby, jak i jego dostosowany DSL w CLI, obsługa tylko Ruby jest przestarzała. To zła wiadomość dla tych, którzy uczyli się tylko Ruby, a nie wewnętrznego DSL.

Ansible przeskoczył Puppet, aby zdobyć największy udział w rynku w branży zarządzania konfiguracją, z wiodącym udziałem 26,5%, a następnie starzy wyjadacze MSCCM i Puppet. Po raz pierwszy wydany na początku 2012 roku, jest również open-source wspierany przez firmę macierzystą - w tym przypadku AnsibleWorks. Został opracowany w Pythonie, a nie w Ruby, co czyni go duchowo bliższym Salt (kolejnemu nowemu narzędziu CM) niż Puppet. Inną zaletą Pythona jest to, że jest on obecnie wbudowany w większość wdrożeń Uniksa i Linuksa, więc rozpoczęcie pracy jest szybsze. Unikalną propozycją sprzedaży Ansible jest jego lekkie i szybkie wdrożenie. W rzeczywistości nie używa nawet możliwych do wdrożenia agentów do komunikacji master-klient; zamiast tego wszystkie funkcje są wykonywane przez SSH. W przypadku tych konfiguracji, które nie obsługują root SSH, Ansible może "sudo" jako root. Rozwiązanie Ansible można uruchomić z poziomu interfejsu wiersza polecenia bez użycia plików konfiguracyjnych do prostych zadań, takich jak upewnienie się, że usługa jest uruchomiona lub wyzwalanie aktualizacji i ponownych uruchomień. W przypadku bardziej złożonych zadań konfiguracja rozwiązania Ansible jest obsługiwana za pomocą składni YAML w plikach konfiguracyjnych nazywanych podręcznikami. Polecenia Ansible mogą być pisane w prawie każdym języku programowania i dystrybuowane jako uniwersalne moduły JSON, co jest wyraźną zaletą w porównaniu z koniecznością wyboru jednego języka.

Ansible stał się znacznie bardziej popularny ze względu na świeże podejście, a wiele firm wdraża Ansible do wdrożeń w dużych centrach danych. Ansible i entuzjastyczna społeczność oczywiście ciężko pracują, aby wykorzystać ten sukces - poprzez zwiększenie liczby obsługiwanych urządzeń, integrację lepszej obsługi systemu Windows, ulepszenie ekosystemu i tak dalej.

Ansible a Puppet: różnice w konfiguracji

Różnice między Ansible a Puppet są widoczne już od momentu skonfigurowania narzędzi. Ponieważ narzędzia są zgodne z różnymi paradygmatami architektonicznymi, ich konfiguracja jest inna. Ansible ma wyraźny cel, aby konfiguracja była tak prosta, jak to tylko możliwe, co widać w doświadczeniu użytkownika.

Aby skonfigurować Ansible, należy wyznaczyć pojedynczy węzeł jako węzeł kontrolny. W rzeczywistości każdy z węzłów może być węzłem kontrolnym. Zainstaluj rozwiązanie Ansible w tym węźle przy użyciu najnowszego pakietu rozwiązania Ansible z repozytoriów pakietów dystrybucji. Nie ma potrzeby instalowania oprogramowania klienckiego na innych węzłach. Utwórz parę kluczy SSH w węźle kontrolnym, a następnie skopiuj ją do pozostałych węzłów. Utwórz plik spisu dla węzłów rozwiązania Ansible. Zazwyczaj trafia to do /etc/ansible/hosts w systemach operacyjnych Linux, takich jak Red Hat Linux, Ubuntu i Debian. Tak proste, że jesteś teraz gotowy do korzystania z Ansible do uruchamiania podręczników zarówno w węźle kontrolnym, jak i w pozostałej części ekwipunku. Rozwiązanie Ansible będzie używać połączeń SSH z kontrolowanymi węzłami do uruchamiania podręczników zarządzania konfiguracją.

W przypadku Puppet konfiguracja jest nieco bardziej skomplikowana, ale w Internecie jest mnóstwo dokumentacji, która pomoże w przypadku utknięcia. Konieczne będzie skonfigurowanie węzłów głównego i agenta tak, aby wszystkie miały ten sam czas i strefę czasową. Jako root zaloguj się do serwera głównego i zainstaluj oprogramowanie serwera Puppet. Skonfiguruj plik /etc/hosts wzorca marionetek, aby rozpoznać wszystkie zarządzane klienty. Uruchom usługę PuppetServer i włącz jej odbieranie połączeń klienckich na porcie 8140. Ponieważ Puppet opiera się na oprogramowaniu agenta działającym na każdym stronniku, będziesz musiał zainstalować oprogramowanie Puppet Agent na każdym kliencie. Będziesz także musiał dodać adres IP urządzenia głównego w /etc/hosts, aby upewnić się, że klient może połączyć się z urządzeniem głównym. Uruchom i włącz usługę agenta Puppet na każdym kliencie. Aby sługusy mogły komunikować się z masterem, musisz wygenerować certyfikaty SSL, ponieważ Puppet polega na HTTPS do komunikacji master-klient.

W przypadku obu konfiguracji będziesz chciał przeprowadzić odpowiednie hartowanie serwera, aby upewnić się, że nieautoryzowane połączenia nie są dozwolone.

Ansible vs Puppet: skalowalność i mechanizmy transportu

Zarówno Ansible, jak i Puppet mogą się naprawdę dobrze skalować, ale wykorzystują różne mechanizmy transportu, aby osiągnąć ten cel. W rzeczywistości, niezależnie od tego, czy chcesz zarządzać kilkuset, czy nawet dziesiątkami tysięcy węzłów, istnieją poprawki i strategie, których możesz użyć na każdej platformie, aby wygodnie skalować się do tego poziomu.

Ansible używa domyślnego mechanizmu transportu "smart", który jest zwykle rozpoznawany jako SSH. Ansible najpierw przeanalizuje Twoje playbooki i określi zasoby reklamowe, których dotyczy problem. Następnie otworzy połączenie SSH i utworzy katalog tymczasowy. Po zamknięciu tego połączenia Ansible otwiera drugie połączenie w celu skopiowania kodu modułu Ansible i kodu standardowego Ansible do wykonania. Ansible zamknie to połączenie przed otwarciem trzeciego, ostatniego połączenia w celu wykonania kodu. Ta konfiguracja będzie służyć większości celów, ale można ją dostosować w miarę skalowania zasobów reklamowych.

Pierwsza funkcja, z której może korzystać Ansible, nazywa się ControlPersist i opiera się na trwałych gniazdach w celu skrócenia czasu i uzgadniania wymaganego w przypadku wielu połączeń. Ansible obsługuje również "potokowanie", konfigurację, która zmniejsza liczbę wymaganych połączeń z trzech do jednego. Wreszcie, Ansible można skonfigurować tak, aby przetwarzał większą liczbę węzłów inwentaryzacyjnych jednocześnie, dostosowując zmienną forks w konfiguracji Ansible. Domyślnie jest to ustawione na 5, ale można ustawić je wyżej, aby uzyskać szybsze przetwarzanie.

Mechanizmem transportowym Puppet jest HTTPS, który jest zarządzany za pomocą certyfikatów SSL. Pojedynczy serwer Puppet będzie obsługiwał żądania konfiguracji z Twojego inwentarza klientów Puppet. Każdy klient wysyła informacje o Puppet do mastera i przesyła prośbę o katalog Puppet. W odpowiedzi mistrz wyśle katalog. Następnie klient przetwarza katalog, sprawdzając każdy zasób pod kątem żądanego stanu konfiguracji określonego w katalogu. Jeśli zasób nie jest w żądanym stanie, klient Puppet zaktualizuje zasób na tym komputerze klienckim, aby był zgodny z określonym żądanym stanem. Po zakończeniu aktualizacji klient wysyła raport z powrotem do serwera Puppet.

Warto zauważyć, że model przetwarzania Puppet przydziela wątek JRuby z puli wątków do obsługi każdego przychodzącego połączenia klienta. W miarę wzrostu liczby węzłów do dużych rozmiarów można dostroić platformę Puppet, aby lepiej skalować, zwiększając liczbę wątków JRuby dostępnych w puli. Możesz to zrobić, ustawiając wartość ustawienia konfiguracyjnego "max-active-instances" Puppet na wartość wyższą niż domyślna, która wynosi 1. Możesz ustawić go tak, aby był tak wysoki, jak liczba rdzeni procesora na maszynie, jednak pamiętaj, że spowoduje to użycie większej ilości pamięci RAM procesora. Zgodnie z ogólną zasadą, będziesz musiał również ustawić wyższy "maksymalny rozmiar sterty" dla JVM serwera Puppet, aby upewnić się, że dodatkowe wątki JRuby mogą zostać przydzielone bez powodowania błędu "brak pamięci" maszyny wirtualnej Java. Zachowaj ostrożność podczas tego dostrajania, ponieważ możesz natknąć się na różne potencjalne pułapki związane z wydajnością.

Przykład kodu Ansible CM

W przypadku codziennej pracy konfiguracyjnej pisanie kodu Ansible jest zaskakująco proste dzięki połączeniu dwóch czynników: używania formatu YAML dla podręczników i deklaratywnego stylu zarządzania konfiguracją, który abstrahuje od drażliwych szczegółów. Będzie to ważne dla szybkiego zwiększenia produktywności zespołów DevOps i zapewnienia łatwości zarządzania kodem, nawet w przypadku złożonych zadań konfiguracyjnych.

Kod Ansible jest idempotentny. Oznacza to, że możesz bezpiecznie uruchamiać podręczniki na swoim ekwipunku w kółko, nie psując serwerów. Ansible zmieni stany zasobów tylko na serwerach, na których te stany znajdują się poza pożądanym stanem. Jeśli na przykład podręcznik wymaga zainstalowania pakietu i utworzenia określonego pliku konfiguracyjnego na dysku, rozwiązanie Ansible zainstaluje tylko ten pakiet i utworzy plik konfiguracyjny określony przy pierwszym uruchomieniu podręcznika w węźle. Kolejne uruchomienia podręczników pozostawią pakiet nietknięty, automatycznie, dopóki nie nastąpi jakaś zmiana, która usunie lub zmieni określoną konfigurację pliku lub pakietu. Dzięki temu węzły pozostają w wysoce przewidywalnym, deterministycznym stanie z niewielką lub żadną szansą na dryf konfiguracji.

Poniżej znajduje się przykład kodu podręcznika rozwiązania Ansible, który instaluje serwer WWW Tomcat w węzłach. To jest przykład Ansible z oficjalnego repozytorium przykładów Ansible, które można przeglądać, aby lepiej zapoznać się z idiomatycznym Ansible:

---
- name: Install Java 1.7
yum: name=java-1.7.0-openjdk state=present
- name: add group "tomcat"
group: name=tomcat
- name: add user "tomcat"
user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no
become: True
become_method: sudo
- name: Download Tomcat
get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz
- name: Extract archive
command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61
- name: Symlink install directory
file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link
- name: Change ownership of Tomcat installation
file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes
- name: Configure Tomcat server
template: src=server.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat
>
- name: Configure Tomcat users
template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat
- name: Install Tomcat init script
copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755
- name: Start Tomcat
service: name=tomcat state=started enabled=yes
- name: deploy iptables rules
template: src=iptables-save dest=/etc/sysconfig/iptables
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'"
notify: restart iptables
- name: insert firewalld rule for tomcat http port
firewalld: port={{ http_port }}/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"
- name: insert firewalld rule for tomcat https port
firewalld: port={{ https_port }}/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"
- name: wait for tomcat to start
wait_for: port={{http_port}}

To konkretne zadanie Ansible pobiera i instaluje Apache Tomcat wraz z jego zależnością, Java JDK 1.7. Następnie konfiguruje, uruchamia i zabezpiecza instalację Tomcata. Jak widać, pliki zarządzane przez Ansible mogą zawierać szablony Jinja, co ułatwia obliczanie wartości i sprawia, że konfiguracja jest bardziej elastyczna. Kod YAML jest łatwy do odczytania i zapisu zarówno dla administratorów systemu, jak i programistów. Dzięki temu Ansible jest przystępnym systemem zarządzania konfiguracją zarówno dla zaawansowanych, jak i początkujących użytkowników.

Przykład kodu CM marionetki

Język specyficzny dla domeny Puppet jest zakorzeniony w Ruby, ale składnia jest znacznie bliższa językom imperatywnym w stylu C, takim jak Perl, Java i C++. To podejście jest pośrednim rozwiązaniem między programistami zaznajomionymi z Ruby a tymi, którzy mogą nie być zaznajomieni z tym językiem. W rezultacie, nie musisz w ogóle znać Ruby, aby nauczyć się Puppet DSL i stać się z nim bardzo produktywnym.

Ten przykładowy manifest Puppet z repozytorium modułu PuppetLabs MySQL Puppet instaluje pakiet klienta MySQL i konfiguruje go:

Prawidłowe wartości to "obecny", "nieobecny" lub "x.y.z".
# @param package_manage
# Czy zarządzać pakietem klienta MySQL. Wartość domyślna to "true".
# @param package_name
# Nazwa pakietu klienta MySQL do zainstalowania.
#
class mysql::client (
$bindings_enable=$mysql::p arams::bindings_enable,
$install_options=undef,
$package_ensure=$mysql::p arams::client_package_ensure,
$package_manage=$mysql::p arams::client_package_manage,
$package_name=$mysql::p arams::client_package_name,
) dziedziczy mysql::p arams {

include '::mysql::client::install'

if $bindings_enable {
class { 'mysql::bindings':
java_enable => true,
perl_enable => true,
php_enable => true,
python_enable => true,
ruby_enable => true,
}
}

# Obejście wzorca kotwicy, aby uniknąć zasobów mysql::client::install do
# "float off" poza mysql::client
anchor { 'mysql::client::start': }
-> Class['mysql::client::install']
-> anchor { 'mysql::client::end': }
}

Ważną zaletą podejścia Puppet jest to, że w przeciwieństwie do imperatywnych języków programowania wymienionych powyżej, DSL Puppet jest deklaratywny, w sposób podobny do XML, a także kodu YAML z powyższego przykładu kodu Ansible. Deklaratywne podejście zarówno Puppet, jak i Ansible naprawdę błyszczy w obu przykładach kodu. Z punktu widzenia kodowania są one podobne i bliższe sobie niż narzędzia takie jak Chef. To powiedziawszy, język deklaratywny używany przez Puppet zapewnia również konstrukcje podobne do Ruby, takie jak instrukcje warunkowe i iteracja, ponownie w stylu pośrodku drogi, który nie zrazi zarówno użytkowników Ruby, jak i osób niebędących użytkownikami.

Ansible kontra marionetka: łatwość użycia

Łatwość użycia powinna być częścią kryteriów oceny narzędzi do zarządzania konfiguracją każdego zespołu DevOps. Biorąc pod uwagę, że Ansible skupia się na prostocie użytkowania wyraźnie jako swojej największej wartości napędowej, jest to obszar, w którym radzi sobie wyjątkowo dobrze. Nie tylko konfiguracja, ale także decyzje, takie jak styl kodu i zarządzanie węzłami, pokazują podejście tematyczne, które przedstawia prosty interfejs inżynierom DevOps, niezależnie od tego, czy wywodzą się z doświadczenia programisty, czy administratora systemu.

Nie oznacza to, że Puppet jest trudny w użyciu, nie do końca. Puppet ma mnóstwo mocy, a jego uparte podejście do zarządzania konfiguracją sprawia, że większość rzeczy jest oczywista, o ile podążasz drogą Puppet, aby zautomatyzować swoją infrastrukturę. Na tym froncie Puppet ogromnie pomaga, modelując jawnie każdy zasób i dostarczając moduły, które mają standardowe zachowania, których możesz użyć w swoich manifestach.

Z punktu widzenia krzywej uczenia się obie platformy są łatwe w użyciu, ale Ansible ma niewielką przewagę. Deklaratywny styl YAML jest łatwy do opanowania, a kod Ansible nigdy nie staje się zbyt skomplikowany. W międzyczasie firma Puppet dostrzegła niektóre wyzwania związane z łączeniem danych i kodu w tych samych plikach źródłowych. Przyczyniło się to do powstania Puppet Hiera, rozwiązania do przechowywania danych, które wykorzystuje format YAML do przechowywania par klucz-wartość danych konfiguracyjnych. Hiera przechodzi długą drogę do uproszczenia i optymalizacji środowiska DevOps Puppet. Format YAML okazał się popularny w przypadkach użycia zarządzania konfiguracją, a Salt by Saltstack również korzysta z tego formatu.

Zarówno Puppet, jak i Ansible mają możliwości sprawdzania i testowania zarządzania konfiguracją, od sprawdzania składni po integrację kodu infrastruktury jako kodu.

Ansible kontra Puppet: licencje i koszty przedsiębiorstwa

Jako narzędzia open source, Ansible i Puppet mają ze sobą wiele wspólnego, jeśli chodzi o licencjonowanie.

Po pierwsze, wersja open source Ansible jest dostępna całkowicie bezpłatnie. W przypadku przedsiębiorstw, które wymagają więcej gwarancji bezpieczeństwa, stabilności i niezawodności, można uaktualnić do Ansible Engine, który jest obsługiwaną, wzmocnioną wersją klasy korporacyjnej dostarczaną przez firmę Red Hat. Koszty licencji Ansible Engine wynoszą zazwyczaj od 47,50 do 70 USD rocznie za węzeł i różnią się w zależności od preferowanej konfiguracji.

Z pewnością warto zaopatrzyć się w wersję enterprise, jeśli weźmiesz pod uwagę dostępność płatnej pomocy technicznej i to, jak może to pomóc w rozwiązywaniu problemów i ich szybszym rozwiązywaniu. Ansible Tower, narzędzie do zarządzania przedsiębiorstwem, jest również dostępne jako pakiet usług i daje Twojemu zespołowi więcej możliwości w zakresie wiedzy, kontroli i planowania zadań z poziomu pulpitu nawigacyjnego GUI.

Podobnie jak Ansible, wersja open source Puppet jest dostępna za darmo. Aby uzyskać więcej funkcji i wsparcia dla przedsiębiorstw, organizacje mogą uaktualnić do Puppet Enterprise, który kosztuje około 112 do 199 USD rocznie za węzeł. Puppet Enterprise oferuje pakiet wielu narzędzi Puppet na poziomie korporacyjnym w jednej instalacji, wraz z narzędziami do raportowania i monitorowania klasy korporacyjnej, a także innymi zaletami w porównaniu z wersją open source.

Ansible kontra marionetka: społeczność

Puppet, uruchomiony w 2005 roku, jest starszym z tych dwóch narzędzi DevOps, dzięki czemu miał więcej czasu na budowanie swojej społeczności i bazy użytkowników. Jednak Ansible, uruchomiony w 2012 roku, dzięki nowatorskiemu podejściu, był w stanie przyciągnąć jeszcze większą publiczność i stworzyć w tym czasie bardzo żywą społeczność użytkowników i współpracowników. Do użytkowników Puppet należą firmy takie jak Uber, Salesforce i PayPal. Z drugiej strony społeczność Ansible obejmuje firmy takie jak Digital Ocean, 9GAG i TypeForm.

Społeczność Ansible na Githubie, mierzona przez współtwórców, ważny wskaźnik w społeczności open source, jest teraz większa niż Ansible, z ponad 4,800 współtwórcami na 527 Puppet. Dynamika Ansible w ciągu ostatnich kilku lat była bardzo szybka i przełomowa. Znajduje to odzwierciedlenie w zawrotnym tempie, w jakim eksplodowała liczba ról współdzielonych przez użytkowników Ansible w repozytorium społeczności Ansible współdzielonego kodu Ansible, Ansible Galaxy. Oznacza to, że społeczność Ansible przyjęła to narzędzie i jest chętna do dzielenia się swoim kodem i wnoszenia wkładu w społeczność.

Tymczasem społeczność Puppet, choć wolniej się rozwija i jest bardziej stabilna, zbudowała infrastrukturę, aby ułatwić znalezienie rozwiązań dla potrzeb Puppet od reszty społeczności. Puppet Forge zapewnia moduły współtworzone przez społeczność do wykonywania typowych zadań związanych z zarządzaniem konfiguracją dla społeczności Puppet.

Oba te narzędzia mają najwyższej klasy narzędzia wiersza poleceń, które umożliwiają precyzyjną kontrolę nad całym cyklem życia projektu zarządzania konfiguracją. Oba dobrze integrują się z innymi powszechnie używanymi systemami devops, takimi jak Docker, Kubernetes i Jenkins, lub platformami przetwarzania w chmurze, takimi jak AWS i Azure.

Czy Ansible czy Puppet są lepsze?

Które z tych dwóch narzędzi jest dla Ciebie najlepsze, to pytanie, które tylko Ty możesz określić. Deklaratywny styl zarówno Ansible, jak i Puppet oznacza, że narzędzia te mają ze sobą więcej wspólnego niż z wieloma innymi narzędziami do zarządzania konfiguracją. Jednak, aby dokonać najlepszego wyboru dla swojego zespołu, musisz zwrócić szczególną uwagę na to, jak Twoje potrzeby zazębiają się z projektem i mocnymi stronami narzędzia.

Ansible powinno być lepszym rozwiązaniem dla zespołów, które są zainteresowane konfiguracją w stylu YAML i które są zsynchronizowane z filozofią Ansible. Filozofia ta zakłada, że jest ona bardzo prosta i wymaga minimalnej krzywej uczenia się, a jednocześnie dąży do bardzo szybkiego i równoległego zarządzania maszynami. Ponadto to podejście jest bez agenta i ma na celu użycie istniejących funkcji SSH zamiast tworzenia niestandardowych agentów.

Z drugiej strony Puppet powinien być lepszym rozwiązaniem dla zespołów, które chcą DSL, który modeluje zasoby systemowe w spójny, powtarzalny sposób. To właśnie osiąga Puppet DSL, wraz z całym ekosystemem narzędzi, dzięki którym praca z dużymi zespołami jest przewidywalna i łatwa.

Tylko Ty możesz powiedzieć, który z tych dwóch opisów lepiej pasuje do Twojego zespołu. Jeśli tak, wybór powinien być łatwy.

Streszczenie

Czy powinieneś więc wybrać Ansible czy Puppet? Nie ma na to łatwej odpowiedzi - to zależy od Twoich potrzeb.