Где хранятся контейнеры docker windows
Перейти к содержимому

Где хранятся контейнеры docker windows

  • автор:

Обзор хранилища контейнера

В этом разделе приводятся общие сведения о различных способах использования контейнерами хранилища в Windows. В случае хранилища контейнеры ведут себя иначе, чем виртуальные машины. По сути, контейнеры создаются так, чтобы выполняющееся в них приложение не могло записывать свое состояние в файловую систему узла. По умолчанию контейнеры используют «вспомогательное» пространство, но Windows также предоставляет средства для хранения в постоянном хранилище.

Область временных файлов

Контейнеры Windows по умолчанию используют временное хранилище. Все операции ввода-вывода контейнера выполняются во «вспомогательном пространстве», и у каждого контейнера такое пространство свое. Данные о создании и записи файлов записываются во вспомогательное пространство и не отправляются на узел. При остановке экземпляра контейнера все изменения, произошедшие во вспомогательном пространстве, сбрасываются. При запуске нового экземпляра контейнера ему предоставляется новое вспомогательное пространство.

Хранилище уровня

Как описано в статье Общие сведения о контейнерах, образы контейнеров представляют собой набор файлов, представленный в виде совокупности слоев. Хранилище слоя содержит все файлы, которые встроены в контейнер. При каждом выполнении операции docker pull и docker run с контейнером результаты совпадают.

Где хранятся уровни и как их изменить

При установке по умолчанию уровни хранятся в C:\ProgramData\docker и распределяются между каталогами «image» и «windowsfilter». Вы можете изменить место хранения уровней, используя конфигурацию docker-root , как показано в документации по подсистеме Docker в Windows.

Для хранилища уровня поддерживается только файловая система NTFS. ReFS и общие тома кластера (CSV) не поддерживаются.

Вам не следует менять какие-либо файлы в каталогах уровня — они тщательно контролируются с помощью таких команд, как:

Поддерживаемые операции хранилища уровня

Запущенные контейнеры могут использовать большинство операций NTFS, за исключением транзакций. К ним относятся настройка списков управления доступом, при этом все списки проверяются внутри контейнера. Если вы хотите запускать процессы как множество пользователей в контейнере, вы можете создать пользователей в Dockerfile с помощью RUN net user /create . , настроить списки управления доступом к файлу, а затем настроить процессы для выполнения с этим пользователем с помощью директивы Dockerfile USER.

Постоянное хранилище

Контейнеры Windows поддерживают механизмы для обеспечения постоянного хранения с помощью привязок и томов. Дополнительные сведения см. в разделе Постоянное хранилище в контейнерах.

Ограничения хранилища

Обычно приложения для Windows запрашивают объем свободного места на диске перед установкой или созданием новых файлов, а также для удаления временных файлов. Для обеспечения максимальной совместимости приложений диск C: в контейнере Windows представляет виртуальное свободное пространство размером 20 ГБ.

Некоторым пользователям может потребоваться переопределить это значение по умолчанию и настроить свободное пространство меньшей или большей емкости. Это можно сделать с помощью параметра «size» в конфигурации «storage-opt».

Пример

Командная строка: docker run —storage-opt «size=50GB» mcr.microsoft.com/windows/servercore:ltsc2019 cmd

Вы также можете изменить файл конфигурации Docker напрямую.

"storage-opts": [ "size=50GB" ] 

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

Изменение расположения контейнеров и образов Docker в Windows

Docker Desktop в Windows 10 создаёт WSL 2 дистрибутив docker-desktop-data и соответствующий виртуальный диск для него, который обычно расположен здесь:

%USERPROFILE%\AppData\Local\Docker\wsl\data\ext4.vhdx

Именно тут хранятся все контейнеры и образы докера. Для перемещения этого диска в другое место нужно выполнить несколько шагов.

Шаг 1. Выйти из Docker Desktop (если запущен).

Контекстное меню Docker Desktop

Завершение работы Docker Desktop

Шаг 2. В командной строке выполняем команду для вывода списка дистрибутивов Linux:

wsl --list -v
  • wsl — команда для взаимодействия с подсистемой Linux в Windows;
  • —list — вывести список дистрибутивов Linux;
  • -v — вывести расширенную информацию.

