Docker volume где хранится windows

Обновлено: 30.06.2024

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

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

В таких случаях лучше всего указать особенности операционной системы в названии вопроса и / или в постановке вопроса. Два хороших ответа были предоставлены для Linux и MacOS (Mac OS X).

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

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

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

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

В случае devicemapper :

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

Могу ли я увидеть содержимое внутри, смонтировав его каким-либо образом? Если вы установите драйвер хранилища после того, как он уже запущен и у него есть несколько запущенных контейнеров с изображениями, перенесет ли он дату при следующем перезапуске демона? Если нет, то как изменить драйвер хранилища в этом случае? Сделайте себе одолжение и не проверяйте значения по умолчанию. Используйте docker info и найдите фактическое местоположение, специфичное для вашей установки . Кажется, это изменилось. Я использую Docker for Mac с 2 изображениями по 1,5 ГБ каждый и /var/lib не имеет каталога docker .

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

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

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

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

Это место для всех изображений (например ubuntu , nginx ) или это место для всех контейнеров? Оригинальный вопрос требует изображений , а не контейнеров . Если вы помните, что Docker все еще работает в ВМ, системные пути относятся к ВМ, а не из системы Mac Osx. Попробуйте следующую команду: docker запустите --rm -it -v /: / vm-root alpine: edge ls -l / vm-root и после этого: docker запустите --rm -it -v /: / vm-root alpine: edge ls -l / vm-root / var / lib / docker Вы можете просмотреть папку докера с хоста WM Кажется, это изменилось. Я использую Docker for Mac с двумя изображениями по 1,5 ГБ каждый и

/Library/Containers/Data/com.docker.docker/Data не имеет каталога, com.docker.driver.amd64-linux и единственный большой файл находится vms/0/Docker.raw с 3,6 ГБ.

Это был старый способ, теперь он изменился. Не обращайте внимания на этот ответ с 2019 года

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

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

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

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

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

После новой установки Docker в Windows 10 я могу подтвердить, что в результате первого щелчка по ярлыку Docker Quickstart Terminal в первый раз создается виртуальная машина (ВМ) с именем «default» (после нескольких неудачных запусков - продолжайте работать до тех пор, пока оно работает). Эта виртуальная машина «по умолчанию» может быть расположена в Windows по адресу: %USERPROFILE%\.docker\machine\machines (обратите внимание на точку остановки в пути) Ответ больше не верен для Windows 10. Вместо этого, посмотрите более новый ответ от @tristan, на который ссылается C:\Users\Public\Documents\Hyper-V\Virtual hard disks\MobyLinuxVM.vhdx % USERPROFILE% \. Docker все еще корректен для установок win7.

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

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

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

Да, к сожалению, эти две строки "(мета) файл данных" не появляются в каждом докере. Это зависит от используемого водителя Правильный ответ: «Это то, где он находится на МОЕЙ машине». Правильный ответ: «Вот как вы найдете это на вашей машине». Это правильный ответ. Я присоединился к компании с 11 различными томами EBS, полными образов докеров. Этот ответ позволил мне выяснить, какой был текущий «Root Dir». В Mac OS X (по крайней мере, в Yosemite, то есть EOL относительно Docker), docker info очень полезно, но в выводе Docker Root Dir: /var/lib/docker не указывается место хранения изображения (см. Ответ для конкретного Mac выше).

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

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

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

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

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

Этот ответ уже устарел, они изменили положение вещей.

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

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

Действительно хорошо. На Mac DaisyDisk аналогичен (отображение колеса), GrandPerspective также полезен (прямоугольники). Кажется, это единственный надежный способ найти его.

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

Я не могу найти никаких контейнеров или папок с изображениями в этом каталоге. $ docker images -a дает около 1 гигабайта изображений, в то время как disk.vmdk в

/ .docker составляет около 20 гигабайт. Как так?

@Grav: виртуальная машина выделяет 20 гигабайт для будущего использования, но использует только 1 гигабайт для изображений.

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

Я выполнил docker build команду, и я не вижу файл, который я считаю файлом изображения. Я вижу некоторые папки и некоторые текстовые файлы (например, service.txt). Какой тип файла и с каким расширением файла docker build создает?

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

