🥇The Inside Playbook. Funkcje sieciowe w nowym Ansible Engine 2.9

W nadchodzącym wydaniu Red Hat Ansible Engine 2.9 czekają na Ciebie imponujące ulepszenia, z których niektóre opisano w tym artykule. Jak zwykle, rozwijaliśmy ulepszenia Ansible Network w sposób otwarty, przy wsparciu społeczności. Dołącz do nas — zajrzyj na tablicę zadań na GitHubie i zapoznaj się z planem rozwoju dla wydania Red Hat Ansible Engine 2.9 na stronie wiki dla Ansible Network.

Jak niedawno ogłosiliśmy, Red Hat Ansible Automation Platform teraz zawiera Ansible Tower, Ansible Engine oraz całą zawartość Ansible Network. Obecnie większość popularnych platform sieciowych jest realizowana za pomocą modułów Ansible. Na przykład:

Arista EOS
Cisco IOS
Cisco IOS XR
Cisco NX-OS
Juniper Junos
VyOS

Pełna lista platform, które są w pełni wspierane przez Red Hat w ramach subskrypcji Ansible Automation, została opublikowana tutaj.

Czego się nauczyliśmy

W ciągu ostatnich czterech lat wiele nauczyliśmy się o rozwijaniu platformy automatyzacji sieci. Dowiedzieliśmy się również, że jak artefakty platformy są używane w playbookach i rolach Ansible przez użytkowników końcowych. I oto, co odkryliśmy:

Organizacje automatyzują urządzenia wielu dostawców, a nie tylko jednego.
Automatyzacja jest procesem nie tylko technicznym, ale również kulturowym.
Skala automatyzacji sieci jest bardziej skomplikowana, niż się wydaje, z powodu fundamentalnych zasad architektury automatyzacji.

Kiedy omawialiśmy nasze długoterminowe plany rozwoju ponad rok temu, nasi klienci korporacyjni prosili o następujące:

Standardyzacja zbierania faktów i integracja z procesem automatyzacji dla dowolnych urządzeń musi być lepsza.
Aktualizacja konfiguracji na urządzeniu również musi być standardyzowana i zintegrowana, aby moduły Ansible mogły obsługiwać drugą połowę cyklu po zbieraniu faktów.
Potrzebne są ścisłe i wspierane metody konwersji konfiguracji urządzenia na dane strukturalne. Na tej podstawie źródło prawdy można będzie przenieść z urządzenia sieciowego.

Ulepszenia faktów

Zbieranie faktów z urządzeń sieciowych za pomocą Ansible często odbywa się na chybił trafił. Platformy sieciowe w różnym stopniu wyposażone są w możliwości zbierania faktów, ale mają prawie wcale — lub wręcz żadnych — funkcji do analizowania i standardyzowania przedstawienia danych w parach klucz-wartość. Przeczytaj post Kena Selenzę (Ken Celenza) o tym, jak trudne i męczące może być analizowanie i standardyzowanie danych faktów.

Możliwe, że zauważyłeś, jak pracowaliśmy nad rolą Ansible Network Engine. Naturalnie, po 24 tysiącach pobrań, rola Network Engine szybko stała się jedną z najpopularniejszych ról Ansible w Ansible Galaxy do automatyzacji sieci. Zanim przenieśliśmy wiele z tego do Ansible 2.8, aby przygotować się na to, co będzie potrzebne w Ansible 2.9, ta rola Ansible dostarczyła pierwszy zestaw narzędzi do pomocy w analizowaniu poleceń, zarządzaniu zespołami i zbieraniu danych dla urządzeń sieciowych.

Jeśli znasz się na używaniu Network Engine, jest to bardzo skuteczny sposób zbierania, analizowania i standaryzowania danych faktów do wykorzystania w Ansible. Minusem tej roli jest to, że trzeba stworzyć całą masę parserów dla każdej platformy i dla wszelkiej aktywności sieciowej. Aby zrozumieć, jak trudno jest tworzyć, dostarczać i utrzymywać parsery, spójrz na ponad 1200 parserów od zespołu Cisco.

Krótko mówiąc, dla dużej automatyzacji kluczowe jest uzyskiwanie faktów z urządzeń i normalizacja ich w pary klucz-wartość, ale osiągnięcie tego jest trudne, gdy masz wielu dostawców i platform sieciowych.

Każdy moduł faktów sieci w Ansible 2.9 może teraz analizować konfigurację urządzenia sieciowego i zwracać uporządkowane dane — bez dodatkowych bibliotek, ról Ansible czy niestandardowych parserów.

Zaczynając od Ansible 2.9, przy każdym wydaniu zaktualizowanego modułu sieciowego, moduł faktów jest ulepszany, aby dostarczać dane dotyczące tej części konfiguracji. Oznacza to, że rozwój faktów i modułów teraz odbywa się w tym samym tempie i będą zawsze miały wspólną strukturę danych.

