Docker linux где хранятся контейнеры

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

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

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

Да, в доках написано —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

Собственно, запускаем 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

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

2 ответа 2

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

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

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

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

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

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

Данные возвращаются в 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 , т.е. образ ищется на удалённых registry.

Источник

Где на хосте хранятся образы и контейнеры Docker? — CloudSavvy ИТ

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

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

Образы — это то, что вы создаете, когда запускаете docker build; они хранятся в реестре контейнеров, таком как Docker Hub, и содержат все файлы и код для запуска приложения. Вы можете думать о них как о файлах ISO для операционной системы виртуальной машины.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

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

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

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

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

• Linux: / var / lib / docker /
• Windows: C: ProgramData DockerDesktop
• macOS: ~ / Библиотека / Контейнеры / com.docker.docker / Data / vms / 0 /

Однако трогать эти данные — плохая идея. Хранилище Docker сложное и на самом деле сильно различается в зависимости от какой драйвер памяти он использует. Linux теперь по умолчанию использует overlay2 в большинстве дистрибутивов, что даже недоступно для большинства конечных пользователей. Игнорирование этого может привести к потере данных.

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

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

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

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

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

• inspect: отображает информацию о версии контейнера.
• save & load: сохраняет и загружает изображения в tar-архив.
• rm: удаляет изображение напрямую.
• pull / push: обновления из удаленного реестра.
• история: предоставляет журнал изменений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако, если вы хотите внести некоторые быстрые изменения, не останавливая контейнер, лучший способ — просто открыть оболочку bash внутри контейнера и изменить ее с помощью Docker. Сделать это очень просто — запустите docker exec в контейнере и передайте «bash» в качестве команды:

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

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

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Источник