Łączymy Terraform i Ansible ze sobą

Łączymy Terraform i Ansible ze sobą

Łączymy Terraform i Ansible ze sobą

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.

Czytaj dalej
Model Driven Telemetry w IOS XE cz. 1

Model Driven Telemetry w IOS XE (część 1)

Model Driven Telemetry w IOS XE cz. 1

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.

Czytaj dalej
Pierwsze logowania i zmiana hasła za pomocą Ansible i modułu expect

Pierwsze logowania i zmiana hasła za pomocą Ansible

Pierwsze logowania i zmiana hasła za pomocą Ansible i modułu expect

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.

Czytaj dalej
Skrypt Python w Jenkins

Uruchamiamy skypt Python w Jenkins

Skrypt Python w Jenkins

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.

Czytaj dalej
Jak oszukuję inventory w Ansible

Jak „oszukuję” inventory w Ansible

Jak oszukuję inventory w Ansible

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?

Czytaj dalej
O automatyzacji sieciach - wywiad z Przemkiem Rogalą

O automatyzacji w sieciach – wywiad z Przemkiem Rogalą (część II)

O automatyzacji sieciach - wywiad z Przemkiem Rogalą

W pierwszej części mojej rozmowy z Przemkiem Rogalą, twórcą bloga TTL255, rozmawialiśmy o egzaminie DEVASC i certyfikacji Cisco DevNet. Certyfikaty byłby jednak zbędne, gdyby nie rzeczywiste projekty, w których wiedzę i doświadczenie zamienia się na konkretne rozwiązania. Zarówno Przemek jak i ja realizujemy tego typu projekty, choć na innych rynkach. W drugiej części mojej rozmowy skupimy się właśnie na rzeczywistym wykorzystaniu automatyzacji, projektach, programowaniu i narzędziach, które wykorzystujemy.

Czytaj dalej
Terraform 0.14

Terraform 0.14

Terraform 0.14

Minęły zaledwie cztery miesiące od wydania Terraform 0.13. W międzyczasie doczekaliśmy się dużej konferencji organizowanej przez Hashicorp, twórcę Terraforma, na której ogłoszono między innymi Terraform Cloud. Programiści nie dostosowali swoich skryptów do wersji 0.13, a już z początkiem grudnia w nasze ręce oddany został Terraform 0.14. Jakie zmiany zostały wprowadzone wraz z nową wersją?

Czytaj dalej
Terraform i Makefile

Terraform i Makefile

Terraform i Makefile

Wielu inżynierów zapomina, że narzędzia, z których korzystają, można w prosty sposób łączyć. Ja w ten sposób w projektach łączę często Terraform i Makefile. Pozwala mi to zautomatyzować proces wykonywania czynności oraz uniknąć prostych błędów, takich jak choćby literówki czy odwoływanie się do nieistniejących plików. Pokażę Ci teraz jakie to banalnie proste!

Czytaj dalej
Jak określam założenia projektu automatyzacji

Jak określam założenia projektu automatyzacji

Jak określam założenia projektu automatyzacji

W najbliższych artykułach pokażę Wam proces budowania narzędzia do automatyzacji oraz jak korzystać z narzędzi do zarządzania kodem i pracy grupowej. Gdy rozpoczynam pracę nad nowym projektem, zawsze zaczynam od określenia kilku kluczowych jego parametrów. Jednym z nich jest oczywiście nazwa, którą zawsze mogę zmienić, dlatego początkowo nie musi ona porywać tłumów. Ciężej jednak odzyskać czas stracony na kodowanie niepotrzebnych funkcjonalności czy takich, które znajdziemy w publicznie dostępnych bibliotekach. Zamiast tego lepiej skupić się na esencjalnych dla tworzonego projektu elementach i pamiętać o nałożonych na projekt ograniczeniach. Tak, są one konieczne, a określając je, powinniśmy postępować zgodnie z zasadami, o których pisałem w poprzednim artykule. Dlatego na początek przedstawię Ci, jakie są moje założenia w tym projekcie.

Założenia projektu dotyczące funkcjonalności

W mojej głowie stworzyła się już wizja aplikacji z tyloma „ficzerami”, że CML 2.0 może się przy niej schować. I to oczywiście w pierwszej wersji, potem ma być tylko lepiej! Właśnie dlatego, aby nie ponieść się wodzom fantazji, a tym samym nie zaprzepaścić pomysłu na pomocny produkt, konieczne jest jasne określenie podstawowych celów. Zawsze określamy założenia projektu automatyzacji, zanim przystąpimy do jakichkolwiek prac. Podstawowe problemy, które chcę rozwiązać za pomocą swojej aplikacji to:

  1. Po ułożeniu topologii w ramach wyznaczonych przeze mnie podsieci chcę, aby moja aplikacja automatycznie zaadresowała:
    • Połączenia L3 pomiędzy urządzeniami
    • Wszystkie interfejsy Loopback0
    • Interfejsy służące do zarządzania
  2. Zmieniła konfigurację obiektów „External Connection” na Bridge 

Nie jest tego dużo. Można by się spytać, dlaczego tylko tyle? Na początku jest ich niewiele po to, by stworzyć aplikację, która rozwiąże moje najbardziej palące problemy. Wyręczy mnie w czynnościach, na których budując symulację, tracę najwięcej czasu. Gdy to się uda, mogę aplikację dalej rozwijać.

Ograniczenia i ramy

Aby stworzyć funkcjonalny produkt, założenia projektu muszą obejmować także listę ograniczeń i wyznaczyć ramy technologiczne, w jakich chcę się zmieścić. Są to minimalne funkcjonalności, które chcę zaimplementować i narzędzia, z których chcę korzystać. Moje ramy odnoszą się zarówno do elementów funkcjonalnych, jak i technicznych tworzonej aplikacji:

  1. W pierwszej wersji urządzenia, które będą obsługiwane, to IOS i IOS XE.
  2. Aplikacja ma jednak pozwalać w sposób prosty na dołączanie do obsługi pozostałych typów urządzeń dostępnych w CML 2.0. Oznacza to, że powinna być ona napisana z myślą pod przyszły jej rozwój.
  3. W możliwie największym zakresie aplikacja ma korzystać z API dostępnego w CML 2.0
  4. Językiem aplikacji będzie Python 3.7 i w miarę możliwości będę ograniczał liczbę wykorzystywanych bibliotek.
  5. Interfejs programu, jak i komentarze w kodzie, będą w języku angielskim.
  6. Będę programował obiektowo.
  7. Kod będę utrzymywał jako publiczny projekt na GitHub.

Dlaczego zdecydowałem się na programowanie obiektowe? Po wstępnej analizie dokumentacji API stwierdziłem, że stworzenie kodu obiektowego może przyszłościowo sprawić, że będzie on bardziej „przenaszalny”. Poza tym dzięki programowaniu w ramach projektu Ansible czuję się dość komfortowo, gdy piszę obiektowo w języku Python.

Być może powyższe ograniczenia będę musiał zweryfikować w trakcie projektu.

Możesz być częścią tego projektu! Napisz w komentarzu, poniżej jakie funkcjonalności uznajesz za kluczowe? Jakie narzędzia wybierzesz? W jakich ramach się zamkniesz? Czy przyjąłbyś inne założenia niż ja? Jeżeli tak to dlaczego?