Konfigurację zasobów na urządzeniu sieciowym można wyciągnąć i przekształcić w uporządkowane dane na dwa sposoby. Oba te sposoby mogą zbierać i przekształcać określoną listę zasobów dzięki nowemu słowu kluczowemu gather_network_resources. Nazwy zasobów odpowiadają nazwom modułów, co jest bardzo wygodne.

Podczas zbierania faktów:

Za pomocą słowa kluczowego gather_facts można wyciągnąć aktualną konfigurację urządzenia na początku playbooka, a następnie używać jej przez cały playbook. Określ konkretne zasoby, które mają zostać wyciągnięte z urządzenia.

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

Mogłeś zauważyć coś nowego w tych przykładach, a mianowicie — gather_facts: true teraz dostępne do natywnego gromadzenia faktów dla urządzeń sieciowych.

Użycie modułu faktów sieciowych bezpośrednio:

- name: zbierz fakty dotyczące konfiguracji interfejsu
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Playbook zwraca następujące fakty o interfejsie:

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: Ethernet1

Zauważ, jak Ansible wydobywa natywną konfigurację z urządzenia Arista i przekształca ją w zorganizowane dane, aby wykorzystać je jako standardowe pary klucz-wartość do kolejnych zadań i operacji.

Fakty interfejsu można dodać do przechowywanych zmiennych Ansible i używać natychmiast lub później jako dane wejściowe dla modułu zasobów eos_interfaces bez dodatkowego przetwarzania lub konwersji.

Moduły zasobów

Otóż to, wydobyliśmy fakty, znormalizowaliśmy dane, wypełniliśmy je w usystematyzowanej wewnętrznej schemie struktury danych i uzyskaliśmy gotowe źródło prawdy. Hurra! To świetnie, ale wciąż musimy jakoś przekształcić pary klucz-wartość z powrotem w konkretną konfigurację, której oczekuje konkretna platforma urządzenia. Teraz potrzebujemy modułów dla konkretnych platform, aby spełnić te nowe wymagania dotyczące gromadzenia faktów i normalizacji.

Czym jest moduł zasobu? Sekcje konfiguracji urządzenia można postrzegać jako zasoby dostarczane przez to urządzenie. Moduły zasobów sieciowych są celowo ograniczone do jednego zasobu i można je składać, jak klocki, aby skonfigurować skomplikowane usługi sieciowe. W rezultacie wymagania i specyfikacja dla modułu zasobu naturalnie ulegają uproszczeniu, ponieważ moduł zasobu może odczytywać i konfigurując konkretną usługę sieciową na urządzeniu sieciowym.

Aby wyjaśnić, co robi moduł zasobu, przyjrzyjmy się przykładowi playbooka, który ilustruje identyczną operację z wykorzystaniem nowych faktów zasobów sieciowych i modułu eos_l3_interface.

- name: przykład faktów przesyłanych bezpośrednio z powrotem do urządzenia.
  hosts: arista
  gather_facts: false
  tasks:
  - name: pobierz fakty eos arista
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: upewnij się, że informacje o adresie IP są dokładne
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: upewnij się, że konfiguracja nie zmieniła się
    assert:
      that: not result.changed

Jak widzicie, dane zebrane z urządzenia są przesyłane bezpośrednio do odpowiedniego modułu zasobów bez przekształcenia. Podczas uruchamiania playbooka wartości są ekstraktowane z urządzenia i porównywane z oczekiwanymi. W tym przykładzie otrzymane wartości odpowiadają oczekiwanym (czyli jest wykonywana kontrola odchyleń konfiguracji) i wydawana jest informacja, czy konfiguracja się zmieniła.

Idealnym sposobem na wykrycie odchyleń w konfiguracji jest przechowywanie faktów w zmiennych Ansible i okresowe ich użycie z modułem zasobów w trybie kontroli. To prosty sposób, aby zobaczyć, czy ktoś zmienił wartości ręcznie. W większości przypadków organizacje zezwalają na ręczne zmiany i konfigurację, mimo że wiele operacji wykonuje się poprzez Ansible Automation.

Czym różnią się nowe moduły zasobów od wcześniejszych?

Dla inżyniera ds. automatyzacji sieci istnieją 3 główne różnice w modułach zasobów w Ansible 2.9 w porównaniu do wcześniejszych wersji.

1) Dla danego zasobu sieciowego (który można również uznać za sekcję konfiguracji) moduły i fakty będą rozwijane we wszystkich obsługiwanych systemach operacyjnych sieci jednocześnie. Uważamy, że jeśli Ansible obsługuje konfigurację zasobu na jednej platformie sieciowej, powinniśmy ją obsługiwać wszędzie. Ułatwia to korzystanie z modułów zasobów, ponieważ inżynier ds. automatyzacji sieci może teraz skonfigurować zasób (np. LLDP) we wszystkich systemach operacyjnych sieciowych z natywnymi i obsługiwanymi modułami.

2) Moduły zasobów teraz zawierają wartość stanu.

