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ę.
Parametry pracy Dockera
Jeżeli chcemy dokonać zmiany konfiguracji samej usługi Dockera, to możemy to zrobić na dwa sposoby – za pomocą pliku konfiguracyjnego lub zmieniając parametry wywołania demona w systemowej konfiguracji usługi. Jednak nawet jeżeli zdecydujemy się na stworzenie pliku konfiguracyjnego, to aktywując dostęp za pomocą API, w większości dystrybucji będziemy musieli zmodyfikować także systemowy plik konfiguracyjny, ale o tym za chwilę.
W dystrybucjach, w których zarządzanie usługami odbywa się za pośrednictwem systemd, plik z konfiguracją startową usługi to /lib/systemd/system/docker.service. Znajdziemy w nim parametr o nazwie ExecStart. Definiuje on polecenie uruchamiające proces wraz z parametrami, które zostanie wywołane, aby uruchomić usługę. Możemy dopisywać w nim własne parametry, tak jakbyśmy uruchamiali proces samodzielnie z linii poleceń.
Drugim sposobem na konfigurację parametrów pracy usługi jest stworzenie dedykowanego pliku konfiguracyjnego /etc/docker/daemon.json. Zapisane w nim są te same parametry, które wywołamy z linii poleceń. Sam plik ma format struktury JSON.
Włączamy API Dockera
API Dockera jest zawsze włączone. Komunikujesz się za jego pośrednictwem z procesem dockera przez gniazdo (/var/run/docker.sock). Oznacza to, że po instalacji Dockera komunikacja z procesem jest możliwa jedynie z poziomu użytkownika z odpowiednimi uprawnieniami. Aby umożliwić komunikację poprzez sieć, musimy wskazać interfejsy, na których proces ma nasłuchiwać, podając ich adresy IP. Aby uaktywnić API na wszystkich interfejsach urządzenia, jako parametr podajemy 0.0.0.0.
Parametry startowe usługi znajdziemy w /lib/systemd/system/docker.service. W większości systemów Linux zdefiniowane są one w następującej postaci:
ExecStart=/usr/bin/dockerd -H fd://
Parametr -H służy określaniu, gdzie proces ma nasłuchiwać na połączenia. Jego wartość fd:// oznacza lokalne gniazdo. Tej wartości nie usuwajmy, inaczej przestanie nam działać linia poleceń z konsoli. To, co musimy zrobić, to dodać kolejne wywołanie parametru.
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376
Domyślnym portem działania usługi jest tcp/2376, ale można go dowolnie zmienić. Alternatywnym sposobem, za pomocą którego możemy zmienić parametry wywołania, ale bez konieczności wprowadzania zmian w systemowym pliku usługi jest utworzenie pliku /etc/systemd/system/docker.service.d/startup_options.conf o następującej zawartości.
[Service] ExecStart= ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376
Plik konfiguracyjny Dockera
Innym sposobem określania parametrów pracy Dockera jest zapisanie ich w pliku konfiguracyjnym /etc/docker/daemon.json. Jest to wygodniejsza metoda, gdy liczba parametrów, które konfigurujemy, jest znacząca. Plik ten nie jest domyślnie tworzony podczas instalacji, należy to zrobić samodzielnie, zapisując parametry w strukturze typu JSON. Pamiętajmy, że zdefiniowane w nim parametry nie mogą stać w sprzeczności, czy nawet pokrywać się z tymi, które znajdują się w pliku usługi systemowe. W takim przypadku najlepiej wcześniej zmienić konfigurację usługi systemowej usuwając z niej wszystkie domyślne parametry.
Plik konfiguracyjny Dockera w naszym przypadku będzie bardzo prosty:
{
"ip": "0.0.0.0",
"hosts": ["tcp://0.0.0.0:2376", "unix://"],
"tls": false
} Parametr tls wymusza wyłączenie szyfrowania połączenia z interfejsem API. Pamiętajmy, aby nigdy takiej konfiguracji nie wdrażać poza swoim domowym labem.
[…] artykule „API Dockera” opisywałem dlaczego warto aktywować API na interfejsach sieciowych maszyny, oraz […]