Опишите жизненный цикл деплоя Go-приложения

Жизненный цикл деплоя современного Go-приложения — это автоматизированный процесс, который превращает исходный код в работающий сервис. Обычно он включает следующие этапы:

1. Сборка (Build)

Цель — создать один статически скомпонованный бинарный файл, который не имеет внешних зависимостей (кроме ядра ОС).

# Команда для кросс-компиляции под Linux с оптимизациями для продакшена
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o my-app ./cmd/server

• CGO_ENABLED=0: Отключает Cgo, что гарантирует статическую линковку.
• GOOS=linux: Указывает целевую операционную систему.
• -ldflags="-s -w": Удаляет отладочную информацию и символы, уменьшая размер бинарника.

2. Контейнеризация (Containerization)

Собранный бинарник упаковывается в легковесный Docker-образ. Для этого используется multi-stage build в Dockerfile.

• Преимущества multi-stage:
  1. Маленький размер итогового образа: В финальный образ попадает только скомпилированный бинарник, без исходного кода и инструментов сборки (Go SDK).
  2. Безопасность: Меньше компонентов в образе — меньше потенциальных уязвимостей.

# --- Stage 1: Build --- 
# Используем образ с полным Go SDK для сборки
FROM golang:1.21-alpine AS builder

# Устанавливаем рабочую директорию
WORKDIR /app

# Копируем зависимости и загружаем их
COPY go.mod go.sum ./
RUN go mod download

# Копируем исходный код
COPY . .

# Собираем приложение
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/my-app ./cmd/server

# --- Stage 2: Final --- 
# Используем минимальный базовый образ. `scratch` - пустой образ, `alpine` - легковесный Linux.
FROM alpine:latest

# Копируем только скомпилированный бинарник из стадии сборки
COPY --from=builder /app/my-app /my-app

# (Опционально) Копируем файлы конфигурации или статику
# COPY --from=builder /app/configs /configs

# Указываем порт, который слушает приложение
EXPOSE 8080

# Команда для запуска приложения
CMD ["/my-app"]

3. CI/CD (Непрерывная интеграция и доставка)

Этот этап автоматизируется с помощью систем вроде GitHub Actions, GitLab CI или Jenkins. Типичный пайплайн:

1. Checkout: Загрузка исходного кода из репозитория.
2. Lint & Test: Запуск статических анализаторов (golangci-lint) и юнит/интеграционных тестов (go test ./...).
3. Build: Сборка бинарника (шаг 1).
4. Build & Push Image: Сборка Docker-образа (шаг 2) и его загрузка в реестр контейнеров (Docker Hub, AWS ECR, GCR).
5. Deploy: Развертывание новой версии образа в целевом окружении (staging, production).

4. Развертывание (Deployment)

Способ развертывания зависит от инфраструктуры:

• Kubernetes: Самый популярный вариант. Деплой управляется через kubectl apply, Helm-чарты или Kustomize. Kubernetes берет на себя управление жизненным циклом подов, масштабирование и self-healing.
• Облачные платформы: Serverless-решения (AWS Lambda, GCP Cloud Functions), PaaS (AWS Elastic Beanstalk, GCP App Engine) или контейнерные сервисы (AWS ECS, GCP Cloud Run).
• Виртуальные/физические серверы: Управление через systemd и системы управления конфигурацией (Ansible, Chef).

5. Конфигурация и Наблюдаемость (Configuration & Observability)

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

• Конфигурация: Передается через переменные окружения (env variables), что соответствует принципам 12-factor app. Секреты хранятся в защищенных хранилищах (HashiCorp Vault, AWS Secrets Manager).
• Health Checks: Настраиваются эндпоинты (/healthz, /readyz), которые Kubernetes или балансировщик используют для проверки работоспособности сервиса (Liveness/Readiness probes).
• Метрики: Приложение отдает метрики в формате Prometheus для мониторинга производительности (CPU, memory, RPS, latency).
• Логирование: Сервис пишет структурированные логи (например, в JSON), которые собираются системами вроде Loki, ELK Stack или Splunk.