Nadchodzące wydanie Red Hat Ansible Engine 2.9 wprowadza ekscytujące ulepszenia, z których niektóre omówiono w tym artykule. Jak zawsze, otwarcie rozwijamy ulepszenia sieci Ansible, przy wsparciu społeczności. Dołącz do nas - zobacz i przestudiować plan rozwoju dla na stronie wiki dla .
Jak niedawno ogłosiliśmy, zawiera teraz Ansible Tower, Ansible Engine i całą zawartość Ansible Network. Obecnie najpopularniejsze platformy sieciowe wdrażane są poprzez moduły Ansible. Na przykład:
- Arista EOS
- Cisco iOS
- Cisco iOS XR
- Cisco NX OS
- Jałowiec Junos
- VyOS
Aby uzyskać pełną listę platform w pełni obsługiwanych przez Red Hat w ramach subskrypcji Ansible Automation, .
Czego się nauczyliśmy
W ciągu ostatnich czterech lat nauczyliśmy się wiele na temat tworzenia platformy automatyzacji sieci. Tego też się nauczyliśmy jak artefakty platformy są używane w podręcznikach i rolach Ansible przez użytkowników końcowych. A oto czego się dowiedzieliśmy:
- Organizacje automatyzują urządzenia nie tylko jednego, ale wielu dostawców.
- Automatyzacja to nie tylko zjawisko techniczne, ale także kulturowe.
- Automatyzacja sieci na dużą skalę jest trudniejsza, niż się wydaje, ze względu na podstawowe zasady architektury projektowania automatyki.
Kiedy ponad rok temu omawialiśmy nasze długoterminowe plany rozwoju, nasi klienci korporacyjni pytali o następujące kwestie:
- Gromadzenie faktów musi być lepiej ujednolicone i dostosowane do procesów automatyzacji na wszystkich urządzeniach.
- Aktualizacja konfiguracji na urządzeniu również musi być ustandaryzowana i spójna, aby moduły Ansible poradziły sobie z drugą połową cyklu po zebraniu faktów.
- Potrzebujemy rygorystycznych i wspieranych metod konwertowania konfiguracji urządzeń na dane strukturalne. Na tej podstawie można przenieść źródło prawdy z urządzenia sieciowego.
Poprawa faktów
Zbieranie faktów z urządzeń sieciowych za pomocą Ansible często odbywa się losowo. Platformy internetowe mają różny stopień możliwości gromadzenia faktów, ale mają niewielką lub żadną funkcjonalność związaną z analizowaniem i standaryzacją reprezentacji danych w parach klucz-wartość. Czytać Kena Celenzy o tym, jak trudne i bolesne może być analizowanie i standaryzacja danych faktycznych.
Być może zauważyłeś, że pracujemy nad rolą Ansible Network Engine. Naturalnie, po 24 tys. pobrań później, rola Network Engine szybko stała się jedną z najpopularniejszych ról Ansible w Ansible Galaxy w scenariuszach automatyzacji sieci. Zanim przenieśliśmy większość tych elementów do Ansible 2.8, aby przygotować się na to, co będzie potrzebne w Ansible 2.9, ta rola Ansible zapewniła pierwszy zestaw narzędzi pomagających analizować polecenia, zarządzać nimi i zbierać dane dla urządzeń sieciowych.
Jeśli wiesz, jak korzystać z Network Engine, jest to bardzo skuteczny sposób gromadzenia, analizowania i standaryzacji danych faktów do wykorzystania w Ansible. Wadą tej roli jest to, że musisz stworzyć całą masę parserów dla każdej platformy i całej aktywności sieciowej. Aby zrozumieć, jak trudno jest tworzyć, dostarczać i utrzymywać parsery, spójrz na od chłopaków z Cisco.
Krótko mówiąc, pobieranie faktów z urządzeń i normalizowanie ich w pary klucz-wartość jest niezbędne do automatyzacji na dużą skalę, ale osiągnięcie tego jest trudne, jeśli masz wielu dostawców i platform sieciowych.
Każdy moduł faktów sieciowych w Ansible 2.9 może teraz analizować konfigurację urządzenia sieciowego i zwracać ustrukturyzowane dane – bez dodatkowych bibliotek, ról Ansible czy niestandardowych analizatorów składni.
Od wersji Ansible 2.9 za każdym razem, gdy wydawany jest zaktualizowany moduł sieciowy, moduł faktów jest ulepszany w celu dostarczania danych o tej sekcji konfiguracji. Oznacza to, że rozwój faktów i modułów następuje teraz w tym samym tempie i zawsze będą miały wspólną strukturę danych.
Konfigurację zasobów urządzenia sieciowego można pobrać i przekonwertować na dane strukturalne na dwa sposoby. W obu przypadkach możesz zebrać i przekształcić określoną listę zasobów za pomocą nowego słowa kluczowego gather_network_resources. Nazwy zasobów odpowiadają nazwom modułów, co jest bardzo wygodne.
Zbierając fakty:
Używanie słowa kluczowego gather_facts możesz pobrać bieżącą konfigurację urządzenia na początku podręcznika, a następnie używać jej w całym podręczniku. Określ poszczególne zasoby, które mają zostać pobrane z urządzenia.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueByć może zauważyłeś coś nowego w tych przykładach, a mianowicie - gather_facts: true jest teraz dostępny do natywnego gromadzenia faktów dla urządzeń sieciowych.
Bezpośrednie użycie modułu faktów sieciowych:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybook zwraca następujące fakty dotyczące interfejsu:
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1Zwróć uwagę, jak Ansible pobiera natywną konfigurację z urządzenia Arista i przekształca ją w ustrukturyzowane dane, które można wykorzystać jako standardowe pary klucz-wartość dla dalszych zadań i operacji.
Fakty dotyczące interfejsu można dodać do zmiennych przechowywanych w Ansible i wykorzystać je natychmiast lub później jako dane wejściowe do modułu zasobów eos_interfaces bez dodatkowego przetwarzania i konwersji.
Moduły zasobów
Wyekstrahowaliśmy więc fakty, znormalizowaliśmy dane, wpasowaliśmy je w ustandaryzowany diagram wewnętrznej struktury danych i otrzymaliśmy gotowe źródło prawdy. Brawo! To oczywiście świetnie, ale nadal musimy w jakiś sposób przekonwertować pary klucz-wartość z powrotem na konkretną konfigurację, jakiej oczekuje konkretna platforma urządzenia. Aby spełnić te nowe wymagania w zakresie gromadzenia faktów i normalizacji, potrzebujemy teraz modułów specyficznych dla platformy.
Co to jest moduł zasobów? Sekcje konfiguracji urządzenia można traktować jako zasoby udostępniane przez to urządzenie. Moduły zasobów sieciowych są celowo ograniczone do jednego zasobu i można je układać w stosy jak elementy konstrukcyjne w celu konfigurowania złożonych usług sieciowych. W rezultacie wymagania i specyfikacja modułu zasobów są w naturalny sposób uproszczone, ponieważ moduł zasobów może czytać и skonfigurować określoną usługę sieciową na urządzeniu sieciowym.
Aby wyjaśnić, co robi moduł zasobów, spójrzmy na przykładowy podręcznik pokazujący idempodentną operację przy użyciu nowych faktów i modułu dotyczącego zasobów sieciowych eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedJak widać, dane zebrane z urządzenia są przesyłane bezpośrednio do odpowiedniego modułu zasobów bez konwersji. Po uruchomieniu playbook pobiera wartości z urządzenia i porównuje je z oczekiwanymi. W tym przykładzie zwrócone wartości są zgodne z oczekiwaniami (czyli sprawdza odchylenia w konfiguracji) i raportuje, czy konfiguracja uległa zmianie.
Idealnym sposobem na wykrycie dryfowania konfiguracji jest przechowywanie faktów w zmiennych przechowywanych w Ansible i okresowe używanie ich z modułem zasobów w trybie inspekcji. Jest to prosta metoda sprawdzenia, czy ktoś ręcznie zmienił wartości. W większości przypadków organizacje pozwalają na ręczne zmiany i konfigurację, chociaż wiele operacji jest wykonywanych za pośrednictwem Ansible Automation.
Czym nowe moduły zasobów różnią się od poprzednich?
Dla inżyniera zajmującego się automatyzacją sieci istnieją 3 główne różnice między modułami zasobów w Ansible 2.9 i poprzednich wersjach.
1) Dla danego zasobu sieciowego (który można również traktować jako sekcję konfiguracji), moduły i fakty będą ewoluować jednocześnie we wszystkich obsługiwanych sieciowych systemach operacyjnych. Uważamy, że skoro Ansible obsługuje konfigurację zasobów na jednej platformie sieciowej, to powinniśmy wspierać ją wszędzie. Upraszcza to korzystanie z modułów zasobów, ponieważ inżynier automatyzujący sieć może teraz konfigurować zasób (taki jak LLDP) we wszystkich sieciowych systemach operacyjnych z modułami natywnymi i obsługiwanymi.
2) Moduły zasobów zawierają teraz wartość stanu.
merged: konfiguracja jest scalana z dostarczoną konfiguracją (domyślnie);replaced: Konfiguracja zasobów zostanie zastąpiona podaną konfiguracją;overridden: Konfiguracja zasobów zostanie zastąpiona podaną konfiguracją; niepotrzebne instancje zasobów zostaną usunięte;deleted: Konfiguracja zasobu zostanie usunięta/przywrócona do ustawień domyślnych.
3) Moduły zasobów zawierają teraz stabilne wartości zwrotne. Gdy moduł zasobów sieciowych dokona (lub zaproponuje) niezbędnych zmian w urządzeniu sieciowym, zwraca te same pary klucz-wartość do podręcznika.
before: konfiguracja na urządzeniu w formie ustrukturyzowanych danych przed zadaniem;after: jeśli urządzenie uległo zmianie (lub może się zmienić w przypadku użycia trybu testowego), wynikowa konfiguracja zostanie zwrócona jako dane strukturalne;commands: Na urządzeniu uruchamiane są dowolne polecenia konfiguracyjne w celu doprowadzenia go do żądanego stanu.
Co to wszystko znaczy? Dlaczego to jest ważne?
Ten post obejmuje wiele skomplikowanych koncepcji, ale mamy nadzieję, że ostatecznie lepiej zrozumiesz, o co tak naprawdę proszą klienci korporacyjni, o gromadzenie, normalizację danych i konfigurację pętli dla platformy automatyzacji. Ale dlaczego potrzebują tych ulepszeń? Wiele organizacji przeprowadza obecnie transformację cyfrową, aby uczynić swoje środowiska IT bardziej elastycznymi i konkurencyjnymi. Na dobre i na złe, wielu inżynierów sieciowych zostaje programistami sieci albo ze względu na własny interes, albo na polecenie kierownictwa.
Organizacje zdają sobie sprawę, że automatyzacja poszczególnych szablonów sieci nie rozwiązuje problemu silosów, a jedynie w pewnym stopniu zwiększa efektywność. Platforma Red Hat Ansible Automation zapewnia rygorystyczne i normatywne modele danych zasobów do programowego zarządzania podstawowymi danymi na urządzeniu sieciowym. Oznacza to, że użytkownicy stopniowo rezygnują z indywidualnych metod konfiguracji na rzecz bardziej nowoczesnych metod, kładąc nacisk na technologie (na przykład adresy IP, sieci VLAN, LLDP itp.), a nie na implementację konkretnego dostawcy.
Czy to oznacza, że dni niezawodnych i sprawdzonych modułów dowodzenia i konfiguracji są policzone? W żadnym wypadku. Oczekiwane moduły zasobów sieciowych nie będą miały zastosowania we wszystkich przypadkach i dla każdego dostawcy, więc moduły poleceń i konfiguracji będą nadal potrzebne inżynierom sieciowym w przypadku niektórych wdrożeń. Celem modułów zasobów jest uproszczenie dużych szablonów Jinja i normalizacja nieustrukturyzowanych konfiguracji urządzeń do ustrukturyzowanego formatu JSON. Dzięki modułom zasobów istniejącym sieciom łatwiej będzie przekształcić swoją konfigurację w ustrukturyzowane pary klucz-wartość, które reprezentują łatwe do odczytania źródło prawdy. Korzystając z ustrukturyzowanych par klucz-wartość, możesz przejść od uruchamiania konfiguracji na każdym urządzeniu do pracy z niezależnymi ustrukturyzowanymi danymi i wysunąć sieci na pierwszy plan w podejściu infrastruktura jako kod.
Jakie moduły zasobów pojawią się w Ansible Engine 2.9?
Zanim opowiemy szczegółowo, co będzie się działo w Ansible 2.9, przypomnijmy sobie, jak podzieliliśmy cały zakres prac.
Zidentyfikowaliśmy 7 kategorii i do każdej przypisaliśmy określone zasoby sieciowe:
Uwaga: Zasoby zaznaczone pogrubioną czcionką zostały zaplanowane i wdrożone w Ansible 2.9.
Na podstawie opinii klientów korporacyjnych i społeczności logiczne było zajęcie się w pierwszej kolejności modułami związanymi z protokołami topologii sieci, wirtualizacją i interfejsami.
Następujące moduły zasobów zostały opracowane przez zespół Ansible Network i odpowiadają platformom obsługiwanym przez Red Hat:
Społeczność Ansible opracowuje następujące moduły:
exos_lldp_global- z Extreme Networks.nxos_bfd_interfaces- od Cisconxos_telemetry- od Cisco
Jak widać koncepcja modułów zasobów wpisuje się w naszą strategię skoncentrowaną na platformie. Oznacza to, że w samym Ansible włączamy niezbędne możliwości i funkcje, aby wspierać standaryzację w rozwoju modułów sieciowych, a także upraszczać pracę użytkowników na poziomie ról i playbooków Ansible. Aby rozszerzyć rozwój modułów zasobów, zespół Ansible udostępnił narzędzie Module Builder.
Plany dotyczące Ansible 2.10 i nowszych wersji
Po wydaniu Ansible 2.9 będziemy pracować nad kolejnym zestawem modułów zasobów dla Ansible 2.10, których można użyć do dalszej konfiguracji topologii i zasad sieci, np.: . Plan rozwoju można jeszcze modyfikować, więc jeśli macie uwagi, prosimy o zgłaszanie ich .
Zasoby i rozpoczęcie pracy
Źródło: www.habr.com