Stronę tą wyświetlono już: 492 razy
Na jednej z wcześniejszych stron tego działu opisałem jak uruchomić kontener bez konieczności tworzenia własnego obrazu. Tak bowiem się składa (szczęśliwie lub nie), że obraz można sobie ściągnąć. Taki ściągnięty obraz można wylistować w następujący sposób:
docker images REPOSITORY TAG IMAGE ID CREATED SIZE tomsik68/xampp latest 0ce2410d4236 3 months ago 1.37GB
Równie dobrze w tym samym celu można skorzystać z polecenia:
docker image ls
Usunięcie obrazu, który nie jest używany:
docker image rm <id obrazu>
Możliwe jest też usunięcie wszystkich nie używanych obrazów:
docker image prune
Istnieje też możliwość zbudowania własnego obrazu:
docker image build <ścieżka do pliku dockerfile>
Najprostszy plik dockerfile może wyglądać tak:
Mając taki plik z konsoli, której ścieżka została ustawiona na folder zawierający plik dockerfile można zbudować obraz, choć w tym przypadku nie ma to wielkiego sensu (równie dobrze można go pobrać):
docker image build ./
Wynikiem czego będzie:
docker build ./ [+] Building 329.2s (6/6) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 49B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/node:14 3.5s => [auth] library/node:pull token for registry-1.docker.io 0.0s => [1/1] FROM docker.io/library/node:14@sha256:3324c688c0e98888f8938509f35356acf69a3e1f9f385d85f7e6086b137c17e3 325.5s => => resolve docker.io/library/node:14@sha256:3324c688c0e98888f8938509f35356acf69a3e1f9f385d85f7e6086b137c17e3 0.0s =>> => sha256:d3d4e1d44a24e0c5abd41b803d14f211ba153bc7963871713cba8ee5fc687888 45.43MB / 45.43MB 93.2s => => sha256:9fec8bceb2e238bbbbec9e458cf83c1342015ed1b717be0f88b50d267c52437d 11.30MB / 11.30MB 43.9s => => sha256:3c2aa521faedb4a16c079e9574f537b51a05c2ad4fbabd16f83d9bd58c365bac 4.34MB / 4.34MB 11.6s => => sha256:3324c688c0e98888f8938509f35356acf69a3e1f9f385d85f7e6086b137c17e3 776B / 776B 0.0s => => sha256:d0c8d2556876ab299286a72fee1ff12a0ab94ed56f69e05ac1994f862f7b1ea1 7.73kB / 7.73kB 0.0s => => sha256:ffa2c3cf72357e567c89ec1d4d48c058018053e572049a76aaeb92d4a3bbd322 2.21kB / 2.21kB 0.0s => => sha256:20527d0d718ee46b5f18a310324e3d635eeb75021e2b9d9ec450ea75755ddcfa 49.77MB / 49.77MB 141.2s => => sha256:7b4ef7fa62d9393e18cbdc052a0c4215c7d3bee0182aa064cc0212d08f91ec26 214.49MB / 214.49MB 317.5s => => sha256:7d04a4e0f73cec169e5270bc286e0ae81a0abd27524a49c9848f5fe6fa4410f2 4.19kB / 4.19kB 94.2s => => extracting sha256:d3d4e1d44a24e0c5abd41b803d14f211ba153bc7963871713cba8ee5fc687888 1.4s => => sha256:a44561cf9a124c10d4e5d0b1ea5580bdddb4738aaaa67e4de33e52d9046c3a6c 35.62MB / 35.62MB 173.2s => => extracting sha256:9fec8bceb2e238bbbbec9e458cf83c1342015ed1b717be0f88b50d267c52437d 0.3s => => extracting sha256:3c2aa521faedb4a16c079e9574f537b51a05c2ad4fbabd16f83d9bd58c365bac 0.1s => => sha256:f6d2582cb79d858b793d51a4086ea286069790d17221b7f7bd76f503c0445d42 2.35MB / 2.35MB 149.0s => => extracting sha256:20527d0d718ee46b5f18a310324e3d635eeb75021e2b9d9ec450ea75755ddcfa 1.8s => => sha256:074f532f663eeeb5e2400b0d34dc594b2430a296a823884f1cfd16c17d7a4961 461B / 461B 150.0s => => extracting sha256:7b4ef7fa62d9393e18cbdc052a0c4215c7d3bee0182aa064cc0212d08f91ec26 6.2s => => extracting sha256:7d04a4e0f73cec169e5270bc286e0ae81a0abd27524a49c9848f5fe6fa4410f2 0.0s => => extracting sha256:a44561cf9a124c10d4e5d0b1ea5580bdddb4738aaaa67e4de33e52d9046c3a6c 1.2s => => extracting sha256:f6d2582cb79d858b793d51a4086ea286069790d17221b7f7bd76f503c0445d42 0.1s => => extracting sha256:074f532f663eeeb5e2400b0d34dc594b2430a296a823884f1cfd16c17d7a4961 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:9dca0ef75c71e36c674f4e0d55e366ae498c2ea5ccc0beae890fe972e0dfbd33 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
Teraz można sprawdzić, czy aby na pewno obraz istnieje:
docker images REPOSITORY TAG IMAGE ID CREATED SIZE9dca0ef75c71 2 weeks ago 946MB tomsik68/xampp latest 0ce2410d4236 3 months ago 1.37GB
I jak widać, istnieje. Można dla ułatwienia sobie życia dodać tag:
docker build --tag node ./
Co spowoduje:
docker build --tag node:14 ./ [+] Building 1.3s (5/5) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 31B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/node:14 1.3s => CACHED [1/1] FROM docker.io/library/node:14@sha256:3324c688c0e98888f8938509f35356acf69a3e1f9f385d85f7e6086b137c17e3 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:9dca0ef75c71e36c674f4e0d55e366ae498c2ea5ccc0beae890fe972e0dfbd33 0.0s => => naming to docker.io/library/node:14 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
Wystarczy teraz wyświetlić listę:
ocker images REPOSITORY TAG IMAGE ID CREATED SIZE node latest 9dca0ef75c71 2 weeks ago 946MB tomsik68/xampp latest 0ce2410d4236 3 months ago 1.37GB
Jak widać ropository się zminiło ale tag ani trochę. Okazuje się, że aby tag< został ustawiony trzeba użyć polecenia:
docker build --tag node:14 ./
co z kolei spowoduje, że na liście:
docker images REPOSITORY TAG IMAGE ID CREATED SIZE node 14 9dca0ef75c71 2 weeks ago 946MB tomsik68/xampp latest 0ce2410d4236 3 months ago 1.37GB
w końcu znajdzie się poszukiwany tag.
Warto też zauważyć, że każde kolejne wywołanie budowania tego samego obrazu nie wznawia pobierania. Innymi słowy Docker jest na tyle sprytny, że przebudowuje tylko to co jest konieczne do przebudowania. A pobieranie obrazu nie jest konieczne.