Где хранятся docker images windows

590053 просмотра

23 ответа

Мне удалось найти контейнеры в каталоге /var/lib/docker/containers , но я не могу найти изображения.

Под какими каталогами и файлами /var/lib/docker ?

Ответы (23)

506 плюса

Содержимое /var/lib/docker каталога различается в зависимости от драйвера, который Docker использует для хранения .

По умолчанию это будет , aufs но может упасть обратно overlay , overlay2 , btrfs , devicemapper или в zfs зависимости от вашей поддержки ядра. В большинстве мест это будет, aufs но RedHats пошел с devicemapper .

Вы можете вручную установить драйвер хранилища с помощью опции -s или —storage-driver= для демона Docker .

• /var/lib/docker/ будет содержать специфичное для драйвера хранилище для содержимого изображений.
• /var/lib/docker/graph/ теперь только содержит метаданные об изображении, в json и layersize файлах.

• /var/lib/docker/aufs/diff/ содержит содержимое файла изображений.
• /var/lib/docker/repositories-aufs файл JSON, содержащий локальную информацию об изображении Это можно посмотреть с помощью команды docker images .

В случае devicemapper :

• /var/lib/docker/devicemapper/devicemapper/data хранит изображения
• /var/lib/docker/devicemapper/devicemapper/metadata метаданные
• Обратите внимание, что эти файлы являются «разреженными» файлами с тонкой подготовкой, поэтому они не такие большие, как кажутся.

Автор: Air Размещён: 22.09.2014 04:31

253 плюса

При использовании Docker для Mac Application создается впечатление, что контейнеры хранятся в виртуальной машине, расположенной по адресу:

ОБНОВЛЕНИЕ (Предоставлено mmorin ):

По состоянию на 15 января 2019 года, кажется, есть только этот файл:

который содержит Docker Disk и все образы и контейнеры внутри него.

119 плюса

В особом случае Mac OS X или Windows, используя boot2docker, ваши образы Docker хранятся в виртуальной машине VirtualBox, управляемой boot2docker.

Эта виртуальная машина будет храниться в обычном месте образов VirtualBox:

Окна: %USERPROFILE%/VirtualBox VMs/boot2docker-vm

Вы можете сбросить его, запустив (ВНИМАНИЕ: это уничтожит все изображения, которые вы создали и загрузили до сих пор):

Это особенно полезно, если вы сохранили тонны промежуточных изображений при сборке / отладке сборки без полезных опций —rm, я приведу их здесь для справки: Использование:

Автор: Phil L. Размещён: 06.08.2014 08:54

87 плюса

На самом деле, изображения Docker хранятся в двух файлах, как показано следующей командой

Файл данных: /var/lib/docker/devicemapper/devicemapper/data

Файл метаданных: /var/lib/docker/devicemapper/devicemapper/metadata

68 плюса

Изображения хранятся в /var/lib/docker/graph/ /layer .

Обратите внимание, что изображения просто отличаются от родительского изображения. Родительский идентификатор хранится вместе с метаданными изображения /var/lib/docker/graph/ /json .

Когда вы docker run изображение. AUFS объединит все слои в одну используемую файловую систему.

Автор: creack Размещён: 07.10.2013 09:29

58 плюса

На недавно выпущенном Docker для Windows, который использует Hyper-V, данные находятся на виртуальном жестком диске Docker:

Вы также можете открыть «Диспетчер Hyper-V» для доступа к Docker / MobyLinuxVM.

Автор: Tristan Размещён: 17.07.2016 08:40

46 плюса

Для тех, кто использует панель инструментов Docker (которая использует docker-machine), ответы относительно boot2docker в Mac OS X недопустимы. Виртуальная машина Docker называется «по умолчанию» и существует в /Users/ /.docker/machine/machines/default/ каталоге.

Автор: mbbce Размещён: 17.09.2015 10:24

37 плюса

В Ubuntu вы можете «играть» с изображениями, запущенными

