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.
Docker
Przekazywanie wrażliwych danych do kontenera
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.
Przez Piotr Wojciechowski, temu
Docker
Jak umieszczam pliki wewnątrz konterena
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.
Przez Piotr Wojciechowski, temu
Docker
GitLab – aktualizacja kontenera bazy danych
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.
Przez Piotr Wojciechowski, temu
DevNet Associate
Przestał budować się obraz kontenera
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.
Przez Piotr Wojciechowski, temu
DevNet Associate
Namespace i podłączenie gniazda Dockera do kontenera
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.
Przez Piotr Wojciechowski, temu
Ansible
Instalacja Dockera za pomocą Ansible
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ń.
Przez Piotr Wojciechowski, temu
Ansible
Uruchamiamy API Dockera za pomocą Ansible
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.
Przez Piotr Wojciechowski, temu
DevNet Associate
API Dockera
Jeżeli chodzi o wszelkiej maści automatyzację, to zawsze preferuję wykorzystywanie API wszędzie gdzie to tylko możliwe. Wydawanie poleceń na urządzeniu i parsowanie wyniku, który normalnie widzisz na ekranie to prosta droga do wywołania awarii w swojej sieci. Wystarczy, że w wyniku zmieni się jeden znak, a już twoje skrypty przestaną poprawnie działać. API działa inaczej, gdyż w operuje ściśle określonymi metodami i strukturami danych w komunikacji między klientem a aplikacją. Dlatego jedną z pierwszych czynności jakie powinniśmy zrobić to podłączenie API Dockera do interfejsów maszyny, na której uruchomiliśmy usługę.
Przez Piotr Wojciechowski, temu