LINUX.ORG.RU
ФорумAdmin

Вопросы к докероводам про бэкапы.

 ,


0

4

У меня есть кейс, в котором мне нужно держать docker-compose докеры. Их там около 8 штук в связке. Мне совершенно непонятно как их бэкапить.

Все это должно работать на KVM виртуалке, сначала я думал, что создам lxc контейнер, в нем подниму докеры и буду бэкапить lxc. Но, как выяснилось, докеры не работают в lxc ( те иногда работают, но не всегда, не везде и не все, короче, это не про продакшен)

У них есть так же несколько volume. Те просто сделать снепшот zfs пула не выйдет.

Вопрос: какие есть best practice по бэкапу связок докеров? Желательно чтобы без страданий, снял снепшот и развернул его на другой машине моментально.

Ну и вообще хотелось бы поговорить о том, нахрен тогда это все нужно, если они не умеют бэкапиться? Для того, чтобы програмистам-виндоводам было удобно разворачивать это на своих виндах и кодить там? Причем тут продакшен?

★★★★

Что такое «связка докеров»? Если ты про развернутую конфигурацию - нафига ее бэкапить, ее оркестратор должен поднимать.
Если вопрос просто про бэкап состояния - то почему у тебя стейт в контейнере лежит? Все персистируемое снаружи - вот его и бэкапь, ну или бэкапь на уровне приложения, если это БД и прочее.

Deleted ()
Ответ на: комментарий от Deleted

Связка докеров в моем случае это docker-compose, они там друг с другом общаются.

ну или бэкапь на уровне приложения, если это БД и прочее.

Вот-вот. те я должен сидеть и думать , что там надо бэкапить на уровне приложения, что на уровне хранилищ и тд.

И к вопросу про докеры вообще в этом ключе. Нахрен мне это надо ( думать о том, что и как там по отдельности бэкапить) ? У меня нет на это времени, я хочу инструмент. Что мне толку от того, что оно красиво разворачивается, если это чудо нельзя нормально как виртуалку забекапить. Те мне проще потратить один раз время на ручную инсталляцию или инсталляцию с помощью ansible/chef/etc и иметь что-то, что я могу бэкапить снепшотами, чем один раз сделать docker-compose pull, но затем получить кучу проблем с тем, как это все содержать.

constin ★★★★ ()

Ты сам всё сказал.

docker

это не про продакшен

Для того, чтобы програмистам [..] было удобно разворачивать это [..] и кодить/компилять там //исправлено

shell-script ★★★★★ ()
Ответ на: комментарий от constin

как виртуалку забекапить

Ты путаешь уровни абстракции. Подними виртуалку, в ней докеры и бэкапь виртуалку.

Докер не виртуализация, а замкнутая среда для исполнения приложений.

думать о том, что и как там по отдельности бэкапить

Я не понимаю чем это будет отличаться от бэкапа сервера на котором у тебя будет вертеться PG и еще какое-нибудь хранилище для персистирования данных.

бэкапить снепшотами

Забинди вольюмы на реальные пути в фс и бэкапь снэпшотами.

Deleted ()
Ответ на: комментарий от shell-script

Ну конечно, все что-бы вебмакаки угнетали админчиков.

Про продакшен\не продакшен расскажи пользователя kubernetes, которые понапихают в него контейнеров и всем довольны.

Deleted ()
Ответ на: комментарий от constin

И снова ты всё правильно понимаешь. Докер нужен, чтобы собрать статический контейнер с фиксированным набором софта и каким-то дефолтным окружением. Никаких динамических данных в докере быть не должно.

Обычные юзкейсы:

- Развернул контейнер, запустил внутри билдагента, притянул исходники, скомпилял, забрал бинарники, грохнул контейнер.

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

А бекапы делаются уже отдельно для данных обычными методами - будь-то снепшоты, bakula или ещё что. Конфиги рулятся через ansible/puppet/etc.

shell-script ★★★★★ ()
Ответ на: комментарий от Deleted

Ты путаешь уровни абстракции. Подними виртуалку, в ней докеры и бэкапь виртуалку.

Не путаю. в этом кейсе KVM виртуалка на Хетценере, те нет возможности получить ее имидж. Но lxc бэкапить можно, а докер нет.

Я не понимаю чем это будет отличаться от бэкапа сервера на котором у тебя будет вертеться PG и еще какое-нибудь хранилище для персистирования данных.

Тем, что докер позиционируется как легкая ( раз и готово) штука. Поэтому не стоит сравнивать его бэкап с бэкапом какого-нибудь распределенного кластера с кучей сервисов на бареметал.

Забинди вольюмы на реальные пути в фс и бэкапь снэпшотами.

Иными словами, красивого решения по бэкапу у докеров нет?

constin ★★★★ ()
Ответ на: комментарий от shell-script

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

constin ★★★★ ()
Последнее исправление: constin (всего исправлений: 1)

The point is, докер не бекапят. Это throw away фигня.

Если у тебя DB в контейнере, you are doing it wrong.

beastie ★★★★★ ()
Ответ на: комментарий от Deleted

Ну конечно, все что-бы вебмакаки угнетали админчиков.

Веб-макаке вообще не обязательно знать, что там на сервере происходит. Им достаточно sftp к $wwwroot, интерфейса к бд и в некоторых случаях кнопочки 'reload backend'.

пользователя kubernetes, которые понапихают в него контейнеров и всем довольны

Если довольны, то отлично. Значит правильно всё сделали. Но вот я вот что-то частенько встречаю недовольных, которые данный тип контейнеризации пытаются использовать как замену виртуализации или openvz/lxc и поэтому страдают.