merged: konfiguracja została połączona z dostarczoną konfiguracją (domyślnie);
replaced: konfiguracja zasobu zostanie zastąpiona dostarczoną konfiguracją;
overridden: konfiguracja zasobu zostanie zastąpiona dostarczoną konfiguracją; nadmiarowe egzemplarze zasobów zostaną usunięte;
deleted: konfiguracja zasobu zostanie usunięta/przywrócona domyślnie.

3) Moduły zasobów teraz obejmują stabilne zwracane wartości. Kiedy moduł zasobu sieciowego wprowadza (lub proponuje) niezbędne zmiany w urządzeniu sieciowym, zwraca te same pary klucz-wartość do playbooka.

before: konfiguracja na urządzeniu w postaci ustrukturyzowanych danych do zadania;
po: jeśli urządzenie się zmieniło (lub może się zmienić, jeśli używany jest tryb weryfikacji), otrzymana konfiguracja zostanie zwrócona w postaci ustrukturyzowanych danych;
komendy: wszelkie komendy konfiguracyjne uruchomione na urządzeniu, aby doprowadzić je do pożądanego stanu.

Co to wszystko oznacza? Dlaczego to ważne?

W tym wpisie opisanych jest wiele skomplikowanych koncepcji, ale mamy nadzieję, że ostatecznie lepiej zrozumiesz, co klienci korporacyjni proszą o zbieranie faktów, normalizację danych i konfigurację cyklu dla platformy automatyzacji. Ale dlaczego potrzebują tych usprawnień? Wiele organizacji obecnie przeprowadza transformację cyfrową, aby uczynić swoje środowiska IT bardziej elastycznymi i konkurencyjnymi. Dobrze czy źle, wielu inżynierów sieciowych staje się inżynierami oprogramowania sieciowego — z własnego zainteresowania lub na polecenie przełożonych.

Organizacje rozumieją, że automatyzacja pojedynczych szablonów sieciowych nie rozwiązuje problemu rozdrobnienia i zwiększa efektywność tylko do pewnego limitu. Platforma Red Hat Ansible Automation Platform zapewnia surowe i normatywne modele danych zasobów, aby programowo zarządzać podstawowymi danymi na urządzeniu sieciowym. Oznacza to, że użytkownicy stopniowo rezygnują z indywidualnych sposobów konfiguracji na rzecz nowocześniejszych metod z naciskiem na technologie (np. adresy IP, VLAN, LLDP itp.), a nie na konkretne implementacje dostawcy.

Czy to oznacza, że dni niezawodnych i sprawdzonych modułów poleceń i konfiguracji są policzone? Oczywiście, że nie. Oczekiwane moduły zasobów sieciowych nie będą stosowane we wszystkich przypadkach i nie dla każdego dostawcy, dlatego moduły poleceń i konfiguracji będą nadal potrzebne inżynierom sieciowym do określonych realizacji. Celem modułów zasobów jest uproszczenie dużych szablonów Jinja i sformatowanie niestrukturalnych konfiguracji urządzenia w zorganizowany format JSON. Dzięki modułom zasobów istniejące sieci będą miały łatwiej w przekształcaniu swojej konfiguracji w zorganizowane pary klucz-wartość, które będą stanowić czytelne źródło prawdy. Korzystając z zorganizowanych par klucz-wartość, możemy przejść od uruchamiania konfiguracji na każdym urządzeniu do pracy z niezależnymi danymi strukturalnymi, co wprowadza sieci na pierwszy plan w podejściu „infrastruktura jako kod”.

Jakie moduły zasobów pojawią się w Ansible Engine 2.9?

Zanim szczegółowo omówimy, co znajdzie się w Ansible 2.9, przypomnijmy sobie, jak podzieliliśmy cały zakres pracy.

Wydzieliliśmy 7 kategorii i przypisaliśmy każdej określone zasoby sieciowe:

Uwaga: zasoby wyróżnione pogrubieniem zostały zaplanowane i zrealizowane w Ansible 2.9.
Na podstawie opinii klientów korporacyjnych i społeczności, sensowne było, aby najpierw zająć się 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 wspieranym przez Red Hat:

Następujące moduły zostały opracowane przez społeczność Ansible:

exos_lldp_global — od Extreme Networks.
nxos_bfd_interfaces — od Cisco
nxos_telemetry — od Cisco

Jak widać, koncepcja modułów zasobów wpisuje się w naszą strategię orientacji na platformy. Oznacza to, że wbudowujemy niezbędne możliwości i funkcje do samego Ansible, aby wspierać standaryzację przy tworzeniu modułów sieciowych, a także ułatwić pracę użytkowników na poziomie ról i playbooków Ansible. Aby rozszerzyć rozwój modułów zasobów, zespół Ansible wydał narzędzie Module Builder.

Plany na Ansible 2.10 i później

Po wydaniu Ansible 2.9 zajmiemy się następnym zestawem modułów zasobów dla Ansible 2.10, które będą mogły być używane do dalszej konfiguracji topologii i polityki sieci, na przykład ACL, OSPF i BGPPlan rozwoju można jeszcze dostosować, więc jeśli masz komentarze, daj nam znać w społeczności Ansible Network.