# Глава 6 — Деплой и обновление проектов

# Docker — Production Deployment Workflow

Эта страница описывает рекомендуемый процесс обновления и развёртывания Docker-проектов на production-сервере. Здесь показан безопасный порядок действий при обновлении кода, образов и контейнеров, а также базовые проверки после деплоя. Материал ориентирован на начинающих и помогает выполнять обновления **предсказуемо и без случайных простоев сервисов**.

---

# Что такое Deployment Workflow

Deployment Workflow — это **последовательность действий**, которую нужно выполнять при обновлении проекта.

Без чёткой процедуры часто возникают проблемы:

* контейнеры запускаются со старыми образами
* сервисы падают после обновления
* изменения не применяются
* ломается база данных
* проект уходит в простой

Поэтому важно использовать **одинаковый и проверенный порядок действий**.

---

# Типичная структура проекта

Пример директории проекта:

```text
/opt/flamy_projects/site1

docker-compose.yml
.env
Dockerfile
src/
```

Где:

| Файл               | Назначение               |
| ------------------ | ------------------------ |
| docker-compose.yml | конфигурация сервисов    |
| Dockerfile         | инструкция сборки образа |
| .env               | переменные окружения     |
| src                | исходный код приложения  |

---

# Стандартная процедура обновления проекта

## Шаг 1 — перейти в директорию проекта

```bash
cd /opt/flamy_projects/site1
```

Проверить файлы:

```bash
ls -la
```

Важно убедиться, что вы находитесь **в правильной директории проекта**.

---

# Шаг 2 — обновить код проекта

Если используется Git:

```bash
git pull
```

Команда скачивает последние изменения из репозитория.

### Когда это нужно

* обновление приложения
* исправления ошибок
* новые функции

---

# Шаг 3 — обновить Docker-образы

Если проект использует готовые образы из registry, нужно загрузить новые версии.

```bash
docker compose pull
```

Команда скачает новые версии образов, указанных в `docker-compose.yml`.

---

# Шаг 4 — пересобрать контейнеры (если требуется)

Если изменились:

* Dockerfile
* зависимости
* системные пакеты

нужно пересобрать образ.

```bash
docker compose up -d --build
```

Эта команда:

1. пересоберёт образы
2. обновит контейнеры
3. запустит сервисы

---

# Шаг 5 — проверить состояние контейнеров

```bash
docker compose ps
```

Пример результата:

```text
NAME           STATUS
site1_nginx    Up
site1_php      Up
site1_mysql    Up
```

Все сервисы должны иметь статус **Up**.

---

# Шаг 6 — проверить логи

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

```bash
docker compose logs --tail=50
```

В логах не должно быть:

* ошибок запуска
* ошибок подключения к базе
* критических ошибок приложения

---

# Шаг 7 — проверить работу приложения

После деплоя рекомендуется проверить:

* доступность сайта
* работу API
* соединение с базой данных
* фоновые задачи (workers, cron)

---

# Быстрое обновление проекта

На практике часто используется короткая команда:

```bash
docker compose pull && docker compose up -d
```

Она:

1. скачивает новые образы
2. обновляет контейнеры

Это самый быстрый способ обновить сервис.

---

# Полное обновление проекта

Если нужно полностью пересобрать контейнеры:

```bash
docker compose build --no-cache
docker compose up -d
```

Это полезно, если:

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

---

# Полный перезапуск проекта

Иногда требуется полностью остановить и заново запустить сервисы.

```bash
docker compose down
docker compose up -d
```

Это может помочь при:

* сетевых проблемах
* зависших контейнерах
* некорректном состоянии сервисов

---

# Перезапуск одного сервиса

Если проблема только в одном сервисе:

```bash
docker compose restart nginx
```

Это быстрее и безопаснее, чем перезапуск всего проекта.

---

# Откат версии (Rollback)

Если после обновления возникли проблемы, можно откатиться к предыдущей версии.

Пример:

```bash
git checkout <previous_commit>
docker compose up -d --build
```

Это восстановит предыдущую рабочую версию приложения.

---

# Проверка после деплоя

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

---

## Проверить контейнеры

```bash
docker ps
```

Это покажет все работающие контейнеры.

