Open Container Initiative (OCI) – standard dla obrazów i kontenerów

Docker (jako firma) w 2015 roku dołączył do OCI (Open Container Initative), tym samym znacznie otwierając się na współpracę z innymi firmami w rozwoju konteneryzacji. Był to jeden z przełomowych momentów (również dla nas – użytkowników) i spora zmiana polityki firmy.

Powiem tylko tyle, albo aż tyle:

Ten wpis powinien przeczytać każdy, kto myśli na poważnie o stosowaniu konteneryzacji.

Gwarantuję – nie pożałujesz. Przejdźmy więc do sedna – czego się dowiesz?

Czego się dowiesz

• Czym jest organizacja Open Container Initiative i dlaczego powstało
• Jakie standardy wprowadza OCI
• Co z pozostałymi narzędziami takimi jak Kubernetes, Podman?
• Jak obrazy dockerowe mogą działać w Kubernetes?
• Czy obraz zbudowany w wersji Dockera 17.03 będzie działać na wersji 19.03?

Open Container Initiative (OCI) – co to jest?

Jeśli pracowałeś w większej firmie, to pewnie możesz kojarzyć coś takiego jak ISO. Jest to organizacja zajmująca się „standardyzacją” – przykład: bezpieczeństwo (bhp), zarządzanie jakością (ISO 9001).

Open Container Initiative również możemy określić jako organizację zajmującą się standaryzacją. Zadaniem OCI jest – jak łatwo się domyślić – utrzymanie standardów konteneryzacji.

Organizacja została założona w 2015 roku przez firmy Docker oraz CoreOS (twórcy świetnych narzędzi takich jak Prometheus, Clair czy Quay.io). Z czasem do projektu dołączały inni giganci z doliny krzemowej, min. Google, Amazon, Redhat, czy Microsoft (i wiele wiele innych).

Jakie standardy wyznacza OCI

OCI skupia się na dwóch ważnych sprawach:

• specyfikacja obrazów (image-spec)
• standard środowisk uruchamiania kontenerów (runtime-spec)

Zarówno OCI Image Format jak i OCI Runtime odbiły się sporym echem i miały znaczny wpływ na dalszy rozwój konteneryzacji. W kolejnym akapicie dowiesz się, co dzięki temu my – użytkownicy na tym zyskujemy.

OCI Image Format – czyli specyfikacja obrazów

Skoro tu jesteś, to wiesz czym jest Docker (a jeśli nie wiesz – jest genialnym narzędziem).

Teraz może Cię trochę zaskoczę, ale jak to zwykle w świecie bywa – Docker nie ma już monopolu i doczekał się konkurencji. Nie mam jednak zamiaru dzisiaj o tym mówić, na przykład – jaka jest przyszłość Dockera, albo czy konkurencja go wyprzedzi. To nie jest temat na dziś, ale możesz być spokojny – warto inwestować czas w Dockera. Mówię to naprawdę z czystym sumieniem („a co miałbyś powiedzieć” – pewnie pomyślałeś – „skoro promujesz się jako ekspert dockerowy”).

Jeśli moje słowa Cię nie przekonują, zerknij na Stack Overlow Survey 2020.

TLDR; Docker zajął drugie miejsce w kategorii Most Loved Platforms. Wyprzedził min. Kubernetes oraz chmurę AWS.

OK — pora wrócić do tematu.

Skupmy się na specyfikacji obrazów (OCI Image Format).

Łatwo zauważyć, że przed erą OCI mieliśmy dysproporcję pomiędzy standardem obrazów dla Docker i RKT (pierwsza konkurencja dla Dockera?).

Oznaczało to, że obraz zbudowany za pomocą Dockera oraz obraz zbudowany przez RKT – to były dwie podobne, ale jednak inne rzeczy. Ba, nawet sam docker image V1 nie był kompatybilny z docker image v2.2 – tym samym nie było to zgodne z różnymi wersjami Docker Registry.

OCI Image Format wprowadził pełną kompatybilność pomiędzy Dockerem a RKT (na początku) jeśli chodzi o strukturę obrazów, a z czasem dołączyły do tego nowo-powstałe narzędzia – na przykład Podman czy Buildah.

Poniższe polecenie to potwierdzają.

Pobieranie obrazu

$ docker pull dnaprawa/hello-world
$ podman pull dnaprawa/hello-world
$ buildah pull dnaprawa/hello-world

Wypchnięcie obrazu do repozytorium

$ docker push dnaprawa/hello-world
$ podman push dnaprawa/hello-world

A teraz mała uwaga.

OCI Image Format to nie tylko to, co widzisz powyżej – czyli podobieństwo poleceń docker pull image i podman pull image.

To przede wszystkim wspólny standard struktury obrazu (od strony technicznej). Mam nadzieję, że jest już to zrozumiałe. Lećmy dalej. Czas na OCI Runtime.

OCI Runtime – czyli standard uruchamiania kontenerów

OCI Image Format był przełomowy, ale bez standaryzacji runtime’u byłby znacznie mniej użyteczny.