Результат выполнения команды должен быть примерно таким:

Результат выполнения команды wsl для вывода списка дистрибутивов Linux

Список дистрибутивов Linux с расширенной информацией

Состояние дистрибутивов (STATE) должно быть Stopped .

Шаг 3. Экспортируем данные в файл. Можно экспортировать в любое место, этот файл позже можно будет удалить. Например, в корень диска f: :

wsl --export docker-desktop-data "f:\docker-desktop-data.tar"

Шаг 4. Удалим дистрибутив docker-desktop-data из WSL. Во время выполнения этой операции виртуальный диск со всеми данными докера будет удалён.

wsl --unregister docker-desktop-data

Шаг 5. Импортируем дистрибутив обратно в WSL, но теперь в новое место. Например, в папку f:\docker\wsl (папка должна быть предварительно создана):

wsl --import docker-desktop-data "f:\docker\wsl" "f:\docker-desktop-data.tar" --version 2

Шаг 6. Запускаем Docker Desktop и проверяем, что всё работает. Если всё хорошо, можно удалить файл, который мы создали при экспорте дистрибутива на 3 шаге ( f:\docker-desktop-data.tar ).

На этом всё. Данные докера хранятся теперь в новом месте.

Полезные ссылки

При написании статьи использовалось следующее ПО:

  • Windows 10 Pro 20H2
  • Docker Desktop 3.5.1 (66090)

Где докер хранит образы на винде?

Обновил докер, он потребовал обновить Wsl до второй версии, после обновы все образы и контейнеры куда то делись, как их восстановить или хотя бы узнать какие образы были? и есть ли возможность восстановить все контейнеры?

  • Вопрос задан более трёх лет назад
  • 5572 просмотра

Комментировать

Решения вопроса 0

Ответы на вопрос 2

Vlatqa

C:\Users\. \AppData\Local\Docker\wsl вот тут они

Где docker хранит контейнеры?

Хочу перенести их, запустить в другом месте, и сделать резервную копию. В документации ясно написано, что контейнеры создаются в том числе для переноса, однако инструкций как это делается я не нашёл. Нашёл, что docker хранит свои файлы в директории /var/lib/docker однако там у меня много тысяч файлов на 4 GB, а мои контейнеры — намного меньше, не хотелось бы таскать всё что есть в этой директории

Отслеживать
задан 28 окт 2015 в 20:14
Алексей Стародубцев Алексей Стародубцев
649 1 1 золотой знак 4 4 серебряных знака 15 15 бронзовых знаков

Вы изначально при запуске контейнеров не создавали volumes на хостовую машину docker run -v /path/to/host/data::/var/lib/postgresql ?

28 окт 2015 в 20:59
скорее всего создавал, я по инструкции настраивал: github.com/sameersbn/docker-redmine
28 окт 2015 в 21:01

Да, в доках написано —volume=/srv/docker/redmine/postgresql:/var/lib/postgresql . Когда контейнер запускался директория /srv/docker/redmine/postgresql должна была создаться автоматически. Посмотрите, что там или sudo docker inspect —format ‘<< .Volumes >>’ postgresql-redmine . Достаточно заархивировать её, перенести на новый сервер и разархивировать. Путь разархиварования, не имеет значение, ибо директория, как вы уже заметили, задаётся через volume. Далее, на новой машине подтянуть образ контейнера желательно той же версии: docker pull quay.io/sameersbn/postgresql:latest

28 окт 2015 в 21:30

Собственно, запускаем postgres-контейнер, но без переменных окружения — нам же не нужно вновь создавать БД и пользователя: docker run —name=postgresql-redmine -d —volume=/srv/docker/redmine/postgresql:/var/lib/postgresql quay.io/sameersbn/postgresql:latest . C redmine аналогично. Архивируем /srv/docker/redmine/redmine , переносим и запускаем docker run —name=redmine -d —link=postgresql-redmine:postgresql -p 10083:80 -e ‘REDMINE_PORT=10083’ -v /srv/docker/redmine/redmine:/home/redmine/data quay.io/sameersbn/redmine

28 окт 2015 в 21:42

Да, перед архивированием контейнеры необходимо остановить docker stop redmine postgresql-redmine , а потому можно запустить вновь docker stop postgresql-redmine redmine .

28 окт 2015 в 21:58

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

В приведённой вами инструкции видно, что контейнер запускается с опцией

--volume=/srv/docker/redmine/postgresql:/var/lib/postgresql 

В момент монтирования происходит затирание данных в контейнере, если те присутствовали по этому пути.

Если опция —volume не была указана, то docker автоматически создаёт volumes исходя из параметров указанных в конфигурационном файле Dockerfile.

Если обратиться к исходникам образа для PostgreSQL, то можно заметить, что это два volumes: /var/lib/postgresql и /run/postgresql . По первому пути расположены данные postgres. Собственно, они нас и интересуют.

Узнать всю информацию про volumes отдельно взятого контейнера можно командой

docker inspect --format '>'

Данные возвращаются в json-формате, а потому предусмотрена возможность фильтрации/поиска через опцию —format

Все volumes для которых не указан путь расположения на хосте (левая часть /host/path/to/data:/container/to/data ) хранятся в директории /var/lib/docker/volumes//_data/ . Таким образом, можно просто исследовав все директории в /var/lib/docker/volumes/ и найти необходимый.

Если левая часть указана, а правая совпадает с volumes, которые указаны в Dockerfile (volumes by default), то происходит переопределение директории на хосте. Зачем нам два волиума с одинковыми данными на хосте ( /var/lib/docker/volumes//_data/ и /host/path/to/data ), правда?

Как уже было отмечено @dmitrz, пока не существует возможности управлять volumes уже на поднятых контейнерах, также как и линковать. Первая проблема должна уже очень скоро решиться.

Команда commit

Volume является отдельной сущностью и потому не попадает в commit. Вот что говорит официальная документация.

The commit operation will not include any data contained in volumes mounted inside the container.

Вообще смущает наличие двух методов создания образов: файлами конфигурации и коммитами.

Файл конфигурации задаёт изначальную конфигурацию контейнера в момент запуска, а коммит сохраняет состояние на момент коммита. Если, к примеру, волиумы не задавать (не в конфиге и не при запуске), то состояние контейнера будет меняться (писаться данные будут именно в него). Возможно, у вас может возникнуть ситуация, когда нужно подправить конфиг postgres или ещё что-то сделать внутри контейнера, то с помощью команды docker exec -it postgresql bash вы можете зайти внутрь. Далее, все сделанные изменения вы можете закоммитить в образ, чтобы запуская контейнер где-нибудь ещё из этого образа не повторять все эти действия. Но такой подход сомнительный. Лучше сделать правки в основном конфиге Dockerfile .

Ошибка в версии Ruby

В docker существует такое понятие, как entrypoint. Обычно это shell-скрипт, который дёргается при запуске docker run или docker start . Если посмотреть листинг entrypoint.sh для redmine, то можно заметить установку плагинов (bundles) для redmine. Далее, если файла $/tmp/plugins.sha1 не существует, то происходит установка плагинов. Обратите внимание на переменную $ и посмотрите в Dockerfile для redmine, т.е. REDMINE_DATA_DIR входит в волиум. Вспоминаем, что при коммите данные волиума не заносятся в образ. Когда закоммиченый контейнер запускается на новой машине видимо возникает конфликт старой версии redmine и устанавливаемых вновь плагинов.

Если данные redmine критичны ( /srv/docker/redmine/redmine:/home/redmine/data ), то их обязательно нужно перенести на новую машину. Далее, поднять либо закоммиченый образ, либо загрузить контейнер с уже новой версией redmine по той инструкции.

Можете ознакомится со всеми доступными версиями redmine образов от sameersbn.

Что касается PostgreSQL контейнера, то его данные ( /srv/docker/redmine/postgresql:/var/lib/postgresql ) обязательно необходимо перенести.

Загрузка образов

Загрузка образов из registry (https://hub.docker.com/, https://quay.io/, можно даже поднять локальный) осуществляется с помощь команды

docker pull :

, где тег — это, как правило, версия софта, который находится в этом образе.

Запуск контейнера происходит командой

docker run --name -d :

Если образа с таким именем и тегом на локальной машине нет, то прозрачно срабатывает команда docker pull , т.е. образ ищется на удалённых registry.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *