Container

Uruchom kubectl run nginx --image=nginx:1.27, a Kubernetes utworzy dokładnie jeden Pod o nazwie nginx. Usuń go poleceniem kubectl delete pod nginx i zniknie na dobre — nikt tego nie zauważy, nikt go nie zastąpi. Pod to najmniejsza jednostka wdrożeniowa w Kubernetes: jeden lub więcej kontenerów dzielących namespace sieciowy i zestaw wolumenów, zaplanowanych razem na jednym Node. Taki pojedynczy Pod to ślepy zaułek w produkcji. Jeśli kontener w nim się wywali, kubelet uruchomi go ponownie w tym samym miejscu. Jeśli Node się zrestartuje albo ktoś usunie Pod, nic go nie odtworzy. Goły Pod nie wie, że w ogóle powinien istnieć. ...

Dlaczego obraz Docker waży dziesięć razy więcej niż aplikacja Usługa Node z kilkuset kilobajtami kodu źródłowego kończy jako obraz ważący ponad 1 GB. To normalny wynik działającego builda, nie błąd w jakiejś konkretnej linii. Waga bierze się z obrazu bazowego, który dźwiga cały system operacyjny, z toolchaina do builda, którego działająca aplikacja nigdy nie wywołuje, i z cache menedżera pakietów, o którego usunięcie nikt builda nie poprosił. Płacisz za to przy każdym deployu: docker pull działa wolniej, a skaner podatności ma kilkaset dodatkowych pakietów do zgłoszenia. Miejsce na dysku też się kumuluje, na każdym tagu, jaki kiedykolwiek wypchnąłeś. Naprawienie tego oznacza przepisanie Dockerfile, nie aplikacji. ...

Ile kosztuje źle napisany Dockerfile 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Cztery linijki, a każda coś kosztuje. docker build uruchamia npm install od nowa przy każdej zmianie kodu, bo COPY . . psuje cache warstw, zanim krok instalacji w ogóle dostanie szansę na ponowne użycie. Finalny obraz niesie ze sobą całą bazę Debiana, cały katalog node_modules razem z zależnościami deweloperskimi i wszystkimi narzędziami budowania, które npm install ściągnął do kompilacji modułów natywnych. Nic nie jest odrzucane. Kontener działa jako root, bo nikt mu nie kazał inaczej, a node:latest oznacza, że obraz bazowy może się zmienić między jedną a drugą buildą, bez żadnego śladu tego, co faktycznie wypuściłeś. ...

Problem, który rozwiązuje Compose Prawdziwa aplikacja rzadko jest jednym kontenerem. Web API potrzebuje bazy danych, baza potrzebuje wolumenu, żeby jej dane przetrwały restart, a potem dochodzi jeszcze cache Redis i worker w tle. To cztery polecenia docker run, każde z własnymi flagami dla portów, wolumenów, zmiennych środowiskowych i wspólnej sieci. W odpowiedniej kolejności. Za każdym razem, gdy siadasz do pracy. Docker Compose zastępuje te polecenia jednym plikiem i jednym poleceniem. Opisujesz kontenery i to, jak się łączą, w pliku o nazwie compose.yaml, a docker compose up uruchamia je wszystkie. Jeśli obrazów i docker run jeszcze nie znasz, przeczytaj najpierw czym jest Docker i jak działają kontenery. ...

Docker i Podman uruchamiają te same obrazy tymi samymi poleceniami. Różni je architektura: Podman nie ma działającego w tle daemona i domyślnie działa bez roota (rootless), a Docker daje dojrzałe narzędzia, Docker Desktop i pełnoprawne Compose. Poniżej różnice, które realnie wpływają na twoją pracę — daemon, root, Compose i pody. Czym jest Podman? Podman (Pod Manager) to narzędzie do zarządzania kontenerami i podami, opracowane przez Red Hat jako open source’owa alternatywa dla Dockera. Jego główna cecha? Nie potrzebuje działającego daemona. ...