w ,

Docker – wykrywanie usług poprzez DNS

Docker wykrywanie usług dla kontenerów
Docker wykrywanie usług dla kontenerów

Docker od wersji 1.1 umożliwia na wykrywanie usług za pomocą aliasu. Jest to osiągalne poprzez demon Dockera, który posiada zaimplementowany wbudowany serwer DNS.

W praktyce oznacza to, że tworząc plik konfiguracyjny dla Docker Compose możemy posługiwać się nazwami usług (aliasami) bez konieczności wskazywania ich adresu. W tym artykule przedstawię Ci najbardziej przydatne polecenia i przykłady, które ułatwią Ci konfiguracje sieci kontenerów.

Opcje konfiguracji ustawień DNS kontenera

  • –name=CONTAINER-NAME – przypisanie nazwy dla kontenera, za pomocą którego będzie można wyszukać go w sieci Dockerowej. Wbudowany serwer DNS przechowuje mapowanie między nazwą kontenera a jego adresem IP (w sieci, do której nastąpiło przyłączenie kontenera).
  • –network-alias=ALIAS – możliwość przypisania aliasu dla kontenera, który działa na podobnej zasadzie jak nazwa. Różnicą jest to, że kontener może mieć różne aliasy w różnych sieciach.
  • –link=CONTAINER_NAME:ALIAS – użycie tej opcji podczas uruchamiania kontenera tworzy wpis w DNS o nazwie ALIAS, który wskazuje adres IP kontenera zidentyfikowany przez CONTAINER_NAME.
  • –dns=[IP_ADDRESS…] – adresy IP podawane za pomocą opcji –dns są używane przez wbudowany serwer DNS do przekazywania zapytań DNS gdy wbudowany serwer DNS nie jest w stanie przetworzyć żądania rozpoznania nazw poszczególnych kontenerów (te adresy IP zarządzane są przez wbudowany serwer DNS i nie będą aktualizowane w pliku /etc/resolv.conf kontenera.)
  • –dns-search=DOMAIN… – ta opcja jest zarządzana przez serwer DNS i nie dokona ona aktualizacji pliku /etc/resolv.conf kontenera (przykład – gdy proces kontenerowy próbuje uzyskać dostęp do hosta i gdy domena wyszukiwania example.com jest ustawiona. W danej instancji logika DNS nie tylko szuka hosta, ale także „host.example.com”).
  • –dns-opt=OPTION… – ustawia opcje używane przez resolvery DNS. Opcjami tymi zarządza wbudowany serwer DNS i nie zostaną zaktualizowane w pliku /etc/resolv.conf kontenera.

Zasada działania DNS dla Docker

W przypadku opcji:

  • –dns=[IP_ADDRESS…]
  • –dns-search=DOMAIN…
  • –dns-opt=OPTION…

Docker używa pliku /etc/resolv.conf, należącego do maszyny-hosta (maszyny, w której zostaje wywołany demon Dokera). W ten sposób demon odfiltrowuje wszystkie wpisy serwera nazw IP hosta lokalnego z oryginalnego pliku hosta.

Filtrowanie jest konieczne, ponieważ wszystkie adresy localhost są nieosiągalne z sieci kontenera. Po odfiltrowaniu, gdy w pliku /etc/resolv.conf kontenera nie ma już wpisów serwera nazw, to demon dodaje publiczne serwery nazw Google DNS (8.8.8.8 i 8.8.4.4) do konfiguracji DNS kontenera. Jeśli w demonie włączono IPv6, to zostaną również dodane publiczne serwery nazw Google DNS IPv6. W przypadku dostępu do resolvera localhosta, konieczna jest modyfikacja usługi DNS na hoście żeby nasłuchiwał adresu hosta nielokalnego, który jest dostępny z poziomu kontenera.

Docker Compose – przykład wykorzystania DNS

W przypadku Docker Compose konfigurowana jest jedna sieć dla aplikacji. Każdy kontener dla usługi dołącza do domyślnej sieci i jest dostępny zarówno dla innych kontenerów w tej sieci oraz inne kontenery mogą go odnaleźć pod nazwą hosta identyczną do nazwy kontenera. Sieć aplikacji otrzymuje nazwę opartą na nazwie projektu (która wzoruje się na nazwie katalogu w którym projekt jest zawarty). Nazwę projektu można podmienić przy użyciu flagi:

-project-name 

lub używając zmienną środowiskową COMPOSE_PROJECT_NAME.

Przy założeniu, że aplikacja znajduje się w katalogu SpringApp plik docker-compose.yml zawiera treść:

version: "3"
services:
  web:
    build: .
    ports:
      - "8000:8000"
  db:
    image: postgres
    ports:
    - "8001:5432"

Można wywnioskować, że po wykonaniu polecenia docker-compose up wykonają się następujące czynności:

  1. Zostanie utworzona sieć o nazwie SpringApp_default
  2. Kontener zostanie utworzony przy użyciu konfiguracji paramentu „web”. Dołącza on do sieci SpringApp_default pod nazwą „web”.
  3. Kontener zostanie utworzony przy użyciu konfiguracji paramentu „db”. Dołącza on do sieci SpringApp_default pod nazwą „db”.

Każdy kontener może teraz wyszukać „web” bądź „db” i otrzymać adres IP odpowiedniego kontenera. Na przykład kod aplikacji „web” może połączyć się z adresem URL postgres://db:5432 i rozpocząć korzystanie z bazy danych Postgres.

Różnice pomiędzy HOST A CONTAINER PORT

Należy zauważyć różnicę między HOST_PORT a CONTAINER_PORT. W naszym przykładzie dla „db” HOST_PORT ma wartość 8001, a port kontenera – 5432 (jest to port domyślny dla Postgresa). Sieciowa komunikacja między usługami korzysta z CONTAINER_PORT. Po zdefiniowaniu HOST_PORT usługa jest dostępna również poza rojem (swarm’em).

Można też skorzystać z linków (łącz) – pozwalają one zdefiniować dodatkowe aliasy, za pomocą których usługa jest osiągalna z innej usługi. Nie są wymagane do umożliwienia komunikacji między serwisami (w przykładzie services) – domyślnie każda usługa może dotrzeć do dowolnego innego serwisu o nazwie tej usługi.

Można również zmienić ustawienia domyślnej sieci dla całej aplikacji zamiast (bądź też) określania własnych sieci, definiując wpis w networks o nazwie default:

version: "3" 
services: 
	web:     
	build: .     
	ports:      
		- "8000:8000"
	db:     
		image: postgres 
networks: 
default: 
# Use a custom driver driver: custom-driver-1 

Napisane przez Przemysław Bykowski

Aktywny programista i energiczny trener. Specjalizuje się w Spring Boot i uczę go w ramach AkademiaSpring.pl. Po godzinach udzielam się na YouTubach. Więcej o mnie.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Ładowanie…

Spring Boot i Google App Engine

Uruchomienie aplikacji Spring Boot w chmurze w 4 krokach

programowanie reaktywne

Programowanie Reaktywne – czym jest i kiedy stosować?