@NrmvY - używanie kontenerów a także ich budowanie jest banalne - i to staram się unaoocznić i zachęcić ludzi do ich spróbowania jeśli tego jeszcze nie zrobili.

Oczywiście jak ktoś chce zrozumieć jakie technologie umożliwiają kontenery to tu już zaczynają się lekkie schody bo trzeba zrozumieć funkcjonalności wbudowane w kernel Linuksa - przykład tutaj gdzie wyjaśniam OverlayFS, którego artykuły nie porusza, ale bez niego nie byłoby kontenerów w obecnej formie.

@koszotorobur miałem pewne schody bo budowałem obraz na windowsie a deploy na NASie z arm64 ale z GPT4 udało się rozwiązać to w kilka minut.

@NrmvY

Oficjalne obrazy kontenerów Pythona nie są multi-arch - zobacz zrzut ekranu, który dołączyłem, który pokazuje, że każdy obraz wspiera tylko jedną architekturę.

Oczywiście da się znaleźć takie obrazy kontenerów Pythona, które zbudowane są tak by wspierać różne architektury - na przykład: https://github.com/multi-py .

Narzędzie buldix to ciekawe rozwiązanie tego problemu - dzięki, że się nim podzieliłeś!

Dodatkowo widzę, że podman (którego można zainstalować na Windowsie) też pozwala budować obrazy kontenerów pod różne architektury: https://docs.podman.io/en/latest/markdown/podman-build.1.html#arch-arch

@lactozzi - ja go tyko znalazłem, oceniłem czy merytorycznie jest poprawny i zrobiłem wpis - podziękuj autorowi

@zboinek - Podoba mi się Twoje krytyczne myślenie kolego!

Wydaje mi się, że autor artykułu mógł starać się uprościć czym jest obraz kontenera i kontener bez poruszania tematu OverlayFS , który jest wykorzystywany przez technologie konteneryzacji takie jak Docker, gdyż temat może wydawać się zbyt skomplikowany dla początkujących.

Niemniej OverlayFS oferuje to o czym wspominasz - czyli współużytkowanie tego samego podstawowego systemu plików dla obrazów kontenera i kontenerów uruchomionych z tychże obrazów. Użycie OverlayFS prowadzi więc do tego, że każdy kontener przechowuje swoje zmiany w postaci warstw, które odnotowują jedynie różnice w systemie plików, zmniejszając tym samym zużycie miejsca na dysku.

Innymi słowy, po uruchomieniu kontenera, Docker tworzy nową warstwę dla systemu plików kontenera ponad tym co znajduje się w obrazie podstawowym. Dzięki temu kontener może mieć własny system plików, który jest odizolowany od systemu hosta i innych kontenerów bez duplikowania zawartości plików pomiędzy obrazem kontenera a kontenerem.

Dla ciekawskich - ten artykuł całkiem dobrze to wyjaśnia: https://blog.devops.dev/overlayfs-and-docker-3dca51c033c4

@koszotorobur zwracam na to uwagę bo dużo tutoriali tłumaczy to w ten sposób a potem jak zagłębimy się w temat to nagle nie wiadomo o co chodzi z tymi plikami.

@Marchew - Docker jest formą wirtualizacji OS.

W przeciwieństwie do pełnej wirtualizacji nie emuluje sprzętu i korzysta z tego samego kernela co System Operacyjny hosta - co czyni kontenery szybszymi ale też mniej odizolowanymi niż pełna wirtualizacja.

Kontenery to tak naprawdę najzwyklejsze procesy działające w swoim własnym namespace i używające własnego systemu plików - uruchomione na OSie hosta i działające dzięki ficzerom kernela dostarczanym przez OS hosta.

@Barcol - z wielu względów, nie tylko bezpieczeństwa, postanowiliśmy na niego całkowicie przejść ostatnio (bo i tak używamy RHEL, obrazów UBI, OpenShift oraz CRI-O) - i wszyscy sobie chwalą.

Generalnie teraz firma jest całkowicie vendor lacked z Red Hat

@koszotorobur ja niestety w pracy jestem zmuszony korzystać z makbuka, więc przedwcześnie osiwieje. Za to we wszystkich domowych linuxach od desktopa po serwer śmiga już podman

@GrindFaterAnona - Podman jest wspierany przez Red Hat (gdzie powstał, ale teraz jest w pełni Open Source) - my używamy RHEL i mamy OpenShift więc Podman ładnie się wpasowuje - niemniej Podman działa dobrze na jakimkolwiek Linuksie i z jakimkolwiek K8s.

@Klamra 

XD