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

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

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

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

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

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

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

docker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не путаю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Именно так

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

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

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

до первого _что-то_пошло_не_так

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

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

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

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

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

А зачем 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:

docker-compose.yml
Dockerfiles

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

volumes

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

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

Типа вместо:

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/ это просто папки на хосте. Разве что во-втором случае все будет в одном месте.

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

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

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