Лекция 8. Основы DevOps-практик

1. Что такое DevOps

1.1. Историческая предпосылка: «стена» между Dev и Ops

Традиционная модель разработки ПО предполагала чёткое разделение ролей:

Dev (разработчики) пишут код и хотят выпускать новые фичи как можно чаще.
Ops (администраторы) отвечают за стабильность продуктовой среды и противятся частым изменениям, поскольку каждое изменение — потенциальный источник сбоя.

Между этими командами возникала так называемая «стена» (wall of confusion): разработчики «перебрасывали» код через стену, а администраторы разбирались, как его развернуть. Результат — длинные циклы релизов, взаимные обвинения при сбоях, низкая скорость поставки.

DevOps возник как ответ на эту проблему — движение за устранение барьеров между разработкой и эксплуатацией.

1.2. Философия CALMS

DevOps — это не конкретный инструмент и не должность, а культурная и организационная философия. Её часто описывают через фреймворк CALMS:

Принцип	Описание
Culture	Культура сотрудничества, общей ответственности, отсутствия обвинений (blameless culture).
Automation	Автоматизация всего, что можно автоматизировать: сборка, тестирование, развёртывание, мониторинг.
Lean	Бережливый подход: устранение лишних шагов, уменьшение размера batch’ей, быстрая обратная связь.
Measurement	Измерение всего: время от коммита до продуктива, частота деплоев, время восстановления после сбоя (MTTR).
Sharing	Обмен знаниями, инструментами и ответственностью между командами.

Ключевая мысль: внедрение Jenkins или Docker ещё не делает организацию «DevOps». DevOps начинается с изменения культуры и процессов.

2. Жизненный цикл ПО в DevOps

DevOps описывает жизненный цикл ПО как непрерывный процесс — бесконечную ленту (infinity loop):

    Plan → Code → Build → Test
      ↑                       ↓
   Monitor                 Release
      ↑                       ↓
    Operate ← Deploy ← (approve)

Каждый этап переходит в следующий, а после мониторинга цикл начинается заново:

Этап	Описание	Инструменты (примеры)
Plan	Планирование задач, backlog	Jira, GitHub Issues, Linear
Code	Написание кода, code review	Git, GitHub, GitLab
Build	Компиляция, сборка артефактов	Maven, npm, Docker build
Test	Автоматическое тестирование	pytest, Jest, Selenium
Release	Подготовка релиза, тегирование	SemVer, GitHub Releases
Deploy	Развёртывание в среду	Kubernetes, Ansible, Terraform
Operate	Эксплуатация, масштабирование	Kubernetes, Docker Compose
Monitor	Мониторинг, алерты, логи	Prometheus, Grafana, ELK

3. Git для DevOps

3.1. Роль системы контроля версий

Git — фундамент DevOps. Всё, что касается проекта, хранится в репозитории: код, конфигурации, Dockerfile, CI/CD-пайплайны, документация, IaC-скрипты. Это обеспечивает:

Воспроизводимость: любое состояние системы можно воссоздать из кода.
Аудит: история изменений доступна через git log.
Совместную работу: ветвление и слияние позволяют работать параллельно.

3.2. Стратегии ветвления

GitFlow

Классическая модель с несколькими долгоживущими ветками:

main ──────●──────────────●──────────────●─────
            \            / \            /
develop ─────●──●──●──●── ──●──●──●──●──
              \      /        \      /
feature/X ─────●──●──          ●──●──
                              release/1.0

