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?
W jednym z poprzednich postów opisałem mechanizm Docker Configs. Pozwala on na umieszczenie zawartości dowolnego pliku w kontenerze działającym w klastrze Swarm. Zawartość pliku definiujemy jako obiekt klastra. Jest jeszcze drugi wart uwagi mechanizm Docker Secrets. Wykorzystujemy go, aby zarządzań i przekazywać w bezpieczny sposób do kontenera wrażliwe informacje takie jak hasła czy klucze SSH.
Czy ma znaczenie, jaki obraz wyjściowy użyjemy do budowy naszego kontenera? Mało kto zaczyna od pustego kontenera. Zazwyczaj jako bazę bierzemy taki, który zawiera jedną z popularnych dystrybucji Linuksa. Czy ma znaczenie jaka to będzie dystrybucja? Jak się okazuje ogromne. Dlatego ja staram się budować swoje kontenery przy pomocy obrazów, które zostały stworzone na bazie Alpine Linux.
Ostatnio chciałem dokonać aktualizacji GitLab-a w moim domowym labie. Nie wyszło. Podnosząc wersję oprogramowania GitLab-a, od dwóch lat nie aktualizowałem wersji bazy danych, która jest niezbędna do prawidłowego działania. O ile wersja GitLab 13.1.4 nadal działała z PostgreSQL 9.6.2 (mimo że w dokumentacji jest zapisane, że to od dawna wersja niewspierana), to wersja 13.2 już ze starą bazą uruchomić się nie chciała. Aktualizacja bazy nigdy nie należy do prostych zadań. Pokażę Ci, w jaki sposób ja podszedłem do tego zadania i wykorzystałem dobrodziejstwo kontenerów. Nie jest to metoda zgodna z zaleceniami, które znajdziesz w dokumentacji, ale działa. I moim zdaniem do zastosowań w labie jest najprostsza i najszybsza. Aktualizacja kontenera bazy danych okazała się dzięki temu całkiem szybka i niezbyt skomplikowana.
W ciągu ostatnich kilku dni opublikowałem na GitHub pierwszy kod mojej aplikacji CMLNetKit. Od razu dostałem pytanie: “Już napisałeś całość? Tak szybko?“. No nie, aplikacja nie jest skończona. Ona jeszcze mało co potrafi, tak naprawdę zaimplementowałem jedynie jedną z funkcjonalności, o których pisałem w moim poprzednim artykule. Dlaczego zatem zdecydowałem się na pierwsze publiczne udostępnienie kodu już teraz? Jak szybko publikować pierwszy kod własnej aplikacji w repozytorium?
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?
W tym roku prowadzę sporo różnego rodzaju webinarów, elementem większości z nich jest demo rozwiązania, a niektóre całe moje wystąpienia były jednym kompletnym demo, bez żadnych slajdów. Do demonstracji rozwiązań sieciowych opartych o urządzenia Cisco używam Cisco Modeling Labs, wcześniej Cisco VIRL. Jak wiecie CML 2.0 nie przypadł mi do gustu, obecnie lista moich zarzutów co do wykonania i użyteczności GUI CML 2.0 jest jeszcze bardziej negatywna. Dlatego postanowiłem sam rozwiązać przynajmniej część z tych problemów. Wy będziecie obserwatorami, a może i uczestnikami procesu tworzenia tego narzędzia. Zanim jednak zaczniemy poznajmy zasady budowy i projektowania różnego typu narzędzi.
Bezpieczne urządzenie w domyślnej konfiguracji to takie wyłączone urządzenie. A najlepiej także odłączone od prądu. Bezpieczna aplikacja to wyłączona aplikacja, a najlepiej odinstalowana. Tak, trochę za dużo chyba ostatnio z “bezpiecznikami” rozmawiam… Niemniej tych zasad nie uda nam się spełniać w systemach IT, musimy zatem zadbać o odpowiednie mechanizmy bezpieczeństwa. Nie inaczej jest z Dockerem. W poprzednim swoim artykule zaznaczałem, że Docker w swojej domyślnej instalacji może się co najwyżej nadawać do domowego odizolowanego laboratorium. Nawet w systemach testowych czy developerskich powinniśmy wdrożyć mechanizm zwany namespace. Jego aktywacja powoduje jednak problemy z dostępem do gniazda (socket), służącego do lokalnej komunikacji z demonem Dockera.