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



21.02.2019

Wdrażanie projektów AI

Infrastruktura OVH
21.02.2019

Certyfikacja kluczy

HEUTHES-CAK
21.02.2019

Kopie zapasowe

Veeam Availability for AWS
21.02.2019

Dysk SSD Samsung 970 EVO Plus

Dysk SSD Samsung 970 EVO Plus
21.02.2019

Szyfrowane USB

Kingston IronKey D300 Serialized
21.02.2019

Bezpieczeństwo sieci

Check Point Maestro i seria 6000
21.02.2019

Ochrona danych

Commvault IntelliSnap i ScaleProtect
21.02.2019

Ułatwienie telekonferencji

Plantronics Calisto 3200 i 5200
21.02.2019

Transformacja centrów danych

Fujitsu PRIMEFLEX for VMware vSAN

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.

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"