main — стабильная ветка, только релизы.
develop — интеграционная ветка.
feature/* — ветки для новых функций (от develop, мержатся в develop).
release/* — подготовка релиза (фиксация багов).
hotfix/* — срочные исправления от main.

GitHub Flow

Упрощённая модель:

main ────●─────────●─────────●─────────●────
          \       /           \       /
feature ───●──●──●             ●──●──●
           (PR + review)       (PR + review)

Единственная долгоживущая ветка — main.
Для каждой задачи создаётся feature-ветка.
Изменения попадают в main через Pull Request с code review.

Trunk-Based Development

Минимум ветвления:

Все разработчики коммитят напрямую в main (или в очень короткоживущие ветки, живущие часы, не дни).
Требует высокой культуры тестирования и feature flags.

3.3. Сравнительная таблица

Характеристика	GitFlow	GitHub Flow	Trunk-Based
Сложность	Высокая	Средняя	Низкая
Длина веток	Долгоживущие	Короткоживущие	Минимальные
Подходит для	Релизные циклы	Непрерывная поставка	Частые деплои
Merge-конфликты	Частые	Редкие	Минимальные
Порог входа	Высокий	Низкий	Средний (нужна дисциплина)

3.4. Семантическое версионирование (SemVer)

Формат: MAJOR.MINOR.PATCH (например, 2.4.1):

MAJOR — обратно несовместимые изменения API.
MINOR — новая функциональность, обратно совместимая.
PATCH — исправление багов, обратно совместимое.

git tag -a v1.2.0 -m "Release 1.2.0: добавлена авторизация через OAuth"
git push origin v1.2.0

4. CI — Continuous Integration

4.1. Идея

Continuous Integration — практика, при которой каждый разработчик часто интегрирует свой код в общую ветку (несколько раз в день). Каждая интеграция автоматически проверяется сборкой и тестами.

4.2. Зачем

Раннее обнаружение ошибок: конфликты и баги выявляются при каждом коммите, а не накануне релиза.
Уверенность в качестве: если тесты проходят — код работает.
Быстрая обратная связь: разработчик узнаёт о проблеме через минуты, а не дни.

4.3. Ключевые практики CI

Коммитить часто — маленькие изменения легче ревьюить и тестировать.
Зелёный main — главная ветка всегда в рабочем состоянии.
Автоматические тесты — юнит-тесты, интеграционные тесты, линтинг.
Быстрая сборка — CI-пайплайн должен занимать минуты, не часы.

5. CD — Continuous Delivery / Continuous Deployment

5.1. Различие

Термин	Описание
Continuous Delivery	Код всегда готов к релизу. Развёртывание в production происходит по ручному решению (нажатие кнопки).
Continuous Deployment	Код автоматически разворачивается в production после прохождения всех проверок. Ручное вмешательство не требуется.

5.2. Типичный пайплайн CD

Code → Build → Unit Tests → Integration Tests → Staging → (approve) → Production
 │       │          │              │                │           │            │
 Git   Docker    pytest        docker compose     Deploy      Manual/     Deploy
push   build    + lint         + test DB          to staging  Auto gate   to prod

Каждый этап — «ворота качества» (quality gate). Если любой этап не прошёл — пайплайн останавливается, разработчик получает уведомление.

6. GitHub Actions: подробно

6.1. Что такое GitHub Actions

GitHub Actions — встроенная в GitHub платформа CI/CD. Пайплайны описываются в YAML-файлах в каталоге .github/workflows/.

6.2. Структура workflow-файла

name: CI Pipeline                    # Имя пайплайна (отображается в UI)

on:                                  # Триггеры запуска
  push:
    branches: [main, develop]        # При push в main или develop
  pull_request:
    branches: [main]                 # При PR в main

jobs:                                # Задачи (могут выполняться параллельно)
  lint:
    runs-on: ubuntu-latest           # Тип раннера
    steps:
      - uses: actions/checkout@v4    # Клонировать репозиторий
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install flake8
      - run: flake8 src/

  test:
    runs-on: ubuntu-latest
    needs: lint                      # Запустить ПОСЛЕ lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest tests/ -v

6.3. Триггеры (on)

on:
  push:                              # При push
    branches: [main]
    tags: ["v*"]                     # При push тега (v1.0.0, v2.1.3)
  pull_request:                      # При открытии/обновлении PR
    branches: [main]
  schedule:                          # По расписанию (cron)
    - cron: "0 6 * * 1"             # Каждый понедельник в 06:00 UTC
  workflow_dispatch:                 # Ручной запуск через UI GitHub
    inputs:
      environment:
        description: "Deploy target"
        required: true
        default: "staging"

6.4. Jobs и Steps

Job — набор шагов, выполняющихся на одном раннере. Jobs по умолчанию запускаются параллельно; для последовательного запуска используют needs.
Step — отдельный шаг: либо action (uses), либо команда (run).

6.5. Runners

Тип	Описание
GitHub-hosted	Виртуальные машины, управляемые GitHub (`ubuntu-latest`, `macos-latest`, `windows-latest`). Чистое окружение каждый раз.
Self-hosted	Собственные серверы организации. Больше контроля, доступ к внутренним ресурсам.

6.6. Полный пример пайплайна: lint → test → build → push

name: Full CI/CD Pipeline

on:
  push:
    branches: [main]
    tags: ["v*"]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # === Шаг 1: Линтинг ===
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install flake8 black
      - run: flake8 src/
      - run: black --check src/

  # === Шаг 2: Тестирование ===
  test:
    runs-on: ubuntu-latest
    needs: lint
    services:                        # Сервисные контейнеры (БД для тестов)
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        ports: ["5432:5432"]
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest tests/ -v --tb=short
        env:
          DATABASE_URL: postgresql://postgres:testpass@localhost:5432/testdb

  # === Шаг 3: Сборка и публикация Docker-образа ===
  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: startsWith(github.ref, 'refs/tags/v')   # Только при push тега
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest

7. Секреты и переменные

7.1. GitHub Secrets

Конфиденциальные данные (токены, пароли, ключи) никогда не хранятся в коде. GitHub предоставляет механизм Secrets:

steps:
  - name: Deploy
    run: ./deploy.sh
    env:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
      SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}

Secrets задаются в настройках репозитория (Settings → Secrets and variables → Actions) и маскируются в логах.

7.2. Environment Secrets

Для разных сред (staging, production) можно создать Environments с отдельными секретами и правилами approval:

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production          # Требует approval, свои секреты
    steps:
      - run: echo "Deploying to production"
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}  # Секрет из environment

7.3. Безопасность

Не хардкодить токены, пароли, ключи в коде или CI-файлах.
Ротация секретов — периодически обновлять токены и пароли.
Принцип наименьших привилегий — давать токенам только те права, которые необходимы.

8. Артефакты и кэширование

8.1. Артефакты (actions/upload-artifact)

Артефакты позволяют сохранить файлы между jobs или для последующего скачивания:

steps:
  - run: pytest tests/ --junitxml=report.xml
  - uses: actions/upload-artifact@v4
    with:
      name: test-report
      path: report.xml
      retention-days: 30             # Хранить 30 дней

8.2. Кэширование (actions/cache)

Кэширование зависимостей ускоряет пайплайн, избегая повторной загрузки:

steps:
  - uses: actions/cache@v4
    with:
      path: ~/.cache/pip             # Что кэшировать
      key: pip-${{ hashFiles('requirements.txt') }}  # Ключ кэша
      restore-keys: |
        pip-                         # Fallback-ключи
  - run: pip install -r requirements.txt

При изменении requirements.txt хэш изменится → кэш пересоздастся. Без изменений — зависимости берутся из кэша, экономя минуты на каждой сборке.

9. Мониторинг и логирование

9.1. Зачем нужен мониторинг

Развернуть приложение в production — лишь половина дела. Необходимо непрерывно наблюдать за его состоянием: отвечает ли сервис, какова нагрузка, не растёт ли потребление памяти, нет ли ошибок.

9.2. Три столпа наблюдаемости (observability)

Столп	Описание	Пример
Логи (Logs)	Текстовые записи о событиях. Подробные, но объёмные.	`2025-01-15 10:23:45 ERROR: Connection to DB refused`
Метрики (Metrics)	Числовые показатели, агрегированные по времени. Компактные, удобны для алертов.	`http_requests_total{status="500"} = 42`
Трейсы (Traces)	Путь запроса через микросервисы. Показывает, где тратится время.	`Request → API (12ms) → DB (45ms) → Cache (2ms)`

9.3. Обзор инструментов

Prometheus — система сбора метрик:

Использует pull-модель: Prometheus периодически опрашивает (scrape) эндпоинты сервисов.
Метрики экспортируются в формате /metrics (текстовый формат).
Запросы к данным через язык PromQL:

# Средний RPS за последние 5 минут
rate(http_requests_total[5m])

# 99-й перцентиль времени ответа
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

Grafana — платформа визуализации:

Подключается к Prometheus (и другим источникам данных).
Позволяет строить дашборды с графиками, таблицами, алертами.
Поддерживает шаблоны и переменные для гибкой фильтрации.

ELK Stack / Loki — для работы с логами:

ELK (Elasticsearch + Logstash + Kibana) — мощный, но ресурсоёмкий стек.
Loki (от Grafana Labs) — легковесная альтернатива, хранит только метки (labels), а не полный текст логов. Интегрируется с Grafana.

10. Инфраструктура как код (IaC)

10.1. Идея

Infrastructure as Code — подход, при котором инфраструктура (серверы, сети, балансировщики, базы данных) описывается в коде, который хранится в git, проходит code review и версионируется.

Преимущества:

Воспроизводимость: одну и ту же среду можно создать многократно.
Аудит: все изменения инфраструктуры отслеживаются в git.
Автоматизация: развёртывание среды — одна команда, а не ручная настройка.

10.2. Terraform

Terraform (HashiCorp) — декларативный инструмент IaC:

Описываем желаемое состояние инфраструктуры в файлах .tf (язык HCL).
Terraform вычисляет разницу между текущим и желаемым состоянием (plan) и применяет изменения (apply).
Провайдеры: плагины для работы с облаками (AWS, GCP, Azure), DNS, GitHub и т.д.
State: Terraform хранит текущее состояние инфраструктуры в файле terraform.tfstate.

# main.tf — пример: создание виртуальной машины в облаке
provider "aws" {
  region = "eu-west-1"
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

terraform init     # Скачать провайдеры
terraform plan     # Показать, что будет сделано
terraform apply    # Применить изменения
terraform destroy  # Удалить инфраструктуру

10.3. Ansible

Ansible (Red Hat) — инструмент управления конфигурацией и развёртывания:

Agentless: не требует установки агента на управляемых серверах — работает через SSH.
Конфигурация описывается в playbooks (YAML).
Inventory: список серверов, на которых выполняются задачи.
Сочетает процедурный и декларативный подходы: задачи выполняются по порядку, но многие модули идемпотентны (повторное выполнение не меняет результат).

# playbook.yml — установка и настройка Nginx
---
- name: Настройка веб-сервера
  hosts: webservers                    # Группа из inventory
  become: yes                          # Повышение привилегий (sudo)

  tasks:
    - name: Установить Nginx
      apt:
        name: nginx
        state: present
        update_cache: yes

    - name: Скопировать конфигурацию
      copy:
        src: files/nginx.conf
        dest: /etc/nginx/nginx.conf
      notify: Restart Nginx            # Вызвать handler при изменении

    - name: Убедиться, что Nginx запущен
      service:
        name: nginx
        state: started
        enabled: yes

  handlers:
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

[webservers]
server1.example.com
server2.example.com

[databases]
db1.example.com

10.4. Сравнение Terraform и Ansible

Характеристика	Terraform	Ansible
Тип	Provisioning (создание инфраструктуры)	Configuration management (настройка серверов)
Подход	Декларативный	Процедурный с идемпотентностью
Состояние	Хранит state-файл	Не хранит состояние
Агент	Нет (работает через API провайдеров)	Нет (работает через SSH)
Язык	HCL	YAML
Типичное применение	Создание серверов, сетей, БД в облаке	Установка ПО, настройка конфигов

На практике Terraform и Ansible часто используются вместе: Terraform создаёт инфраструктуру (серверы, сети), Ansible настраивает созданные серверы (устанавливает ПО, копирует конфигурации).

11. Безопасность в DevOps (DevSecOps)

11.1. Shift-left security

Традиционный подход: проверка безопасности происходит в конце цикла разработки, перед релизом. DevSecOps предлагает сдвинуть безопасность влево (shift left) — встраивать проверки на ранних этапах:

Традиционный:  Code → Build → Test → Release → Security Review → Deploy
DevSecOps:     Code+Security → Build+Scan → Test+SAST → Release → Deploy

11.2. Сканирование образов

Docker-образы могут содержать уязвимые пакеты. Инструменты сканирования:

Docker Scout — встроенный в Docker Desktop анализ уязвимостей.
Trivy (Aqua Security) — open-source сканер, поддерживает образы, файловые системы, IaC-конфигурации.

# Сканирование образа с помощью Trivy
trivy image myapp:latest

# Пример вывода:
# myapp:latest (debian 12.4)
# Total: 15 (HIGH: 3, CRITICAL: 1)
# ┌──────────────┬────────────────┬──────────┬───────────────────┐
# │   Library    │ Vulnerability  │ Severity │  Fixed Version    │
# ├──────────────┼────────────────┼──────────┼───────────────────┤
# │ openssl      │ CVE-2024-XXXX  │ CRITICAL │ 3.0.13-1~deb12u1  │
# └──────────────┴────────────────┴──────────┴───────────────────┘

11.3. SAST и DAST

Тип	Описание
SAST (Static Application Security Testing)	Анализ исходного кода без его выполнения. Находит SQL-инъекции, XSS, утечки секретов. Инструменты: Semgrep, SonarQube, CodeQL.
DAST (Dynamic Application Security Testing)	Тестирование работающего приложения — отправка вредоносных запросов, поиск уязвимостей в runtime. Инструменты: OWASP ZAP, Burp Suite.

11.4. Управление секретами

GitHub Secrets — для CI/CD (уже рассмотрены выше).
HashiCorp Vault — централизованное хранилище секретов с API, ротацией, аудитом.
Принцип наименьших привилегий — каждый сервис и пользователь получает только те права, которые необходимы для его задач.

12. Обзор современных трендов

12.1. GitOps

GitOps — подход, при котором git-репозиторий является единственным источником истины для инфраструктуры и приложений. Специальный оператор в кластере отслеживает репозиторий и автоматически применяет изменения:

Developer → git push → Git repo ← ArgoCD/Flux → Kubernetes cluster

Инструменты:

ArgoCD — декларативный GitOps-контроллер для Kubernetes.
Flux — набор инструментов от Weaveworks для GitOps.

Преимущества GitOps:

Вся конфигурация в git — полный аудит.
Откат — это git revert.
Нет прямого доступа к кластеру — всё через PR.

12.2. Podman как альтернатива Docker

Podman — инструмент для работы с контейнерами, совместимый с Docker CLI:

Rootless — контейнеры запускаются без привилегий root, что повышает безопасность.
Daemonless — нет фонового демона (как dockerd). Каждый контейнер — отдельный процесс.
Совместимость: alias docker=podman — большинство команд работают без изменений.

12.3. Serverless-контейнеры

Платформы, которые скрывают управление серверами и кластерами:

Google Cloud Run — запуск контейнеров без управления инфраструктурой. Масштабирование до нуля.
AWS Fargate — serverless-движок для ECS/EKS. Не нужно управлять EC2-инстансами.
Azure Container Instances — запуск контейнеров по требованию.

Разработчик предоставляет Docker-образ; платформа берёт на себя масштабирование, балансировку, мониторинг.

13. Итоги курса

На протяжении курса мы прошли путь от фундаментальных основ операционных систем до современных DevOps-практик:

Лекция	Тема	Ключевые понятия
1	Введение в ОС	Ядро, классификация, функции ОС
2	Процессы и потоки	Процесс, поток, планирование, состояния
3	Управление памятью	Виртуальная память, страницы, подкачка
4	Файловые системы и ввод-вывод	Файловые системы, права доступа, устройства
5	Компьютерные сети	TCP/IP, DNS, HTTP, модель OSI
6	Docker и контейнеризация	Контейнеры, образы, Dockerfile, volumes, networks
7	Docker Compose и оркестрация	Compose, healthchecks, реестры, Kubernetes (обзор)
8	Основы DevOps	CI/CD, GitHub Actions, IaC, мониторинг, безопасность

Что дальше:

Kubernetes на практике: развёртывание приложений, Helm, ConfigMaps, Ingress.
Облачные платформы: AWS, GCP, Azure — IaaS, PaaS, managed-сервисы.
SRE (Site Reliability Engineering): SLI/SLO/SLA, error budgets, toil reduction.
Продвинутые темы: service mesh (Istio), chaos engineering, platform engineering.

14. Вопросы для самопроверки

Что такое DevOps? Почему это «культура», а не инструмент? Расшифруйте принципы CALMS.
Перечислите этапы жизненного цикла ПО в модели DevOps. Почему его изображают в виде бесконечной ленты?
Сравните стратегии ветвления GitFlow, GitHub Flow и Trunk-Based Development. В каких ситуациях каждая предпочтительнее?
В чём разница между Continuous Delivery и Continuous Deployment?
Опишите структуру workflow-файла GitHub Actions. Что такое job, step, runner?
Как безопасно передать конфиденциальные данные (токен, пароль) в CI/CD-пайплайн GitHub Actions?
Зачем нужно кэширование зависимостей в CI? Как работает actions/cache?
Назовите три столпа наблюдаемости (observability). Чем метрики отличаются от логов?
Чем Terraform отличается от Ansible? Как они дополняют друг друга?
Что такое DevSecOps и принцип «shift left»? Какие инструменты используются для сканирования Docker-образов?