Wśród wielu serwisów udostępniających skrypty automatyzacji warto zwrócić uwagę na Cisco DevNet Code Exchange. Jest to platforma, na której zebrane są stworzone przez Cisco oraz niezależnych developerów i entuzjastów skrypty ułatwiające automatyzację produktów z ekosystemu Cisco. Jeżeli więc pracujesz z urządzeniami tej firmy na co dzień, to powinieneś mieć ten serwis w swoich zakładkach. Mój projekt, CMLNetKit, także znajduje się w tym repozytorium.
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.
Trafił do mnie na jakiś czas firewall Fortigate 60E, więc postanowiłem skorzystać z okazji i zobaczyć co oferuje platforma od strony programowalnego zarządzania. Z urządzeniami Fortigate mam styczność co jakiś czas, wielu mniejszych klientów z nich korzysta. Nie miałem okazji jednak wykorzystywać ich interfejsu API czy programowalnych funkcjonalności. Opisane funkcje testowałem na najnowszym firmware 7.0.0.
Telemetria to nie to samo co monitoring zatem i konfiguracja telemetrii przebiega nieco inaczej. To nie system monitorujący odpytuje urządzenia o ich stan, lecz to same urządzenia przesyłają strumień danych, w których zawierają się informacje o statystykach czy zdarzeniach. O tym teoretycznej stronie telemetrii napisałem w pierwszej części. Teraz czas na trochę praktyki, czyli zajmiemy się konfiguracją Model Driven Telemetry w IOS XE.
Wczoraj miałem przyjemność gościć jako prelegent na kolejnym webinarze w ramach cyklu Władcy Sieci. Tym razem opowiadałem i pokazywałem w jaki sposób połączyć ze sobą dwa narzędzia do automatyzacji – Terraform oraz Ansible. To jedne z najczęściej wykorzystywanych produktów służących do automatyzacji i bardzo dobrze się dopełniają.
Na GitHub Szkoły DevNet umieściłem skrypt, który powstał w czasie webinaru. Realizowaliśmy proste zadanie – zbudowanie skalowalnej infrastruktury serwerów WWW, które budowane są za pomocą Terraforma, a konfigurowane z wykorzystaniem Ansible. Oczywiście całość wykonywana poprzez jedno wywołanie, a playbook Ansible wykonany jako zadanie z Terraforma.
Prowadziłem wczoraj webinar, w trakcie którego pokazywałem jak działa usługa Azure Virtual WAN (Azure vWAN). Laboratorium do tego webinaru przygotowałem korzystając z Terraforma. To chyba ostatnio moje ulubione narzędzie do budowania usług w chmurze publicznej – zazwyczaj jest to Azure lub AWS. Podzielę się z Wami skryptem, który utworzyłem.
Telemetria nie jest czymś nowym. Od zawsze administratorzy zbierali informacje o administrowanych systemach i wyciągali z nich wnioski. Mieli do tego odpowiednie protokoły (choćby znane wszystkim SNMP) i narzędzia (na przykład Nagios). Narzędzia te są jednak niewystarczające w środowisku opartym o modele. Tak powstało Model Driven Telemetry, czyli telemetria oparta na modelach.
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.
Jenkins to elastyczne narzędzie do tworzenia i wykonywania scenariuszy w modelu CI/CD. Scenariusz taki może składać się z przeróżnych kroków, w trakcie których wykorzystujemy zewnętrzne narzędzia takie jak skrypty Pythona. W dzisiejszym artykule zaprezentuję Ci trzy sposoby wywoływania skryptów Python w Jenkins w projektach opisywanych za pomocą zdefiniowanych akcji jak i jako pipeline.
Inventory, czyli zbiór urządzeń, na których ma zostać wykonany playbook Ansible, co do zasady definiujemy jako statyczny plik, lub w sposób dynamiczny korzystając z wtyczek z grupy Inventory Plugins. Ja czasami jednak uciekam się do drobnej sztuczki, która jest dla mnie niezwykle wygodna, gdy uruchamiam proste playbooki, w których wykorzystuję moduły do Dockera. Jaka to sztuczka?