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 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.
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.
Projektując mikrosegmentację usług i ich konteneryzację powinniśmy pamiętać, by nie zapisywać wewnątrz kontenerów informacji, które zmieniają się w zależności od instancji. Umieszczanie plików konfiguracyjnych aplikacji uruchamianej w kontenerze “na sztywno” w obrazie kontenera nie jest zbyt dobrym pomysłem. Podobnie rzecz ma się choćby z certyfikatami SSL. Pokażę Ci dwa sposoby na to, w jaki sposób możesz przekazać podłączyć dowolny plik do kontenera. Zdradzę Ci, że drugi jest moim ulubionym.
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.
Częścią obrazów kontenerów, które używam w swoich środowiskach sieciowych zarządzam samodzielnie. Ich cykliczną budową zajmuje się Jenkins. Także kontenery z obrazem samego Jenkinsa są budowane w ten sposób. 10 sierpnia coś się jednak stało. Mój skrypt przestał działać. W efekcie tego przestał budować się obraz kontenera. Wszystko ze względu na zmiany w pakietach z językiem Python w dystrybucji Alpine Linux. Jeżeli budujesz obrazy w oparciu o tą właśnie dystrybucję, to w tym artykule znajdziesz rozwiązanie.
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.
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ń.