Jaka jest różnica między obrazami Dockera a kontenerami?

Question

Accepted Answer

Obraz Dockera (**image**) to szablon **tylko do odczytu** (spakowana aplikacja z jej zależnościami); **kontener** to **uruchomiona instancja** obrazu. Relacja jest jak klasa i obiekt: jeden obraz może utworzyć wiele kontenerów. ## Obraz vs kontener ```text IMAGE → a read-only TEMPLATE: the app + dependencies + config, built in layers (like a blueprint/class; stored, shared, versioned) CONTAINER → a RUNNING INSTANCE of an image (with a writable layer on top) (like an object created from a class; has runtime state) One IMAGE → many CONTAINERS (run the same image multiple times) ``` ## Praca z obrazami ```bash docker build -t myapp:1.0 . # BUILD an image from a Dockerfile docker images # list local images docker pull nginx # download an image from a registry docker push myapp:1.0 # upload an image to a registry docker rmi myapp:1.0 # remove an image ``` Obrazy są budowane (z Dockerfile), przechowywane lokalnie lub w rejestrach, wersjonowane za pomocą tagów (`myapp:1.0`) i udostępniane. ## Praca z kontenerami ```bash docker run -d -p 80:80 nginx # RUN a container from an image (-d = background) docker ps # list RUNNING containers docker ps -a # list all (including stopped) docker stop # stop a container docker start # start a stopped container docker rm # remove a container docker logs # view a container's logs docker exec -it bash # run a command inside a running container ``` Kontajnery są tworzone z obrazów, mają cykl życia (run, stop, start, remove) i można sprawdzić ich logi lub wykonać polecenia wewnątrz nich. ## Relacja warstwowa ```text → Images are built in LAYERS (each Dockerfile instruction adds a layer, cached/shared) → A container = the image's read-only layers + a thin WRITABLE layer on top → Changes in a running container go to its writable layer (lost when removed, unless persisted via volumes) — the underlying image is unchanged ``` ## Dlaczego to ważne Rozumienie rozróżnienia między obrazami a kontenerami jest fundamentalne dla pracy z Dockerem, dlatego jest to niezbędna, obowiązkowa wiedza. Relacja — **obraz** to szablon **tylko do odczytu** (spakowana aplikacja z zależnościami, jak plan techniczny lub klasa) natomiast **kontener** to **uruchomiona instancja** tego obrazu (jak obiekt utworzony z klasy, ze stanem w czasie wykonywania) — jest rdzeniem konceptualnego modelu Dockera, a mylenie tych dwóch pojęć prowadzi do zamieszania w rozumieniu, jak Docker działa. Rozumienie, że **jeden obraz może utworzyć wiele kontenerów** (uruchomienie tego samego obrazu wiele razy) jest kluczowe dla tego, jak Docker umożliwia skalowanie i spójność. Znajomość praktycznych operacji — budowania, wyświetlania, pobierania, przesyłania i wersjonowania **obrazów** (z tagami takimi jak `myapp:1.0`) oraz uruchamiania, zatrzymywania, sprawdzania (logów) i wykonywania poleceń wewnątrz **kontenerów** (zarządzania ich cyklem życia) — to codzienna praktyczna wiedza dotycząca korzystania z Dockera. Rozumienie **relacji warstwowej** (obrazy budowane w buforowanych, udostępnianych warstwach; kontener będący warstwami tylko do odczytu obrazu plus cienka warstwa zapisywalna, gdzie zmiany w czasie wykonywania trafiają, tracone podczas usuwania chyba że zachowywane poprzez woluminy) wyjaśnia zarówno wydajność Dockera (udostępnianie/buforowanie warstw) jak i ważną pułapkę (zmiany w kontenerze są ulotne bez woluminów). Ponieważ rozróżnienie obraz/kontener jest fundamentalnym modelem mentalnym dla Dockera, a ponieważ jego zrozumienie (oraz związanych z nim operacji i struktury warstwowej) jest niezbędne do poprawnego budowania, uruchamiania i zarządzania obciążeniami Dockera, zrozumienie różnicy między obrazami a kontenerami jest niezbędną, fundamentalną wiedzą Docker — rdzeniem koncepcji, na której opiera się wszystko inne w Dockerze, i rozróżnieniem, które każdy użytkownik Dockera musi wyraźnie zrozumieć.