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.
Plik konfiguracji na hoście
Aplikacje uruchamiane w kontenerach powinny co do zasady są raczej bezstanowe, co nie znaczy, że pozbawione są konfiguracji. Wiele aplikacji wymaga plików konfiguracyjnych do poprawnego działania. W zależności od uruchomionej instancji zazwyczaj różnią się one między sobią. Na przykład każda instancja NGINX czy Apache będzie miała własną konfigurację specyficzną dla uruchomionej usługi serwera WWW.
Najgorszym i najmniej praktycznym sposobem umieszczania plików konfiguracyjnych jest ich zapisywanie jako jednej z warstw w obrazie, z którego uruchamiać będziemy kontenery. Stosując takie podejście musimy utworzyć i utrzymywać obraz dla każdego z wirtualnych serwerów WWW oddzielnie. Jest to wysoce niepraktyczne i wypacza ideę konteneryzacji.
Powszechnie stosowaną metodą jest montowanie pliku konfiguracyjnego z hosta, na którym uruchomiliśmy usługę Dockera, w uruchamianym kontenerze jako wolumen.
version: '3'
services:
web:
image: web:latest
restart: unless-stopped
volumes:
- /home/user/CONFIG:/opt/app/CONFIG:Z
Jeżeli używamy docker-compose do uruchomienia aplikacji, to w sekcji volumes dodajemy nowy wpis. Podajemy w nim ścieżkę (względną lub bezwzględną) do pliku konfiguracyjnego znajdującego się w systemie hosta. Następnie podajmy ścieżkę w kontenerze, za pomocą której wskazujemy na miejsce, w którym podłączony plik ma być umieszczony, oraz jego nazwę. Jeżeli kontener uruchamiany z linii poleceń musimy operujemy parametrem -v w następujący sposób:
docker run -d -it --name web -v /home/user/CONFIG:/opt/app/CONFIG web:latest
Docker Swarm Configs
Przedstawione powyżej rozwiązanie ma jedną wadę, gdy używamy klastrów Docker Swarm. Zazwyczaj w klastrze kontener z aplikacją może zostać uruchomiony na każdym z węzłów klastra, lub na wybranych węzłach. Oznacza to, że podłączając plik konfiguracyjny jaj we wcześniejszych przykładach, kopię pliku z konfiguracją musimy trzymać na każdym z urządzeń wchodzących w skład klastra. I to w tym samym katalogu, do którego odwołamy się za pomocą ścieżki bezwzględnej.
Jeżeli używasz klastrów Docker Swarm to do dyspozycji dostajemy moją ulubioną metodę, czyli mechanizm Docker Configs. Pozwala on na zapisanie pliku konfiguracyjnego, czy jakiegokolwiek innego pliku tekstowego, jako obiektu klastra Swarm. Nie musimy zatem martwić się o jego synchronizację pomiędzy węzłami klastra, odbywa się ona automatycznie.
Nowy obiekt typu config najprościej utworzyć na podstawie pliku, choć można też pobrać jego zawartość ze strumienia stdin.
docker config create KONFIGURACJA /home/user/CONFIG
Listę utworzonych plików konfiguracyjnych wyświetlimy poleceniem docker config ls. Do odczytania zawartości zapisanego obiektu wydamy polecenie docker config inspect z parametrem –pretty. Brak tego parametru spowoduje wyświetlenie informacji o samym obiekcie, a nie zapisaną zawartość.
Aby użyć utworzony obiekt typu config w uruchamianym stosie Swarm musimy w pliku konfiguracyjnym zdefiniować odpowiednie obiekty. Jako nazwę obiektu używamy nazwę, którą nadaliśmy samodzielnie obiektowi config. Dodajemy też parametr external: yes za pomocą którego określamy, że jest to obiekt globalny. Powinniśmy go wcześniej utworzyć. W konfiguracji samej usługi podajemy ścieżkę wewnątrz kontenera, w której zawartość obiektu będzie zapisana.
version: '3'
services:
web:
image: web:latest
restart: unless-stopped
configs:
- source: KONFIGURACJA
target: /opt/app/CONFIG
configs:
KONFIGURACJA:
external: yes
Mechanizm Docker Configs, obok Secrets, stanowi jeden z dwóch powodów, dlaczego rekomenduję uruchamianie klastra Swarm nawet na pojedynczym hoście z Dockerem.
