with 2 komentarze

Kontenery. Nowy trend, czy może coś więcej?

Dużo miejsca, w wielu publikacjach poświęca się coraz częściej kontenerom. Istnieje przy tym sporo opinii o tym, że jest to technologia „przejściowa”. Nawet jeżeli rzeczywiście tak jest, to moim zdaniem warto się przyjrzeć temu rozwiązaniu. W tym artykule opowiem o kontenerach uruchamianych w chmurze publicznej. Porównam kontener z wirtualną maszyną. A na koniec pokażę między innymi jak w prosty i szybki sposób uruchomić swój pierwszy klaster kontenerów w chmurze publicznej oraz jak uruchomić swoją aplikację wewnątrz kontenera.

Kontenery to technologia przejściowa? Naprawdę?

Zacznę od przykładu wykorzystania kontenerów z perspektywy chmury publicznej i uruchamiania naszych aplikacji właśnie w takim środowisku. Każdy z trzech najbardziej popularnych dostawców chmury publicznej (mam na myśli tutaj rozwiązania: Microsoft Azure, Amazon Web Services oraz Google Cloud Platform) pozwala na uruchomienie aplikacji w kilku modelach. Rysunek poniżej przedstawia tradycyjny podział modeli dostarczania usług w chmurze obliczeniowej. Takich modeli jest obecnie o wiele więcej, ale dla uproszczenia proponuje skupić się na tych trzech podstawowych.

 

TomaszJangas.com, modele dostarczania usług w chmurze

 

Kontenery na tym rysunku moglibyśmy umiejscowić gdzieś pomiędzy usługami typu Infrastructure as a Service (IaaS), a usługami typu Platform as a Service (PaaS). A najlepiej widać to na przykładzie konkretnych usług dostępnych w chmurze jednego z dostawców:

 

TomaszJangas.com, rozwiązania w Google Cloud Platform

 

  • IaaS (Infrastructure as a Service) – tworzymy wirtualną maszynę i dopiero w niej budujemy całe środowisko dla naszej aplikacji,
  • PaaS (Platform as a Service) – skupiamy się na samej aplikacji, infrastruktura oraz środowisko uruchomieniowe jest przygotowywane dla nas automatycznie, nie musimy się martwić o systemy operacyjne, bazy danych i całą resztę middleware-u,
  • FaaS (Function as a Service) – zamiast budować całą aplikację, której podstawowym celem jest wykonanie jakiejś konkretnej funkcji, tworzymy i uruchamiamy w środowisku typu serverless tylko tę określoną funkcję.

 

Z punktu widzenia użytkownika chmury (usługobiorcy) wygodniejsze wydaje się być uruchamianie aplikacji lub nawet konkretnych pojedynczych funkcji w przygotowanym i zarządzanym przez producenta chmury (usługodawcę) środowisku. Oddajemy w ręce zaufanego partnera biznesowego obsługę infrastruktury i środowiska uruchomieniowego, a skupiamy się tylko i wyłącznie na tym co bezpośrednio generuje nasz biznes, czyli na samej aplikacji. W takim scenariuszu trudno już nawet mówić o metodyce tworzenia aplikacji opierającej się na współpracy programistów z działami eksploatacji, czyli DevOps. Tutaj za utrzymanie całego środowiska dla naszej aplikacji odpowiada nasz usługodawca (zewnętrzny partner), czyli można powiedzieć, że zaczynamy działać w oparciu o metodykę NoOps.

W takim kontekście rzeczywiście kontenery można by uznać za technologię „przejściową”. Wraz z rozwojem aplikacji, będziemy chcieli dążyć w przyszłości do budowania środowisk działających w oparciu o metodykę NoOps – przynajmniej w przypadku aplikacji działających w chmurze publicznej. Tak pomyślałby nasz usługobiorca. Nie zapominajmy jednak, że zanim będzie on mógł skorzystać z przygotowanego dla niego i zautomatyzowanego środowiska, to ktoś wcześniej musi je zaprojektować i uruchomić. I tutaj dla usługodawcy technologia kontenerów wydaje się być bardzo atrakcyjną opcją. W związku z tym moim zdaniem absolutnie nie traktowałbym rozwiązań opartych na kontenerach jako rozwiązania „przejściowe”. A poza tym…

 

Przecież moja aplikacja działa i jeszcze długo będzie działać OnPremise.

