Автоматизация деплоя: сэкономьте 6 ч на 30‑сек задаче
Пошаговый гайд по автоматизации деплоя с monitoring и automation: экономьте 6 ч, избегайте лишних зависимостей и упрощайте процесс за 30 сек.
Требования
- Базовые знания Bash или Python
- Доступ к серверу по SSH
- Установленный Git
- Понимание CI/CD-пайплайнов
Оцените реальную стоимость автоматизации
Прежде чем писать скрипт, посчитайте: сколько раз в неделю вы выполняете задачу, сколько времени она занимает и сколько часов уйдёт на автоматизация. Если задача выполняется реже раза в неделю и занимает меньше минуты — автоматизация, скорее всего, не окупится. Запишите метрики: частота выполнения, текущее время, ожидаемое время на автоматизацию.
# Простая таблица для оценки
# | Метрика | Значение |
# |---|---|
# | Частота выполнения | 2 раза/неделю |
# | Время вручную | 30 сек |
# | Время на автоматизацию | 6 часов |
# | Окупаемость | ~26 недель |Начните с простого скрипта деплоя
Создайте минимальный bash-скрипт, который делает ровно то, что вы делаете вручную. Не добавляйте обработку ошибок, роллбэки и мониторинг на этом этапе — только основной путь. Скрипт должен быть читаемым и понятным через 6 месяцев.
#!/usr/bin/env bash
set -euo pipefail
# deploy.sh — минимальный скрипт деплоя
echo "→ Сборка проекта..."
npm run build
echo "→ Копирование на сервер..."
rsync -avz --delete ./dist/ user@server:/var/www/app/
echo "→ Перезапуск сервиса..."
ssh user@server 'sudo systemctl restart myapp'
echo "✅ Деплой завершён: $(date '+%Y-%m-%d %H:%M:%S')"Добавьте базовую проверку здоровья
После деплоя убедитесь, что приложение действительно работает. Один HTTP-запрос к health-endpoint — этого достаточно для начала. Не подключайте три системы мониторинга сразу — начните с одного проверочного запроса.
#!/usr/bin/env bash
set -euo pipefail
HEALTH_URL="https://example.com/health"
MAX_RETRIES=5
RETRY_DELAY=10
# ... (шаги деплоя из предыдущего скрипта) ...
echo "→ Проверка здоровья..."
for i in $(seq 1 $MAX_RETRIES); do
STATUS=$(curl -s -o /dev/null -w '%{http_code}' "$HEALTH_URL")
if [ "$STATUS" = "200" ]; then
echo "✅ Приложение здорово (попытка $i)"
exit 0
fi
echo "⚠️ Попытка $i: статус $STATUS, повтор через ${RETRY_DELAY}с..."
sleep $RETRY_DELAY
done
echo "❌ Приложение не ответило после $MAX_RETRIES попыток"
exit 1Реализуйте простой роллбэк
Сохраняйте предыдущую версию и добавьте скрит отката. Это проще, чем кажется: достаточно хранить символическую ссылку на предыдущий релиз и уметь переключаться обратно.
#!/usr/bin/env bash
set -euo pipefail
DEPLOY_DIR="/var/www/app"
RELEASES_DIR="/var/www/releases"
CURRENT_LINK="$DEPLOY_DIR/current"
rollback() {
echo "→ Откат к предыдущей версии..."
PREVIOUS=$(readlink -f "$CURRENT_LINK" | xargs dirname | xargs ls -td | sed -n '2p')
if [ -z "$PREVIOUS" ]; then
echo "❌ Нет предыдущей версии для отката"
exit 1
fi
ln -sfn "$PREVIOUS" "$CURRENT_LINK"
sudo systemctl restart myapp
echo "✅ Откат к $(basename $PREVIOUS) завершён"
}
# Использование в основном скрипте:
# trap rollback ERR # автоматический откат при ошибкеПодключите один инструмент мониторинга
Выберите один инструмент для отслеживания деплоев. Для начала достаточно простого логирования в файл или отправки уведомления в Slack/Telegram. Не устанавливайте Prometheus, Grafana и Datadog одновременно — это и есть та самая «зависимость от трёх систем мониторинга».
#!/usr/bin/env bash
# Вариант 1: логирование в файл
LOG_FILE="/var/log/deployments.log"
log_deploy() {
echo "$(date -Iseconds) | $1 | status=$2 | duration=${3}s" >> "$LOG_FILE"
}
# Вариант 2: уведомление в Telegram
TELEGRAM_BOT_TOKEN="your-token"
TELEGRAM_CHAT_ID="your-chat-id"
notify_telegram() {
local message="🚀 *Деплой*\n$1\nСтатус: $2"
curl -s -X POST \
"https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
-d chat_id="$TELEGRAM_CHAT_ID" \
-d text="$message" \
-d parse_mode="Markdown" > /dev/null
}
# Использование:
# log_deploy "myapp" "success" "45"
# notify_telegram "myapp v1.2.3" "✅ Успешно"Интегрируйте в CI/CD пайплайн
Подключите скрипт к вашей CI/CD-системе. Для GitHub Actions — создайте workflow-файл, который запускает деплой при пуше в main-ветку. Это стандартный подход, который не требует кастомных решений.
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup SSH
run: |
mkdir -p ~/.ssh
echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
ssh-keyscan -H ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts
- name: Deploy
run: |
chmod +x deploy.sh
./deploy.sh
env:
SERVER_IP: ${{ secrets.SERVER_IP }}Документируйте и остановитесь
Напишите README к вашему скрипту деплоя: что он делает, как запустить, как откатить. После этого — остановитесь. Не добавляйте фичи «на будущее». Если через месяц понадобится что-то новое — добавите тогда. Помните: лучшая автоматизация — та, которую не нужно поддерживать.
# Deployment
## Быстрый старт
```bash
# Деплой последней версии
./deploy.sh
# Ручной откат
./deploy.sh --rollback
```
## Требования
- SSH-доступ к серверу
- rsync
- Node.js 18+
## Мониторинг
- Логи: `/var/log/deployments.log`
- Уведомления: Telegram-канал #deployments
## Откат
```bash
./deploy.sh --rollback
```Автоматизация деплоя: не тратьте 6 часов на 30-секундную задачу
Описание: Пошаговый гайд по разумной автоматизации деплоя с мониторингом — без избыточной сложности и зависимостей. Научитесь окупать время на автоматизацию и не усложнять процесс.
Предварительные требования
- Базовые знания Bash или Python
- Доступ к серверу по SSH
- Установленный Git
- Понимание CI/CD-пайплайнов
Шаг 1: Оцените реальную стоимость автоматизации
Прежде чем писать скрипт, посчитайте: сколько раз в неделю вы выполняете задачу, сколько времени она занимает и сколько часов уйдёт на автоматизацию. Если задача выполняется реже раза в неделю и занимает меньше минуты — автоматизация, скорее всего, не окупится.
Таблица для оценки окупаемости
Запишите метрики: частота выполнения, текущее время, ожидаемое время на автоматизацию.
# Простая таблица для оценки
# | Метрика | Значение |
# |---|---|
# | Частота выполнения | 2 раза/неделю |
# | Время вручную | 30 сек |
# | Время на автоматизацию | 6 часов |
# | Окупаемость | ~26 недель |
Шаг 2: Начните с простого скрипта деплоя
Создайте минимальный bash-скрипт, который делает ровно то, что вы делаете вручную. Не добавляйте обработку ошибок, роллбэки и мониторинг на этом этапе — только основной путь. Скрипт должен быть читаемым и понятным через 6 месяцев.
Минимальный скрипт
#!/usr/bin/env bash
set -euo pipefail
# deploy.sh — минимальный скрипт деплоя
echo "→ Сборка проекта..."
npm run build
echo "→ Копирование на сервер..."
rsync -avz --delete ./dist/ user@server:/var/www/app/
echo "→ Перезапуск сервиса..."
ssh user@server 'sudo systemctl restart myapp'
echo "✅ Деплой завершён: $(date '+%Y-%m-%d %H:%M:%S')"
Шаг 3: Добавьте базовую проверку здоровья
После деплоя убедитесь, что приложение действительно работает. Один HTTP-запрос к health-endpoint — этого достаточно для начала. Не подключайте три системы мониторинга сразу — начните с одного проверочного запроса.
Health-check с повторами
#!/usr/bin/env bash
set -euo pipefail
HEALTH_URL="https://example.com/health"
MAX_RETRIES=5
RETRY_DELAY=10
# ... (шаги деплоя из предыдущего скрипта) ...
echo "→ Проверка здоровья..."
for i in $(seq 1 $MAX_RETRIES); do
STATUS=$(curl -s -o /dev/null -w '%{http_code}' "$HEALTH_URL")
if [ "$STATUS" = "200" ]; then
echo "✅ Приложение здорово (попытка $i)"
exit 0
fi
echo "⚠️ Попытка $i: статус $STATUS, повтор через ${RETRY_DELAY}с..."
sleep $RETRY_DELAY
done
echo "❌ Приложение не ответило после $MAX_RETRIES попыток"
exit 1
Шаг 4: Реализуйте простой роллбэк
Сохраняйте предыдущую версию и добавьте скрипт отката. Это проще, чем кажется: достаточно хранить символическую ссылку на предыдущий релиз и уметь переключаться обратно.
Функция отката
#!/usr/bin/env bash
set -euo pipefail
DEPLOY_DIR="/var/www/app"
RELEASES_DIR="/var/www/releases"
CURRENT_LINK="$DEPLOY_DIR/current"
rollback() {
echo "→ Откат к предыдущей версии..."
PREVIOUS=$(readlink -f "$CURRENT_LINK" | xargs dirname | xargs ls -td | sed -n '2p')
if [ -z "$PREVIOUS" ]; then
echo "❌ Нет предыдущей версии для отката"
exit 1
fi
ln -sfn "$PREVIOUS" "$CURRENT_LINK"
sudo systemctl restart myapp
echo "✅ Откат к $(basename $PREVIOUS) завершён"
}
# Использование в основном скрипте:
# trap rollback ERR # автоматический откат при ошибке
Шаг 5: Подключите один инструмент мониторинга
Выберите один инструмент для отслеживания деплоев. Для начала достаточно простого логирования в файл или отправки уведомления в Slack/Telegram. Не устанавливайте Prometheus, Grafana и Datadog одновременно — это и есть та самая «зависимость от трёх систем мониторинга».
Логирование и уведомления
#!/usr/bin/env bash
# Вариант 1: логирование в файл
LOG_FILE="/var/log/deployments.log"
log_deploy() {
echo "$(date -Iseconds) | $1 | status=$2 | duration=${3}s" >> "$LOG_FILE"
}
# Вариант 2: уведомление в Telegram
TELEGRAM_BOT_TOKEN="your-token"
TELEGRAM_CHAT_ID="your-chat-id"
notify_telegram() {
local message="🚀 *Деплой*\n$1\nСтатус: $2"
curl -s -X POST \
"https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
-d chat_id="$TELEGRAM_CHAT_ID" \
-d text="$message" \
-d parse_mode="Markdown" > /dev/null
}
# Использование:
# log_deploy "myapp" "success" "45"
# notify_telegram "myapp v1.2.3" "✅ Успешно"
Шаг 6: Интегрируйте в CI/CD-пайплайн
Подключите скрипт к вашей CI/CD-системе. Для GitHub Actions — создайте workflow-файл, который запускает деплой при пуше в main-ветку. Это стандартный подход, который не требует кастомных решений. Если вы используете GitLab, аналогичный процесс описан в нашей статье про настройку GitLab Runner.
Workflow для GitHub Actions
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup SSH
run: |
mkdir -p ~/.ssh
echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
ssh-keyscan -H ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts
- name: Deploy
run: |
chmod +x deploy.sh
./deploy.sh
env:
SERVER_IP: ${{ secrets.SERVER_IP }}
Шаг 7: Документируйте и остановитесь
Напишите README к вашему скрипту деплоя: что он делает, как запустить, как откатить. После этого — остановитесь. Не добавляйте фичи «на будущее». Если через месяц понадобится что-то новое — добавите тогда.
Шаблон документации
Помните: лучшая автоматизация — та, которую не нужно поддерживать. Подробнее о принципах разумной автоматизации — в нашей статье про инфраструктуру как код.
# Deployment
## Быстрый старт
# Деплой последней версии
./deploy.sh
# Ручной откат
./deploy.sh --rollback
## Требования
- SSH-доступ к серверу
- rsync
- Node.js 18+
## Мониторинг
- Логи: `/var/log/deployments.log`
- Уведомления: Telegram-канал #deployments
## Откат
./deploy.sh --rollback
Заключение
Автоматизация деплоя не обязана быть сложной. Семь шагов — от оценки окупаемости до документации — дают рабочую систему без избыточных зависимостей. Начните с простого скрипта, добавьте проверку здоровья и роллбэк, подключите одно уведомление — и остановитесь. Остальное приложится по мере необходимости.