Nadszedł rok 2017 i celebracja powstania pierwszej wersji Open Container Initivative Specification 1.0.

Dzięki temu firmy takie, jak Docker, CoreOs, czy RedHat mogły rozwijać autorskie narzędzia, ale już nie po swojemu, ale według odgórnie ustalonego STANDARDU. My jako użytkownicy zyskaliśmy na tym wiele. Zyskaliśmy pełną dowolność jeśli chodzi o wybór narzędzi do pracy z kontenerami jak również kompatybilność przy wdrażaniu na produkcję.

• Po pierwsze: do budowania obrazów (Docker)
• Po drugie: wybierania środowiska uruchomieniowego.

Jak już wcześniej wspominałem, Docker nie jest już jedyną opcją jeśli chodzi o runtime kontenerów. Sama roadmapa na rok 2020 to potwierdza. Docker obecnie skupia się na rozwiązaniach dla programistów – czyli zapewnienie jak najlepszego ekosystemu do codziennej pracy z kontenerami lokalnie, jak również tworzenia i dystrybucji obrazów.

Kilka alternatyw dla Dockera:

• CRI-O (stworzony z myślą o Kubernetes)
• ContainerD (stworzony przez Dockera i udostępniony jako open-source, wykrzystywany również przez k8s)
• Podman (chyba największa „konkurencja” dla Dockera)

To oznacza, że obrazy zgodne z OCI będą działać dla każdego runtime’u kontenerów, który będzie zgodny OCI runtime.

Obraz zgodny z formatem OCI

Obraz zbudowany przy pomocy Dockera jest artefaktem – zgodnym z formatem OCI. Dzięki temu nie jesteśmy całkowicie uzależnieni od ekosystemu Dockera. Naszym wyborem wcale nie musi być Docker Hub jeśli chodzi o repozytorium obrazów.

Nie muszę też przypominać, że obecnie na rynku można dowolnie przebierać w prywatnych Docker Registry. Kilka najpopularniejszych to:

• Azure Container Registry (ACR)
• Elastic Container Registry (ECR)
• Google Container Registry (GCR)
• Gitlab Container Registry
• Canister.io

Można by wymieniać prawie bez końca. Nowe rejestry obrazów powstają jak grzyby po deszczu. Co to oznacza?

Zwyczajnie jest na to zapotrzebowanie na rynku. Coraz więcej firm decyduje się na migrację do kontenerów i potrzebuje gdzieś te komercyjne obrazy przechowywać.

Czy obraz zbudowany na wersji Dockera 17.03 będzie działać na nowszej wersji?

Załóżmy, że zaadaptowaliśmy Dockera i kontenery jakiś czas temu, gdy najnowszą wersją Dockera była 17.03. Aplikacja działała przez te wszystkie lata stabilnie, ale chcemy się zmigrować do najnowszej wersji Dockera, albo przejść na Kubernetes. Może pojawić się pytanie:

Czy to będzie działać?

Zacznijmy od tego co się zmieniło w Dockerze na przestrzeni lat. W starszych wersjach, obraz po pobraniu (docker image pull) był inaczej reprezentowany na dysku. Za tę kwestię odpowiedzialny jest storage driver.

Jeżeli jesteś zainteresowany szczegółami działania najnowszego i zarazem rekomendowanego storage drivera – overlay2 – to zajrzyj TUTAJ. W tym filmie dość szczegółowo omawiam jego działanie. Jeżeli z kolei jesteś już na pokładzie mojego programu Docker Maestro, to również znajdziesz tam lekcję o tej tematyce (Moduł: Docker Advanced, lekcja „Przechowywanie warstw obrazu na dysku”)

Może pojawić się pytanie?

Generalnie będzie działać (bo obraz zbudowany na wersji Docker 17.03 jest już zgodny z OCI Image Format), ale mogą być drobne różnicę w działaniu „pod spodem” (głównie w/w storage driver). Więcej na ten temat znajdziesz w „breaking changes”: https://docs.docker.com/engine/breaking_changes/

Docker – kluczowe zmiany

Jak widać dotyczą one Dockera w wersji 1.10. Warto zwrócić uwagę na to zdanie: 

Every Engine release strives to be backward compatible with its predecessors, and interface stability is always a priority at Docker

Tutaj też lista wszystkich starszych realease’ów oraz lista wprowadzonych zmian względem poprzedniej wersji: https://docs.docker.com/engine/release-notes/17.03/

Co dalej?

Mam nadzieję, że ten post pomógł Ci zrozumieć czym jest OCI oraz rozwiał Twoje wątpliwości w kwestii kompatybilności obrazów, a różnymi wersjami Dockera oraz pozostałymi narzędziami takimi jak Kubernetes czy Podman.

Jeżeli masz jakieś dodatkowe pytania – śmiało pisz w komentarzu.

Będę również niezmiernie wdzięczny ??, jeśli podzielisz się tym postem z kolegą albo w Social Media. Możesz również zapisać się do newslettera poniżej i być na bieżąco z kolejnymi wpisami.

Dzięki i do usłyszenia wkrótce!
– Damian