Środowiska IT stają się coraz bardziej złożone. W tych warunkach niezwykle istotne jest, aby system automatyki IT posiadał aktualne informacje o węzłach występujących w sieci i podlegających przetwarzaniu. W platformie Red Hat Ansible Automation ten problem rozwiązuje się poprzez tzw. inwentaryzację () – listy zarządzanych węzłów.
W najprostszej formie inwentarz jest plikiem statycznym. Jest to idealne rozwiązanie, gdy zaczynasz pracę z Ansible, ale w miarę wzrostu automatyzacji staje się niewystarczające.
A oto dlaczego:
- Jak aktualizować i utrzymywać pełną listę monitorowanych węzłów, gdy sytuacja stale się zmienia, gdy obciążenia — a następnie węzły, na których są uruchamiane — przychodzą i odchodzą?
- Jak sklasyfikować elementy infrastruktury IT, aby konkretnie wybrać węzły do zastosowania określonej automatyzacji?
Zasoby dynamiczne dostarczają odpowiedzi na oba te pytania () – skrypt lub wtyczka wyszukująca węzły do automatyzacji, odwołując się do źródła prawdy. Ponadto dynamiczna inwentaryzacja automatycznie klasyfikuje węzły w grupy, dzięki czemu można dokładniej wybierać systemy docelowe do wykonywania określonej automatyzacji Ansible.
dać użytkownikowi Ansible możliwość dostępu do platform zewnętrznych w celu dynamicznego wyszukiwania węzłów docelowych i wykorzystania tych platform jako źródła prawdy podczas tworzenia inwentarza. Standardowa lista źródeł w Ansible obejmuje platformy chmurowe AWS EC2, Google GCP i Microsoft Azure, a także istnieje wiele innych wtyczek inwentaryzacyjnych dla Ansible.
Ansible Tower zawiera wiele , które działają od razu po wyjęciu z pudełka i oprócz wymienionych powyżej platform chmurowych zapewniają integrację z VMware vCenter, Red Hat OpenStack Platform i Red Hat Satellite. W przypadku tych wtyczek wystarczy podać dane uwierzytelniające, aby połączyć się z platformą docelową, po czym można je wykorzystać jako źródło danych inwentaryzacyjnych w Ansible Tower.
Oprócz standardowych wtyczek dołączonych do Ansible Tower istnieją inne wtyczki ekwipunku obsługiwane przez społeczność Ansible. Wraz z przejściem do wtyczki te zaczęto dołączać do odpowiednich kolekcji.
W tym poście zajmiemy się przykładem pracy z wtyczką inwentaryzacyjną dla ServiceNow, popularnej platformy do zarządzania usługami IT, w której klienci często przechowują informacje o wszystkich swoich urządzeniach w bazie CMDB. Ponadto CMDB może zawierać kontekst przydatny do automatyzacji, taki jak informacje o właścicielach serwerów, poziomach usług (produkcyjny/nieprodukcyjny), zainstalowanych aktualizacjach i oknach konserwacji. Wtyczka Ansible Inventory może współpracować z ServiceNow CMDB i stanowi część kolekcji na portalu .
Repozytorium Gita
Aby użyć wtyczki ekwipunku z kolekcji w Ansible Tower, należy ją ustawić jako źródło projektu. W Ansible Tower projekt jest integracją z pewnego rodzaju systemem kontroli wersji, takim jak repozytorium git, którego można używać do synchronizowania nie tylko podręczników automatyzacji, ale także zmiennych i list inwentarzowych.
Nasze repozytorium jest w rzeczywistości bardzo proste:
├── collections
│ └── requirements.yml
└── servicenow.yml
Plik servicenow.yml zawiera szczegółowe informacje na temat spisu wtyczek. W naszym przypadku po prostu określamy tabelę w bazie CMDB ServiceNow, z której chcemy skorzystać. Ustawiamy także pola, które zostaną dodane jako zmienne węzła oraz 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: ''
Należy pamiętać, że nie określa to instancji ServiceNow, z którą będziemy się w jakikolwiek sposób łączyć, ani nie określa żadnych danych uwierzytelniających do połączenia. Wszystko to skonfigurujemy później w Ansible Tower.
potrzebne, aby Ansible Tower mogło pobrać wymaganą kolekcję i w ten sposób uzyskać wymaganą wtyczkę ekwipunku. W przeciwnym razie musielibyśmy ręcznie zainstalować i utrzymywać tę kolekcję na wszystkich naszych węzłach Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Po przekazaniu tej konfiguracji do kontroli wersji możemy utworzyć projekt w Ansible Tower, który odwołuje się do odpowiedniego repozytorium. Poniższy przykład łączy Ansible Tower z naszym repozytorium github. Zwróć uwagę na adres URL SCM: pozwala zarejestrować konto w celu połączenia się z prywatnym repozytorium, a także określić konkretną gałąź, tag lub zatwierdzenie do sprawdzenia.
Tworzenie poświadczeń dla ServiceNow
Jak już wspomnieliśmy, konfiguracja w naszym repozytorium nie zawiera danych uwierzytelniających umożliwiających połączenie z ServiceNow oraz nie określa instancji ServiceNow, z którą będziemy się komunikować. Dlatego, aby ustawić te dane, utworzymy poświadczenia w Ansible Tower. Według , istnieje szereg zmiennych środowiskowych, za pomocą których ustawimy parametry połączenia, na przykład tak:
= username
The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE
set_via:
env:
- name: SN_USERNAME
W takim przypadku, jeśli ustawiona jest zmienna środowiskowa SN_USERNAME, wtyczka inwentarzowa użyje jej jako konta do połączenia z ServiceNow.
Musimy także ustawić zmienne SN_INSTANCE i SN_PASSWORD.
Jednakże w Ansible Tower nie ma poświadczeń tego typu, w których można by określić te dane dla usługi ServiceNow. Ale Ansible Tower pozwala nam zdefiniować , więcej na ten temat przeczytasz w artykule .
W naszym przypadku konfiguracja wejściowa niestandardowych poświadczeń dla ServiceNow wygląda następująco:
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Te poświadczenia zostaną ujawnione jako zmienne środowiskowe o tej samej nazwie. Jest to opisane w konfiguracji wtryskiwaczy:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Zdefiniowaliśmy więc potrzebny typ danych uwierzytelniających, teraz możemy dodać konto ServiceNow i ustawić instancję, nazwę użytkownika i hasło w następujący sposób:
Tworzymy inwentarz
Zatem teraz wszyscy jesteśmy gotowi na utworzenie inwentarza w Ansible Tower. Nazwijmy to ServiceNow:
Po utworzeniu inwentarza możemy do niego dołączyć źródło danych. Tutaj podajemy utworzony wcześniej projekt i wpisujemy ścieżkę do naszego pliku inwentarza YAML w repozytorium kontroli źródła, w naszym przypadku jest to servicenow.yml w katalogu głównym projektu. Ponadto musisz połączyć swoje konto ServiceNow.
Aby sprawdzić jak wszystko działa spróbujmy przeprowadzić synchronizację ze źródłem danych klikając przycisk „Synchronizuj wszystko”. Jeżeli wszystko zostało poprawnie skonfigurowane to węzły powinny zostać zaimportowane do naszego inwentarza:
Informujemy, że potrzebne nam grupy również zostały utworzone.
wniosek
W tym poście przyjrzeliśmy się, jak używać wtyczek ekwipunku z kolekcji w Ansible Tower na przykładzie wtyczki ServiceNow. Bezpiecznie zarejestrowaliśmy również dane uwierzytelniające, aby połączyć się z naszą instancją ServiceNow. Powiązanie wtyczki ekwipunku z projektem działa nie tylko z wtyczkami innych firm lub wtyczkami niestandardowymi, ale może być również użyte do modyfikacji działania niektórych standardowych inwentarzy. Dzięki temu platforma Ansible Automation Platform jest łatwa i bezproblemowa w integracji z istniejącymi narzędziami podczas automatyzacji coraz bardziej złożonych środowisk IT.
Więcej informacji na tematy omówione w tym poście, a także inne aspekty korzystania z Ansible, znajdziesz tutaj:
- Blog autorstwa .
- .
- Lista kolekcji obsługiwanych przez firmę Red Hat w witrynie Automation Hub ().
- .
*Firma Red Hat nie gwarantuje, że kod zawarty w niniejszym dokumencie jest poprawny. Wszystkie materiały są udostępniane bez poparcia, chyba że wyraźnie określono inaczej.
Źródło: www.habr.com