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?
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.
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ą?
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!
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.
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:
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ć.
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:
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?
Kolejne dni pracy z Cisco Modeling Labs 2.0. Przygotowywałem się do pierwszego wykorzystania go w większej topologii i scenariuszu w ramach webinaru. Ale tym razem nie będę pisał o CML 2.0. Przygotowując scenariusza laba chciałem mieć zapisane wzorcowe konfiguracje urządzeń z kolejnych etapów. Niestety CML 2.0 nie pozwala na łatwe zgranie konfiguracji z urządzeń biorących udział w symulacji. Napisanie playbooka wykonującego backup konfiguracji routera za pomocą Ansible jest przecież bardzo proste.
Od początku roku przygotowałem kilka labów typu PoC (Proof of Concept), webinariów oraz prezentacji, w ramach których używałem rozwiązań w chmurze Azure. Dema i testy mają jedną wspólną cechę – wykonuje się je z modyfikacjami wielokrotnie. W takich sytuacjach staram się korzystać ze zautomatyzowanych narzędzi do budowy infrastruktury. Do takich należy choćby Terraform. Zanim jednak pokażę Ci fragmenty konfiguracji budujących środowisko do wspomnianych projektów, zobacz, w jaki sposób Terraform zainstalować i uruchomić.
Konfigurując mechanizmy automatyzujące codzienne czynności, bardzo szybko spotkasz się z koniecznością przekazywania danych pomiędzy modułami, pomiędzy aplikacjami, czy pomiędzy Twoją aplikacją a interfejsem API. Zmienne systemu operacyjnego do takich zadań nie wystarczą, dlatego musisz skorzystać z jednej z dostępnych struktur danych. Znajomość dwóch z nich jest wręcz niezbędna – są to XML i JSON. Osobiście preferuję korzystanie z tego drugiego, gdzie tylko jest to możliwe. Przede wszystkim ze względu na lepszą czytelność informacji i prostotę użycia.
Ostatni artykuł, w którym pokazałem jak skonfigurować API Dockera za pomocą playbooka Ansible zaowocował przysłanym mi pytaniem, czy równie prosto da się zautomatyzować instalację samego Dockera. Oczywiście że się da! Pierwsze moduły do Ansible miały na celu ułatwić zarządzanie pakietami i konfigurację systemów typu Linux. Pokarzę Ci teraz fragmenty z mojego playbooka (poszczególne zadania), którego używam do instalacji Dockera na RaspberryPi i dystrybucji Raspbian. Instalacja Dockera za pomocą Ansible składa się jedynie z kilku zadań.
W artykule „API Dockera” opisywałem dlaczego warto aktywować API na interfejsach sieciowych maszyny, oraz pokazałem kilka metod jak to zrobić. W różnego rodzaju testach, które przeprowadzam, rozpoczynam je od instalacji systemu operacyjnego. Manualne wprowadzanie za każdym razem zmian w konfiguracji byłoby krótko mówiąc marnowaniem czasu. Pokarzę Ci teraz w jaki sposób zautomatyzować tą pojedynczą czynność za pomocą Ansible.