Запуск БД в Docker и без него. Способы организации репликации. Написание скрипта резервного копирования базы данных PostgreSQL с загрузкой в S3-совместимое файловое хранилище. Эмуляция хранилища для локальной разработки.
- 00:00:15 Вопрос надёжности хранения
- 00:02:02 Репликация для PostgreSQL в Docker
- 00:06:09 Запуск СУБД вне Docker
- 00:10:13 Использование облачных СУБД
- 00:16:57 Переименование Cron-сервиса
- 00:17:22 Уменьшение интервала для docker prune
- 00:18:33 Выбор хранилища и протокола
- 00:20:54 Протокол Amazon S3
- 00:22:01 Консольный клиент aws
- 00:23:45 Альтернативы от других провайдеров
- 00:24:57 Создание контейнера для бэкапов
- 00:27:50 Эмулятор для локальной разработки
- 00:32:11 Проброс для веб-интерфейса
- 00:34:50 Автосоздание Bucket в эмуляторе
- 00:38:00 Docker-сервис для бэкапа
- 00:41:02 Скрипт резервного копирования
- 00:48:01 Dockerfile для образа
- 00:50:26 Проверка backup-скрипта в Jenkins
- 00:52:54 Запуск по Cron в production
- 00:57:29 Обзор результата
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо!
Спасибо, прям то что нужно.
Спасибо.
Спасибо за видео. Есть только один момент - увидав в заголовке тему про репликацию был очень обнадежен. Однако по видео не понятно, какую проблему решает данный подход кроме резервного копирования данных в реалтайме. Может быть в следующих видосах будет раскрыта пошире эта тема - как сделать эти базы реально безотказными, с выбором мастера, как приложению переключаться на новый мастер, как новую ноду запускать чтобы она как-то влилась в процесс и подцепила бекап и тд. Кажется, эта тема была интересна многим )
Полноценная репликация с автопереключением сложнее. Там нужно следить за мастером через repmgr, чтобы в мастер направлять все запросы на запись через балансировщик pgpool. Для этого можно взять такие готовые образы от этого же автора.
А приложение подключать напрямую к балансировщику pgpool.
Спасибо за указание нужного направления, ушел курить интернет на эту тему...
Одна из некомфортных для меня тем (девопсная), но считаю очень полезным все равно изучать это, так как хорошо расширяет кругозор. Да и взаимодействие с девопсами лучше, когда ты хотя бы отчасти понимаешь их работу.
Спасибо!
Вакансии с высокими ценниками часто предполагают, что кандидат будет владеть devops-инструментами. Так что это уж точно не будет лишним
Добрый день, Дмитрий.
Всё очень просто и доступно рассказано и показано, спасибо.
Но вот что-то на локалке не могу запустить по cron сохнанение backup-ов (на prod ещё не пробовал)
В crontab записываю команду
но она не срабатывает. Если записать другую команду, например создание файла, то всё работает.
С чем это может быть связано?
В общем проблема на рабочем сервере решилась через указание полного пути к docker-compose и sh.
Вот так заработало. OC Ubuntu 20.04 LTS
На локальном не стал возиться с этим вопросом.
Добрый вечер, Дмитрий.
Возникла проблема с backup-ами баз данных.
Сделал всё по Вашему уроку.
Поначалу всё работало. Cron команды отрабатывались без проблем в течении недели. Но в последнее время backup-ы перестали создаваться. Если запустить вручную создание backup, то в консоли заканчивается ошибкой
Через playbook выполнил docker-login, скрипт отработал без ошибок, но ситуация не изменилась.
Зашёл на сервер по ssh. Выполнил docker login вручную. После этого начал создаваться backup одной базы данных. Но со второй базы всё равно не создаётся, всё та же ошибка доступа.
В syslog более подробная ошибка.
В чём может быть причина такого поведения cron команд?
В том, что docker-login выполняется для пользователя deploy, а внешние cron-команды запускаются по умолчанию от root.
Возможно я удалил ssh ключ для root, но как и зачем - не помню)
У меня тогда такой вопрос.
В видео про установку jenkins Вы создавали команду cron
Эта команда, насколько я помню, для очистки образов для dind. Все образы, которые будут старше десяти дней будут удалены.
Но она не работает. Пробовал два варианта, с указанием полного пути к sh и docker-compose и без. На ubuntu указание полного пути помогло решить проблему, а вот в debian нет.
Хотя если зайти на сервер по ssh от root и вручную запустить, то она отработает.
В чём может быть причина, что cron команда не работает от root когда её выполняет cron?
А какие логи вывоит cron?
Вы имеете ввиду syslog?
На сервере Debian 10, есть /var/log/faillog и /var/log/lastlog, но не могу прочитать их.
Переустановите логи
и syslog появится.
После ввода Вашей команды запустил задание на каждую минуту.
В syslog только такие записи
Значит работает?
Вроде нет. Изменил значение until на 72h, запуск каждую минуту. Но ни один из образов, который создался 4 дня назад не удалился.
В логах
А какой командой список образов смотрите?
docker exec jenkins_jenkins_1 docker images
Нашёл решение, правда подсказали.
В конец команды добавил >/tmp/test-cron.log 2>&1
В файле появилась запись
На stackoverflow подобный вопрос, всё дело в флагах.
После exec необходимо указать флаг -T.
Вроде заработало, старые образы удалились, но будем посмотреть как дальше будет работать.
Добрый вечер.
Возникла такая проблема.
Хочу полностью эмулировать работу с облачным хранилищем, но возникла проблема с получением файлов из локального облака.
При настройках nginx, из Ваших уроков, без проблем получается залить какой либо файл в локальное облако.
Но при получении, когда обращаюсь по адресу файла в облаке не всегда получаю файл.
Например
Если для последнего примера добавить заголовок с content-type, то ответ сервера тоже будет 200, но на самой странице будет такое сообщение (подставляется в alt img)
Где искать проблему?
Или войти через: