Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


25.10.2019

Skalowalna infrastruktura

Red Hat OpenStack Platform 15
25.10.2019

Cienki klient 2.0

Windows Virtual Desktop
25.10.2019

Nowy sprzęt Microsoftu

Rodzina Surface się powiększa
24.10.2019

Serwery ARM

Oracle stawia na Ampere Computing
24.10.2019

Wszechstronny i elegancki

Dell XPS 15
10.10.2019

CYBERSEC EXPO - największe w...

Bezpieczeństwo cyfrowe nie jest problemem dotyczącym jedynie działów IT. Obecnie stanowi...
30.09.2019

Nowości w wirtualizacji

VMware World 2019
30.09.2019

Bezpieczeństwo mobile-first

Android 10

Kontenery – broker połączeń, przechowywanie danych, aplikacje

Data publikacji: 24-01-2018 Autor: Maciej Lelusz
PRZECHOWYWANIE DANYCH W...

Niezależnie, gdzie będzie budowany klaster, warto mieć wiedzę o tym, jak podczas używania platformy Docker zachowa się sieć. Wymagania aplikacji i realia sieci to często dwa zupełnie różne światy. Często trudno jest zrealizować wymagania względem środowiska sieciowego, jakie powinno zostać dostarczone przez dział IT dla produktów budowanych przez developerów.

Platforma Docker udostępnia trzy modele konfiguracji sieci w ramach tzw. Contai­ner Network Model (CNM). Rzeczony CNM jest swoistym brokerem połączeń poprzez sterowniki sieciowe dostępne w platformie. Są to moduły dołączane do Docker Engine, Swarm lub UCP (płatny Universal Control Plane). Standardowo mamy pięć modułów: host, bridge, overlay, MACVLAN i none. Ogólną architekturę rozwiązania pokazano na rys. 1.


Mamy tutaj wspomniane sterowniki (oczywiście poza standardowymi można dołączać inne), dostarczane przez różnych producentów w formie pluginów, oraz tzw. IPAM Drivery, czyli sterowniki odpowiedzialne za zarządzanie adresacją IP. Przyjrzyjmy się głównym sterownikom sieciowym (Network Drivers), a dokładnie trzem z nich – bridge, overlay, MACVLAN – ponieważ można wykorzystać je w naprawdę dużej liczbie scenariuszy:

 

  • bridge – tworzy linuksowy bridge, na hoście, gdzie działa Docker Engine, do interfejsu kontenera, który jest na nim uruchomiony. Domyślnie kontenery w obrębie hosta mogą się ze sobą komunikować, a za pomocą sterownika bridge można komunikacją i dostępem na zewnątrz zarządzać;
  • overlay – przy użyciu tego sterownika tworzona jest sieć nakładkowa (overlay), która standardowo wspiera połączenia pomiędzy różnymi hostami z zainstalowanym Docker Engine i kontenerami działającymi na nich. Metoda ta używa do działania kombinacji Linux Bridge i VXLAN, aby obsłużyć komunikację miedzy kontenerami za pomocą fizycznej sieci;
  • MACVLAN – ustawiany tzw. MACVLAN bridge mode, pozwala na ustanowienie połączenia z interfejsem (lub subinterfejsem) hosta, na którym znajduje się Docker Engine i uruchomiony jest kontener. Pozwala to na nadanie kontenerowi adresu IP, który jest routowalny do sieci fizycznej. Dzięki sterownikowi MACVLAN możliwe jest również przekazanie VLAN do samego kontenera, co umożliwia segmentację w warstwie drugiej modelu OSI.


> DZIAŁANIE MODELI CNM. KONTROLA RUCHU

W celu lepszego zobrazowania działania modeli CNM omówmy hipotetyczny scenariusz, gdzie w kontenerze znajduje się serwer HTTP działający na porcie 8080. Chcemy go udostępnić na świat poprzez mapowanie portu 8080 z kontenera na 8080 w Docker Engine (DE). Najprostszym sposobem użycia scenariusza jest użycie CNM w modelu Bridge i zmostkowanie wewnętrznego interfejsu kontenera z interfejsem DE, a następnie zmapowanie portu z interfejsu wewnętrznego do zewnętrznego. Overlay będzie nam pomocny, gdy zechcemy np. komunikować się w dokładnie zdefiniowany sposób pomiędzy wspomnianym serwerem HTTP a bazą danych, która ma się znaleźć w innym DE na innym kontenerze.

Tworzymy interfejs przy użyciu sterownika overlay pomiędzy bazą a serwerem HTTP, a pakiety zaczynają płynąć pomiędzy hostami fizycznymi lub VM, gdzie znajdują się kontenery. MACVLAN użyjemy, gdy będziemy chcieli widzieć w naszej sieci fizycznej MAC adresy każdego z kontenerów. Ważne jest, aby wspomnieć, że używając sieci overlay, informacje (jej Control Plane) dot. zarządzania przesyłane są po tzw. sieci Gossip, która pakuje dane w otoczkę TLS, czyli poprzez szyfrowany kanał wykorzystujący mechanizm AES. Dzieje się to automatycznie i nie mamy na to wpływu. Klucz przetrzymywany jest przez węzły Manager klastra i wymieniany co 12 godzin. Ruch pomiędzy kontenerami (Data Plane) może być również szyfrowany na życzenie za pomocą jednego przełącznika, ale nie jest to domyślne zachowanie.

> PRZECHOWYWANIE DANYCH. KONTENERY I WARSTWY

Komunikacja to jedna rzecz. Istotne jest również, jak przechowujemy dane w świecie kontenerów. Kwestia storage w kontekście Dockera powiązana jest z ideą warstw. Wiemy już, że obraz kontenera jest ściągany z repozytorium znajdującego się w Rejestrze (np. Docker Hub). Dany obraz jest ściągany na dysk lokalny hosta, na którym uruchomiony jest Docker Engine – i to on właśnie jest pierwszą warstwą, która pozostaje w trybie tylko do odczytu.

[...]

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT, specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"