---

## Проверить ресурсы

```bash
docker stats
```

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

---

## Проверить сети

```bash
docker network ls
```

Если сервисы не взаимодействуют — возможно проблема в сети.

---

# Типичный production workflow

Чаще всего используется следующий порядок действий:

```bash
cd /opt/flamy_projects/site1

git pull
docker compose pull
docker compose up -d --build

docker compose ps
docker compose logs --tail=50
```

Этот процесс:

1. обновляет код
2. обновляет образы
3. пересобирает контейнеры
4. проверяет состояние сервисов

---

# Частые ошибки при деплое

## Пропуск шага pull

Если не выполнить `docker compose pull`, контейнеры могут запускаться со старыми образами.

---

## Запуск команд не из директории проекта

Docker Compose работает с файлом `docker-compose.yml`, поэтому важно находиться в нужной папке.

---

## Игнорирование логов

После деплоя всегда нужно проверять логи.

---

## Использование latest в production

Лучше указывать фиксированные версии образов:

```yaml
nginx:1.25
```

Это делает деплой более предсказуемым.

---

# Краткая памятка

```bash
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

```bash id="kvx7ep"
docker compose exec mysql mysqldump -u root -p database_name > backup.sql
```

Эта команда:

1. подключается к контейнеру MySQL
2. делает дамп базы
3. сохраняет файл `backup.sql`

---

## Backup PostgreSQL

```bash id="ecv8u4"
docker compose exec postgres pg_dump -U postgres database_name > backup.sql
```

---

# Backup Docker Volume

Если данные хранятся в volume, можно сделать архив.

---

## Создание backup volume

```bash id="fd9n6h"
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              | создаёт архив        |

В результате появится файл:

```text id="f6a6fy"
volume_backup.tar.gz
```

---

# Восстановление volume

Чтобы восстановить данные из backup:

```bash id="op9dpp"
docker run --rm \
  -v volume_name:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/volume_backup.tar.gz -C /
```

Данные будут восстановлены в volume.

---

# Backup директории проекта

Иногда нужно сохранить весь Docker-проект.

---

## Архив проекта

```bash id="zuybb6"
tar -czf project_backup_$(date +%Y%m%d).tar.gz /opt/flamy_projects/site1
```

Архив будет содержать:

* docker-compose.yml
* Dockerfile
* исходный код
* конфигурации

---

# Backup пользовательских файлов

Если приложение хранит файлы в директории:

```text id="0nh8k0"
/var/www/storage
```

Можно сделать backup так:

```bash id="reye7v"
tar -czf storage_backup.tar.gz storage/
```

---

# Backup через rsync

`rsync` часто используется для копирования backup на другой сервер.

```bash id="tbj02p"
rsync -avz /opt/flamy_projects user@backup-server:/backup/docker_projects
```

Это позволяет хранить резервные копии **на отдельном сервере**.

---

# Автоматизация backup (cron)

Backup можно запускать автоматически.

Пример cron-задачи:

```bash id="t8gmyc"
crontab -e
```

Добавить строку:

```text id="zslg7o"
0 3 * * * /usr/local/bin/docker_backup.sh
```

Это будет запускать backup каждый день в 03:00.

---

# Пример простого backup-скрипта

```bash id="f3khr0"
#!/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

Очень важно проверять резервные копии.

Проверить архив:

```bash id="tk4s3d"
tar -tzf backup.tar.gz
```

Проверить SQL-дамп:

```bash id="kchp9s"
head backup.sql
```

---

# Типичные ошибки при backup

## Backup только контейнеров

Контейнеры легко пересоздаются, поэтому важно сохранять **данные**, а не контейнеры.

---

## Отсутствие автоматического backup

Ручной backup часто забывают делать.

Лучше использовать cron.

---

## Хранение backup на том же сервере

Если сервер выйдет из строя, backup тоже может быть потерян.

Лучше хранить копии:

* на другом сервере
* в облаке
* в S3-хранилище

---

# Рекомендуемая стратегия backup

Минимальная стратегия:

* ежедневный backup базы данных
* ежедневный backup volumes
* хранение копий минимум 7 дней

---

# Краткая памятка

```bash id="22r5v7"
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
```