/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux $ ls -lh | grep Docker -rw-r--r--@ 1 jasper staff 6.3G May 25 19:20 Docker.qcow2 я нашел изображение. Но это не контейнеры, хотя. Не видеть их в этом каталоге данных действительно ..

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

Docker.qcow2? Как я должен извлечь конкретное изображение докера из этого?

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

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

Это только перемещает машину Hyper-V, но не изображения, изображения будут по-прежнему сохраняться там, где находится VHD. @olive_tree Я пытаюсь найти изображения, созданные docker build командой. Я на компьютере с Windows 10. Я смотрю в C: \ Users \ Public \ Documents \ Hyper-V \ Виртуальные жесткие диски, но вижу только MobyLinuxVM.vhdx. Где хранятся реальные изображения?

Если вы помните, что 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

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

Спасибо! Это единственный ответ, который работал для меня в Windows 10 с Hyper-v. Мне удалось очистить поврежденные файлы в папке elusive / var / lib / docker / overlay2.

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

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

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

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

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

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

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

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

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

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

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

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

Важная характеристика Docker-контейнеров — эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но как в таком случае запускать в Docker приложения, которые должны сохранять информацию о своём состоянии? Для этого есть несколько инструментов.

В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.

Особенности работы контейнеров

Прежде чем перейти к способам хранения данных, вспомним устройство контейнеров. Это поможет лучше понять основную тему.

Контейнер создаётся из образа, в котором есть всё для начала его работы. Но там не хранится и тем более не изменяется ничего важного. В любой момент приложение в контейнере может быть завершено, а контейнер уничтожен, и это нормально. Контейнер отработал — выкидываем его и собираем новый. Если пользователь загрузил в приложение картинку, то при замене контейнера она удалится.

На схеме показано устройство контейнера, запущенного из образа Ubuntu 15.04. Контейнер состоит из пяти слоёв: четыре из них принадлежат образу, и лишь один — самому контейнеру. Слои образа доступны только для чтения, слой контейнера — для чтения и для записи. Если при работе приложения какие-то данные будут изменяться, они попадут в слой контейнера. Но при уничтожении контейнера слой будет безвозвратно потерян, и все данные вместе с ним.

В идеальном мире Docker используют только для запуска stateless-приложений, которые не читают и не сохраняют данные о своём состоянии и готовы в любой момент завершиться. Однако в реальности большинство программ относятся к категории stateful, то есть требуют сохранения данных между перезапусками.

Поэтому нужны способы сделать так, чтобы важные изменяемые данные не зависели от эфемерности контейнеров и, как бонус, были доступными сразу из нескольких мест.

В Docker есть несколько способов хранения данных. Наиболее распространенные:

тома хранения данных (docker volumes),
монтирование каталогов с хоста (bind mount).

Особые типы хранения:

именованные каналы (named pipes, только в Windows),
монтирование tmpfs (только в Linux).

На схеме показаны самые популярные типы хранения данных для Linux: в памяти (tmpfs), в файловой системе хоста (bind mount), в томе Docker (docker volumes). Разберём каждый вариант.

Тома (docker volumes)

Тома — рекомендуемый разработчиками Docker способ хранения данных. В Linux тома находятся по умолчанию в /var/lib/docker/volumes/. Другие программы не должны получать к ним доступ напрямую, только через контейнер.

Тома создаются и управляются средствами Docker: командой docker volume create, через указание тома при создании контейнера в Dockerfile или docker-compose.yml.

В контейнере том видно как обычный каталог, который мы определяем в Dockerfile. Тома могут быть с именами или без — безымянным томам Docker сам присвоит имя.

Один том может быть примонтирован одновременно в несколько контейнеров. Когда никто не использует том, он не удаляется, а продолжает существовать. Команда для удаления томов: docker volume prune.

Можно выбрать специальный драйвер для тома и хранить данные не на хосте, а на удалённом сервере или в облаке.

Для чего стоит использовать тома в Docker:

шаринг данных между несколькими запущенными контейнерами,
решение проблемы привязки к ОС хоста,
удалённое хранение данных,
бэкап или миграция данных на другой хост с Docker (для этого надо остановить все контейнеры и скопировать содержимое из каталога тома в нужное место).

Монтирование каталога с хоста (bind mount)

Это более простая концепция: файл или каталог с хоста просто монтируется в контейнер.

Используется, когда нужно пробросить в контейнер конфигурационные файлы с хоста. Например, именно так в контейнерах реализуется DNS: с хоста монтируется файл /etc/resolv.conf.

Другое очевидное применение — в разработке. Код находится на хосте (вашем ноутбуке), но исполняется в контейнере. Вы меняете код и сразу видите результат. Это возможно, так как процессы хоста и контейнера одновременно имеют доступ к одним и тем же данным.

Особенности bind mount:

Запись в примонтированный каталог могут вести программы как в контейнере, так и на хосте. Это значит, есть риск случайно затереть данные, не понимая, что с ними работает контейнер.
Лучше не использовать в продакшене. Для продакшена убедитесь, что код копируется в контейнер, а не монтируется с хоста.
Для успешного монтирования указывайте полный путь к файлу или каталогу на хосте.
Если приложение в контейнере запущено от root, а совместно используется каталог с ограниченными правами, то в какой-то момент может возникнуть проблема с правами на файлы и невозможность что-то удалить без использования sudo.

Когда использовать тома, а когда монтирование с хоста

Volume	Bind mount
Просто расшарить данные между контейнерами.	Пробросить конфигурацию с хоста в контейнер.
У хоста нет нужной структуры каталогов.	Расшарить исходники и/или уже собранные приложения.
Данные лучше хранить не локально (а в облаке, например).	Есть стабильная структура каталогов и файлов, которую нужно расшарить между контейнерами.

Монтирование tmpfs

Tmpfs — временное файловое хранилище. Это некая специально отведённая область в оперативной памяти компьютера. Из определения выходит, что tmpfs — не лучшее хранилище для важных данных. Так оно и есть: при остановке или перезапуске контейнера сохранённые в tmpfs данные будут навсегда потеряны.

На самом деле tmpfs нужно не для сохранения данных, а для безопасности, полученные в ходе работы приложения чувствительные данные безвозвратно исчезнут после завершения работы контейнера. Бонусом использования будет высокая скорость доступа к информации.

Например, приложение в контейнере тормозит из-за того, что в ходе работы активно идут операции чтения-записи, а диски на хосте не очень быстрые. Если вы не уверены, в какой каталог идёт эта нагрузка, можно применить к запущенному контейнеру команду docker diff . И вот этот каталог смонтировать как tmpfs, таким образом перенеся ввод-вывод с диска в оперативную память.

Такое хранилище может одновременно работать только с одним контейнером и доступно только в Linux.

Общие советы по использованию томов

Монтирование в непустые директории

Если вы монтируете пустой том в каталог контейнера, где уже есть файлы, то эти файлы не удалятся, а будут скопированы в том. Этим можно пользоваться, когда нужно скопировать данные из одного контейнера в другой.

Если вы монтируете непустой том или каталог с хоста в контейнер, где уже есть файлы, то эти файлы тоже не удалятся, а просто будут скрыты. Видно будет только то, что есть в томе или каталоге на хосте. Похоже на простое монтирование в Linux.

Монтирование служебных файлов

С хоста можно монтировать любые файлы, в том числе служебные. Например, сокет docker. В результате получится docker-in-docker: один контейнер запустится внутри другого. UPD: (*это не совсем так. mwizard в комментариях пояснил, что в таком случае родительский docker запустит sibling-контейнер). Выглядит как бред, но в некоторых случаях бывает оправдано. Например, при настройке CI/CD.

Монтирование /var/lib/docker

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

Ключ командной строки для Docker при работе с томами.

Для volume или bind mount:

Команды для управления томами в интерфейсе CLI Docker:

Создадим тестовый том:

Вот он появился в списке:

Команда inspect выдаст примерно такой список информации в json:

Попробуем использовать созданный том, запустим с ним контейнер:

После самоуничтожения контейнера запустим другой и подключим к нему тот же том. Проверяем, что в нашем файле:

То же самое, отлично.

Теперь примонтируем каталог с хоста:

Docker не любит относительные пути, лучше указывайте абсолютные!

Теперь попробуем совместить оба типа томов сразу:

Отлично! А если нам нужно передать ровно те же тома другому контейнеру?

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

Создавать том заранее необязательно, всё сработает в момент запуска docker run:

Посмотрим теперь на список томов:

Ещё немного усложним команду запуска, создадим анонимный том:

Такой том самоуничтожится после выхода из контейнера, так как мы указали ключ –rm.

Если этого не сделать, давайте проверим что будет:

Хозяйке на заметку: тома (как образы и контейнеры) ограничены значением настройки dm.basesize, которая устанавливается на уровне настроек демона Docker. Как правило, что-то около 10Gb. Это значение можно изменить вручную, но потребуется перезапуск демона Docker.

При запуске демона с ключом это выглядит так:

Однажды увеличив значение, его уже нельзя просто так уменьшить. При запуске Docker выдаст ошибку.

Если вам нужно вручную очистить содержимое всех томов, придётся удалять каталог, предварительно остановив демон:

Если вам интересно узнать подробнее о работе с данными в Docker и других возможностях технологии, приглашаем на двухдневный онлайн-интенсив в феврале. Будет много практики.

Автор статьи: Александр Швалов, практикующий инженер Southbridge, Certified Kubernetes Administrator, автор и разработчик курсов Слёрм.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

Разница между изображениями и контейнерами

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

Работа с хранилищем образов Docker

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

Если вы хотите получить прямой доступ к данным изображения, они обычно хранятся в следующих местах:

Linux: / var / lib / docker /
Windows: C: ProgramData DockerDesktop
macOS:

Вместо этого Docker предоставляет управляемые команды для обработки изображений. Вы можете просмотреть все версии загруженных изображений с помощью простой команды:

образ докера ls

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

Однако, если вы используете много разных изображений, у вас может быть сохранено много изображений, которые даже больше не используются. Чтобы очистить их, Docker предоставляет встроенную команду для запуска сборки мусора. Это приведет к удалению всех изображений, на которые нет ссылок, т. Е. Не отмеченных тегами или не упоминаемых каким-либо контейнером.

обрезка образа докера

Чтобы удалить все старые образы, не используемые существующими контейнерами, запустите его с флагом -a:

docker image prune -a

Это охватывает основной вариант использования, но есть еще несколько полезных команд:

Работа с хранилищем контейнеров Docker

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

докер проверяет идентификатор контейнера

Контейнеры хранят данные двумя способами. Во-первых, это базовая файловая система, которая копируется из образа и уникальна для каждого контейнера. Docker использует «нижний каталог» и «верхний каталог», которые представляют собой отдельные уровни, которые объединяются в одну гибридную файловую систему. Нижний каталог хранит данные базового образа, а верхний каталог хранит все, что было изменено во время выполнения, например файлы журнала. В любом случае их хранение зависит от того, какой драйвер файловой системы Docker настроен на использование.

Тогда есть горы, которые привязывают каталоги с хоста к контейнеру, обычно управляются автоматически с помощью функции Docker, называемой тома. Они обычно хранятся и доступны для конечных пользователей. Если вы выполняете какую-либо работу, требующую изменения данных в запущенных контейнерах, вам, вероятно, следует изменить том или привязать монтирование.

Доступ к томам

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

Если вы хотите изменить данные, хранящиеся в томах, вы тоже можете это сделать. Они хранятся в стандартном формате, доступном из Linux:

/ вар / библиотека / докер / тома / volumeID / _data

Вы можете получить идентификатор тома и информацию с помощью docker volume inspect.

объем докера удалить объем докера rm volumeID

Изменение файловой системы контейнера Docker

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

docker exec -it контейнер bash

Отсюда вы можете использовать обычные команды Linux. Если вы хотите сделать это удаленно, вы можете установить SSH-сервер в свой контейнер и привязать порт 22 к другому порту на хосте.

Читайте также: