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.
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.
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.
Spośród wielu narzędzi, których będziesz używał, jednym z podstawowych będzie Docker. To w kontenerach najlepiej odpalić inne narzędzia takie jak Jenkis, Puppet, Ansible Tower czy nawet własną instancję GitLaba. Rozwiązanie takie sprawdza się zarówno na systemach produkcyjnych jak i w laboratorium. Wiele aplikacji jest od podstaw napisanych, lub zostało zoptymalizowane, do działania w kontenerach. Instalacja Dockera jest bardzo prosta. Pamiętaj jednak, że Docker zaraz po zainstalowaniu nie jest odpowiednio zabezpieczony, aby bezpiecznie go wykorzystywać poza domowym zaciszem lub labem.