Глава 6 — Деплой и обновление проектов
Docker — Production Deployment Workflow
Эта страница описывает рекомендуемый процесс обновления и развёртывания Docker-проектов на production-сервере. Здесь показан безопасный порядок действий при обновлении кода, образов и контейнеров, а также базовые проверки после деплоя. Материал ориентирован на начинающих и помогает выполнять обновления предсказуемо и без случайных простоев сервисов.
Что такое Deployment Workflow
Deployment Workflow — это последовательность действий, которую нужно выполнять при обновлении проекта.
Без чёткой процедуры часто возникают проблемы:
- контейнеры запускаются со старыми образами
- сервисы падают после обновления
- изменения не применяются
- ломается база данных
- проект уходит в простой
Поэтому важно использовать одинаковый и проверенный порядок действий.
Типичная структура проекта
Пример директории проекта:
/opt/flamy_projects/site1
docker-compose.yml
.env
Dockerfile
src/
Где:
| Файл | Назначение |
|---|---|
| docker-compose.yml | конфигурация сервисов |
| Dockerfile | инструкция сборки образа |
| .env | переменные окружения |
| src | исходный код приложения |
Стандартная процедура обновления проекта
Шаг 1 — перейти в директорию проекта
cd /opt/flamy_projects/site1
Проверить файлы:
ls -la
Важно убедиться, что вы находитесь в правильной директории проекта.
Шаг 2 — обновить код проекта
Если используется Git:
git pull
Команда скачивает последние изменения из репозитория.
Когда это нужно
- обновление приложения
- исправления ошибок
- новые функции
Шаг 3 — обновить Docker-образы
Если проект использует готовые образы из registry, нужно загрузить новые версии.
docker compose pull
Команда скачает новые версии образов, указанных в docker-compose.yml.
Шаг 4 — пересобрать контейнеры (если требуется)
Если изменились:
- Dockerfile
- зависимости
- системные пакеты
нужно пересобрать образ.
docker compose up -d --build
Эта команда:
- пересоберёт образы
- обновит контейнеры
- запустит сервисы
Шаг 5 — проверить состояние контейнеров
docker compose ps
Пример результата:
NAME STATUS
site1_nginx Up
site1_php Up
site1_mysql Up
Все сервисы должны иметь статус Up.
Шаг 6 — проверить логи
После обновления важно убедиться, что сервисы работают корректно.
docker compose logs --tail=50
В логах не должно быть:
- ошибок запуска
- ошибок подключения к базе
- критических ошибок приложения
Шаг 7 — проверить работу приложения
После деплоя рекомендуется проверить:
- доступность сайта
- работу API
- соединение с базой данных
- фоновые задачи (workers, cron)
Быстрое обновление проекта
На практике часто используется короткая команда:
docker compose pull && docker compose up -d
Она:
- скачивает новые образы
- обновляет контейнеры
Это самый быстрый способ обновить сервис.
Полное обновление проекта
Если нужно полностью пересобрать контейнеры:
docker compose build --no-cache
docker compose up -d
Это полезно, если:
- изменения не применяются
- образ собран неправильно
- нужно выполнить чистую сборку
Полный перезапуск проекта
Иногда требуется полностью остановить и заново запустить сервисы.
docker compose down
docker compose up -d
Это может помочь при:
- сетевых проблемах
- зависших контейнерах
- некорректном состоянии сервисов
Перезапуск одного сервиса
Если проблема только в одном сервисе:
docker compose restart nginx
Это быстрее и безопаснее, чем перезапуск всего проекта.
Откат версии (Rollback)
Если после обновления возникли проблемы, можно откатиться к предыдущей версии.
Пример:
git checkout <previous_commit>
docker compose up -d --build
Это восстановит предыдущую рабочую версию приложения.
Проверка после деплоя
После обновления рекомендуется выполнить несколько проверок.
Проверить контейнеры
docker ps
Это покажет все работающие контейнеры.
Проверить ресурсы
docker stats
Позволяет убедиться, что сервисы не перегружают сервер.
Проверить сети
docker network ls
Если сервисы не взаимодействуют — возможно проблема в сети.
Типичный production workflow
Чаще всего используется следующий порядок действий:
cd /opt/flamy_projects/site1
git pull
docker compose pull
docker compose up -d --build
docker compose ps
docker compose logs --tail=50
Этот процесс:
- обновляет код
- обновляет образы
- пересобирает контейнеры
- проверяет состояние сервисов
Частые ошибки при деплое
Пропуск шага pull
Если не выполнить docker compose pull, контейнеры могут запускаться со старыми образами.
Запуск команд не из директории проекта
Docker Compose работает с файлом docker-compose.yml, поэтому важно находиться в нужной папке.
Игнорирование логов
После деплоя всегда нужно проверять логи.
Использование latest в production
Лучше указывать фиксированные версии образов:
nginx:1.25
Это делает деплой более предсказуемым.
Краткая памятка
cd /opt/flamy_projects/project_name
git pull
docker compose pull
docker compose up -d --build
docker compose ps
docker compose logs --tail=50
docker compose restart <service>
docker compose down && docker compose up -d
Итог
Правильный workflow обновления Docker-проектов позволяет:
- безопасно обновлять сервисы
- быстро диагностировать проблемы
- минимизировать время простоя
Использование чёткой процедуры деплоя помогает поддерживать стабильную работу production-систем и упрощает администрирование Docker-инфраструктуры.
Docker — Backup (Резервное копирование данных)
Эта страница описывает способы резервного копирования данных Docker-проектов. Здесь разобраны методы backup контейнерных данных, volumes и баз данных, а также способы восстановления данных. Материал рассчитан на начинающих и помогает понять, как защитить данные Docker-приложений от потери при сбоях, обновлениях или ошибках администрирования.
Почему резервное копирование важно
Docker-контейнеры можно легко пересоздать, но данные приложения могут быть потеряны, если они не вынесены в volumes или не сохраняются отдельно.
Резервное копирование особенно важно для:
- баз данных
- пользовательских файлов
- загрузок
- конфигураций приложения
- логов
Даже небольшая ошибка (например, удаление volume) может привести к потере данных.
Что нужно резервировать
В Docker-проектах обычно нужно делать backup:
| Тип данных | Пример |
|---|---|
| Базы данных | MySQL, PostgreSQL |
| Docker volumes | данные контейнеров |
| Файлы приложения | uploads, storage |
| Конфигурации | .env, config |
Backup базы данных из контейнера
Самый распространённый способ — использовать встроенные утилиты базы данных.
Backup MySQL
docker compose exec mysql mysqldump -u root -p database_name > backup.sql
Эта команда:
- подключается к контейнеру MySQL
- делает дамп базы
- сохраняет файл
backup.sql
Backup PostgreSQL
docker compose exec postgres pg_dump -U postgres database_name > backup.sql
Backup Docker Volume
Если данные хранятся в volume, можно сделать архив.
Создание backup volume
docker run --rm \
-v volume_name:/data \
-v $(pwd):/backup \
alpine tar czf /backup/volume_backup.tar.gz /data
Что делает команда
| Параметр | Назначение |
|---|---|
| -v volume_name:/data | подключает volume |
| -v $(pwd):/backup | папка для сохранения |
| tar czf | создаёт архив |
В результате появится файл:
volume_backup.tar.gz
Восстановление volume
Чтобы восстановить данные из backup:
docker run --rm \
-v volume_name:/data \
-v $(pwd):/backup \
alpine tar xzf /backup/volume_backup.tar.gz -C /
Данные будут восстановлены в volume.
Backup директории проекта
Иногда нужно сохранить весь Docker-проект.
Архив проекта
tar -czf project_backup_$(date +%Y%m%d).tar.gz /opt/flamy_projects/site1
Архив будет содержать:
- docker-compose.yml
- Dockerfile
- исходный код
- конфигурации
Backup пользовательских файлов
Если приложение хранит файлы в директории:
/var/www/storage
Можно сделать backup так:
tar -czf storage_backup.tar.gz storage/
Backup через rsync
rsync часто используется для копирования backup на другой сервер.
rsync -avz /opt/flamy_projects user@backup-server:/backup/docker_projects
Это позволяет хранить резервные копии на отдельном сервере.
Автоматизация backup (cron)
Backup можно запускать автоматически.
Пример cron-задачи:
crontab -e
Добавить строку:
0 3 * * * /usr/local/bin/docker_backup.sh
Это будет запускать backup каждый день в 03:00.
Пример простого backup-скрипта
#!/bin/bash
DATE=$(date +%Y%m%d)
docker compose exec mysql mysqldump -u root -psecret db > backup_$DATE.sql
tar -czf docker_backup_$DATE.tar.gz /opt/flamy_projects/site1
Скрипт делает:
- дамп базы
- архив проекта
Проверка backup
Очень важно проверять резервные копии.
Проверить архив:
tar -tzf backup.tar.gz
Проверить SQL-дамп:
head backup.sql
Типичные ошибки при backup
Backup только контейнеров
Контейнеры легко пересоздаются, поэтому важно сохранять данные, а не контейнеры.
Отсутствие автоматического backup
Ручной backup часто забывают делать.
Лучше использовать cron.
Хранение backup на том же сервере
Если сервер выйдет из строя, backup тоже может быть потерян.
Лучше хранить копии:
- на другом сервере
- в облаке
- в S3-хранилище
Рекомендуемая стратегия backup
Минимальная стратегия:
- ежедневный backup базы данных
- ежедневный backup volumes
- хранение копий минимум 7 дней
Краткая памятка
docker compose exec mysql mysqldump > backup.sql # backup MySQL
docker compose exec postgres pg_dump > backup.sql # backup PostgreSQL
docker run -v volume:/data alpine tar czf backup.tar.gz /data # backup volume
tar -czf project_backup.tar.gz project/ # архив проекта
rsync -avz project backup-server:/backup # копирование backup