Red Hat Ansible Automation Platform
Ansible powstało w 2012 roku, a od 2015 roku stało się własnością firmy Red Hat. Cechuje go bezagentowość, prostota i bardzo duże możliwości. Nadaje się do automatyzacji nie tylko rozwiązań Red Hat, czy systemów z rodziny GNU/Linux. Z powodzeniem jest stosowany w automatyce rozwiązań Microsoft, środowisk DevOps, usług chmurowych, platform do kontenerów i wirtualizacji, a nawet całych centrów danych czy sieci. Ilość zastosowań i obsługiwanych produktów ciągle rośnie.
Red Hat Ansible Automation jest platformą o otwartym kodzie (ang. Open Source) do szerokorozumianej automatyzacji z użyciem Ansible. Nadaje się zarówno do automatyzacji niskopoziomowej, która realizowana jest bezpośrednio, na każdym z elementów oddzielnie, jak i wysokopoziomowej, która realizowana jest poprzez dedykowane kontrolery innych producentów. Sprawia to, że oprócz bezpośredniej automatyzacji różnych rozwiązań firmy Red Hat oraz produktów firm trzecich, spaja dodatkowo automatykę w ramach całego środowiska informatycznego, opartego o produkty i rozwiązania wielu producentów.
Platforma ta posiada także komponent decyzyjny, który jest w stanie realizować określone zadania w oparciu o dynamicznie zmieniające się warunki czy też reagować na wskazane zdarzenia. Odpowiada za to komponent EDA (Event-Driven Ansible). Zbiór zasad reagowania na konkretne zdarzenia składowany jest formie w tak zwanego Rulebook. Dzięki temu platforma ta jest w stanie m.in. zebrać i dostarczyć dodatkowe informacje powiązane z wystąpieniem awarii lub wykrytym incydentem bezpieczeństwa, automatycznie rozwiązać problem z działaniem wdrożonej aplikacji/usługi czy eskalować problem do odpowiedniego zespołu. Zdarzenia takie może odbierać z użyciem m.in. webooka, kolejek zdarzeń z AWS, Azure i Apache Kafka, journald systemu GNU/Linux i zmian w plikach. Jest także w stanie monitorować konkretne URL i stosownie reagować na podstawie otrzymanej odpowiedzi.
Zapraszamy do
W ramach platformy dostępny jest interfejs CLI i WebUI oraz API do integracji z zewnętrznymi rozwiązaniami. Platforma udostępnia scentralizowane zarządzanie oraz wgląd w bieżące i historyczne zdarzenia. Da się w niej tworzyć bardzo zaawansowane przepływy zadań, które mogą być od siebie zależne oraz być wykonywane warunkowo. Obsługiwany jest też harmonogram, który umożliwia cykliczne wykonywanie zadań i ułatwia weryfikację zgodności (ang. compliance). Dostęp do jej poszczególnych elementów da się odpowiednio różnicować i kontrolować. Umożliwia także wygodną integrację z wewnętrznymi i zewnętrznymi pojemnikami poświadczeń oraz bazami użytkowników. Wykorzystuje natywnie dostępne i popularne sposoby zarządzania, do których należy m.in. SSH (Secure Shell), WinRM (Windows Remote Management), NETCONF (RFC 6241), RESTCONF (RFC 8040) czy API. Dzięki temu, zwykle można z niej korzystać bez większych zmian wewnątrz infrastruktury i na zarządzanych węzłach, jak rekonfiguracja zapór sieciowych (ang. firewall) czy instalacji dodatkowego oprogramowania w postaci agentów pośrednich.
Red Hat Ansible Automation Platform udostępnia teraz jeden, zunifikowany interfejs do monitorowania i zarządzania wszystkimi swoimi komponentami, w skład których wchodzi m.in.:
- Automation Analytics - zawiera dodatkową analitykę, raporty i statystyki.
- Automation Content - udostępnia funkcjonalność Private Automation Hub do składowania kolekcji Ansible oraz repozytorium dla obrazów kontenerów ze środowiskami wykonawczymi (Execution Environments) do automatyzacji.
- Automation Decisions - służy do obsługi strumieni zdarzeń, powiązanych z komponentem EDA (Event-Driven Ansible) i ich obsługą, w ramach zdefiniowanych w Rulebook-ach zasad reagowania (routing zdarzeń do odpowiednich Rulebook-ów).
- Automation Execution - zawiera funkcjonalność Automation Controller (dawny Ansible Tower), gdzie możemy w centralny sposób obsługiwać i uruchamiać wybrane zestawy zadań (tak zwane "Jobs").
- Access Management - do obsługi RBAC (Role Based Access Control) w oparciu o organizacje, zespoły i użytkowników.
- Ansible Lightspeed z IBM watson Code Assistant - usługa z generatywnym AI (ang. generative AI) dla użytkowników platformy (zamienia opisany przez nas zamiar na fragment kodu Ansible w języku YAML).
W ramach subskrypcji dostępny jest także Red Hat Automation Hub, który zawierający certyfikowane kolekcje, role i moduły Ansible. Dostępny jest on pod adresem URL: https://console.redhat.com/ansible/automation-hub.
Red Hat Ansible Automation Platform Self-Service udostępnia interfejs samoobsługowy dla personelu nietechnicznego lub mniej technicznego. Za jego pomocą mogą one w sposób kontrolowany (bez lub z zatwierdzeniem) samodzielnie tworzyć nowe usługi, aplikacje lub systemy w ramach lokalnej infrastruktury i środowisk chmurowych.
Red Hat Insights dla Red Hat Ansible Automation Platform zapewnia dodatkowe narzędzia analityczne, których celem jest dostarczanie informacji o automatyzacji i wpływie automatyzacji na całe przedsiębiorstwo w skali całego przedsiębiorstwa.
Początkowa architektura Red Hat Ansible Automation Platform, bazująca na Ansible Tower i Ansible Engine, miała ściśle powiązany ze sobą Control Plane i Execution Plane. Chociaż możliwe było używanie różnych środowisk wirtualnych interpretera Python, z różnymi wersjami i komponentami Ansible, były one obsługiwane czy też zarządzane w sposób ręczny. W rezultacie proces ten był złożony, żmudny i podatny na błędy oraz wymagał zaangażowania administratorów platformy.
Nowa wersja Red Hat Ansible Automation Platform może natywnie obsługiwać wiele różnych środowisk wykonawczych (Execution Environments), dostosowanych do automatyzacji określonych scenariuszy, urządzeń i systemów. Nowa architektura platformy realizuje warstwę sterowania z użyciem Automation Controller, który zastąpił Ansible Tower.
Wprowadzenie separacji między warstwą sterowania, a warstwą wykonawczą zapewnia znacznie większą elastyczność, stabilność i przewidywalność całej automatyzacji. Execution Environment to samodzielny obraz RHEL (Red Hat Enterprise Linux) UBI (Universal Base Image) w wersji 8 lub 9, który wykonuje zadania automatyzacji w formie działającego kontenera.
Taki obraz zawiera w sobie odpowiednią wersję interpretera Python oraz Ansible, wraz ze wszystkimi niezbędnymi kolekcjami (Ansible Content Collections) lub dodatkowymi pakietami, frameworkami i powiązanymi zależnościami. W ten sposób, każdy zespół może łatwo tworzyć zadania automatyzacji dostosowane do określonego i zoptymalizowanego środowiska wykonawczego, mając pewność, że będzie ono działać równie dobrze, jak to używane podczas developmentu i testów.
Dobrze przetestowane i sprawdzone środowisko wykonawcze zapewnia przenośność oraz przewidywalną, stabilną i niezawodną automatyzację nawet tam, gdzie mamy do czynienia z bardziej rozproszonmi scenariuszami. Dzięki dwukierunkowej sieci Automation Mesh, Automation Controller może wygodnie i bezpiecznie, wykorzystując technologię sieci nakładkowej i szyfrowanie oparte na TLS, komunikować się z rozproszonymi węzłami obsługującymi warstwę wykonawczą (Execution Nodes), która może obejmować serwery fizyczne i wirtualne, obsługujące system RHEL (Red Hat Enterprise Linux) oraz platformy Red Hat OpenShift.
W ramach subskrypcji Red Hat Ansible Automation Platform uzyskujemy dostęp do kilku środowisk wykonawczych, które można pobrać w formie specjalnych obrazów. Red Hat udostępnia również narzędzie Ansible Builder, za pomocą którego można modyfikować lub tworzyć takie środowiska, oraz narzędzie Ansible Navigator, które zapewnia interfejs do edycji, analizowania i sprawdzania środowisk wykonawczych oraz uruchamiania w nich wcześniej przygotowanych Playbook-ów.
W nowych wersjach Ansible, Ansible Core zostało oddzielone od Ansible Content Collections. Komponenty te były wcześniej dostarczane razem, jako pojedyncza jednostka. Ansible Core obejmuje aktualnie tylko podstawowe moduły i narzędzia wiersza poleceń Ansible i jego komponentów, które umożliwiają interpretację i wykonywanie kodu YAML oraz używanie wyrażeń warunkowych i pętli. Wcześniej, Ansible Core dostarczał wiele dodatkowych modułów, które rozszerzały dostępne funkcje automatyzacji Ansible. Liczba tych modułów i ich funkcjonalności rosła tak szybko, że konieczne stało się ich wyizolowanie w osobnych pakietach, zwanych Ansible Content Collections. Pojedyncza kolekcja to zestaw modułów, ról i dodatkowych wtyczek, które razem są używane do określonego celu, takiego jak automatyzacja wybranego urządzenia lub systemu.
Takie podejście ma wiele zalet. Środowisko wykonawcze może teraz zawierać tylko kolekcje wymagane do określonych zadań automatyzacji. Dotyczy to nie tylko wyboru określonych kolekcji, ale także ich dokładnych wersji. Dzięki temu, każda z kolekcji może być rozwijana, utrzymywana i aktualizowana bardziej niezależnie od Ansible Core.
W nowej wersji platformy poszerzono funkcjonalność Automation Hub. Wcześniej dawał on dostęp zarówno do kolekcji tworzonych przez społeczność w ramach Ansible Galaxy, jak i tych komercyjnych, tworzonych, utrzymywanych i obsługiwanych bezpośrednio przez Red Hat oraz certyfikowanych partnerów technologicznych Red Hat. Należą do nich dostawcy różnych rozwiązań komercyjnych, jak m.in. Cisco Systems, IBM czy VMware. Automation Hub został wyposażony we wbudowane funkcje ograniczające dostępne kolekcje, w tym te o nie zawsze określonej jakości, które są szeroko udostępniane przez społeczność w ramach Ansible Galaxy. Jest to przydatne w aspektach bezpieczeństwa i stabilności.
Kolekcje dostarczane przez Red Hat i certyfikowanych partnerów Red Hat są dostępne i wspierane przez Red Hat w ramach subskrypcji Red Hat Ansible Automation Platform. Warto pamiętać też o Private Automation Hub, który umożliwia wygodne zarządzanie i udostępnianie kolekcji oraz obrazów środowisk wykonawczych w obrębie tej samej organizacji.
Pomimo tych wszystkich zmian, sposób tworzenia kodu automatyzacji lub jego uruchamiania przez Ansible może być realizowany dokładnie w ten sam sposób, jak miało to miejsce wcześniej. Warto jednak pamiętać o wprowadzeniu FQCN (Fully Qualified Collection Name) i nowych narzędziach, które usprawniają cały proces. Zmiany wprowadzone w ramach Red Hat Ansible Automation Platform lepiej rozwiązują problemy automatyzacji w wielu dużych przedsiębiorstwach i organizacjach, stąd stanowią kluczowy element większych środowisk lub miejsc, w których automatyzacja powinna być wdrażana w sposób spójny.
Zadaniem Ansible jest doprowadzenie urządzeń, systemów, plików, aplikacji i usług do żądanego stanu, który opisywany jest w sposób deklaratywny (ang. declarative language). Oznacza to, że określamy tylko stan jaki chcemy, aby dany obiekt przyjął, bez opisywania w szczegółach sposób, w jaki ma zostać to zrealizowane. Doprowadzeniem go do określonego stanu zajmują się już odpowiednie moduły. W zależności od tego, w jakim stanie początkowym jest dany obiekt, użyty moduł może wykonać na nim więcej lub mniej różnych operacji, czy nawet nie wykonać żadnej, jeżeli nie jest to potrzebne. Podejście takie charakteryzuje się idempotentnością (ang. idempotent), czyli możliwość wielokrotnego uruchomienia tego samego modułu, bez zmiany stanu końcowego. Oznacza to też to, że możemy bez obaw wielokrotnie wykonywać ten sam moduł na danym obiekcie. Jeżeli dany obiekt jest już w zadeklarowanym stanie, to nic się nie stanie, a jeżeli nie jest, to Ansible doprowadzi go do niego.
Idempotentność jest zagwarantowana tylko, jeżeli korzystamy z wbudowanych modułów. Jeżeli tworzymy je sami lub korzystamy z innych możliwości, jak dla przykładu wysyłanie doraźnych poleceń, to o idempotentność musimy zadbać sami.
Oprócz modułów i poleceń, możemy także korzystać z szablonów Jinja2. Nadają się one świetnie do personalizacji zawartości plików w oparciu o zadeklarowane wartości zmiennych. O ile korzystanie z szablonów Jinja2 czy możliwości wydawania poleceń CLI może być wygodne, a czasami nawet niezbędne, to należy z tych metod korzystać tylko w konkretnych przypadkach. Jeżeli tylko jest dostępny odpowiedni moduł, to z niego powinniśmy skorzystać w pierwszej kolejności. Chyba, że podmieniamy cały plik.
W ten sposób nie tylko będziemy mieli zapewnioną idempotentność, ale także będziemy mieli opisaną całą infrastrukturę jednym, spójnym kodem czy językiem (ang. IaC - Infrastructure as Code).
W przypadku Ansible, tym językiem jest YAML (YAML Ain’t Markup Language). Za jego pomocą budujemy playbooki (ang. playbooks), które są sekwencyjną listą zadań do odegrania (ang. plays) na zadanych obiektach, czy inaczej mówiąc stanów, jakie powinny one po ich wykonaniu przyjąć. Należy pamiętać, że w ramach playbooka mogą także zostać zdefiniowane różne inne operacje, jak m.in. przekopiowanie pliku, pobranie czegoś z jakiegoś miejsca, uruchomienie konkretnych poleceń CLI czy wykorzystanie silnika szablonów Jinja2. Istnieje także możliwość korzystania z różnych pętli, wyrażeń warunkowych, wyrażeń regularnych, zmiennych i uchwytów (ang. handlers). Mamy również możliwość wykonywanie doraźnych (łac. ad-hoc) poleceń i zadań, a także definiowanie bardziej złożonych roli (ang. roles). Role są zbiorem zadań, plików i szablonów, niezbędnych do pełnienia przez dane urządzenie czy system jakiejś konkretnej roli czy funkcji w naszym środowisku. Ansible jest szkieletem (ang. framework) do automatyzacji, który wygodnie da się rozbudowywać o nowe funkcjonalności. Realizowane jest to poprzez dodatkowe wtyczki (ang. plugins), moduły (ang. modules) i kolekcje (ang. collections), których ilość ciągle rośnie.
Red Hat Ansible Automation Platform obsługuje zarówno statyczne jak i dynamiczne inwentarze (ang. inventory). Statyczne tworzy się w plikach INI lub YAML, a dynamiczne poprzez zaciąganie danych z innych rozwiązań, jak Red Hat Satellite, Red Hat Insights, Amazon EC2, Google Compute Engine, Microsoft Azure Resource Manager, VMware vCenter, VMware ESXi, OpenStack, Red Hat OpenShift Virtualization czy Terraform State lub poprzez dynamiczne skrypty z różnych baz danych.
Platforma Red Hat Ansible Automation świetnie nadaje się do automatyzacji zarówno małych, jak i dużych sieci.
W mniejszych może bezpośrednio łączyć się do urządzeń, dostosowując ich stan do zadanych wymagań, a w większych realizować to poprzez dedykowane kontrolery, jak:
- Cisco NSO (Network Services Orchestrator),
- Cisco APIC (Application Policy Infrastructure Controller) dla ACI (Application Centric Infrastructure),
- Cisco Catalyst SD-WAN Manager i Cisco Meraki dla SD-WAN,
- Cisco Catalyst Center dla SD-Access.
Powodem wykorzystywania w większych sieciach dodatkowych kontrolerów SDN (Software Defined Network) jest nie tylko automatyzacja i orkiestracja. Systemy te dostarczają bardzo rozbudowane narzędzia diagnozy, analizy, korelacji i wizualizacji, czego nie udostępnia Red Hat Ansible Automation Platform. Dlatego o ile platforma ta nie zastąpi takich rozwiązań w pełni, to może z nimi kooperować, działając na poziomie wyżej. W ten sposób Red Hat Ansible Automation może być narzędziem spajającym naszą całą infrastrukturę. Ponadto, ręczne przeklikiwanie się przez dużą ilość zakładek różnych kontrolerów jest uciążliwe, czasochłonne oraz podatne na błędy i pominięcia. Dlatego o wiele łatwiej zautomatyzować to na poziomie Ansible.
Zapraszamy do
