Zrozumieć Docker-a

Zrozumieć Docker-a3 min read

W niedzielne popołudnie siedziałem oglądając jakiś serial na telewizorze rownocześnie pisząc posta na temat tworzenia Mikroserwisów za pomocą takich narzędzi jak Docker i Node.js. Będąc blisko ukończenia spostrzegłem, że nie publikowałem nic o tym czym jest Docker… ba, nawet o samej wirtualizacji nie wspomniałem słowem… Shame on me

Zanim wykorzystasz narzędzie, musisz poznać jaki problem ma ono za zadanie rozwiązać.

Jako świeżo upieczony dotnet-owiec, jakiś czas temu, obejrzałem prezentację “8 Lines of Code“.  Wygłosił ją przez Greg Young podczas QCon London 2013. Polecam ją każdemu adeptowi sztuki programowania, nieżalenie od języka czy “skill”-a. Podczas swojego wystąpienia Greg poruszył bardzo ważny temat: odpowiedzialności za wszystkie zależności, które ładujemy do projektu. Cokolwiek nie załadujemy do naszego systemu to na nas spada obowiązek zapewnienia stabilności rozwiązania na produkcji.

Po kilku minutach refleksji nad swoim postem o Node.js i Docker-ze postanowiłem nieco przybliżyć Wam samą idę wirutalizacji, jak i pokrótce omówić wady i zalety rozwiązań technologicznych z nią zwiazanych.

Najpierw był serwer

Wszystko zaczęło się od architektury, gdzie jedna fizyczna maszyna była przyporządkowana pojedynczej aplikacji.

Niestety wraz z rozwojem aplikacji internetowych zaczęły pojawiać się problemy związane z taką wersją architektury,  jak np.:

  • Spore koszty utrzymania
  • Powolny deploy aplikacji
  • Ciężka migracja

Problemy tego typu zmusiły inżynierów do szukania rozwiązań optymalnych dla bardziej skomplikowanych aplikacji.

Wirtualne maszyny są całkiem fajne

W ten oto sposób pojawiła się architektura oparta na Hipernadzorcy(en. Hypervisor), narzędziu niezbędnemu do prowadzenia procesu wirtualizacji.

Możemy wydzielić dwa typy hipernadzorców:

  • Natywny (Bare metal) – Operujący czysto na sprzęcie, mający nad nim pełną kontrolę i monitorujący uruchomione systemy operacyjne. Działają na wyższych poziomach niż hipernadzorca.
  • Hostowany – Działa jak program uruchomiony na danym systemie operacyjnym (hoście). Są to rodzaje emulatorów. Zwirtualizowane systemy działają dwa poziomy ponad sprzętem.

Podstawowymi plusami tego rozwiązania są:

  • Mniejsze koszty
  • Łatwiejsza skalowalność

Jednak i te rozwiązanie nie obeszło się bez problemów z:

  • Duplikacja zasobów kerneli
  • Portowaniem aplikacji

Kontenery wychodzą przed szereg

Po Hipernadzorcy przyszła kolej na obecne cudowne dziecko… Kontenery!

Główne powody popularności metody:

  • Rozmiar – bez potrzeby przechowywania kerneli, kontenery straciły bardzo dużo zbędnych danych.
  • Izolacja środowiska – ułatwia to działanie w czasach popularności mikroserwisów, gdzie  system składa się ze skończonej liczby małych aplikacji od siebie niezależnych.  Jest to ważne, gdy aplikacje są napisane z wykorzystaniem różnych technologii. Dzięki kontenerom możemy to osiągnąć w dość prosty sposób. Wystarczy “pozamykać” te małe aplikację w kontenery (przykład: kontener A będzie zawierać aplikację A napisaną w JAVA, JRE 8 a kontener B będzie zawierać aplikację B napisaną w JavaScript na Node 6.9.4).
  • Zmniejszone koszty
  • Szybka możliwość deploy-u
  • Gwarantowana portowalność aplikacji

Podsumowanie

W taki sposób przedstawia się krótka historia rozwiązań serwerowych. Mam nadzieje że miło się wam czytało tego post-a! W najbliższej przyszłości opublikuję tekst o początkach tworzenia mikroserwisu w Node.js i Docker.

By | 2017-09-08T17:01:58+00:00 Marzec 21st, 2017|Docker|4 komentarze