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
  • Jacek Kosiński

    byc moze lamerskie pytanie, ale nie daje mi spokoju. Probuje znależć zastosowanie dla dockera i nie do końca mi sie wszystko rozjaśniło:
    na maszynie wirtualnej aplikacja korzystala z zasobów systemu operacyjnego GuestOS (z diagramu 2). A z jakiego systemu korzysta kontener dockerowy ? Hosta ?

    • Cześć 🙂
      Zawsze mi powtarzano że nie ma głupich / lamerskich pytań 🙂
      Sam Docker jest uruchomiony na systemie operacyjnym Host-a, jednak ten silnik, który na diagramie podpisałem jako “Container Engine” daje warstwę abstrakcji pomiędzy systemem a aplikacją uruchomioną w obrazie docker-a.
      Dlatego docker jest lżejszy od serwerów wirtualnych 🙂
      Z takich ciekawostek to samego docker-a można bardziej przyrównać do procesu niż wirtualki. Nawet jeśli odpalisz w obrazie np. bazę mongo to będziesz mógł zobaczyć go na liście procesów hosta 🙂

      Pozdrawiam

      • Jacek Kosiński

        dzięki za rozjasnienie .. ale będe drazył dalej. mam aplikacje napisana pod windows, a dockera na np na Synology.MAC/Linux, ktory windowsa/ .net frameworka, nie ma. Czy jestem w stanie ta aplikację “skonteneryzować” i uruchamiac pod dockerem ?