DevOps

Gdzie kończą zmienne środowiskowe kontenera Uruchamiasz kontener poleceniem -e DB_PASSWORD=hunter2 i sprawdzasz go docker inspect: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Hasło leży tam jawnym tekstem, czytelne dla każdego z dostępem do socketa Docker, dla docker exec api env i dla każdego procesu działającego w kontenerze. To nie jest błąd — dokładnie do tego służą zmienne środowiskowe. Problem pojawia się, gdy używasz ich do wartości, które nigdy nie powinny być aż tak widoczne. ...

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ś. ...

Dlaczego dwa kontenery na tym samym hoście domyślnie się nie widzą Uruchamiasz Postgresa i swoje API zwykłym docker run, a API nie potrafi połączyć się z bazą danych, mimo że oba kontenery działają na tej samej maszynie. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Oba trafiają na domyślną sieć bridge, do której Docker podłącza każdy kontener Docker, jeśli nie skonfigurujesz tego inaczej. Dostają adresy IP, ale nie dostają sposobu na odnalezienie się po nazwie — API musiałoby mieć na sztywno wpisany wewnętrzny adres IP bazy danych, który zmienia się przy każdym restarcie kontenera. ...

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. ...

Co właściwie robi Docker Docker to platforma open source, która pakuje aplikację razem ze wszystkim, czego potrzebuje do działania — kodem, bibliotekami, runtime’em, konfiguracją — w kontener zachowujący się tak samo na każdej maszynie. Przeprowadzka dobrze pokazuje ten kompromis. Masz dwie opcje: Przenosić wszystkie rzeczy luzem, mając nadzieję, że dotrą nienaruszone Zapakować wszystko w uporządkowane, opisane kartony, które łatwo przewieźć Docker robi dokładnie to z aplikacjami: “pakuje” je w kontenery, które zawierają wszystko, co potrzebne do działania. ...

Co robi Kubernetes Jeden kontener Docker na jednej maszynie uruchomisz ręcznie bez problemu. Pięćdziesiąt kontenerów na dziesięciu maszynach — restartowanie ich po awarii, przenoszenie, gdy maszyna padnie, rozdzielanie między nie ruchu, aktualizowanie bez przestoju — to już inna sprawa. Kubernetes (w skrócie K8s) to system, który robi to zarządzanie za ciebie. Czym jest Kubernetes? Kubernetes to platforma open source do orkiestracji kontenerów. Została stworzona przez Google w 2014 roku, bazując na 15 latach doświadczenia w zarządzaniu kontenerami na dużą skalę, i jest teraz utrzymywana przez Cloud Native Computing Foundation (CNCF). ...

Dlaczego kontener traci dane po restarcie Zapisz wiersz do bazy danych działającej w kontenerze Docker, zatrzymaj kontener, uruchom go ponownie: wiersza nie ma. Każdy kontener przy każdym starcie dostaje swój system plików na nowo z obrazu. Wszystko, co kontener sam zapisze — pliki bazy danych, przesłane pliki, logi — trafia do warstwy zapisywalnej, która jest kasowana przy usunięciu kontenera. Wolumin Docker to sposób na trzymanie tych danych poza kontenerem, tam gdzie przetrwają. ...

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. ...