Gdy po reinstalacji za pomocą mechanizmy Zero Touch Provisioning maszyna wirtualna się uruchomi odtwarzamy z kopii zapasowej konfigurację Cisco ISE. Jest to o tyle proste, że w konfiguracji ZTP wskazaliśmy, że API Cisco ISE ma być domyślnie aktywne. Zapraszam na ostatnią część cyklu, w którym odtworzymy konfigurację Cisco ISE z kopii zapasowej.
Czy możemy uruchomić Cisco ISE i dokonać wstępnej konfiguracji bez dostępu do konsoli? Tak, służy do tego ZTP. Mechanizm Zero Touch Provisioning na Cisco ISE pozwala na przekazanie podstawowych parametrów konfiguracyjnych do nowej maszyny wirtualnej oraz uruchomienie podstawowych usług. Dzięki temu dostęp do konsoli za pomocą hypervisora nie jest wymagany.
W poprzednich dwóch krokach sprawdziłem warunki, czy w ogóle mogę odtworzyć Cisco ISE z kopii zapasowej. Sprawdziłem czy mam “świeżą” kopię zapasową oraz czas licencji trial jest bliski wyczerpania. Jeżeli oba warunki są spełnione to mogę przechodzę do odtworzenia maszyny z kopii zapasowej. Na początek jednak muszę wyłączyć działającą maszynę wirtualną z Cisco ISE i na wszelki wypadek zrobić jej kopię zapasową na poziomie samego hypervisora.
W kolejnym wpisie z cyklu zajmiemy się sprawdzaniem drugiego z warunków, które są niezbędne do podjęcia decyzji o odtworzeniu z kopii zapasowej. Pokażę Ci teraz jak sprawdzić ważność licencji trial, czy liczba pozostałych dni jest mniejsza niż 21. Wykorzystamy do tego API dostarczane przez Cisco ISE.
W kolejnym wpisie z cyklu zajmiemy się sprawdzeniem daty ostatniego backupu. Potrzebuję sprawdzić, czy spełniony jest pierwszy z moich warunków pozwalający na odtworzenie Cisco ISE z backupu. Jest to dostęp do kopii zapasowej, która została wykonana nie wcześniej niż wczoraj. Jest to warunek, które sam ustaliłem, gdyż równie dobrze mógłbym sprawdzać, czy mam dostęp do jakiegokolwiek backupu i wykorzystać najnowszy z dostępnych. Spójrz w jaki sposób zaimplementowałem sprawdzenie daty backupu, z którego możliwe będzie odtworzenie później konfiguracji Cisco ISE.
W tej serii artykułów pokazuję jak stworzyłem w swoim labie automatyzację procesu cyklicznego odtwarzania Cisco ISE w postaci maszyny wirtualnej. W pierwszym artykule przedstawiłem Ci projekt. z jakich komponentów korzystam. Opisałem też jak wygląda konfiguracja Jenkinsa, a dokładniej jak utworzyłem w nim nowy projekt. Spójrzmy teraz dokładniej jakie dodatkowe komponenty są potrzebne, aby wykonanie playbooków Ansible przez Jenkinsa było możliwe.
W tej serii artykułów przybliżę Ci jeden z moich ostatnich projektów do domowego labu. Nie ukrywam, że lubię mieć lab always-on, czyli taki, który działa, który ma skonfigurowane pewne funkcjonalności, do których w każdej chwili mogę się odwołać, sprawdzić je czy zmodyfikować. Powstała więc potrzeba zautomatyzowania procesu budowania maszyny wirtualnej z Cisco ISE oraz odtwarzania konfiguracji ISE z kopi zapasowej. W pierwszym odcinku spójrzmy jak wygląda automatyzacja odtwarzania Cisco ISE i z jakich komponentów będę korzystał.
Ostatnio zastąpiłem mojego starego, wysłużonego (i głośnego) Junipera SRX urządzeniem Fortigate 30E. Firewall jest zainstalowany na brzegu mojej sieci domowo-labowej. Zapewnia mi między innymi zdalny dostęp do laba czy przestrzeni dyskowej na NAS. Jedną z kluczowych funkcjonalności jest zatem zdalny dostęp za pomocą SSL VPN. Ponieważ portal SSL VPN jest wystawiony na świat, to chciałem by prezentował się za pomocą publicznego certyfikatu podpisanego przez jedno z globalnych CA. Niestety mój firewall nie posiada funkcji automatycznego odnawiania certyfikatów Let’s Encrypt, dlatego czynność tą musiałem samodzielnie zautomatyzować. Pokażę Ci w jaki sposób wykorzystałem do tego Ansible.
Ostatnio realizowałem szkolenie, w którym dość często musiałem reinstalować system operacyjny Linux na maszynach wirtualnych. Sama reinstalacja systemu i jego późniejsza konfiguracja nie sprawiały mi żadnego problemu. Mam przygotowane playbooki Ansible, które konfigurują system, instalują odpowiednie pakiety i wgrywają ich konfigurację. Problem pojawiał się z jednym krokiem – pierwszym logowaniem i wymuszoną zmianą hasła. Na szczęście w Ansible jest moduł expect.
W klastrach Docker Swarm możemy uruchamiać serwisy w dwóch trybach – global oraz replicated. Jeżeli wybierzemy pierwszy z nich, to na każdym węźle wchodzącym w skład klastra zostanie uruchomiona dokładnie jednak kopia serwisu. W trybie replicated wskazujemy, ile kopii serwisu chcemy mieć uruchomionych, ale to Swarm decyduje, na których węzłach zostaną one uruchomione. Możemy w pewnym stopniu na nie wpływać za pomocą tak zwanych placement constraints i placement preferences. Jest też parametr MaxReplicas, którego wsparcie napisałem dla biblioteki docker-py oraz do modułu docker_swarm_service kolekcji community.docker w projekcie Ansible. Korzytanie z niego jest bardzo proste.