На самом деле, изображения хранятся в /var/lib/docker/aufs/diff

Автор: test30 Размещён: 13.05.2014 01:13

20 плюса

В Docker для Windows (собственная Windows) контейнерное хранилище по умолчанию находится по адресу:

20 плюса

Если вы используете Docker для MAC (не boot2docker ), то местоположение /Users/ UserName> /Library/Containers/com.docker.docker/Data/

6 плюса

Как ответили здесь , если вы находитесь на Mac, он находится по адресу

5 плюса

Более подробно об ответе Тристана, в Windows с Hyper-V вы можете переместить изображение с помощью следующих шагов из matthuisman:

1. Стоп докер и т. Д.
2. Введите «Диспетчер Hyper-V» в поле поиска панели задач и запустите его.
3. Выберите свой ПК в левой панели (мой называется DESKTOP-CBP **)
4. Щелкните правой кнопкой мыши на правильной виртуальной машине (моя называется MobyLinuxVM)
5. Выберите «Выключить» (если он запущен)
6. Щелкните правой кнопкой мыши еще раз и выберите «Переместить»
7. Следуйте инструкциям

3 плюса

Я использую boot2docker для Docker на Mac OSX, поэтому изображения сохраняются в /Users/ /VirtualBox VMs/boot2docker-vm/boot2docker-vm.vmdk .

3 плюса

Я могу ответить на этот вопрос только для пользователей Ubuntu:

Корневой каталог докера можно найти при запуске команды docker info

Каталог Docker будет указан в этой строке: » Docker Root Dir: /var/lib/docker «

Об образах докеров они хранятся в каталоге докеров: /var/lib/docker/aufs/diff/

Помните, что эти вещи не одинаковы во всех версиях докера. В настоящее время я использую 1.12.3.

Автор: Arif A. Размещён: 08.12.2016 03:42

3 плюса

Если вы помните, что Docker все еще работает в ВМ, системные пути относятся к ВМ, а не из системы Mac Osx. Как говорится, все содержится в файле VM:

Попробуйте запустить Alpine образ с этим параметром тома и командой ls, вы можете перечислить хост VM:

docker run —rm -it -v /: / vm-root alpine: край ls -l / vm-root

После этого просто попробуйте:

запустить docker —rm -it -v /: / vm-root alpine: край ls -l / vm-root / var / lib / docker

Теперь вы можете перечислить папку докера с хоста WM

2 плюса

В Docker для Windows журналы находятся здесь: %USERPROFILE%\AppData\Local\Docker

Автор: omasoud Размещён: 30.07.2016 08:42

2 плюса

проверьте папку докера в /var/lib

изображения хранятся в расположении ниже:

0 плюса

В Fedora Docker использует LVM для хранения, если доступно. На моей системе docker info показывает:

В этом случае, чтобы увеличить объем хранилища, вам придется использовать инструменты командной строки LVM или совместимые менеджеры разделов, такие как blivet .

0 плюса

На Debian Unstable / Sid,

docker info найти общесистемную информацию.

изображения хранятся в /var/lib/docker/image/overlay2/imagedb/content и

контейнеры хранятся в /var/lib/docker/containers

версия докера, версия 18.06.0-ce API 1.38

Автор: Dhanuka Размещён: 14.09.2018 04:55

0 плюса

Используйте docker info команду для отображения общесистемной информации, и ее местоположение может отличаться.

В зависимости от используемого драйвера хранилища может отображаться дополнительная информация, такая как имя пула, файл данных, файл метаданных, используемое пространство данных, общее пространство данных, используемое пространство метаданных и общее пространство метаданных.

В файле данных хранятся изображения, а в файле метаданных хранятся метаданные, относящиеся к этим изображениям. При первом запуске Docker выделяет определенное количество пространства данных и пространства метаданных из пространства, доступного на томе, где /var/lib/docker смонтирован.

Вот пример на Ubuntu (проверьте Root Dir ):

И вот пример на Travis CI (см. Docker Root Dir ):

