Как сохранить образ контейнера в файл

Сохранить изменения в docker

Запустил docker с образом ubuntu. Обновил, поменял конфиги, вышел, зашел и ничего не сохранилось. Как правильно сохранять изменения в docker? Гугл предлагает сохранение образа, а мне надо сохранять изменения внутри контейнера.

NoobeR ★★★★
30.05.16 18:00:16 MSK

Use volumes, Luke!

theNamelessOne ★★★★★
( 30.05.16 18:02:09 MSK )

монтируй вольюм и пиши в него

leave ★★★★★
( 30.05.16 18:02:43 MSK )

Но скорее всего ты хочешь странного от докера.

staseg ★★★★★
( 30.05.16 18:03:06 MSK )
Последнее исправление: staseg 30.05.16 18:03:33 MSK (всего исправлений: 1)

Ответ на: комментарий от staseg 30.05.16 18:03:06 MSK

я хочу обновить ПО, подредачить конфиги и потом запускать с этими изменениями, а не делать всё с нуля

NoobeR ★★★★
( 30.05.16 18:04:44 MSK ) автор топика
Ответ на: комментарий от NoobeR 30.05.16 18:04:44 MSK

Тащемта, ты запускаешь контейнер на основе какого-то образа, редактируешь в нём конфиги, коммитишь изменения и получаешь уже новый образ, в котором эти изменения зафиксированы.

theNamelessOne ★★★★★
( 30.05.16 18:06:22 MSK )
Ответ на: комментарий от NoobeR 30.05.16 18:04:44 MSK

Смотри эту ссылку, обращай внимания на картинки и описания к ним.

theNamelessOne ★★★★★
( 30.05.16 18:07:40 MSK )
Ответ на: комментарий от NoobeR 30.05.16 18:04:44 MSK

Обновлять ПО вручную 99% не надо, просто используй свежий образ. Или создай его сам с помощью docker commit или Dockerfile. Конфиги и персистентные стораджи лучше просовывать с помощью volumes.

staseg ★★★★★
( 30.05.16 18:09:26 MSK )
Ответ на: комментарий от staseg 30.05.16 18:09:26 MSK

А, и еще важно понять разницу между контейнером и образом, у многих из-за этого каша в голове.

staseg ★★★★★
( 30.05.16 18:10:25 MSK )
Ответ на: комментарий от staseg 30.05.16 18:10:25 MSK

контейнер это то, что работает, а образ это то, из чего создаем контейнер?

NoobeR ★★★★
( 30.05.16 18:23:29 MSK ) автор топика
Ответ на: комментарий от NoobeR 30.05.16 18:23:29 MSK

Образ — это совокупность неизменяемых “слоев” (layers), представляющих различия (differences) в состояниях файловой системы. Контейнер — это рантайм-инстанс образа. Как я уже сказал, образа сами по себе неизменяемы, однако контейнеры содержат вдобавок к неизменяемым слоям образа содержат доступный для записи слой, в котором отражаются его изменения. Когда ты запустил контейнер и внёс изменения в конфиги, эти изменения записались в этот самый слой контейнера. Чтобы зафиксировать эти изменения, есть команда docker commit , которая создаёт из контейнера новый образ, добавляя его доступный для записи слой поверх неизменяемых слоёв базового контейнера. Можно также описывать изменения базового слоя декларативно с помощью Dockerfile .

theNamelessOne ★★★★★
( 30.05.16 18:34:46 MSK )
Ответ на: комментарий от theNamelessOne 30.05.16 18:34:46 MSK

NoobeR ★★★★
( 30.05.16 18:37:03 MSK ) автор топика
Ответ на: комментарий от theNamelessOne 30.05.16 18:34:46 MSK

Можно также описывать изменения базового слоя декларативно с помощью Dockerfile .

Можно также описывать изменения базового образа декларативно с помощью Dockerfile .

Посмотри ещё на volume’ы, вполне возможно, для твоей задачи они будут предпочтительней.

theNamelessOne ★★★★★
( 30.05.16 18:42:53 MSK )
Ответ на: Fix от theNamelessOne 30.05.16 18:42:53 MSK

я и так использую тома, для хранения самих сайтов (~/www). в контейнере ~/www смонтирован в /var/www/srv. если это правильно..

NoobeR ★★★★
( 30.05.16 18:47:32 MSK ) автор топика
Ответ на: комментарий от NoobeR 30.05.16 18:47:32 MSK

Ну так можно с помощью томов примонтировать конфиги.

theNamelessOne ★★★★★
( 30.05.16 18:54:50 MSK )
Ответ на: комментарий от theNamelessOne 30.05.16 18:54:50 MSK

что-то вроде ~/www/config/:/etc/apache2/sites-available ?

NoobeR ★★★★
( 30.05.16 18:56:46 MSK ) автор топика
Ответ на: комментарий от NoobeR 30.05.16 18:56:46 MSK

Насколько я знаю, в таком случае в типовой конфигурации апача ещё требуется симлинк в sites-enabled , так что лучше сразу монтировать туда.

theNamelessOne ★★★★★
( 30.05.16 19:00:09 MSK )
Ответ на: комментарий от theNamelessOne 30.05.16 19:00:09 MSK

NoobeR ★★★★
( 30.05.16 19:01:59 MSK ) автор топика
Ответ на: комментарий от NoobeR 30.05.16 18:04:44 MSK

я хочу обновить ПО, подредачить конфиги и потом запускать с этими изменениями, а не делать всё с нуля

Если ты хочешь ручками что-то править в системе и работать с контейнером как с отдельным компьютером, то тебе нужно смотреть не на Docker, а на LXC.

В Docker же твоя задача решается так:

— Делаем Dockerfile для твоих изменений (исходный образ + действия в нём)
— Из Dockerfile делаем image (или это сделает автоматом docker-compose)
— Запускаем docker-образ, монтируя внутрь него индивидуальные для контейнера конфиги, сохраняемые данные и т.п.

Если тебе требуется сохранять сделанные в Docker изменения, то 99% за то, что ты делаешь что-то не так.

Учебник. Сохранение данных в приложении-контейнере с помощью томов в VS Code

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

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

В этом учебнике также рассматриваются слои в образе, кэширование слоев и многоэтапные сборки.

В этом руководстве описано следующее:

• Общие сведения о данных в контейнерах.
• Сохранение данных с помощью именованных томов.
• Использование подключений привязок.
• Просмотр слоя образа.
• Кэширование зависимостей.
• Общие сведения о многоэтапных сборках.

Необходимые компоненты

Этот учебник является продолжением предыдущего — Создание приложения Docker и предоставление к нему общего доступа с помощью Visual Studio Code. Начните с первого учебника, поскольку в нем приводятся предварительные требования.

Общие сведения о данных в контейнерах

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

Запустите контейнер ubuntu с помощью следующей команды:

docker run -d ubuntu bash -c "shuf -i 1-10000 -n 1 -o /data.txt && tail -f /dev/null" 

Эта команда запускает две команды с помощью && . Первая часть выбирает одно случайное число и записывает его в файл /data.txt . Вторая команда наблюдает за файлом, чтобы работа контейнера не прекращалась.

cat /data.txt 

docker exec cat /data.txt 

docker run -d ubuntu bash -c "shuf -i 1-10000 -n 1 -o /data.txt && tail -f /dev/null" 

docker run -it ubuntu ls / 

docker volume create todo-db 

docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started 

docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started 

docker volume inspect todo-db 

[ < "CreatedAt": "2019-09-26T02:18:36Z", "Driver": "local", "Labels": <>, "Mountpoint": "/var/lib/docker/volumes/todo-db/_data", "Name": "todo-db", "Options": <>, "Scope": "local" > ] 

docker run -dp 3000:3000 -w /app -v $:/app node:20-alpine sh -c "yarn install && yarn run dev" 

docker logs -f

$ nodemon src/index.js [nodemon] 2.0.20 [nodemon] to restart at any time, enter `rs` [nodemon] watching path(s): *.* [nodemon] watching extensions: js,mjs,json [nodemon] starting `node src/index.js` Using sqlite database at /etc/todos/todo.db Listening on port 3000 

Просмотр слоев образа

Можно просмотреть слои, составляющие образ. Выполните команду docker image history , чтобы просмотреть команды, которые использовались для создания каждого слоя в образе.

Используйте docker image history для просмотра слоев в образе getting-started, созданном ранее в этом учебнике.

docker image history getting-started 

Результат должен быть похож на выходные данные, приведенные ниже.

IMAGE CREATED CREATED BY SIZE COMMENT a78a40cbf866 18 seconds ago /bin/sh -c #(nop) CMD ["node" "/app/src/ind… 0B f1d1808565d6 19 seconds ago /bin/sh -c yarn install --production 85.4MB a2c054d14948 36 seconds ago /bin/sh -c #(nop) COPY dir:5dc710ad87c789593… 198kB 9577ae713121 37 seconds ago /bin/sh -c #(nop) WORKDIR /app 0B b95baba1cfdb 13 days ago /bin/sh -c #(nop) CMD ["node"] 0B 13 days ago /bin/sh -c #(nop) ENTRYPOINT ["docker-entry… 0B 13 days ago /bin/sh -c #(nop) COPY file:238737301d473041… 116B 13 days ago /bin/sh -c apk add --no-cache --virtual .bui… 5.35MB 13 days ago /bin/sh -c #(nop) ENV YARN_VERSION=1.21.1 0B 13 days ago /bin/sh -c addgroup -g 1000 node && addu… 74.3MB 13 days ago /bin/sh -c #(nop) ENV NODE_VERSION=12.14.1 0B 13 days ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B 13 days ago /bin/sh -c #(nop) ADD file:e69d441d729412d24… 5.59MB 

docker image history --no-trunc getting-started 

Кэширование зависимостей

После изменения слоя все нижестоящие слои также необходимо создать заново. Вот Dockerfile:

FROM node:20-alpine WORKDIR /app COPY . . RUN yarn install --production CMD ["node", "/app/src/index.js"] 

Каждая команда в Dockerfile становится новым слоем в образе. Чтобы максимально сократить количество слоев, можно изменить структуру Dockerfile для поддержки кэширования зависимостей. Для приложений на основе узлов эти зависимости определяются в файле package.json .

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

Сначала измените Dockerfile, чтобы выполнить копирование в package.json , установите зависимости, а затем скопируйте все остальное. Вот новый файл:

FROM node:20-alpine WORKDIR /app COPY package.json yarn.lock ./ RUN yarn install --production COPY . . CMD ["node", "/app/src/index.js"] 

docker build -t getting-started . 

Вы должны увидеть выходные данные, аналогичные приведенным ниже.

Sending build context to Docker daemon 219.1kB Step 1/6 : FROM node:12-alpine ---> b0dc3a5e5e9e Step 2/6 : WORKDIR /app ---> Using cache ---> 9577ae713121 Step 3/6 : COPY package* yarn.lock ./ ---> bd5306f49fc8 Step 4/6 : RUN yarn install --production ---> Running in d53a06c9e4c2 yarn install v1.17.3 [1/4] Resolving packages. [2/4] Fetching packages. info fsevents@1.2.9: The platform "linux" is incompatible with this module. info "fsevents@1.2.9" is an optional dependency and failed compatibility check. Excluding it from installation. [3/4] Linking dependencies. [4/4] Building fresh packages. Done in 10.89s. Removing intermediate container d53a06c9e4c2 ---> 4e68fbc2d704 Step 5/6 : COPY . . ---> a239a11f68d8 Step 6/6 : CMD ["node", "/app/src/index.js"] ---> Running in 49999f68df8f Removing intermediate container 49999f68df8f ---> e709c03bc597 Successfully built e709c03bc597 Successfully tagged getting-started:latest 

