Вопрос: Как я могу создать резервную копию контейнера Docker с его объемами данных?
Я использовал этот Docker-образ тутум / WordPress для демонстрации веб-сайта WordPress. Недавно я узнал, что образ использует тома для MySQL-данных.
Поэтому проблема заключается в следующем: если я хочу создать резервную копию и восстановить контейнер, я могу попытаться зафиксировать изображение, а затем удалить контейнер и создать новый контейнер из зафиксированного изображения. Но если я сделаю это, то объем удаляется, и все мои данные исчезнут.
Должен быть какой-то простой способ резервного копирования моего контейнера и его объемных данных, но я не могу его найти нигде.
72
2017-10-13 01:09
источник<\p>
Ответы:
Как объясняет руководство пользователя docker, объемы данных предназначены для сохранения данных вне файловой системы контейнера. Это также облегчает обмен данными между несколькими контейнерами.
Хотя Docker никогда не удалит данные в томах (если вы не удалите связанный контейнер с docker rm -v), томы, на которые не ссылается какой-либо контейнер докера, называются болтающиеся объемы , Те болтающиеся объемы трудно избавиться от них и получить доступ к ним.
Это означает, что, как только последний контейнер с использованием тома будет удален, объем данных становится свисающим, а его содержимое трудно справиться.
Чтобы предотвратить эти оборванные тома, трюк заключается в создании дополнительного контейнера докера, использующего объем данных, который вы хотите сохранить; так что всегда будет, по крайней мере, контейнер докеров, ссылающийся на объем. Таким образом вы можете удалить контейнер докеров, на котором запущено приложение WordPress, без потери удобства доступа к содержимому этого объема данных.
Такие контейнеры называются контейнеры объема данных ,
резервные копии докеров
Для резервного копирования изображений докеров используйте сохранить докер команда, которая будет создавать tar-архив, который позднее можно будет использовать для создания нового изображения докеры с помощью докерная нагрузка команда.
резервные контейнеры докеров
Вы можете сделать резервную копию контейнера докеров различными способами
- путем создания нового изображения докеров на основе текущего состояния контейнера докера, используя фиксация докеров команда
- путем экспорта файловой системы контейнера докеров в качестве tar-архива, используя экспорт докеров команда. Позднее вы можете создать новое изображение докеры из этого tar-архива с помощью импорт докеров команда.
Имейте в виду, что эти команды будут выполнять только резервное копирование файловой системы на уровне докеров. Это исключает объемы данных ,
резервные копии данных докеров
Чтобы создать резервную копию тома данных, вы можете запустить новый контейнер с помощью тома, который вы хотите создать, и выполнить команду tar, чтобы создать архив тома, как описано в руководство пользователя docker ,
В вашем конкретном случае объем данных используется для хранения данных для сервера MySQL. Поэтому, если вы хотите экспортировать tar-архив для этого тома, вам нужно сначала остановить сервер MySQL. Для этого вам придется остановить контейнер wordpress.
резервное копирование данных MySQL
Другой способ – дистанционное подключение к серверу MySQL для создания дампа базы данных с помощью туздЫшпр команда. Однако для того, чтобы это сработало, ваш сервер MySQL должен быть настроен для приема удаленных подключений, а также иметь пользователя, которому разрешено удаленно подключаться. Это может быть не так с изображением докеры WordPress, которое вы используете.
редактировать
Докер недавно представил Плагины объема докеров которые позволяют делегировать обработку томов плагинам, реализованным поставщиками.
docker run команда имеет новое поведение для -v вариант. Теперь можно передать его имя тома , Объемы, созданные таким образом, названный и с легкостью ссылаться позже, ослабляя проблемы с помощью болтающиеся объемы ,
Изменить 2
Докер представил docker volume prune чтобы удалить все оборванные тома.
81
2017-10-13 12:18
ОБНОВЛЕНИЕ 2
Сырой сценарий резервного копирования одного тома:
#!/bin/bash
# This script allows you to backup a single volume from a container
# Data in given volume is saved in the current directory in a tar archive.
CONTAINER_NAME=$1
VOLUME_NAME=$2 usage() { echo “Usage: $0 [container name] [volume name]” exit 1
} if [ -z $CONTAINER_NAME ]
then echo “Error: missing container name parameter.” usage
fi if [ -z $VOLUME_NAME ]
then echo “Error: missing volume name parameter.” usage
fi sudo docker run -rm –volumes-from $CONTAINER_NAME -v $(pwd):/backup busybox tar cvf /backup/backup.tar $VOLUME_NAME
Исходный сценарий восстановления единого тома:
#!/bin/bash
# This script allows you to restore a single volume from a container
# Data in restored in volume with same backupped path
NEW_CONTAINER_NAME=$1 usage() { echo “Usage: $0 [container name]” exit 1
} if [ -z $NEW_CONTAINER_NAME ]
then echo “Error: missing container name parameter.” usage
fi sudo docker run -rm –volumes-from $NEW_CONTAINER_NAME -v $(pwd):/backup busybox tar xvf /backup/backup.tar
Использование может быть следующим:
$ volume_backup.sh old_container /srv/www
$ sudo docker stop old_container && sudo docker rm old_container
$ sudo docker run -d –name new_container myrepo/new_container
$ volume_restore.sh new_container
Предположения: резервный файл называется backup.tar, он находится в том же каталоге, что и сценарий резервного копирования и восстановления, имя тома между контейнерами одинаково.
ОБНОВИТЬ
Мне кажется, что резервное копирование томов из контейнеров не отличается от резервного копирования томов из контейнеров данных.
Объемы – это не что иное, как пути, связанные с контейнером, поэтому процесс тот же.
Я не знаю, работает ли резервное копирование докеров для одинаковых объемов контейнеров, но вы можете использовать:
sudo docker run -rm –volumes-from yourcontainer -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data
а также:
sudo docker run -rm –volumes-from yournewcontainer -v $(pwd):/backup busybox tar xvf /backup/backup.tar
END UPDATE
Доступен этот хороший инструмент, который позволяет создавать резервные копии и восстанавливать контейнеры тонов докеров:
https://github.com/discordianfish/docker-backup
если у вас есть контейнер, связанный с некоторыми контейнерами, например:
$ docker run –volumes-from=my-data-container –name my-server …
вы можете сделать резервную копию всех томов следующим образом:
$ docker-backup store my-server-backup.tar my-server
и восстановите вот так:
$ docker-backup restore my-server-backup.tar
Или вы можете следовать официальному пути:
Как переносить объемы данных только с одного хоста на другой?
19
2017-10-13 12:19
Если вам нужна только резервная копия смонтированных томов, вы можете просто скопировать папки из своего Dockerhost ,
На Ubuntu
Здесь вы можете найти все папки с томами: /var/lib/docker/volumes/ поэтому вы можете копировать их и архивировать там, где хотите.
На MAC
Это не так просто, как на Ubuntu. Вам нужно скопировать файлы с виртуальной машины.
Ниже приведен сценарий копирования всех папок с томами с виртуальной машины (где работает сервер Docker) на ваш локальный компьютер. Предположим, что ваша виртуальная машина-докер-машина по умолчанию ,
docker-machine ssh default sudo cp -v -R /var/lib/docker/volumes/ /home/docker/volumes docker-machine ssh default sudo chmod -R 777 /home/docker/volumes docker-machine scp -R default:/home/docker/volumes ./backup_volumes docker-machine ssh default sudo rm -r /home/docker/volumes
Он собирается создать папку ./backup_volumes в вашем текущем каталоге и скопировать все тома в эту папку.
Вот сценарий копирования всех сохраненных томов из вашего локального каталога ( ./backup_volumes ) к машине Dockerhost
docker-machine scp -r ./backup_volumes default:/home/docker docker-machine ssh default sudo mv -f /home/docker/backup_volumes /home/docker/volumes docker-machine ssh default sudo chmod -R 777 /home/docker/volumes docker-machine ssh default sudo cp -v -R /home/docker/volumes /var/lib/docker/ docker-machine ssh default sudo rm -r /home/docker/volumes
Теперь вы можете проверить, работает ли это:
docker volume ls
10
2018-03-10 14:55
Я знаю, что это старо, но я понимаю, что не существует хорошо документированного решения для толкания контейнера данных (как резервного) в концентратор докеров. Я только что опубликовал короткий пример о том, как это делается при https://dzone.com/articles/docker-backup-your-data-volumes-to-docker-hub
Ниже приводится нижняя строка
Учебное пособие докеров предлагает вам возможность локального резервного копирования и восстановления данных. Мы собираемся использовать эту технику, добавим еще несколько строк, чтобы эта резервная копия была перенесена в концентратор докеров для легкой будущей реставрации в любом месте, которое мы желаем. Итак, давайте начнем. Это следующие шаги:
Резервное копирование объема данных из контейнера данных с именем data-container-to-backup
docker run –rm –volumes-from data-container-backup –name tmp-backup -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /folderToBackup
Разверните этот tar-файл в новый контейнер, чтобы мы могли зафиксировать его как часть его изображения
docker run -d -v $(pwd):/backup –name data-backup ubuntu /bin/sh -c “cd / && tar xvf /backup/backup.tar”
Зафиксируйте и нажмите изображение с нужным тегом ($ VERSION)
docker commit data-backup repo/data-backup:$VERSION
docker push repo/data-backup:$VERSION
Наконец, позволяет очистить
docker rm data-backup
docker rmi $(docker images -f “dangling=true” -q)
Теперь у нас есть образ с именем data-backup в нашем репо, который представляет собой просто файловую систему с резервными файлами и папками. Чтобы использовать это изображение (aka restore from backup), мы делаем следующее:
Запустите контейнер данных с резервным копированием данных
run -v /folderToBackup –entrypoint “bin/sh” –name data-container repo/data-backup:${VERSION}
Запустите ваше изображение WhatEver с томами из Data-Conainter
docker run –volumes-from=data-container repo/whatEver
Это оно.
Я был удивлен, что нет документации для этой работы. Надеюсь, кто-то найдет это полезным. Я знаю, что мне потребовалось некоторое время, чтобы подумать об этом.
6
2017-12-22 09:31
Скажем, ваше имя тома data_volume, Вы можете использовать следующие команды для резервного копирования и восстановления тома на и с изображения докеры с именем data_image:
Для резервного копирования:
docker run –rm –mount source=data_volume,destination=/data alpine tar -c -f- data | docker run -i –name data_container alpine tar -x -f-
docker container commit data_container data_image
docker rm data_container
Восстановить:
docker run –rm data_image tar -c -f- data | docker run -i –rm –mount source=data_volume,destination=/data alpine tar -x -f-
6
2018-01-05 11:45
Следующая команда запускает tar в контейнере с установленными всеми указанными томами данных и перенаправляет вывод в файл:
docker run –rm `docker volume list -q | egrep -v '^.{64}$' | awk '{print “-v ” $1 “:/mnt/” $1}'` alpine tar -C /mnt -cj . > data-volumes.tar.bz2
Обязательно проверьте полученный архив на случай, если что-то пойдет не так:
tar -tjf data-volumes.tar.bz2
2
2017-10-31 20:14
Я создал инструмент для организации и запуска резервного копирования данных и контейнеров mysql, которые просто называются Докер резервного копирования , Существует даже готовое к использованию изображение на докере-хабе ,
Это в основном написано в Bash, поскольку это в основном оркестровка. Оно использует duplicity для реального механизма резервного копирования. Вы можете в настоящее время выполнять резервное копирование на FTP (S) и Amazon S3.
Конфигурация довольно проста: напишите файл конфигурации в YAML, описывая, что делать с резервным копированием, и где, и здесь вы идете!
Для контейнеров данных он автоматически монтирует тома, разделяемые вашим контейнером, для резервного копирования и обработки. Для контейнеров mysql они связывают их и запускают mysqldump в комплекте с вашим контейнером и обрабатывают результат.
Я написал это, потому что я использую Docker-Cloud, который не обновляется с недавними версиями док-двигателей, и потому, что я хотел использовать способ Docker, не включая какой-либо процесс резервного копирования внутри контейнеров приложений.
2
2018-04-25 07:52
Источник: http://programmerz.ru/questions/4302/how-can-i-backup-a-docker-container-with-its-data-volumes-question
Простое резервное копирование, восстановление и миграция контейнеров в Docker
Сегодня мы узнаем, как мы можем легко создавать резервные копии, восстанавливать и переносить контейнеры докеров из коробки.
Докер это платформа с открытым исходным кодом, которая автоматизирует развертывание приложений с быстрым и легким способом упаковки, отправки и запуска его под легким слоем программного обеспечения, называемого контейнером.
Это делает платформу приложений независимой, поскольку она выполняет дополнительный уровень абстракции и автоматизации виртуализации уровня операционной системы в Linux. Он использует функции выделения ресурсов ядра Linux с его составными группами и пространством имен, чтобы избежать накладных расходов на виртуальные машины.
Это делает большие строительные блоки для развертывания и масштабирования веб-приложений, баз данных и внутренних служб, не зависящих от конкретного стека или провайдера. Контейнеры – это те программные уровни, которые создаются из образа докера, который содержит соответствующую файловую систему Linux и приложения из коробки.
Если у нас есть контейнер-докер, который работает в нашем ящике, и вам необходимо сделать резервную копию этих контейнеров для будущего использования или захотеть перенести эти контейнеры, то этот учебник поможет вам в том, как мы можем создавать резервные копии, восстанавливать и переносить контейнеры докеров в операционную систему Linux.
Вот несколько простых шагов по тому, как мы можем создавать резервные копии, восстанавливать и переносить контейнеры докеров в Linux.
1. Резервное копирование контейнеров
Прежде всего, чтобы сделать резервную копию контейнеров в докере, мы хотим увидеть список контейнеров, которые мы хотим сделать. Для этого нам нужно запустить docker ps в нашей Linux-машине, работающей с механизмом докеров, с уже созданными контейнерами.
После этого мы выберем контейнеры, которые хотим создать, а затем создадим моментальный снимок контейнера. Мы можем использовать команду фиксации докеров для создания моментального снимка.
Это создаст моментальный снимок контейнера в качестве изображения докеров. Мы можем увидеть изображение докера, запустив изображения докеры команд, как показано ниже.
Как мы видим, снимок, который был взят выше, был сохранен как изображение докеров. Теперь, чтобы сделать резервную копию этого моментального снимка, у нас есть два варианта: один из них – это то, что мы можем войти в концентратор реестра докеров и нажать изображение, а следующее – сделать резервную копию изображения докеров в качестве tarball для дальнейшего использования.
Если мы хотим загрузить или создать резервную копию изображения в центр регистрации докеров, мы можем просто запустить команду входа в docker для входа в концентратор реестра докеров, а затем нажать требуемое изображение.
Если мы не хотим делать резервную копию в концентраторе реестра докеров и хотим сохранить изображение для будущего использования на машине локально, мы можем сделать резервную копию изображения в виде архивов. Для этого нам нужно запустить следующую команду сохранения докеров.
Чтобы проверить, был ли tarball создан или нет, мы можем просто запустить докер внутри каталога, где мы сохранили tarball.
2. Восстановление контейнеров
Затем, после того как мы успешно выполним резервное копирование наших контейнеров-докеров, мы теперь перейдем к восстановлению тех contianers, которые были сняты как изображения докеров. Если мы переместили эти файлы докеров в центр реестра, мы можем просто вытащить это изображение докеры и запустить его из коробки.
Но если мы сохранили эти файлы докеров в локальном виде в качестве файла tarball, тогда мы сможем легко загрузить это изображение докеров, используя команду загрузки докеров, а затем резервный архив.
Теперь, чтобы гарантировать, что эти изображения докеров загружены успешно, мы запустим команду docker images.
После того, как изображения будут загружены, мы запустим контейнер докера из загруженного изображения.
3. Миграция контейнеров Docker
Миграция контейнеров включает в себя как вышеупомянутый процесс, т. Е. Резервное копирование и восстановление. Мы можем перенести любой контейнер докеров с одной машины на другую. В процессе миграции сначала берем резервную копию контейнера в качестве снимка док-станции.
Затем это изображение докеры либо помещается в концентратор реестра докеров, либо сохраняется как файлы tarball в локальном режиме. Если мы переместили изображение в концентратор реестра докеры, мы сможем легко восстановить и запустить контейнер с помощью команды запуска docker с любой машины, которую мы хотим.
Но если мы сохранили изображение как tarballs локально, мы можем просто скопировать или переместить изображение на машину, где мы хотим загрузить изображение и запустить требуемый контейнер.
Заключение
Наконец, мы узнали, как мы можем создавать резервные копии, восстанавливать и переносить контейнеры докеров из коробки. Этот учебник точно такой же для каждой платформы операционной системы, где докер работает успешно. Действительно, докер – довольно простой и простой в использовании, но очень мощный инструмент. Он довольно легко запоминает команды, которые достаточно коротки, с множеством простых, но мощных флагов и параметров. Вышеупомянутые методы позволяют нам сохранять резервные копии наших контейнеров, чтобы мы могли их восстановить в будущем. Это может помочь нам восстановить наши контейнеры и изображения, даже если наша хост-система выйдет из строя или будет уничтожена случайно. Если у вас есть какие-либо вопросы, предложения, отзывы, пожалуйста, напишите их в поле ниже, чтобы мы могли улучшить или обновить наше содержимое. Спасибо ! Наслаждайтесь
Источник: https://websetnet.net/ru/easy-backup-restore-and-migrate-containers-in-docker/
Percona Server и Percona XtraBackup в docker-контейнере
Со стремительным ростом популярности docker-контейнеров уже никого не удивить, например, запуском Percona Server в docker’е. Однако на просторах Интернета не так уж много подробных инструкций о том, как делать резервные копии (и восстанавливаться из них), если ваш MySQL-сервер запущен в docker-контейнере.
Давайте разберемся с запуском Percona Server в docker’е и рассмотрим вариант создания бекапов с помощью утилиты Percona XtraBackup!
Итак, нам понадобятся два docker-контейнера — один непосредственно для MySQL-сервера, второй — для создания резервных копий. В качестве MySQL-сервера будем использовать Percona Server 5.7, контейнеры будем собирать самостоятельно — это несложно.
Создадим каталог, в котором будет находиться все необходимое для основного контейнера (назовем его percona):
mkdir /percona
В данном каталоге у нас будут находится инструкции по сборке контейнера (Dockerfile), конфигурационный файл для MySQL-сервера (my.cnf), файл docker-compose.yml для запуска контейнера (не люблю вводить длиннющие команды вида docker run …) и файл с переменными окружения, которые будут использоваться при запуске контейнера (.env).
Давайте рассмотрим содержимое данных файлов, Dockerfile выглядит так:
FROM percona:5.7 RUN chown -R mysql:mysql /var/lib/mysql/ ADD my.cnf /etc/mysql/conf.d/my.cnf CMD [“mysqld”] EXPOSE 3306
Содержимое файла с настройками MySQL-сервера в моем случае такое (разумеется, для вашего случая подберите эти параметры индивидуально):
[client]
socket = /var/run/mysqld/mysqld.sock [mysqld]
socket = /var/run/mysqld/mysqld.sock
pid-file = /var/run/mysqld/mysqld.pid
user = mysql
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /var/lib/mysql-tmp
sql-mode = “STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”
sysdate-is-now = 0
transaction-isolation = REPEATABLE-READ
default-storage-engine = InnoDB
event-scheduler = OFF
performance_schema = 0
collation-server = utf8_general_ci
character-set-server = utf8 ### Percona specific general options
expand_fast_index_creation = OFF
userstat = OFF
thread_statistics = OFF ### Connectivity options
port = 3306
max_user_connections = 400
secure-auth = ON
back_log = 2048
skip-name-resolve = 0
max_connect_errors = 1000000
read_only = OFF
bind-address = ::
max_allowed_packet = 16777216
wait_timeout = 14400
max_connections = 500
thread_cache_size = 64
net_write_timeout = 60
net_read_timeout = 30
safe-user-create = 1
interactive_timeout = 14400 ### General caches
key_buffer_size = 16777216
query_cache_size = 0
tmp_table_size = 16777216
max_heap_table_size = 16777216
table_open_cache = 8192
query_cache_type = 0 ### InnoDB options
innodb_buffer_pool_size = 512M
innodb_open_files = 1024
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_read_io_threads = 4
innodb_file_format = Barracuda
innodb_old_blocks_time = 1000
innodb_autoinc_lock_mode = 2
innodb_io_capacity = 200
innodb_log_buffer_size = 8M
innodb_stats_on_metadata = OFF
innodb_thread_concurrency = 0
innodb_support_xa = ON
innodb_buffer_pool_instances = 1
innodb_concurrency_tickets = 10000
innodb_write_io_threads = 4
innodb = force
innodb_file_per_table = ON
innodb_flush_log_at_trx_commit = 2 ### Logging options
general_log_file = /var/log/mysql/mysql_general.log
log-error = /var/log/mysql/mysql_error.log
slow_query_log_file = /var/log/mysql/mysql_slow.log
log-warnings = 1
log-queries-not-using-indexes = ON
long_query_time = 2
log-slow-admin-statements = 1
log-slow-slave-statements = 1
general-log = OFF
slow-query-log = ON ### Percona specific logging options
log_slow_rate_type = session
slow_query_log_use_global_control = log_slow_filter,log_slow_rate_limit,log_slow_verbosity,long_query_time,min_examined_row_limit
log_slow_sp_statements = ON
log_slow_filter = ''
log_slow_verbosity = microtime,query_plan
log_slow_rate_limit = 1
slow_query_log_always_write_time = 10 [mysqld_safe]
log-error = /var/log/mysql/mysql_error.log
Файл с переменными окружения может выглядеть, например, так:
### Data Path for all storage systems.
DATA_SAVE_PATH=/srv
### Percona ############################################################################################################
PERCONA_DATABASE=test_db
PERCONA_USER=testuser
PERCONA_PASSWORD=testpassword
PERCONA_PORT=3306
PERCONA_ROOT_PASSWORD=rootpassword
И, наконец, docker-compose.yml содержит такие строки:
version: '2'
services:
### Percona Container ######################################## percona: container_name: percona image: my-percona-test:latest environment: – MYSQL_DATABASE=${PERCONA_DATABASE} – MYSQL_USER=${PERCONA_USER} – MYSQL_PASSWORD=${PERCONA_PASSWORD} – MYSQL_ROOT_PASSWORD=${PERCONA_ROOT_PASSWORD} volumes: – ${DATA_SAVE_PATH}/percona:/var/lib/mysql ports: – “${PERCONA_PORT}:3306”
Для сборки образа, находясь в каталоге /percona, запускаем команду:
docker build -t my-percona-test:latest .
После успешной сборки контейнер можно запустить командой:
docker-compose up -d
Приступим к второму docker-контейнеру, с помощью которого мы будем делать резервные копии и восстанавливаться из них. Создадим каталог для него (назовем его xtrabackup):
mkdir /xtrabackup
В данном каталоге у нас будут находиться инструкции по сборке контейнера (Dockerfile) и два скрипта — один для создания бекапа (make_backup.sh), второй для восстановления данных (make_backup.sh).
Содержимое Dockerfile следующее:
FROM percona:5.7 RUN apt-get update && apt-get install -y –no-install-suggests pigz percona-xtrabackup-24 && rm -rf /var/lib/apt/lists/* RUN mkdir -p /backups ADD make_backup.sh /make_backup.sh
ADD restore_backup.sh /restore_backup.sh VOLUME [“/backups”]
Содержимое скрипта создания бекапа:
BACKUP=”/usr/bin/innobackupex”
workdir=”/backups/”
OPTIONS=”–host=percona –port=3306 –user=root –password=rootpassword”
dump=”mysql.tar” # при распаковке использовать ключ -i, например tar -ixvf backup.tar
$BACKUP $OPTIONS –stream=tar ./ | pigz -p 5 > ${workdir}${dump}.gz
Скрипт для восстановления данных из резервной копии выглядит так:
backupdir=”/backups/”
archive=”mysql.tar.gz”
mysqldir=”/var/lib/mysql/” cd $mysqldir && rm -rf *
cd $backupdir && tar -ixvf $archive -C $mysqldir
cd $mysqldir && innobackupex –apply-log –ibbackup=xtrabackup ./
chown -R 999:999 $mysqldir
Собираем контейнер (находясь в каталоге с Dokerfile) командой:
docker build -t my-xtrabackup:latest .
После всех проделанных действий для создания резерной копии баз данных достаточно запустить следующую команду:
docker run -it –net=docker_default –link percona:percona –name=xtrabackup -v /srv/percona:/var/lib/mysql -v /srv/backups:/backups –rm my-xtrabackup:latest sh -c 'exec /make_backup.sh'
Даная команда запускает контейнер из собранного нами образа (my-xtrabackup:latest), присваивает ему имя xtrabackup, назначает ему такую же локальную сеть, как и в запущенного ранее контейнера с Percona Server, связывает контейнеры с помощью опции –link, пробрасывает внутрь контейнера каталоги /srv/percona и /srv/backups с хост-машины (в одном находятся БД, второй используется для хранения бекапов) и выполняет скрипт make_backup.sh. После после выполнения скрипта (когда бекап будет создан) контейнер будет удален, благодаря использованию опции –rm.
Чтобы восстановить данные из резервной копии, следует использовать такую команду (контейнер с Percona Server должен быть выключен во избежание возможных конфликтов):
docker run -it –name=xtrabackup -v /srv/percona:/var/lib/mysql -v /srv/backups:/backups –rm my-xtrabackup:latest sh -c 'exec /restore_backup.sh'
Данная команда очень похожа на предыдущую, разница лишь в выполняемом скрипте и в отсутствии параметров –net=docker_default –link percona:percona — они нам не нужны, так как контейнер с MySQL-сервером выключен.
Источник: https://letsclearitup.com.ua/mysql/percona-server-i-percona-xtrabackup-v-docker-konteynere.html
Как я могу инициализировать базу данных MySQL с помощью схемы в контейнере Docker?
Прошу прощения за этот длинный ответ, но у вас есть небольшой путь, чтобы добраться туда, где вы хотите.
Я скажу, что, как правило, вы не ставили бы хранилище для базы данных в том же контейнере, что и сама база данных, вы бы либо монтировали том хоста, чтобы данные сохранялись на хосте docker, либо, возможно, контейнер мог использоваться для удерживайте данные (/ var / lib / mysql). Кроме того, я новичок в mysql, поэтому это может быть не очень эффективно. Тем не менее …
Я думаю, здесь может быть несколько проблем. Файл Docker используется для создания изображения. Вам нужно выполнить шаг сборки. Как минимум, из каталога, содержащего Dockerfile, вы сделаете что-то вроде:
docker build .
Dockerfile описывает созданное изображение. Я не очень разбираюсь в mysql (я фанат постов), но я сделал поиск по интерведам для «как инициализировать контейнер для докеров mysql». Сначала я создал новый каталог для работы, я назвал его mdir, а затем создал каталог файлов, в который я записал файл epcis_schema.sql, который создает базу данных и одну таблицу:
create database test;
use test; CREATE TABLE testtab
(
id INTEGER AUTO_INCREMENT,
name TEXT,
PRIMARY KEY (id)
) COMMENT='this is my test table';
Затем я создал скрипт под названием init_db в каталоге файлов:
#!/bin/bash # Initialize MySQL database.
# ADD this file into the container via Dockerfile.
# Assuming you specify a VOLUME [“/var/lib/mysql”] or '-v /var/lib/mysql' on the 'docker run' command…
# Once built, do e.g. 'docker run your_image /path/to/docker-mysql-initialize.sh'
# Again, make sure MySQL is persisting data outside the container for this to have any effect. set -e
set -x mysql_install_db # Start the MySQL daemon in the background.
/usr/sbin/mysqld &
mysql_pid=$! until mysqladmin ping >/dev/null 2>&1; do echo -n “.”; sleep 0.2
done # Permit root login without password from outside container.
mysql -e “GRANT ALL ON *.* TO [email protected]'%' IDENTIFIED BY '' WITH GRANT OPTION” # create the default database from the ADDed file.
mysql < /tmp/epcis_schema.sql # Tell the MySQL daemon to shutdown.
mysqladmin shutdown # Wait for the MySQL daemon to exit.
wait $mysql_pid # create a tar file with the database as it currently exists
tar czvf default_mysql.tar.gz /var/lib/mysql # the tarfile contains the initialized state of the database.
# when the container is started, if the database is empty (/var/lib/mysql)
# then it is unpacked from default_mysql.tar.gz from
# the ENTRYPOINT /tmp/run_db script
(большая часть этого скрипта была снята здесь: Ссылка )
Вот созданный файл / run_db:
# start db set -e
set -x # first, if the /var/lib/mysql directory is empty, unpack it from our predefined db
[ “$(ls -A /var/lib/mysql)” ] && echo “Running with existing database in /var/lib/mysql” || ( echo 'Populate initial db'; tar xpzvf default_mysql.tar.gz ) /usr/sbin/mysqld
Наконец, файл Dockerfile для их привязки:
FROM mysql
MAINTAINER (me) # Copy the database schema to the /data directory
ADD files/run_db files/init_db files/epcis_schema.sql /tmp/ # init_db will create the default
# database from epcis_schema.sql, then
# stop mysqld, and finally copy the /var/lib/mysql directory
# to default_mysql_db.tar.gz
RUN /tmp/init_db # run_db starts mysqld, but first it checks
# to see if the /var/lib/mysql directory is empty, if
# it is it is seeded with default_mysql_db.tar.gz before
# the mysql is fired up ENTRYPOINT “/tmp/run_db”
Итак, я подключился к моей директории mdir (у которой есть файл Dockerfile вместе с каталогом файлов). Затем я запустил команду:
docker build –no-cache .
Вы должны увидеть вывод следующим образом:
Sending build context to Docker daemon 7.168 kB
Sending build context to Docker daemon Step 0 : FROM mysql —> 461d07d927e6
Step 1 : MAINTAINER (me) —> Running in 963e8de55299 —> 2fd67c825c34
Removing intermediate container 963e8de55299
Step 2 : ADD files/run_db files/init_db files/epcis_schema.sql /tmp/ —> 81871189374b
Removing intermediate container 3221afd8695a
Step 3 : RUN /tmp/init_db —> Running in 8dbdf74b2a79
+ mysql_install_db
2015-03-19 16:40:39 12 [Note] InnoDB: Using atomics to ref count buffer pool pages
…
/var/lib/mysql/ib_logfile0 —> 885ec2f1a7d5
Removing intermediate container 8dbdf74b2a79
Step 4 : ENTRYPOINT “/tmp/run_db” —> Running in 717ed52ba665 —> 7f6d5215fe8d
Removing intermediate container 717ed52ba665
Successfully built 7f6d5215fe8d
Теперь у вас есть изображение '7f6d5215fe8d'. Я мог бы запустить это изображение:
docker run -d 7f6d5215fe8d
и начинается изображение, я вижу строку экземпляра:
4b377ac7397ff5880bc9218abe6d7eadd49505d50efb5063d6fab796ee157bd3
Я мог бы «остановить» его и перезапустить.
docker stop 4b377
docker start 4b377
Если вы посмотрите на журналы, первая строка будет содержать:
docker logs 4b377 Populate initial db
var/lib/mysql/
…
Затем в конце журналов:
Running with existing database in /var/lib/mysql
Это сообщения из сценария / tmp / run_db, первый указывает, что база данных была распакована из сохраненной (начальной) версии, вторая указывает, что база данных уже существует, поэтому использовалась существующая копия.
Вот ls -lR структуры каталогов, описанной выше. Обратите внимание, что init_db и run_db – это скрипты с установленным битом выполнения:
gregs-air:~ gfausak$ ls -Rl mdir
total 8
-rw-r–r– 1 gfausak wheel 534 Mar 19 11:13 Dockerfile
drwxr-xr-x 5 gfausak staff 170 Mar 19 11:24 files mdir/files:
total 24
-rw-r–r– 1 gfausak staff 126 Mar 19 11:14 epcis_schema.sql
-rwxr-xr-x 1 gfausak staff 1226 Mar 19 11:16 init_db
-rwxr-xr-x 1 gfausak staff 284 Mar 19 11:23 run_db
Источник: http://askdev.info/questions/461095/how-can-i-initialize-a-mysql-database-with-schema-in-a-docker-container
- Explore
- Help
- Sign In
Last pushed: a year agoDocker image mysql-backup
Это Dockerfile, позволяющие собрать образ Docker для создания резервных копий баз данных MySQL.
Репозиторий Git
Репозиторий исходных файлов данного проекта: https://github.com/pgallery/mysql-backup
Репозиторий Docker Hub
Расположение образа в Docker Hub: https://hub.docker.com/r/pgallery/mysql-backup/
Использование Docker Hub
sudo docker pull pgallery/mysql-backup
Доступные параметры конфигурации
Основные параметры:
Обратите внимание, если Вы используете данный образ для создания резервных копий pGallery, то данные параметры будут получены из файла /var/www/html/gallery/.env (см. пример ниже).
- TIMEZONE: временная зона контейнера, по умолчанию Europe/Moscow
- DB_HOST: хост или IP сервера MySQL, по умолчанию 127.0.0.1
- DB_PORT: порт, на котором работает MySQL, по умолчанию 3306
- DB_USERNAME: имя пользователя MySQL, по умолчанию root
- DB_PASSWORD: пароль пользователя MySQL
- DB_DATABASE: имя базы данных MySQL
Параметры создания резервной копии:
- DUMP_STORAGE: тип хранилища резервных копий, доступные значения: local – на локальный диск, ssh – копирование по SSH на удаленный сервер, aws – AWS S3 удаленное хранилище
- DUMP_INTERVAL: интервал создания резервных копий, в минутах, по умолчанию 1440 минут (раз в сутки)
- DUMP_BEGIN: интервал времени, через который после запуска контейнера будет выполнена первая резервная копия, по умолчанию установлено 15 минут
- DUMP_PREFIX: префикс имени архива резервной копии, по умолчанию 'db_'
Параметры подключения к удаленному серверу по SSH:
Данные параметры необходимы при DUMP_STORAGE=ssh
- BACKUP_USER: имя пользователя на удаленном сервере для сохранения резервной копии (необходимо доступ по SSH)
- BACKUP_PASSWORD: пароль пользователя на удаленном сервере для сохранения резервной копии
- BACKUP_HOST: хост или IP удаленного сервера
- BACKUP_DIR: директория для сохранения резервной копии на удаленном сервере
Параметры подключения к AWS S3:
Данные параметры необходимы при DUMP_STORAGE=aws
- BACKUP_AWS_ENDPOINT: хост AWS сервера
- BACKUP_AWS_KEY: ключ доступа аккаунта
- BACKUP_AWS_SECRET: секретный ключ аккаунта
- BACKUP_AWS_BUCKET: имя бакета для сохранения резервной копии
Примеры использования
Сохранение резервных копий на локальном хранилище:
sudo docker run -d –link mymysql:mysql -v /home/username/sitename/dump/:/backup/ -e 'DB_HOST=mysql' -e 'DB_PASSWORD=MysqlRootPass' pgallery/mysql-backup
Загрузка резервной копии на удаленный сервер по SSH:
sudo docker run -d -e 'DB_USER=user_db' -e 'DB_PASSWORD=NNNN' -e 'DUMP_INTERVAL=240' -e 'DUMP_PREFIX=docker1_' -e 'BACKUP_USER=dockerbackup' -e 'BACKUP_PASSWORD=NNNN' -e 'BACKUP_HOST=192.168.1.100' -e 'BACKUP_DIR=/home/dockerbackup/dump' pgallery/mysql-backup
Источник: https://hub.docker.com/r/pgallery/mysql-backup/
Почему резервная копия mysql не восстанавливается в мой контейнер докеров?
Вы на самом деле не выполняет скрипт при запуске контейнера. Я не уверен, что вы пытаетесь сделать с этим, и я не должен просить разъяснений, поэтому я просто буду отвечать как можно лучше и надеюсь, что это поможет.
Try что-то вроде:
Dockerfile
FROM alpine:latest WORKDIR /app COPY startup.sh /startup.sh COPY backup.sql /app/ RUN apk add –update mysql mysql-client && rm -f /var/cache/apk/* COPY my.cnf /etc/mysql/my.cnf EXPOSE 3306 ENTRYPOINT [“/startup.sh”] CMD /bin/bash -c “/usr/bin/mysqld –user=root –console && mysql -u root myDb < backup.sql"
Затем вы измените сценарий запуска, как это:
startup.sh
#!/bin/sh if [ -d /app/mysql ]; then echo “[i] MySQL directory already present, skipping creation” else echo “[i] MySQL data directory not found, creating initial DBs” mysql_install_db –user=root > /dev/null if [ “$MYSQL_ROOT_PASSWORD” = “” ]; then MYSQL_ROOT_PASSWORD=111111 echo “[i] MySQL root Password: $MYSQL_ROOT_PASSWORD” fi MYSQL_DATABASE=myDb if [ ! -d “/run/mysqld” ]; then mkdir -p /run/mysqld fi tfile=`mktemp` if [ ! -f “$tfile” ]; then return 1 fi cat > $tfile echo “CREATE DATABASE IF NOT EXISTS $MYSQL_DATABASE CHARACTER SET utf8 COLLATE utf8_general_ci;” >> $tfile echo “CREATE DATABASE IF NOT EXISTS $MYSQL_DATABASE CHARACTER SET utf8 COLLATE utf8_general_ci;” echo “CREATE USER 'myuser'@'localhost' IDENTIFIED BY '2E7A80BFD6Cwdct5q4i1r9l3';” >> $tfile echo “CREATE USER 'myuser'@'localhost' IDENTIFIED BY '2E7A80BFD6Cwdct5q4i1r9l3';” echo “CREATE USER 'myuser'@'%' IDENTIFIED BY '2E7A80BFD6Cwdct5q4i1r9l3';” >> $tfile echo “CREATE USER 'myuser'@'%' IDENTIFIED BY '2E7A80BFD6Cwdct5q4i1r9l3';” echo “GRANT ALL PRIVILEGES ON * . * TO 'myuser'@'localhost' WITH GRANT OPTION;” >> $tfile echo “GRANT ALL PRIVILEGES ON * . * TO 'myuser'@'localhost' WITH GRANT OPTION;” echo “GRANT ALL PRIVILEGES ON * . * TO 'myuser'@'%' WITH GRANT OPTION;” >> $tfile echo “GRANT ALL PRIVILEGES ON * . * TO 'myuser'@'%' WITH GRANT OPTION;” echo “FLUSH PRIVILEGES;” >> $tfile fi /usr/bin/mysqld –user=root –bootstrap –verbose=0 < $tfile rm -f $tfile fi exec "[email protected]"
Посмотрите, как Dockerfile и docker-entrypoint.sh настроены в official mysql Docker image repo.
Источник: https://stackoverrun.com/ru/q/9944782
Docker контейнер с данными на Postgres для интеграционного тестирования и лёгким расширением
Про использование Docker и Docker-compose последнее время написано очень много, например рекомендую недавнюю статью на Хабре, если вы до сих пор не прониклись. Это действительно очень удобно, а в связке в ansible особенно. И я его использую везде.
От разработки, до автоматического интеграционного тестирования на CI. Про использование в тестировании, тоже писали. Это здорово и удобно.
Однако, для локальной разработки, для траблешутинга данных “как в продакшене” или тестирование производительности, на “объёмах близких в продакшену”, хочется иметь под рукой образ, содержащий базу, “как в продакшене”!
Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:
./gradlew dockerRun
и приложение поднялось бы сразу со всеми необходимыми связанными контейнерами? А главное чтобы в нём уже были бы данные для большинства кейсов разработки и багфиксинга, стандартные пользователи и большинство работающих сервисов, над которыми сразу можно было бы приступить работать, не тратя времени на экспорт-импорт каких-то там образов или демоданных!
Как приятный бонус, ну разве не здорово иметь базу данных в несколько гигабайт и возможность откатиться к её исходному (или любому другому коммиту) состоянию в течении пары секунд?
Разумеется мы поговорим о написании Dockerfile для такого образа с данными, и некоторых подводных камнях этого процесса.
Вот на этом и сосредоточимся. В нашем приложении мы активно используем Postgres, поэтому повествование и примеры будут о контейнере именно с ним, но это касается лишь примеров, суть изложения применима к любой другой реляционной или модной NoSQL базе данных.
Чего хочется
Для начала определим проблему подробнее. Мы готовим образ, с данными, с которыми сможет работать каждый, кто работает с нашим приложением:
- Некоторые данные нуждаются в обфускации (например почтовые ящики или личные данные пользователей) — то есть нельзя просто восстановить дамп, требуется его обработка
- Однако мы хотим общий механизм накатывания предоставленных для сборки SQL скриптов, без дальнейшей модификации механизма сборки! Например это может использовать для семплинга (уменьшения количества данных) и уменьшения размера образа
- Хочется удобно включать в образ дополнительные настройки, не передавая их опциями во время запуска и не модифицируя каждый раз конфиг сложными регулярными выражениями
- Данные одинаковые, для разработчиков и CI
Я не буду начинать с того что такое Dockerfile, надеюсь вы уже знакомы с этим. Тех же, кто хочет получить представление, отсылаю к статье, ну или официальной документации.
Стоит отметить что официальный docker образ postgres уже имеет несколько точек расширения:
- POSTGRES_* переменные
- И директорию внутри образа /docker-entrypoint-initdb.d куда можно положить sh скрипты или sql файлы, которые будут выполнены на старте. Это очень удобно, если вы скажем хотите создать дополнительных пользователей или базы данных, установить права, проинициализировать расширения.
Однако, для наших целей этого мало:
- Мы не можем включать некоторые данные, затирая их на старте:
- Во-первых это может привести к огромному размеру БД (мы хотим удалить некоторые логи или историю)
- Во вторых, пользователь может запустить образ переопределив entrypoint, и увидеть приватные данные, которые видеть не должен
- Дополнительно, мы можем передавать практически любые параметры в командной строке при запуске, вроде –max_prepared_transactions=110, но мы не можем легко положить их в образ, и сделать стандартными
- Так, например, раз мы строим образ для тестирования и имеем быстрый откат, я хочу включить в него агрессивные настройки оптимизации производительности, нежели надёжности (включая полное отключение fsync)
Я наверное сразу покажу прототип файла (вырезаны лишь некоторые незначащие части чтобы он стал меньше, например много места занимает включение расширения pg_hint_plan, которое ставится на Debian из RPM, потому что отсутствует в Deb и официальных репозиториях):
Dockerfile
Источник: https://habr.com/post/328226/
Using Convoy to Backup and Recover a WordPress MySQL database with Docker
The latest release of Docker Engine now supports volume plugins, which allow users to extend Docker capabilities by adding solutions that can create and manage data volumes for containers that need to manage and operate on persistent datasets.
This is especially important for databases, and addresses one of the key limitations in Docker. Recently at Rancher we released Convoy, an open-source Docker volume driver that makes it simple to snapshot, backup, restore Docker volumes across clouds.
In this post I will put Convoy into action, by using Convoy to snapshot and backup a database state for a WordPress application, and will use the backup to create a replica in another datacenter.
I’ll also cover incremental and scheduled backups, so that you can begin regularly backing up any stateful data running in containers.
Installing Convoy
For this walkthrough you’ll need to make sure your hosts are running Docker 1.8 or later before installing Convoy. I’ll be using Digital Ocean for this walkthrough, and will begin by downloading the latest release of Convoy and then starting the Convoy daemon on two DigitalOcean machines running in different data centers:
$ wget https://github.com/rancher/convoy/releases/download/v0.2.1/convoy.tar.gz
$ tar xvf convoy.tar.gz
$ sudo cp convoy/convoy convoy/convoy-pdata_tools /usr/local/bin/
$ sudo mkdir -p /etc/docker/plugins/
$ sudo bash -c 'echo “unix:///var/run/convoy/convoy.sock” > /etc/docker/plugins/convoy.spec'
The last two commands will enable the Convoy plugin with Docker. Since we are going to use snapshots with the container’s volume I will start Convoy with the Linux Device Mapper storage backend which has support for snapshots.
WordPress Application with Convoy Storage
For this setup, I am going to start a WordPress application container and MySQL database container. The MySQL container will use Convoy to create a volume for the container’s data, the following is a compose file that contains instructions to create both containers:
wordpress: image: wordpress links: – mysql:mysql ports: – 80:80 mysql: image: mysql environment: MYSQL_ROOT_PASSWORD: “somebigpassword” volume_driver: convoy volumes: – wp_vol:/var/lib/mysql
This means that we will create a convoy volume for the MySQL container, this volume will store the database of the created WordPress, volume on the first node. Run the compose file using docker-compose:
To make sure that the volume is created, use the convoy command line to list all the volumes and snapshots:
$ convoy list { “36746db2-6964-40ee-8a50-1fd9b59c0da1”: { “UUID”: “36746db2-6964-40ee-8a50-1fd9b59c0da1”, “Name”: “wp_vol”, “Driver”: “devicemapper”, “Size”: 107374182400, “MountPoint”: “/var/lib/convoy/devicemapper/mounts/36746db2-6964-40ee-8a50-1fd9b59c0da1”, “CreatedTime”: “Thu Aug 27 16:14:42 -0400 2015”, “DriverInfo”: { “DevID”: “1”, “Driver”: “devicemapper”, “MountPoint”: “/var/lib/convoy/devicemapper/mounts/36746db2-6964-40ee-8a50-1fd9b59c0da1”, “Size”: “107374182400” }, “Snapshots”: {} } }
The volume is created and mounted to a directory inside /var/lib/convoy/devicemapper. Let’s create a sample post on the wordpress to test the application:<\p>
Snapshotting The WordPress Volume
Snapshots are saved states of a block devices, which are mountable and writable without interfering with the original content, to take a snapshot of the volume, use the following command:
$ sudo convoy snapshot create wp_vol –name wp_snap
$ sudo convoy list
…… “Snapshots”: { “9fe78648-0da4-42c8-a153-0a9b2f355044”: { “UUID”: “9fe78648-0da4-42c8-a153-0a9b2f355044”, “Name”: “wp_snap”, “CreatedTime”: “Thu Aug 27 17:00:14 -0400 2015”, “DriverInfo”: { “DevID”: “2”, “Driver”: “devicemapper”, “Size”: “107374182400”, “UUID”: “9fe78648-0da4-42c8-a153-0a9b2f355044”, “VolumeUUID”: “36746db2-6964-40ee-8a50-1fd9b59c0da1” } ……
Convoy Backup
Convoy supports incremental backup of snapshots to various object stores, including Amazon S3 or NFS/VFS. This means that Convoy will backup incremental changes between snapshots, as they are taken. First let’s create an S3 bucket to store our backups, I’ll use the awscli to create my S3 bucket:
# aws s3 mb s3://backup-convoy make_bucket: s3://backup-convoy/
Now use the following command to backup the snapshot to the backup-convoy s3 bucket:
# time convoy backup create wp_snap –dest s3://[email protected]/
s3://[email protected]/?backup=c993e80f-7bad-412d-bc63-55b7adfd3738u0026volume=4cd384c5-5121-4c9b-a834-9150b34a81f7 real 2m36.789s
user 0m0.020s
sys 0m0.008s
The command will backup the snapshot to the backup-convoy S3 bucket and then will print the backup url. You can see it took 2 minutes and 36 seconds to backup the snapshot to the S3 destination.
To take a look on the delta block backup, which only copies the incremental data between snapshots, let’s create another post on wordpress and check the time for the newly created backup this time:<\p>
$ sudo convoy snapshot create wp_vol –name wp_snap2
$ sudo time convoy backup create wp_snap2 –dest s3://[email protected]/ s3://[email protected]/?backup=e4b4f0e2-dd48-48ed-8720-6b2d5e889fffu0026volume=4cd384c5-5121-4c9b-a834-9150b34a81f7
real 0m9.185s
user 0m0.006s
sys 0m0.013s
The process this time took only 9 seconds which is the time taken to only backup the data created by the new post.
Replicating The Docker Container to Another Datacenter
Using the S3 backend as a centralized place for Docker volumes, will give us the ability to replicate the state of the Docker container to another datacenter, on another machine. First install Convoy and Docker on the new machine. And then restore the backup of the latest snapshot created earlier:
$ sudo convoy create wp_repl_vol –backup s3://[email protected]/?backup=e4b4f0e2-dd48-48ed-8720-6b2d5e889fffu0026volume=4cd384c5-5121-4c9b-a834-9150b34a81f7
Now this will restore the backup of the snapshots as a new volume called wp_repl_vol:
# convoy list { “c18ef169-52b7-47fa-9065-eeb8de55e551”: { “UUID”: “c18ef169-52b7-47fa-9065-eeb8de55e551”, “Name”: “wp_repl_vol”, “Driver”: “devicemapper”, “Size”: 107374182400, “MountPoint”: “”, “CreatedTime”: “Thu Aug 27 19:04:43 -0400 2015”, “DriverInfo”: { “DevID”: “1”, “Driver”: “devicemapper”, “MountPoint”: “”, “Size”: “107374182400” }, “Snapshots”: {} } }
Editing the docker-compose.yml to mount this new volume to the data directory of mysql will make the container point to the restored wordpress database:
volume_driver: convoy
volumes: – wp_repl_vol:/var/lib/mysql
Now when I run docker-compose up it will create a replica of the wordpress site: Using a simple cronjob I can run a script to create regular snapshot of the targeted volume and back it up to my S3 object store:
#!/bin/bash
S3_BUCKET=backup-convoy S3_REGION=us-west-1 VOL_NAME=wp_vol DATE=`date +%y%m%d%H%M` SNAPSHOT_NAME=wp_snap-$DATE BACKUP_URL_FILE=/var/log/backupurl.log /usr/local/bin/convoy snapshot create $VOL_NAME –name $SNAPSHOT_NAME /usr/local/bin/convoy backup create $SNAPSHOT_NAME –dest s3://[email protected]$S3_REGION/ > $BACKUP_URL_FILE
Conclusion
Data management is an essential part of any Docker environment, Docker Volumes and Convoy makes it easy to manage persistent data by adding a set of operations to manage Docker volumes, and soon Convoy will be incorporated into Rancher orchestration suite which will make it simple to manage and recover these backups directly from the Rancher UI, CLI and API. To learn more about Convoy, view a recording of our recent Convoy meetup, or request a demonstration from one of our engineers.
Источник: https://rancher.com/using-convoy-to-backup-and-recover-a-wordpress-mysql-database-with-docker/
Загрузка...