Вы можете использовать —format параметр, чтобы извлечь эту информацию в один файл, например

Автор: kenorb Размещён: 13.01.2019 06:53

0 плюса

В Windows 2016 докер (DockerMsftProvider) использует папку «windowsfilter» в корневом каталоге докера.

Он использует папку «tmp» в корневом каталоге докера для загрузки файлов и удаляет файлы после извлечения загруженных файлов в папку «windowsfilter».

0 плюса

Я не смог решить вопрос с Docker версии 18.09 на macos, используя приведенные выше ответы, и попытался снова.

Единственным реальным решением для меня было использование этой docker-compose.yml конфигурации:

После запуска docker-compose up я наконец-то получил /tmp/host-volume от macos общий доступный для записи том из контейнера:

Надеюсь, что это помогает другим.

0 плюса

Окружающая среда: Windows 10 Pro, Docker Desktop 2.0.3.0 край

щелкните правой кнопкой мыши значок докера в системном трее, выберите настройки — дополнительно:

Where are docker images and containers stored when we use it with Windows?

NOTE: Am super new to both Windows and Docker

The tutorial I’ve been using says that they are under /var/lib/docker/containers if we’re using Linux, but I can’t seem to find that on my Windows machine.

5 Answers 5

Enter docker-machine with

there you should find your containers.

