Środowiska IT stają się coraz bardziej złożone. W tych warunkach dla systemu automatyzacji IT kluczowe jest posiadanie aktualnych informacji o węzłach, które znajdują się w sieci i wymagają przetwarzania. W Red Hat Ansible Automation Platform problem ten rozwiązywany jest poprzez tzw. inwentarze () – listy zarządzanych węzłów.
W swojej najprostszej formie inwentarz to statyczny plik. To idealne rozwiązanie na początek pracy z Ansible, ale w miarę rozszerzania automatyzacji staje się niewystarczające.
I oto dlaczego:
- Jak aktualizować i utrzymywać pełną listę kontrolowanych węzłów, gdy wszystko ciągle się zmienia, gdy obciążenia robocze – a za nimi i węzły, na których są realizowane – jedne się pojawiają, a inne znikają?
- Jak klasyfikować komponenty infrastruktury IT, aby celowo wybierać węzły do zastosowania konkretnej automatyzacji?
Odpowiedzi na oba te pytania daje dynamiczny inwentarz () – skrypt lub wtyczka, która wyszukuje węzły do automatyzacji, odwołując się do źródła prawdy (source of truth). Ponadto, dynamiczny inwentarz automatycznie klasyfikuje węzły w grupy, aby umożliwić dokładniejsze selekcjonowanie systemów docelowych do realizacji danej automatyzacji Ansible.
dają użytkownikowi Ansible możliwość korzystania z zewnętrznych platform do dynamicznego wyszukiwania docelowych węzłów i wykorzystania tych platform jako źródła prawdy w tworzeniu inwentarza. Standardowa lista źródeł w Ansible obejmuje platformy chmurowe AWS EC2, Google GCP i Microsoft Azure, a także wiele innych wtyczek inwentarza dostępnych w Ansible.
Ansible Tower dostarczany jest z zestawem , które działają „od razu” i oprócz wspomnianych platform chmurowych zapewniają integrację z VMware vCenter, Red Hat OpenStack Platform oraz Red Hat Satellite. Dla tych wtyczek wystarczy podać dane logowania do połączenia z docelową platformą, po czym można je wykorzystać jako źródło danych inwentarzowych w Ansible Tower.
Oprócz standardowych wtyczek dostarczanych z Ansible Tower istnieją również inne wtyczki inwentarza wspierane przez społeczność Ansible. Z przejściem na te wtyczki zaczęły być dołączane do odpowiednich kolekcji.
W tym wpisie zbadamy przykład użycia wtyczki inwentaryzacyjnej dla ServiceNow, popularnej platformy zarządzania usługami IT, w której klienci często przechowują informacje o wszystkich swoich urządzeniach w CMDB. Ponadto, CMDB może zawierać kontekst przydatny do automatyzacji, na przykład informacje o właścicielach serwerów, poziomach wsparcia (produkcja/nietprodukcja), zainstalowanych aktualizacjach i oknach konserwacyjnych. Wtyczka inwentaryzacyjna Ansible może współpracować z CMDB ServiceNow i jest częścią kolekcji na portalu .
repozytorium Git
Aby użyć wtyczki inwentaryzacyjnej z kolekcji w Ansible Tower, należy ją określić jako źródło projektu. W Ansible Tower projekt to integracja z jakimś systemem kontroli wersji, takim jak repozytorium git, które można wykorzystać do synchronizacji nie tylko skryptów automatyzacji, ale także zmiennych i list inwentaryzacyjnych.
Nasze repozytorium jest w rzeczywistości bardzo proste:
├── collections
│ └── requirements.yml
└── servicenow.yml
Plik servicenow.yml zawiera szczegóły dla wtyczki inwentaryzacyjnej. W naszym przypadku po prostu wskazujemy tabelę w CMDB ServiceNow, którą chcemy użyć. Określamy również pola, które będą dodawane jako zmienne węzła, a także pewne informacje o grupach, które chcemy utworzyć.
$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
- key: sn_sys_class_name | lower
prefix: ''
separator: ''
- key: sn_os | lower
prefix: ''
separator: ''
Zauważ, że tutaj nie określa się instancji ServiceNow, do której będziemy się łączyć, ani nie podaje się żadnych danych uwierzytelniających do połączenia. Wszystko to skonfigurujemy później w Ansible Tower.
jest potrzebny, aby Ansible Tower mogło pobrać odpowiednią kolekcję i uzyskać w ten sposób potrzebną wtyczkę inwentaryzacyjną. W przeciwnym razie trzeba by było ręcznie instalować i utrzymywać tę kolekcję na wszystkich naszych węzłach Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Po wysłaniu tej konfiguracji do systemu kontroli wersji, w Ansible Tower można tworzyć projekt odnoszący się do odpowiedniego repozytorium. W poniższym przykładzie Ansible Tower łączy się z naszym repozytorium na GitHubie. Zauważ SCM URL: umożliwia to wprowadzenie konta do połączenia z prywatnym repozytorium oraz określenie konkretnej gałęzi, etykiety lub commita do wyciągnięcia.
Tworzymy poświadczenia dla ServiceNow
Jak już wspomniano, konfiguracja w naszym repozytorium nie zawiera danych logowania do połączenia z ServiceNow i nie określa instancji ServiceNow, z którą będziemy się komunikować. Dlatego, aby wprowadzić te dane, stworzymy poświadczenia w Ansible Tower. Zgodnie z , istnieje szereg zmiennych środowiskowych, za pomocą których określimy parametry połączenia, na przykład w ten sposób:
= username
Konto użytkownika ServiceNow, powinno mieć prawo do odczytu cmdb_ci_server (domyślnie) lub tabeli określonej przez SN_TABLE
set_via:
env:
- name: SN_USERNAME
W takim przypadku, jeśli zmienna środowiskowa SN_USERNAME jest ustawiona, wtyczka inwentarza użyje jej jako konta do połączenia z ServiceNow.
Musimy również ustawić zmienne SN_INSTANCE i SN_PASSWORD.
Jednak w Ansible Tower brakuje poświadczeń tego typu, gdzie można by określić te dane dla ServiceNow. Zamiast tego Ansible Tower pozwala nam definiować , więcej na ten temat można przeczytać w artykule .
W naszym przypadku konfiguracja wejściowa dla niestandardowych poświadczeń dla ServiceNow wygląda następująco:
fields:
- id: SN_USERNAME
type: string
label: Użytkownik
- id: SN_PASSWORD
type: string
label: Hasło
secret: true
- id: SN_INSTANCE
type: string
label: Instancja Snow
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Te poświadczenia będą eksponowane jako zmienne środowiskowe o tej samej nazwie. Jest to opisane w konfiguracji injektora:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Zdefiniowaliśmy potrzebny nam typ poświadczenia, teraz możemy dodać konto ServiceNow i ustawić instancję, nazwę użytkownika i hasło, w ten sposób:
Tworzymy inwentarz
Zatem teraz wszystko jest gotowe, aby stworzyć inwentarz w Ansible Tower. Nazwijmy go ServiceNow:
Po stworzeniu inwentory możemy przypisać do niej źródło danych. Tutaj wskazujemy projekt, który stworzyliśmy wcześniej, oraz wprowadzamy ścieżkę do naszego pliku inwentory YAML w repozytorium systemu zarządzania wersjami, w naszym przypadku jest to servicenow.yml w katalogu projektu. Ponadto, musimy również powiązać konto ServiceNow.
Aby sprawdzić, jak wszystko działa, spróbujmy zsynchronizować się z źródłem danych, klikając przycisk „Sync all”. Jeśli wszystko jest skonfigurowane prawidłowo, węzły powinny zostać zaimportowane do naszego inwentory:
Zauważ, że potrzebne nam grupy również zostały utworzone.
Podsumowanie
W tym poście omówiliśmy, jak w Ansible Tower używać wtyczek inwentory z kolekcji na przykładzie wtyczki ServiceNow. Bezpiecznie zapisaliśmy również dane logowania do połączenia z naszym instansem ServiceNow. Powiązanie wtyczki inwentory z projektem działa nie tylko z wtyczkami zewnętrznymi lub dostosowanymi, ale może być również zastosowane do modyfikacji działania niektórych standardowych inwentory. Dzięki temu Ansible Automation Platform łatwo i bezproblemowo integruje się z istniejącymi narzędziami przy automatyzacji środowisk IT, które stają się coraz bardziej złożone.
Dodatkowe informacje na temat omawianych w tym poście tematów, jak również innych aspektów zastosowania Ansible można znaleźć tutaj:
- Blog o .
- .
- Lista wspieranych kolekcji Red Hat na stronie Automation Hub ().
- .
*Red Hat nie daje żadnych gwarancji poprawności podanego tutaj kodu. Wszystkie materiały są udostępniane bez wsparcia, chyba że wyraźnie zaznaczone inaczej.
Źródło: habr.com