No właśnie. Pamiętajmy o tym, że bardzo duża ilość aplikacji ciągle działa w środowiskach wewnątrz przedsiębiorstwa (OnPremise). Dawno temu uruchamialiśmy te aplikacje na serwerach fizycznych. Potem przenieśliśmy je do środowisk wirtualnych, gdzie aplikacje instalowane są wewnątrz maszyny wirtualnej. I w ten sposób funkcjonuje to dzisiaj w wielu przedsiębiorstwach i organizacjach. Teraz z kolei „namawiają nas”, aby przesiąść się z wirtualnej maszyny do kontenera. Taka migracja aplikacji z wersji monolitycznej do wersji opartej o mikroserwisy jest bardzo ciekawym i wartym rozważenia tematem. I jest to zresztą pierwszy krok, do przystosowania aplikacji do pracy w chmurze obliczeniowej. Poza tym, stosując architekturę opartą o mikroserwisy:

  • łatwiejsze jest budowanie i potem zarządzanie aplikacją,
  • łatwiejsze jest wykonywanie aktualizacji określonych procesów i serwisów (zamiast całej aplikacji),
  • łatwiejsze jest zarządzanie ciągłością pracy aplikacji; jeżeli awarii ulegnie jakiś określony serwis to z dużym prawdopodobieństwem nie będzie to oznaczać awarii całej aplikacji (pozostałe serwisy będą nadal świadczyć swoje usługi).

 

I właśnie kontenery znakomicie nadają się do tego, aby "przesiąść się" z aplikacją na architekturę opartą o mikroserwisy. W przypadku uruchamiania mikroserwisów bezpośrednio w wirtualnej maszynie marnowanych jest relatywnie dużo zasobów (CPU, RAM, HDD), dlatego technologia kontenerów sprawdza się w tym przypadku zdecydowanie lepiej. Migracja aplikacji do kontenerów wcale nie oznacza jednak, że nagle wszyscy przestaną korzystać z wirtualnych maszyn. Ale o tym za chwilę. Przede wszystkim pozwól, że odpowiem na pytanie, czym różni się kontener od wirtualnej maszyny i jakie korzyści przyniesie przeniesienie aplikacji do kontenera?

 

Kontener vs wirtualna maszyna.

Przede wszystkim, kontener, mimo iż wygląda podobnie, nie jest wirtualną maszyną. Kontener i wirtualna maszyna różnią się zarówno architekturą jak i korzyściami jakie niesie każde z nich. Posłużę się tutaj analogią zapożyczoną z jednego z wykładów konferencji „Dockercon 2017”, jaka odbyła się w kwietniu tego roku w Austin, TX, USA:

  • wirtualna maszyna to jest dom, który posiada swój własny fundament, mury oraz swoje własne instalacje: wodno-kanalizacyjną, elektryczną, itp. Jeżeli chcę zbudować kolejny dom obok tego, który już posiadam, buduje dla niego jego własny fundament, mury oraz wyposażam go w oddzielne instalacje. Podobnie jest z wirtualną maszyną. Jeżeli w mojej aplikacji wykorzystuje webowy front-end i chcę ją skalować horyzontalnie i potrzebuje dodatkowego węzła w klastrze, muszę postawić kolejną wirtualną maszynę ze swoim własnym fundamentem i instalacjami. Wielkość wirtualnej maszyny i konieczność uruchamiania wewnątrz niej niezależnego systemu operacyjnego, powoduje, że startuje one relatywnie długo (kilka - kilkanaście minut). Podobnie jest w przypadku domu. Jego budowa i wykończenie trwa raczej długo.
  • kontener to jest z kolei mieszkanie w bloku, które współdzieli fundament, mury oraz wiele różnych instalacji z innymi mieszkaniami. Mieszkania są z reguły mniejsze niż domy, ale w tym samym bloku ich rozmiary mogą być bardzo różne. Wielkość kontenera oraz fakt, że współdzieli on jądro systemu operacyjnego (fundament, mury i instalacje) z innymi kontenerami oraz brak konieczności uruchamiania systemu operacyjnego podczas uruchamiania kontenera, powoduje, że startuje on znacznie szybciej niż wirtualna maszyna (kilka – kilkanaście sekund). Mimo, że kontenery współdzielą jądro systemu operacyjnego, to są odizolowane od siebie. Każdy z nich, tak jak w przypadku mieszkania ma swoje drzwi „wejściowo-wyjściowe”, przez które można wejść tylko do tego określonego kontenera (mieszkania).

 

TomaszJangas.com, kontenery vs wirtualnej maszyny

 

Kontenery mogą zostać uruchomione:

  • na serwerze fizycznym (jak powyżej) – ponieważ na przykład muszę dostarczyć bardzo dużą wydajność dla swojej aplikacji,
  • wewnątrz wirtualnej maszyny (jak poniżej) – ponieważ na przykład zależy mi na lepszym wykorzystaniu zasobów serwera, a wydajność jaką mogę dostarczyć wewnątrz wirtualnej maszyny jest dla mojej aplikacji w zupełności wystarczająca.

 

TomaszJangas.com, kontenery wewnątrz wirtualnej maszyny

 

I ze względu na lepsze wykorzystanie zasobów serwera raczej to drugie rozwiązanie jest i będzie częściej wykorzystywane w praktyce. Pamiętaj jednak, że to gdzie uruchomisz kontener ze swoją aplikacją będzie w dużej mierze zależało od wymagań tej właśnie aplikacji.

 

Obrazy, kontenery, wolumeny.