Things might have changed with Windows 10 Anniversary Update. I installed Docker from source here (https://master.dockerproject.org/windows/amd64/docker-1.13.0-dev.zip) as described here:

Docker puts all of the images in this folder:

and all containers in this folder:

An easy way to check is to execute this:

It should tell you where your files are stored:

After review some post on Stackoverflow and Google. I found this directory :

Here you can fin the configuration with the Virtual Machines

Another important thing is the images are virtualized by the Hyper-V, so the info should be stored here.

Update 2020 for WSL2

If you’re using this with WSL2, docker images will be maintained inside of your wsl drive available at \\wsl$\ per this github issue:

• Windows: \\wsl$\docker-desktop-data\mnt\wsl\docker-desktop-data\data\docker\volumes
• Linux: sudo ls /mnt/wsl/docker-desktop-data/data/docker/volumes

Docker installed on windows with docker toolbox(using virtual box in place of hyper-v) one VM is created on at C:\Users\YOURUSERNAME\.docker\machine\machines with name default so you can find all VM files in default folder.

you can connect this vm using

and you can find pulled images and container under this path (you may need to use sudo sometimes)

Образы и контейнеры Docker в картинках

Перевод поста Visualizing Docker Containers and Images, от новичка к новичкам, автор на простых примерах объясняет базовые сущности и процессы в использовании docker.

Если вы не знаете, что такое Docker или не понимаете, как он соотносится с виртуальными машинами или с инструментами configuration management, то этот пост может показаться немного сложным.

Пост предназначен для тех, кто пытается освоить docker cli, понять, чем отличается контейнер и образ. В частности, будет объяснена разница между просто контейнером и запущенным контейнером.

В процессе освоения нужно представить себе некоторые лежащие в основе детали, например, слои файловой системы UnionFS. В течение последней пары недель я изучал технологию, я новичок в мире docker, и командная строка docker показалась мне довольно сложной для освоения.

По-моему, понимание того, как технология работает изнутри — лучший способ быстро освоить новый инструмент и правильно его использовать. Часто новая технология разрабатывает новые модели абстракций и привносит новые термины и метафоры, которые могут быть как будто бы понятны в начале, но без четкого понимания затрудняют последующее использование инструмента.

Хорошим примером является Git. Я не мог понять Git, пока не понял его базовую модель, включая trees, blobs, commits, tags, tree-ish и прочее. Я думаю, что люди, не понимающие внутренности Git, не могут мастерски использовать этот инструмент.

Определение образа (Image)

Визуализация образа представлена ниже в двух видах. Образ можно определить как «сущность» или «общий вид» (union view) стека слоев только для чтения.

Слева мы видим стек слоев для чтения. Они показаны только для понимания внутреннего устройства, они доступны вне запущенного контейнера на хост-системе. Важно то, что они доступны только для чтения (иммутабельны), а все изменения происходят в верхнем слое стека. Каждый слой может иметь одного родителя, родитель тоже имеет родителя и т.д. Слой верхнего уровня может быть использован как UnionFS (AUFS в моем случае с docker) и представлен в виде единой read-only файловой системы, в которой отражены все слои. Мы видим эту «сущность» образа на рисунке справа.

Если вы захотите посмотреть на эти слои в первозданном виде, вы можете найти их в файловой системе на хост-машине. Они не видны напрямую из запущенного контейнера. На моей хост-машине я могу найти образы в /var/lib/docker/aufs.

Определение контейнера (Container)

Контейнер можно назвать «сущностью» стека слоев с верхним слоем для записи.

На изображении выше показано примерно то же самое, что на изображении про образ, кроме того, что верхний слой доступен для записи. Вы могли заметить, что это определение ничего не говорит о том, запущен контейнер или нет и это неспроста. Разделение контейнеров на запущенные и не запущенные устранило путаницу в моем понимании.

Контейнер определяет лишь слой для записи наверху образа (стека слоев для чтения). Он не запущен.

Определение запущенного контейнера

Запущенный контейнер — это «общий вид» контейнера для чтения-записи и его изолированного пространства процессов. Ниже изображен контейнер в своем пространстве процессов.

Изоляция файловой системы обеспечивается технологиями уровня ядра, cgroups, namespaces и другие, позволяют докеру быть такой перспективной технологией. Процессы в пространстве контейнера могут изменять, удалять или создавать файлы, которые сохраняются в верхнем слое для записи. Смотрите изображение:

Чтобы проверить это, выполните команду на хост-машине:

Вы можете найти новый файл в слое для записи на хост-машине, даже если контейнер не запущен.

Определение слоя образа (Image layer)

Наконец, мы определим слой образа. Изображение ниже представляет слой образа и дает нам понять, что слой — это не просто изменения в файловой системе.

Метаданные — дополнительная информация о слое, которая позволяет докеру сохранять информацию во время выполнения и во время сборки. Оба вида слоев (для чтения и для записи) содержат метаданные.

Кроме того, как мы уже упоминали раньше, каждый слой содержит указатель на родителя, используя id (на изображении родительские слои внизу). Если слой не указывает на родительский слой, значит он наверху стека.

Расположение метаданных

На данный момент (я понимаю, что разработчики docker могут позже сменить реализацию), метаданные слоев образов (для чтения) находятся в файле с именем «json» в папке /var/lib/docker/graph/id_слоя:

где «e809f156dc985. » — урезанный id слоя.

Свяжем все вместе

Теперь, давайте посмотрим на команды, иллюстрированные понятными картинками.

docker create

До:

После:

Команда ‘docker create’ добавляет слой для записи наверх стека слоев, найденного по . Команда не запускает контейнер.

docker start

До:

После:

Команда ‘docker start’ создает пространство процессов вокруг слоев контейнера. Может быть только одно пространство процессов на один контейнер.

docker run

До:

После:

Один из первых вопросов, который задают люди (я тоже задавал): «В чем разница между ‘docker start’ и ‘docker run’?» Одна из первоначальных целей этого поста — объяснить эту тонкость.

Как мы видим, команда ‘docker run’ находит образ, создает контейнер поверх него и запускает контейнер. Это сделано для удобства и скрывает детали двух команд.

Продолжая сравнение с освоением Git, я скажу, что ‘docker run’ очень похожа на ‘git pull’. Так же, как и ‘git pull’ (который объединяет ‘git fetch’ и ‘git merge’), команда ‘docker run’ объединяет две команды, которые могут использоваться и независимо. Это удобно, но поначалу может ввести в заблуждение.

docker ps

Команда ‘docker ps’ выводит список запущенных контейнеров на вашей хост-машине. Важно понимать, что в этот список входят только запущенные контейнеры, не запущенные контейнеры скрыты. Чтобы посмотреть список всех контейнеров, нужно использовать следующую команду.

docker ps -a

Команда ‘docker ps -a’, где ‘a’ — сокращение от ‘all’ выводит список всех контейнеров, независимо от их состояния.

docker images

Команда ‘docker images’ выводит список образов верхнего уровня (top-level images). Фактически, ничего особенного не отличает образ от слоя для чтения. Только те образы, которые имеют присоединенные контейнеры или те, что были получены с помощью pull, считаются образами верхнего уровня. Это различие нужно для удобства, так как за каждым образом верхнего уровня может быть множество слоев.

docker images -a

Команда ‘docker images -a’ выводит все образы на хост-машине. Это фактически список всех слоев для чтения в системе. Если вы хотите увидеть все слои одного образа, воспользуйтесь командой ‘docker history’.

docker stop

До:

После:

Команда ‘docker stop’ посылает сигнал SIGTERM запущенному контейнеру, что мягко останавливает все процессы в пространстве процессов контейнера. В результате мы получаем не запущенный контейнер.

docker kill

До:

После:

Команда ‘docker kill’ посылает сигнал SIGKILL, что немедленно завершает все процессы в текущем контейнере. Это почти то же самое, что нажать Ctrl+\ в терминале.

docker pause

До:

После:

В отличие от ‘docker stop’ и ‘docker kill’, которые посылают настоящие UNIX сигналы процессам контейнера, команда ‘docker pause’ используют специальную возможность cgroups для заморозки запущенного пространства процессов. Подробности можно прочитать здесь, если вкратце, отправки сигнала Ctrl+Z (SIGTSTP) не достаточно, чтобы заморозить все процессы в пространстве контейнера.

docker rm

До:

После:

Команда ‘docker rm’ удаляет слой для записи, который определяет контейнер на хост-системе. Должна быть запущена на остановленном контейнерах. Удаляет файлы.

docker rmi

До:

После:

Команда ‘docker rmi’ удаляет слой для чтения, который определяет «сущность» образа. Она удаляет образ с хост-системы, но образ все еще может быть получен из репозитория через ‘docker pull’. Вы можете использовать ‘docker rmi’ только для слоев верхнего уровня (или образов), для удаления промежуточных слоев нужно использовать ‘docker rmi -f’.

docker commit

До:
или

После:

Команда ‘docker commit’ берет верхний уровень контейнера, тот, что для записи и превращает его в слой для чтения. Это фактически превращает контейнер (вне зависимости от того, запущен ли он) в неизменяемый образ.

docker build

До:
Dockerfile и

После:

Со многими другими слоями.

Команда ‘docker build’ интересна тем, что запускает целый ряд команд:

На изображении выше мы видим, как команда build использует значение инструкции FROM из файла Dockerfile как базовый образ после чего:

1) запускает контейнер (create и start)
2) изменяет слой для записи
3) делает commit
На каждой итерации создается новый слой. При исполнении ‘docker build’ может создаваться множество слоев.

docker exec

До:

После:

Команда ‘docker exec’ применяется к запущенному контейнеру, запускает новый процесс внутри пространства процессов контейнера.

docker inspect |

До:
или

После:

Команда ‘docker inspect’ получает метаданные верхнего слоя контейнера или образа.

docker save

До:

После:

Команда ‘docker save’ создает один файл, который может быть использован для импорта образа на другую хост-систему. В отличие от команды ‘export’, она сохраняет все слои и их метаданные. Может быть применена только к образам.

docker export

До:

После:

Команда ‘docker export’ создает tar архив с содержимым файлов контейнера, в результате получается папка, пригодная для использования вне docker. Команда убирает слои и их метаданные. Может быть применена только для контейнеров.

docker history

До:

После:

Команда ‘docker history’ принимает и рекурсивно выводит список всех слоев-родителей образа (которые тоже могут быть образами)