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.