W sieci znajdziecie mnóstwo materiałów i szkoleń na temat kontenerów. Nie jest moim celem kopiowanie całej tej wiedzy tutaj. Pozwolę sobie jedynie na przytoczenie trzech najważniejszych definicji związanych z kontenerami. Może to zaowocować, gdy będziecie oglądać krótkie demo jakie nagrałem i udostępniłem na końcu tego artykułu.

Po pierwsze obraz (image). Definicje systemu operacyjnego i aplikacji przechowywane są jako obrazy. Jest to coś w rodzaju przepisu kucharskiego, według którego możemy ugotować naszą zupę pomidorową.

Po drugie kontener (container). Kontener jest uruchomioną instancją naszego obrazu. Ugotowaną zupą pomidorową. Tak samo jak z jednego przepisu możemy ugotować wiele zup pomidorowych, również z jednego obrazu możemy uruchomić wiele instancji – kontenerów, które będą działać równolegle.

Po trzecie wolumen (volume). Kontener, czyli uruchomiona instancja obrazu, podobnie jak nasza zupa pomidorowa, jest to coś bardzo ulotnego (szczególnie ta przygotowana przez babcię). Po wyłączeniu procesu, pracującego wewnątrz kontenera, kontener ten przestaje istnieć. Mogę oczywiście uruchomić kolejną instancję zapisanego obrazu (przygotować nową zupę), ale będzie to zupełnie nowy kontener. To oznacza, że jeżeli zapisałbym jakieś dane wewnątrz kontenera, to po jego wyłączeniu, dane te przestaną istnieć. Dlatego korzystam z wolumenów. Dane przechowywane są na przykład w katalogu na zewnątrz kontenera. Katalog ten jest podmapowany wewnątrz kontenera jako wolumen. Zmiany wykonywane w katalogu (na zewnątrz) oraz w wolumenie (wewnątrz) są automatycznie synchronizowane. Po wyłączeniu kontenera dane nie są usuwane. Zupa zjedzona, ale talerz można wykorzystać ponownie, aby zjeść dokładkę.

 

Bezpieczeństwo, bezpieczeństwo i jeszcze raz bezpieczeństwo.

W organizacjach, w których ze względów bezpieczeństwa wymagane jest dla określonych aplikacji zapewnienie ich separacji na poziomie jądra systemu, lepszym rozwiązaniem będą wirtualne maszyny. Aczkolwiek już dzisiaj w świecie kontenerów pojawiają się możliwości izolacji na poziomie hyperwizora, więc ten argument przeciwko wykorzystaniu kontenerów ze względów separacji aplikacji i ich bezpieczeństwa powoli przestaje mieć znaczenie (na przykład izolacja w hyperwizorze Hyper-V dla linuxowych kontenerów).

Okazuje się jednak, że w przypadku kontenerów bezpieczeństwo nie sprowadza się jedynie do izolacji aplikacji działających wewnątrz. Warto wziąć pod uwagę tutaj również takie czynniki jak:

  • jakie jest pochodzenie obrazów kontenerów, z których korzystam?
  • czy obrazy te są aktualne?
  • jak dbam o dane wrażliwe?
  • czy kanały komunikacji są bezpieczne?
  • kto ma dostęp do zasobów?

 

Są to jednak w większości przypadków dokładnie te same pytania, które zadajemy sobie podczas budowania środowiska opartego o wirtualne maszyny.

 

Podsumujmy.

Kontener wprowadza wirtualizację na poziomie systemu operacyjnego i pozwala na oddzielenie systemu operacyjnego od kodu aplikacji oraz tym samym eliminuje różnego rodzaju zależności pomiędzy systemem operacyjnym i aplikacją. Dzięki temu możemy zapewnić dokładnie takie samo środowisko uruchomieniowe i zagwarantować spójność aplikacji oraz jej łatwe przenoszenie pomiędzy środowiskami developerskim, testowym, akceptacyjnym i produkcyjnym. Dodatkowym atutem kontenera jest szybkość jego uruchomienia. Zyskujemy przez to większą efektywność i wydajność pracy klastra, w którym nasza aplikacja jest rozproszona horyzontalnie na wielu węzłach i gdy zależy nam na tym, aby skalowała się ona automatycznie w zależności od bieżącego obciążenia (poprzez włączanie i wyłączanie mikroserwisów działających w kontenerach).

 

I na koniec, zapraszam Cię do obejrzenia 28 minutowego video pokazu, podczas którego:

  • zainstaluję Dockera wewnątrz wirtualnej maszyny i porównam czas uruchamiania wirtualnej maszyny z czasem uruchamiania kontenera,
  • pokażę, jak uruchamiać aplikacje wewnątrz kontenera (m.in. WordPress oraz serwer www nginx)  oraz skąd można pobierać obrazy systemów i aplikacji,
  • uruchomię klaster Kubernetes Engine w chmurze Google Cloud Platform.

 

2 Responses

  1. Angelika
    | Odpowiedz

    Świetny artykuł 😉

    • Tomasz Jangas
      | Odpowiedz

      Dziękuję 🙂

Dodaj komentarz

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