Red Hat OpenShift: Docker vs CRI-O - Linux Polska
Podziel się

Pierwsze wydanie platformy Red Hat OpenShift to rok 2011. Od tego czasu technologia ta wielokrotnie zmieniała swoje oblicze. Bardzo długo była pozycjonowana jako PaaS i „naturalnie” umiejscawiana na Red Hat OpenStack Platform (IaaS).

Obecnie sytuacja wygląda zupełnie inaczej: Docker i Kubernetes są głównymi filarami platformy OpenShift.

Przypomnijmy główne cechy obu projektów.

Docker

Jedna z kilku implementacji konteneryzacji na platformie GNU/Linux. Ze względy na łatwość instalacji i obsługi – najpopularniejsza w tym momencie.

Główne zalety to:

  • izolacja zasobów (procesów, pamięci RAM, sieci, oprogramowania i bibliotek programistycznych);
  • łatwe przenoszenie i uruchamianie na dowolnej maszynie linuksowej;
  • wielokrotne wykorzystywanie obrazów do tworzenia nowych obrazów;
  • łatwe współdzielenie tych samych obrazów poprzez zdalne repozytorium;
  • wersjonowanie obrazów ułatwia ich przebudowywanie i aktualizowanie;
  • szybkie uruchamianie i małe zapotrzebowanie na zasoby w porównaniu z wirtualizacją;
  • bezpieczeństwo (izolacja zasobów, SELinux, sumy kontrolne obrazów).

Mnogość dystrybucji systemów z rodziny GNU/Linux oraz różnorodne formaty dostarczania – paczkowania – aplikacji jest jednym w wielu nierozwiązanych problemów, z którymi borykają się deweloperzy dostarczający aplikacje w tych systemach operacyjnych. Ciekawym może być spojrzenie na Dockera i jego obrazy kontenerów jako sposób na dostarczanie dowolnej aplikacji na dowolny system operacyjny, który jest w stanie uruchomić dockerowy kontener.

Bardziej skomplikowane aplikacje zgodnie z architekturą mikroserwisów będziemy rozbijać na kilka niezależnych połączonych z sobą kontenerów.

Zalety te są bardzo interesujące dla środowisk deweloperskich, gdyż upraszczają, a co za tym idzie, skracają czas wytworzenia aplikacji. To deweloper decyduje, w jakich wersjach potrzebne są biblioteki programistyczne i język programowania, a utworzony obraz kontenera uwalnia go od problemu paczkowania.

Kubernetes

Sam jeden kontener z naszą nową aplikacją to trochę za mało. Aplikacje będą utylizować wiele różnych technologii, a ich praca ma być niezawodna, tak? A co począć odnośnie do takich aspektów jak: skalowalność aplikacji, automatyzacja czy wysoka dostępność?

Odpowiedzią jest oryginalnie wytworzony przez Google projekt Kubernetes.

Oto jego główne cechy:

  • łatwe zarządzanie kontenerami;
  • skalowanie horyzontalne: uruchomienie dodatkowych kontenerów i równomierne rozłożenie obciążenia;
  • persystentne wolumeny dyskowe w takich technologiach jak: nfs, glusterfs;
  • „webhooks”: automatyczne wykonywanie akcji (np.: aktualizacja kontenera jak tylko w repozytorium pojawi się nowe wersja aplikacji).

Docker a OpenShift

Niewątpliwie Red Hat OpenShift jest bardzo interesującym rozwiązaniem dla środowisk deweloperskich, gdyż skraca czas wytwarzania, aktualizowania i wdrażania nowych aplikacji. Czy pozycja Dockera jest niezagrożona? Tak na pierwszy rzut oka zagrożenia nie widać, ale czy aby na pewno?

CRI-O

Na platformie Red Hat OpenShift to Kubernetes jest odpowiedzialny za uruchamianie dockerowych kontenerów. W uproszczeniu: usługa Kubernetes „rozmawia” z usługą „Docker”, a ta uruchamia kontener.

Czy Kubernetes mógłby sam uruchamiać kontenery? Czy możemy Dockera usunąć z tego równania?

Biorąc pod uwagę, iż konteneryzacja głównie oparta jest o własności jądra linuksowego, to odpowiedź brzmi: TAK.

Red Hat postawił na projekt CRI-O (poprzednio OCID), będący implementacją kubernetesowego interfejsu CRI (Container Runtime Interface), którego celem jest uruchamianie kontenerów zgodnych z OCI (Open Container Initiative).

Warto zauważyć, że aby uruchomić kontener, potrzebny jest obraz przestrzeni dysku, tzw. obraz kontenera, a CRI-O wspiera obrazy kontenerów dockerowych, gdyż Docker wspiera inicjatywę OCI…

Głównym celem tego projektu jest uniezależnienie Kubernetesa od jakiejkolwiek konkretnej implementacji konteneryzacji, jakiegokolwiek konkretnego formatu obrazu kontenera i konkretnego sposobu dostarczenia go.

Głównymi kontrybutorami tego projektu są: Red Hat, Intel, SUSE, Hyper, IBM.

Podsumowanie

Od wersji 3.9 na platformie Red Hat OpenShift mamy wsparcie dla CRI-O (od wersji 3.7 jako „technology preview”).

Jeśli nawet w niedalekiej przyszłości to CRI-O będzie odpowiedzialne za uruchamianie wszystkich kontenerów na platformie OpenShift, to nadal będą potrzebne obrazy kontenerów, a te najłatwiej i najwygodniej wytwarzać z użyciem Dockera. Na obecną chwilę nie widać innego tak przyjaznego użytkownikowi podejścia do konteneryzacji w środowisku GNU/Linux jak Docker.

Deweloperzy, którzy jeszcze nie zdążyli zainteresować się Dockerem, powinni nadrobić zaległości, a osoby zainteresowane platformą Red Hat OpenShift zachęcamy do śledzenia dalszych losów projektu CRI-O.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

    Skontaktuj się z nami