shell-script ★★★★★ ()
Ответ на: комментарий от constin

Не путаю.

И еще раз - путаешь. Докер и LXC это не виртуализация. Kvm - виртуализация.

KVM виртуалка на Хетценере

Хетцнеропроблемы. У Амазона есть снэпшоты стораджей + AMI.

Но lxc бэкапить можно, а докер нет.

Если ты про lxc-backup/lxc-restore - то так себе инструменты для бэкапа. В докере ты впринципе можешь делать commit, получать новый image и в случае проблем запускать уже его, но из-за оверлеев будет не очень.

докер позиционируется как легкая ( раз и готово) штука.

Тебе пять лет и ты веришь в «silver bullet»?

Поэтому не стоит сравнивать его бэкап с бэкапом какого-нибудь распределенного кластера с кучей сервисов на бареметал.

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

Иными словами, красивого решения по бэкапу у докеров нет?

Нет. А у бэйрметалл линукса есть?

Deleted ()
Ответ на: комментарий от shell-script

пытаются использовать как замену виртуализации

Вот это вот. Фундаментальное непонимание.

sftp к $wwwroot
интерфейса к бд

Путь в ад. Только версионированные собранные пакеты.

Deleted ()
Ответ на: комментарий от Deleted

Путь в ад. Только версионированные собранные пакеты.

Я обобщённо. :)

Суть в том, что у веб-макаки не должно быть шелла на сервер(ни на девелоперский, ни на тестовый, ни тем более на прод), а потому при нормально настроенном окружении, веб-макаке в принципе пофигу, что там и как админ накрутил.

shell-script ★★★★★ ()
Ответ на: комментарий от Deleted

И еще раз - путаешь. Докер и LXC это не виртуализация. Kvm - виртуализация.

Ты просто плохо меня читаешь. докер и lxc это контейнеры, но в lxc бэкапы есть, а у докеров нет.

Хетцнеропроблемы. У Амазона есть снэпшоты стораджей + AMI.

Речь об кроссплатформенном решении по бэкапу докеров. Поэтому «а вот сделай kvm и ее бэкапь» не подходит.

Нет. А у бэйрметалл линукса есть?

Нет. но их не нужно сравнивать, из-за «докер позиционируется как легкая ( раз и готово) штука.»

Тебе пять лет и ты веришь в «silver bullet»?

Я просто стулкнулся с задачей и пытаюсь найти выход.

constin ★★★★ ()
Ответ на: комментарий от beastie

А как правильно делается? К контейнеру цепляется снаружи нечто куда можно писать файлы а внутри только stateless штуки?

Dark_SavanT ★★★★★ ()

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

itn ★★★ ()

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

Dred ★★★★★ ()
Ответ на: комментарий от SevikL

ну все _что-то_пошло_не_так_ при правильно написанном приложении заканчивается перераспределением нагрузки на другие инстансы этого имейджа и выдачей стектрейса\дампов разработику. The Reactive Manifesto > Resilent, все дела.

Deleted ()
Ответ на: комментарий от Dred

Забэкил содержимое /var/lib/docker/volumes

Забэкапил папку с docker-compose.yml и статик контентом типа web/ , config/ , Dockerfiles, etc

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

constin ★★★★ ()
Ответ на: комментарий от constin

А зачем volumes бэкапишь? есть какие-то контейнеры с непроброшенными наружу данными? Пробрасывай всё.

Deleted ()
Ответ на: комментарий от Deleted

А зачем volumes бэкапишь? есть какие-то контейнеры с непроброшенными наружу данными? Пробрасывай всё.

так volumes это и есть проброшенные данные


mysql:
      image: mariadb:10.2
      volumes:
        - mysql-vol-1:/var/lib/mysql/
        - ./data/conf/mysql/:/etc/mysql/conf.d/:ro

.......
volumes:
  vmail-vol-1:
  mysql-vol-1:
  redis-vol-1:
  rspamd-vol-1:
  postfix-vol-1:
  crypt-vol-1:
  rspamd-sock:
constin ★★★★ ()
Последнее исправление: constin (всего исправлений: 1)
Ответ на: комментарий от constin

docker-compose.yml
Dockerfiles

Обычно такое в гит выносят, но на твое усмотрение

volumes

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

Dred ★★★★★ ()
Ответ на: комментарий от Dred

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

Типа вместо:

mysql:
      image: mariadb:10.2
      volumes:
        - mysql-vol-1:/var/lib/mysql/
        - ./data/conf/mysql/:/etc/mysql/conf.d/:ro

Вот так:?

mysql:
      image: mariadb:10.2
      volumes:
        - ./data/mysqldb/:/var/lib/mysql/:rw
        - ./data/conf/mysql/:/etc/mysql/conf.d/:ro

Технически разницы не будет, и mysql-vol-1 и ./data/mysqldb/ это просто папки на хосте. Разве что во-втором случае все будет в одном месте.

constin ★★★★ ()
Последнее исправление: constin (всего исправлений: 2)
Ответ на: комментарий от constin

Для корректного backup-а mysql на уровне файлов говорят нужно ещё делать
flush tables with read lock;
flush logs;
Иначе при запуске mysql на новом месте он увидит поломанные таблицы, начнёт чинить.

spirit ★★★★★ ()
Ответ на: комментарий от spirit

Т.е. родной бэкап уже не кошерен? Тогда уж mysqld stop;rsync... mysqld start;

anc ★★★★★ ()
Ответ на: комментарий от spirit

если сервис остановлен, то можно копировать файлы.

constin ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.