DockerAlt
Содержание
- 1 Лабораторные работы по Docker
- 1.1 Подготовка рабочего места
- 1.2 [Практическая работа №1] Создание простого контейнера
- 1.3 [Практическая работа №2] Создание контейнера для разработки приложения на языке Java
- 1.4 [Практическая работа №3] Создание контейнера для запуска приложения на Lazarus
- 1.5 [Практическая работа №4] Взаимодействие двух контейнеров по сети
- 1.6 [Практическая работа №5] Взаимодействие двух контейнеров по сети
- 2 Проблемы под Windows
- 3 NVIDIA IN DOCKER
- 4 Backup and Restore docker volumes
Лабораторные работы по Docker
Подготовка рабочего места
Для выполнения всех работ достаточно установить в виртуальную машину ОС Альт Рабочая Станция 10.
Ссылка на загрузку установочного образа: https://download.basealt.ru/pub/distributions/ALTLinux/p10/images/workstation/x86_64/alt-workstation-10.0-x86_64.iso
После установки нужно обновить систему
su -
apt-get update
apt-get dist-upgrade
update-kernel -f
открыть терминал и установить Docker командой
apt-get install docker-engine
Затем добавить текущего пользователя в группу docker командой
usermod -a -Gdocker student
затем включить сервис и поставить его в автозагрузку
systemctl start docker
systemctl enable docker
перезагрузиться
reboot
[Практическая работа №1] Создание простого контейнера
Вручную
Откройте терминал хостовой машины
На базе официального стандартного Docker-образа
altlinux/base:p10
Только получить образ на компьютер можно командой:
docker pull altlinux/base:p10
создайте и запустите Docker-контейнер:
docker run -it --name=my_first_container --hostname=my-first-container altlinux/base:p10 /bin/bash
В случае успешного создания Docker-контейнера в эмуляторе терминала приглашение должно смениться на такое:
root@my-first-container:/#
Внимание! Сейчас вы внутри Docker-контейнера и можете командовать им! Если скомандовать
exit
, то контейнер завершит свою работу и найти и запустить его можно таким образом:
Найти:
docker ps -a
в ответе среди возможных прочих контейнеров должен быть такой:
f0a3cc6a8b63 altlinux/base:p10 "/bin/bash" 15 seconds ago Exited (0) 5 seconds ago my_first_container
Имя его в данном случае:
my_first_container
Идентификатор его в данном случае:
f0a3cc6a8b63
Запустить:
docker start my_first_container
или:
docker start f0a3cc6a8b63
Естественно, в конкретном случае идентификатор будет другой.
Подключиться к терминалу Docker-контейнера:
docker attach my_first_container
или
docker attach f0a3cc6a8b63
Внимание! Сейчас вы внутри контейнера и можете командовать им! Если скомандовать
exit
, то контейнер завершит свою работу придётся опять читать выше по тексту как его запускать...
Однако есть способ отключиться от терминала и не завершить Docker-контейнер:
Для этого нужно последовательно нажать сочетания клавиш:
Ctrl + P
затем
Ctrl + Q
После этого приглашение командной строки контейнера должно заменить приглашение хостовой системы.
На этом этапе мы научились запускать контейнер на базе образа. Однако наша цель -- создать собственный образ, поведение контейнеров, запущенных на базе которого который будет отличаться от поведения только что созданного нами контейнера.
Для создания собственного образа вручную необходимо внести изменения внутри нашего контейнера, а затем выполнить операцию по "превращению" нашего контейнера в образ.
Задача
Создать образ, содержащий стартовый сценарий, который будет считывать переменную окружения с именем пользователя и приветствовать пользователя по имени.
Ход работы
Запустите контейнер my_first_container и подключитесь к его терминалу (как это сделать - описано выше)
Установите внутри контейнера текстовый редактор
apt-get update apt-get install nano
Создайте с помощью установленного редактора nano файл сценария
bootstrap.sh
со следующим содержимым:
#!/bin/bash echo "Hello, $USER_NAME"
Сделайте файл исполняемым
chmod +x /bootstrap.sh
Проверьте работоспособность командой:
USER_NAME=Ivan /bootstrap.sh
в результате в терминал должна быть выдана строка
Hello, Ivan
Завершите контейнер, выйдя из него:
exit
Создайте новый образ на базе изменённого контейнера командой:
docker commit -a Vasya -m "My first own image" my_first_container my_first_image
Образ будет доступен в списке образов
docker images
Выполните запуск контейнера с автоматическим удалением его после завершения, передавая в команду запуска различные значения переменной окружения
USER_NAME
Примеры команды:
docker run --rm -e USER_NAME=Ivan -it my_first_image /bootstrap.sh
docker run --rm -e USER_NAME=Maria -it my_first_image /bootstrap.sh
docker run --rm -e USER_NAME=Petr -it my_first_image /bootstrap.sh
docker run --rm -e USER_NAME=Ekaterina -it my_first_image /bootstrap.sh
Автоматически (посредством файла Dockerfile)
Откройте терминал хостовой машины и создайте рабочий каталог
mkdir pr01
Перейдите в рабочий каталог
cd pr01
Создание файлов
В рабочем каталоге создайте файл
Dockerfile
по следующему шаблону (в файле нужно изменить имя и емэйл разработчика на собственное):
FROM altlinux/base:p10 MAINTAINER Vasya I Pupkin <vasya@pupkin.com> RUN echo '#!/bin/bash' > /bootstrap.sh RUN echo 'echo "Hello, $USER_NAME"' >> /bootstrap.sh RUN chmod +x /bootstrap.sh CMD /bootstrap.sh
В конце этого этапа в рабочем каталоге должен быть один файл:
Dockerfile
Создание образа контейнера
Для создания Docker-образа (image) выполните команду:
docker build -t 'my_second_image:latest' .
Для проверки существования созданного контейнера выполните команду:
docker images
Среди текста ответа должна появиться строчка с новым контейнером:
my_second_image latest add5d00c3dc0 7 seconds ago 72.9MB
Запуск контейнера на базе образа
Запуск контейнеров на базе созданного образа (за исключением имени образа и отсутствием необходимости указывать исполняемый скрипт (он указан непосредственно в Dockerfile)) ни чем не будет отличаться от запуска контейнеров в ходе создания образа вручную:
docker run --rm -e USER_NAME=Ivan -it my_second_image
docker run --rm -e USER_NAME=Maria -it my_second_image
docker run --rm -e USER_NAME=Petr -it my_second_image
docker run --rm -e USER_NAME=Ekaterina -it my_second_image
[Практическая работа №2] Создание контейнера для разработки приложения на языке Java
Откройте терминал хостовой машины и создайте рабочий каталог
mkdir pr02
Перейдите в рабочий каталог
cd pr02
Создание файлов
Скачайте в рабочий каталог JDK версии 19.0.1. Это можно сделать командой (рекомендуется использовать в локальной сети колледжа)
wget https://wiki.nntc.nnov.ru/download/openjdk-19.0.1_linux-x64_bin.tar.gz
или командой (при работе вне локальной сети колледжа)
wget https://download.java.net/java/GA/jdk19.0.1/afdd2e245b014143b62ccb916125e3ce/10/GPL/openjdk-19.0.1_linux-x64_bin.tar.gz
Распакуйте загруженный файл командой
tar -xzpf openjdk-19.0.1_linux-x64_bin.tar.gz
В результате будет доступен каталог
jdk-19.0.1
На этом этапе архив можно удалить командой
rm openjdk-19.0.1_linux-x64_bin.tar.gz
В рабочем каталоге создайте файл
Dockerfile_dev
по следующему шаблону (в файле нужно изменить имя и емэйл разработчика на собственное):
FROM altlinux/base:p10 MAINTAINER Vasya I Pupkin <vasya@pupkin.com> COPY jdk-19.0.1 /opt/
В конце этого этапа в рабочем каталоге должны быть файл:
Dockerfile_dev
и каталог
jdk-19.0.1
Создание образа контейнера
Далее в этом разделе будем исходить из условия, что ваш логин на https://hub.docker.com/ будет
vpupkin
а пароль
ну, вы сами знаете...
! Также стоит помнить, что в эмуляторе терминала находиться нужно в рабочем каталоге !
Для создания Docker-образа (image) выполните команду:
docker build -t 'vpupkin/java_dev:latest' -f Dockerfile_dev .
Для проверки существования созданного образа выполните команду:
docker images
Среди текста ответа должна появиться строчка с новым образом:
vpupkin/java_dev latest fa1a63896356 9 seconds ago 2.42GB
Запуск контейнера на базе образа
mkdir /home/student/pr02/src
На базе полученного образа запустите контейнер, пробросив внутрь контейнера локальный каталог хостовой машины:
docker run -it --mount source=/home/student/pr02/src,target=/root/src,type=bind --name=java_dev --hostname=java-dev vpupkin/java_dev /bin/bash
Также в этой команде запуска задаются: имя контейнера, имя хоста, команда, которую выполнит контейнер при запуске и указаны ключи, которые автоматически подключают терминал к контейнеру.
В случае успешного создания контейнера в эмуляторе терминала приглашение должно смениться на такое:
root@java-dev:/#
Внимание! Сейчас вы внутри контейнера и можете командовать им! Если скомандовать
exit
, то контейнер завершит свою работу и найти и запустить его можно таким образом:
Найти:
docker ps -a
в ответе среди возможных прочих контейнеров должен быть такой:
8e5f4fd0a99b vpupkin/java_dev "/bin/bash" 3 minutes ago Exited (0) 6 seconds ago java_dev
Имя его в данном случае:
java_dev
Идентификатор его в данном случае:
8e5f4fd0a99b
Остальное пока не важно, однако можно догадаться за что отвечают остальные параметры...
Запустить:
docker start java_dev
или:
docker start 8e5f4fd0a99b
Естественно, в конкретном случае идентификатор будет другой.
Подключиться к терминалу:
docker attach java_dev
или
docker attach 8e5f4fd0a99b
Внимание! Сейчас вы внутри контейнера и можете командовать им! Если скомандовать
exit
, то контейнер завершит свою работу придётся опять читать выше по тексту как его запускать...
Однако есть способ отключиться от терминала и не завершить контейнер:
Для этого нужно последовательно нажать сочетания клавиш:
Ctrl + P
затем
Ctrl + Q
После этого приглашение командной строки контейнера должно заменить приглашение хостовой системы.
На этом этапе мы научились создавать образ контейнера и запускать контейнер на его базе.
... Написать про особенности сборки и запуска приложения на Java (TBD) ...
Теперь наша задача - запустить приложение прямо на хостовой машине (но выполняться оно будет в контейнере).
Делаем образ из контейнера с приложением на языке Java
Для того, чтобы запустить получившееся приложение внутри контейнера, но графическую часть его иметь на хостовой машине, нужно запустить еще один контейнер. Однако, из какого образа?
Вероятно, из такого, где оно (приложение на языке Java) присутствует. У нас есть такой образ?
Верно, нет. У нас есть лишь контейнер, который мы получили на базе подготовленного чистого образа.
Но мы можем теперь легко получить образ на базе нашего контейнера с приложением на языке Java. Для этого нужно завершить контейнер и выполнить команду в хостовой систиеме:
docker commit -a Vasya java_dev vpupkin/java_test
Убедиться, что образ создался, можно по прежнему командой:
docker images
А вот теперь уже можно запустить контейнер на базе образа:
vpupkin/java_test
, который будет запускать приложение на Lazarus прямо на хостовой системе. Для этого нужно запустить контейнер такой командой:
docker run --rm -it -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --mount source=/home/user/pr02/src,target=/root/src,type=bind --name=java_test --hostname=java-test vpupkin/java_test /startup.sh
Для успешного запуска графического приложения, работающего в контейнере, с возможностью отображения графического интерфейса, в этой команде сделано две вещи:
Первая: установлена (внутрь контейнера) переменная окружения
DISPLAY
равная значению аналогичной переменной окружения хостовой системы.
Вторая: проброшено устройство
/tmp/.X11-unix
из хостовой системы в контейнер.
Также добавлено монтирование каталога src для обмена файлами межу контейнером и хостовой системой, а также добавлена опция
--rm
которая уничтожает контейнер после его завершения (за данные мы не переживаем, они же лежат локально в каталоге src, который каждый раз монтируется при старте в новый контейнер).
Однако, возможно, не стоит каждый раз содавать контейнер из образа, если изменений в параметрах запуска не требуется?
Достаточно убрать параметр
--rm
из команды запуска контейнера, но следует помнить, что при завершении графического приложения контейнер будет завершён и запускать его уже нужно будет командой старта контейнера (в этом случае контейнер никуда не девается, а просто лежит на хостовой системе в выключенном состоянии).
И включить его можно (т.е. запустить наше java-приложение) так:
docker start java_test
Отвечаем на главный вопрос?
Вопрос звучит так:
Если мы уже разработали приложение, то надо ли конечному пользователю все эти дополнительные инструменты для сборки приложения, которые использовались для создания контейнера с инструментами разработки?
Наверное нет. Они сильно загружают систему при том, что больше никогда не понадобятся пользователю.
Поэтому для конечного пользователя целесообразно создать новый контейнер, исключив оттуда всё лишнее и оставив лишь непосредственно готовое приложение.
Как это сделать -- см. в следующей практической работе.
[Практическая работа №3] Создание контейнера для запуска приложения на Lazarus
Откройте терминал хостовой машины. Если в домашнем каталоге пользователя присутствует каталог
docker
то переместите его в резервную копию командой:
mv docker docker_backup1
затем заново создайте рабочий каталог командой:
mkdir docker
Перейдите в рабочий каталог
cd docker
Создание файлов
В рабочем каталоге создайте файл
Dockerfile_prod
по следующему шаблону (в файле нужно изменить имя и емэйл разработчика на собственное):
FROM ubuntu:20.04
MAINTAINER Vasya I Pupkin <vasya@pupkin.com>
ENV USER ubuntu
ENV HOME /home/$USER
# Install dependencyes
RUN apt-get update \
&& apt-get install -y libgtk2.0-0 \
&& apt-get autoclean \
&& apt-get autoremove \
&& rm -rf /var/lib/apt/lists/*
# Create new user for run app
RUN adduser $USER --disabled-password
# Copy app to user homedir
COPY mypr /home/$USER/
CMD /bin/su -c "/home/ubuntu/mypr" ubuntu
Скопируйте исполняемый файл, полученный в предыдущей работе в рабочий каталог
cp ../docker_backup1/lazarus/project_name/mypr ./
Мы находимся в новом рабочем каталоге хостовой машины:
/home/user/docker
В начале этой работы каталог предыдущей работы мы переместили сюда:
/home/user/docker_backup1
Следовательно, относительно каталога
/home/user/docker
команда копирования исполняемого файла требует подняться на уровень выше
../
и из каталога
docker_backup1
уровнем выше относительно
/home/user/docker
скопировать необходимый файл в текущий каталог
./
В конце этого этапа в рабочем каталоге должно быть два файла:
Dockerfile_prod mypr
Создание образа контейнера
Далее в этом разделе будем исходить из условия, что ваш логин на https://hub.docker.com/ будет
vpupkin
а пароль
ну, вы сами знаете...
! Также стоит помнить, что в эмуляторе терминала находиться нужно в рабочем каталоге !
Для создания Docker-образа (image) выполните команду:
docker build -t 'vpupkin/lazarus_prod:latest' -f Dockerfile_prod .
Для проверки существования созданного контейнера выполните команду:
docker images
Среди текста ответа должна появиться строчка с новым контейнером:
vpupkin/lazarus_prod latest 20bb2900074d 16 seconds ago 217MB
! Обратите внимание на размер контейнера ! Сравните размер контейнера с размером контейнера lazarus_dev из предыдущей работы
Запуск контейнера на базе образа
На базе полученного образа запустите контейнер, пробросив внутрь контейнера локальный каталог хостовой машины и пробросив порт для взаимодействия с графической оболочкой контейнера посредством клиента noVNC:
docker run -it -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --name=lazarus_prod --hostname=lazarus-prod vpupkin/lazarus_prod
При запуске контейнера таким образом не указывается команда, т.к. она задаётся в файле
Dockerfile_prod
строчкой
CMD /bin/su -c "/home/ubuntu/mypr" ubuntu
Результатом запуска контейнера должно стать запущенное внутри контейнера графическое приложение с отображением графического интерфейса на хостовой машине.
При закрытии окна графического приложения контейнер будет завершён и будет доступен среди списка контейнеров
docker ps -a
Повторный запуск уже существующего контейнера можно осуществить по имени контейнера командой:
docker start lazarus_prod
[Практическая работа №4] Взаимодействие двух контейнеров по сети
Задача: Запустить ПО Moodle в контейнере с именем c2, который взаимодействует с базой данных Mariadb, запущенной в контейнере с именем c1
Загрузить образы контейнеров
docker pull mariadb docker pull bitnami/moodle
Создание и подготовка контейнера C1
Создать контейнер с базой данных Mariadb и задать пароль пользователя root через переменную окружения
docker run --name=c1 --hostname=c1 -e MYSQL_ROOT_PASSWORD=123321 --network bridge -d mariadb
Создать временный контейнер с ПО Moodle и запустить его с доступом в командную оболочку
docker run -it --rm --name c2_tmp --network bridge bitnami/moodle:latest /bin/bash
Установить во временный контейнер утилиты проверки состояния сети
apt update apt install net-tools iputils-ping
Изнутри контейнера c2_tmp проверить доступ в базу данных (для этого нужно убедиться в корректности ip адреса контейнера c1):
1. Посмотреть ip адрес конейнера c2_tmp (если контейнеры были запущены последовательно, то адрес контейнера c1 будет на единицу меньше)
ifconfig
2. Выполнить
ping <предполагаемый адрес контейнера c1>
в соседней консоли остановить контейнер c1
docker stop c1
в предыдущей консоли убедиться что пинги прекратились. Вернуться в соседнюю консоль. Запустить контейнер c1
docker start c1
в предыдущей консоли убедиться что пинги возобновились.
3. Выполнить проверку подключения к Mariadb посредством клиента mysql в контейнере c2_tmp
mysql -u root -p<пароль, установленный в переменной окружения при запуске контейнера c1> -h <корректный ip адрес контейнера c1>
4. Создать базу пользователя и базу данных Mariadb для работы Moodle (из консоли mysql, предварительно подключившись к ней под пользователем root)
CREATE DATABASE mdatabase; CREATE USER 'muser'@'%' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON mdatabase.* to 'muser'@'%' WITH GRANT OPTION;
5. Проверить корректность подключения к Mariadb с созданным пользователем к созданной базе данных
mysql -u muser -p123456 -h <корректный ip адрес контейнера c1> mdatabase
6. Выйти из временного контейнера c2_tmp
exit
Запуск контейнера C2 с ПО Moodle
Поскольку в предыдущем пункте были подготовлены параметры доступа в базу данных Mariadb, используем их для запуска контейнера с ПО Moodle
docker run -d --name c2 -p 8080:8080 -p 8443:8443 --env ALLOW_EMPTY_PASSWORD=no --env MOODLE_DATABASE_USER=muser --env MOODLE_DATABASE_PASSWORD=123456 --env MOODLE_DATABASE_NAME=mdatabase --env MOODLE_DATABASE_HOST=<корректный ip адрес контейнера c1> --env MOODLE_USERNAME=user --env MOODLE_PASSWORD=123321 --env MOODLE_EMAIL=user@host.com --env MOODLE_SITE_NAME=user_moodle --network bridge bitnami/moodle:latest
Проверка: Открыть в браузере адрес:
http://localhost:8080
Ввести логин и пароль от ПО Moodle, указанные ранее в переменных окружения при старте контейнера.
Подробное описание по контейнеру: https://hub.docker.com/r/bitnami/moodle
Важно! Первые несколько минут ПО Moodle не будет доступно по указанному адресу http://localhost:8080 т.к. будет выполняться его первое развёртывание.
Проследить процесс развёртывания можно внутри базы данных в контейнере c1, подключившись к ней с хостовой машины
mysql -u muser -p123456 -h <корректный ip адрес контейнера c1> mdatabase
и из консоли mysql проверить наличие таблиц в базе данных
show tables
Самостоятельное задание
Используя справку по утилите docker запустить два аналогичных контейнера, установив статические ip адреса для них.
[Практическая работа №5] Взаимодействие двух контейнеров по сети
Создайте рабочий каталог и перейдите в него
mkdir composemoodle cd composemoodle
Создайте файл
docker-compose.yml
со следующим содержимым
version: "2.2"
services:
mariadb:
image: "mariadb:latest"
environment:
- MYSQL_ROOT_PASSWORD=123321
- MYSQL_ALLOW_EMPTY_PASSWORD=no
- MYSQL_DATABASE=mdatabase
- MYSQL_USER=muser
- MYSQL_PASSWORD=123456
moodle:
ports:
- "8080:8080"
- "8443:8443"
image: "bitnami/moodle:latest"
environment:
- ALLOW_EMPTY_PASSWORD=no
- MOODLE_DATABASE_USER=muser
- MOODLE_DATABASE_PASSWORD=123456
- MOODLE_DATABASE_NAME=mdatabase
- MOODLE_DATABASE_HOST=mariadb
- MOODLE_USERNAME=user
- MOODLE_PASSWORD=123321
- MOODLE_EMAIL=user@host.com
- MOODLE_SITE_NAME=user_moodle
В результате в рабочем каталоге должен быть файл:
docker-compose.yml
В рабочем каталоге выполнить команду для запуска проекта
docker-compose up
Проблемы под Windows
В этом разделе описаны возможные проблемы при использовании Docker и Docker-compose в Windows в случае если до этого была нормальная и понятная работа в системах GNU/Linux или MacOSx, а теперь по каким-то причинам потребовалось работать с Docker из Windows...
Как запускать под виндой синтаксический сахар, если он у вас есть в формате bash скриптов
Поставить GIT отсюда https://git-scm.com (он все равно будет нужен)
Вместе с ним поставится Git Bash, которому будет передавать управление Power Shell, если из него (из Power Shell) запускать исполняемые *.sh файлы с шебангом:
#!/bin/bash
/bin/bash^M: bad interpreter: No such file or directory
Решение описано здесь: https://forums.docker.com/t/error-while-running-docker-code-in-powershell/34059/5
Кратко:
Шаг 1
удалить репозиторий
Шаг 2
Настроить git командой
git config --global core.autocrlf input
Шаг 3
склонировать заново и попробовать ещё раз
Но есть вероятность что винда не поймёт эту глобальную настройку, если командовать из PowerShell. Поэтому сразу железобетонный вариант -- клонировать с указанием ключа, например:
git clone -o core.autocrlf=input https://ну_и_тут_путь_к_репозиторию
Кеширование образов контейнеров виндой
Вроде бы полностью удален и контейнер и образ, однако, при повторном создании контейнера и докер-файла в консоли видно что он поднимается из кеша и не пересобирается как нужно.
Решение - отключить кеширование. Для этого нужно создать пустой файл
%APPDATA%\Docker\disable-filesystem-caching
Источник: https://github.com/docker/for-win/issues/5530
Возможно, способ с созданием файла поможет после перезагрузки ОС.
Если способ не помогает, то можно попробовать остановить Docker (пкм на иконке Docker Desktop в трее), затем перейти в каталог
%APPDATA%\
и удалить там оба каталога, имя которых начинается на
Docker
Затем запустить Docker Desktop тыком в ярлык
NVIDIA IN DOCKER
https://nvidia.github.io/nvidia-container-runtime/
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/user-guide.html
Backup and Restore docker volumes
Backup
Допустим, у нас был запущен контейнер с локальным volume такой командой:
docker run -v /dbdata --name dbstore ubuntu /bin/bash
/dbdata
здесь это указание на то, что внутри контейнера в каталоге /dbdata будут находиться данные, которые docker будет физически хранить в одном из volumes. Эти данные мы и будем резервировать.
Общая суть заключается в том, что мы забрасываем все volumes из определённого контейнера (в данном случае имя контейнера -- dbstore) в новый промежуточный контейнер (как можно заметить, он запускается с ключом самоуничтожения --rm), который, в свою очередь, монтирует текущий каталог пользователя (вне контейнера, на хосте, который управляет контейнерами) в каталог /backup (это уже внутри контейнера, который временно запускается). Затем происходит процедура создания архива tar из содержимого /dbdata внутри контейнера. Таким образом сам контейнер уничтожается, но в рабочем каталоге пользователя на хост-машине остаётся файл резервной копии backup.tar
docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
Restore
Допустим у нас есть бэкап, сделанный в предыдущем пункте и он у нас лежит в текущем каталоге и называется backup.tar
Теперь нам нужно этот бэкап распаковать в определённый каталог внутри контейнера. На текущем этапе нам без разницы: каталог назначения (куда мы будем распаковывать архив backup.tar) находится на volume или это маппинг каталога в каталог хостовой системы без использования volume -- смотрим на этот каталог назначения как на обычный каталог дерева внутри контейнера. При необходимости можно воспользоваться опцией
--volumes-from
при старте контейнера, чтобы "подкинуть" в этот контейнер volume из другого контейнера. Всё зависит от задачи.
И так, мы собираемся распаковать backup.tar в каталог /dbdata нового контейнера. Для этого примерная команда будет выглядеть так:
docker run -v $(pwd):/backup ubuntu tar xvf /backup/backup.tar /dbdata
Если предполагается, что контейнер, из которого даётся команда для распаковки, временный и его задача на время зацепить volume из другого контейнера (в примере этот контейнер называется dbstorecopy), то есть смысл использовать ключ самоуничтожения контейнера (--rm) и зацепить из другого контейнера volume опцией --volumes-from dbstorecopy. Тогда команда будет такой:
docker run --rm --volumes-from dbstorecopy -v $(pwd):/backup ubuntu tar xvf /backup/backup.tar /dbdata
Перемещение данных между двумя контейнерами
Кейс для 12.12.2022
# [1] stop two containers docker stop nntc_de_mobd_c1_1 nntc_de_mobd_c2_1 # [2] make dir for backups mkdir /root/containers/nntc-jupyter/backup # [3] backup dir `/opt/notebooks` from nntc_de_mobd_c1_1 to /root/containers/nntc-jupyter/backup/q.tar docker run --rm --volumes-from nntc_de_mobd_c1_1 -v /root/containers/nntc-jupyter/backup:/backup --workdir /opt/notebooks ubuntu tar -cpf /backup/q.tar . # [4] restore dir `/opt/notebooks` in nntc_de_mobd_c2_1 from /root/containers/nntc-jupyter/backup/q.tar docker run --rm --volumes-from nntc_de_mobd_c2_1 -v /root/containers/nntc-jupyter/backup:/backup --workdir /opt/notebooks ubuntu tar -xpf /backup/q.tar # [5] start two containers docker start nntc_de_mobd_c1_1 nntc_de_mobd_c2_1