Sending build context to Docker daemon 219.1kB Step 1/6 : FROM node:12-alpine ---> b0dc3a5e5e9e Step 2/6 : WORKDIR /app ---> Using cache ---> 9577ae713121 Step 3/6 : COPY package* yarn.lock ./ ---> Using cache ---> bd5306f49fc8 Step 4/6 : RUN yarn install --production ---> Using cache ---> 4e68fbc2d704 Step 5/6 : COPY . . ---> cccde25a3d9a Step 6/6 : CMD ["node", "/app/src/index.js"] ---> Running in 2be75662c150 Removing intermediate container 2be75662c150 ---> 458e5c6f080c Successfully built 458e5c6f080c Successfully tagged getting-started:latest 

Многоэтапная сборка

Многоэтапные сборки — невероятно мощное средство для использования нескольких этапов при создании образа. У них есть несколько преимуществ.

• Отделение зависимостей времени сборки от зависимостей среды выполнения.
• Уменьшение общего размера образа за счет доставки только того, что нужно вашему приложению для работы.

В этом разделе приводятся краткие примеры.

Пример с Maven и Tomcat

При создании приложений на основе Java для компиляции исходного кода в байт-код Java требуется JDK. JDK не требуется в рабочей среде. Для упрощения сборки приложения можно использовать такие средства, как Maven или Gradle. Они также не нужны в окончательном образе.

FROM maven AS build WORKDIR /app COPY . . RUN mvn package FROM tomcat COPY --from=build /app/target/file.war /usr/local/tomcat/webapps 

В этом примере один этап ( build ) используется для выполнения фактической сборки Java с помощью Maven. Второй этап (начиная с «FROM tomcat») копирует в файлы с этапа build . Окончательный образ создается только на последнем этапе (что можно переопределить с помощью параметра —target ).

Пример React

При создании приложений React требуется среда Node для компиляции кода JavaScript, таблиц стилей SASS и др. в статический HTML, JavaScript и CSS. Если вы не выполняете отрисовку на стороне сервера, вам даже не нужна среда узла для рабочей сборки.

FROM node:20-alpine AS build WORKDIR /app COPY package* yarn.lock ./ RUN yarn install COPY public ./public COPY src ./src RUN yarn run build FROM nginx:alpine COPY --from=build /app/build /usr/share/nginx/html 

В этом примере для выполнения сборки используется образ node:20 , который максимально эффективно кэширует слой, а затем копирует выходные данные в контейнер nginx.

Очистка ресурсов

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

Следующие шаги

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

Что вы хотите сделать дальше?

• Работа с несколькими контейнерами с помощью Docker Compose: Создание многоконтейнерных приложений с помощью MySQL и Docker Compose
• Развертывание в приложениях контейнеров Azure:
  • Краткое руководство. Развертывание в приложениях контейнеров Azure с помощью Visual Studio Code
  • Руководство по развертыванию в приложениях контейнеров Azure
  • Развертывание контейнерного приложения в Azure

  Хранение данных в Docker

  

  Важная характеристика 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:

  1. Запись в примонтированный каталог могут вести программы как в контейнере, так и на хосте. Это значит, есть риск случайно затереть данные, не понимая, что с ними работает контейнер.
  2. Лучше не использовать в продакшене. Для продакшена убедитесь, что код копируется в контейнер, а не монтируется с хоста.
  3. Для успешного монтирования указывайте полный путь к файлу или каталогу на хосте.
  4. Если приложение в контейнере запущено от 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:

  --volume | -v

  --tmpfs

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

  $ docker volume Commands: create Create a volume (Создать том) inspect Display detailed information on one or more volumes (Отобразить детальную информацию) ls List volumes (Вывести список томов) prune Remove all unused volumes (Удалить все неиспользуемые тома) rm Remove one or more volumes (Удалить один или несколько томов)

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

  $ docker volume create slurm-storage slurm-storage

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

  $ docker volume ls DRIVER VOLUME NAME local slurm-storage

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

  $ docker inspect slurm-storage [ < "CreatedAt": "2020-12-14T15:00:37Z", "Driver": "local", "Labels": <>, "Mountpoint": "/var/lib/docker/volumes/slurm-storage/_data", "Name": "slurm-storage", "Options": <>, "Scope": "local" > ]

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

  $ docker run --rm -v slurm-storage:/data -it ubuntu:20.10 /bin/bash # echo $RANDOM > /data/file # cat /data/file 13279 # exit

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

  $ docker run --rm -v slurm-storage:/data -it centos:8 /bin/bash -c "cat /data/file" 13279

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

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

  $ docker run -v /srv:/host/srv --name slurm --rm -it ubuntu:20.10 /bin/bash

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

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

  $ docker run -v /srv:/host/srv -v slurm-storage:/data --name slurm --rm -it ubuntu:20.10 /bin/bash

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

  $ docker run --volumes-from slurm --name backup --rm -it centos:8 /bin/bash

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

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

  $ docker run -v newslurm:/newdata -v /srv:/host/srv -v slurm-storage:/data --name slurm --rm -it ubuntu:20.10 /bin/bash

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

  $ docker volume ls DRIVER VOLUME NAME local slurm-storage local newslurm

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

  $ docker run -v /anonymous -v newslurm:/newdata -v /srv:/host/srv -v slurm-storage:/data --name slurm --rm -it ubuntu:20.10 /bin/bash

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

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

  $ docker run -v /anonymous -v newslurm:/newdata -v /srv:/host/srv -v slurm-storage:/data --name slurm -it ubuntu:20.10 /bin/bash $ docker volume ls DRIVER VOLUME NAME local 04c490b16184bf71015f7714b423a517ce9599e9360af07421ceb54ab96bd333 local newslurm local slurm-storage

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

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

  $ sudo dockerd --storage-opt dm.basesize=40G

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

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

  $ sudo service docker stop $ sudo rm -rf /var/lib/docker

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

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

  • Блог компании Слёрм
  • Системное администрирование
  • Виртуализация
  • Серверное администрирование
  • DevOps

  Как сохранить docker контейнер?

  как сохранить докер контейнер, чтобы потом его можно было загружать на другие машины с уже предустановленными пакетами и файлами?

  в файле Dockerfile я прописываю некоторые пакеты которые мне нужны установленными, потом делаю
  docker build .
  потом добавляю в докер некоторые файлы или ещё что-то
  как мне потом всё это сохранить, чтобы весь этот контейнер в таком же виде скопировать на другие машины?

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

  Комментировать
  Решения вопроса 2

  

  PHP developer

  Можно расписать все шаги в файле docker-compose и билдить и поднимать с помощью него, но еще можно создать свой имейдж, залить его на docker registry или dockerhub и оттуда стягивать на машину https://docs.docker.com/develop/develop-images/bas.

  Ответ написан более трёх лет назад
  Комментировать
  Нравится 1 Комментировать
  Сисадмин, просто сисадмин.

  1. Загрузить в docker registry (свой или чужой), в публичный docker hub и брать оттуда.

  2. Сохранить образ в архив, скопировать на новое место и там загрузить:

  docker save -o image.tar imagename1:latest imagename2:3.1415926
  docker load -i image.tar

  Ответ написан более трёх лет назад
  Комментировать
  Нравится 1 Комментировать
  Ответы на вопрос 0
  Ваш ответ на вопрос

  Войдите, чтобы написать ответ

  

  • Docker

  Почему не работает fetch запрос внутри docker сети?

  • 1 подписчик
  • 8 часов назад
  • 27 просмотров
  Похожие публикации:

  1. Как отключить airpods pro от чужого устройства
  2. Как отключить звук печатания в opera gx
  3. Как открыть лючок бензобака ленд крузер 200
  4. Как поменять язык в консоли