DevOps-инженер с нуля: пошаговый план обучения на практическом проекте

DevOps проще понять, когда у вас есть приложение, которое нужно изменить, проверить, запустить и восстановить после ошибки. В этом уроке вы создадите небольшой HTTP-сервис, сохраните его в Git и получите первый проверяемый результат. Затем разберём, какие инженерные задачи добавляются при переходе от запуска на ноутбуке к эксплуатации.

Результат практикума: локальный сервис отвечает JSON на /health, возвращает 404 для неизвестного пути, хранится в репозитории и имеет инструкцию проверки. Для выполнения нужны Linux или WSL, Git, curl и PHP CLI 8.3+. Знание Laravel и покупка VPS не требуются. Выделите около часа; время зависит от знакомства с терминалом.

1. Разделите разработку, доставку и эксплуатацию

Разработчик меняет поведение приложения. Доставка превращает исходники в проверенную версию, которую можно установить. Эксплуатация отвечает за доступность этой версии, наблюдение за ошибками и восстановление. DevOps связывает эти обязанности: код и конфигурация имеют историю, изменения проверяются автоматически, запуск воспроизводим, а после релиза команда видит результат.

Названия инструментов не заменяют эту цепочку. Kubernetes без понятного способа выпустить и откатить приложение не делает проект зрелым. Начните с небольшого сервиса: на нём легче увидеть, где заканчивается код и начинается ответственность за работающую систему.

2. Подготовьте рабочий каталог

Проверьте наличие программ. Эти команды ничего не устанавливают:

git --version
php --version
curl --version
mkdir -p devops-lab/public
cd devops-lab
git init -b main

Если команда не найдена, установите соответствующий пакет средствами своей ОС. Для Ubuntu базовый вариант — sudo apt update и sudo apt install git curl php-cli. Версию PHP после установки проверьте отдельно: набор доступных пакетов зависит от выпуска ОС. В WSL работайте внутри Linux-каталога пользователя, чтобы не смешивать права и пути Windows и Linux.

3. Напишите приложение с понятной ответственностью

Создайте файл public/index.php со следующим содержимым. Первый класс формирует данные о состоянии, второй принимает HTTP-путь и создаёт ответ. Для такой небольшой задачи контейнер зависимостей и фреймворк не нужны.

<?php
declare(strict_types=1);

final readonly class HealthStatus
{
    public function __construct(private string $version) {}

    public function toArray(): array
    {
        return ['status' => 'ok', 'version' => $this->version];
    }
}

final readonly class Application
{
    public function __construct(private HealthStatus $health) {}

    public function handle(string $path): void
    {
        header('Content-Type: application/json; charset=utf-8');
        if ($path !== '/health') {
            http_response_code(404);
            echo json_encode(['error' => 'not_found'], JSON_THROW_ON_ERROR);
            return;
        }
        echo json_encode($this->health->toArray(), JSON_THROW_ON_ERROR);
    }
}

$version = getenv('APP_VERSION') ?: 'dev';
$path = parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH);
(new Application(new HealthStatus($version)))->handle((string) $path);

strict_types помогает обнаружить ошибочный тип аргумента, readonly запрещает менять внедрённую конфигурацию после создания объекта. Версия приходит через окружение: один и тот же код можно запустить с разными обозначениями релиза. В ответ не включены пароли, переменные окружения целиком или сведения о базе.

4. Запустите и проверьте HTTP-поведение

Из корня проекта запустите сервер в первом терминале:

APP_VERSION=lab-1 php -S 127.0.0.1:8080 -t public public/index.php

Во втором терминале выполните проверки:

curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8080/missing
curl --fail --silent --show-error http://127.0.0.1:8080/health

Первый запрос должен вернуть HTTP 200 и {"status":"ok","version":"lab-1"}. Второй — HTTP 404 и {"error":"not_found"}. Последняя команда удобна для автоматизации: --fail превращает HTTP-ошибку в ненулевой код завершения. При сетевой ошибке curl тоже завершается неуспешно.

Встроенный PHP-сервер предназначен для разработки. Здесь он слушает только loopback. Это позволяет изучить HTTP без публикации открытого порта. Для реальной эксплуатации понадобятся подходящий веб-сервер, управление процессами, TLS и отдельные настройки доступа.

5. Сохраните воспроизводимую инструкцию

Добавьте .gitignore:

.env
vendor/
*.log

В README.md запишите требуемую версию PHP, команду запуска, два URL проверки и ожидаемые статусы. Это часть инженерной работы: другой человек должен получить результат без вопросов о вашем ноутбуке. Затем зафиксируйте файлы:

git add public/index.php README.md .gitignore
git diff --cached
git commit -m "Add versioned health endpoint"
git log --oneline -1

Если Git просит имя и email, задайте их для этого репозитория через git config user.name и git config user.email. Не публикуйте личный адрес, если для работы используете специальный commit email.

6. Составьте план развития проекта

1. Git: изменение проходит через ветку и review; известен коммит, который работает.
2. CI: каждая правка автоматически проверяет синтаксис и тесты; намеренно сломанный тест останавливает процесс.
3. Контейнер: приложение запускается из одного собранного образа; версия определяется digest, а не содержимым случайной папки.
4. Конфигурация: окружение сервера описано Ansible; изменения видны в diff и воспроизводятся на новой VM.
5. Инфраструктура: Terraform показывает план ресурсов до применения; состояние хранится отдельно от публичного кода.
6. Доставка: GitOps связывает версию образа с декларацией приложения, а проверка rollout подтверждает запуск.
7. Наблюдаемость: метрики и журналы позволяют обнаружить поломку и проверить восстановление.

Для каждого этапа нужен результат, а не просто установленная программа. Запись «настроил CI» слабее, чем «pipeline отклоняет изменение, нарушающее контракт health endpoint». Так же устроено полезное портфолио: исходники, команды воспроизведения, сценарий сбоя, измерение и восстановление.

7. Проведите маленькое учение

Остановите сервер сочетанием Ctrl+C и повторите запрос curl: он должен завершиться с ошибкой соединения. Запустите сервис снова, но с APP_VERSION=lab-2. Убедитесь, что ответ изменился. Теперь вы различаете как минимум три состояния: процесс не запущен, HTTP-путь не существует, рабочая версия отвечает правильно.

Health endpoint пока не проверяет базу или очередь. HTTP 200 здесь подтверждает только работоспособность этого обработчика. Не называйте такую проверку доказательством исправности всей системы. В реальном приложении отдельно определяют liveness, readiness и проверки пользовательского действия.

Ошибки, которые стоит уметь объяснить

• Address already in use: порт занят. Найдите процесс через ss -lntp или выберите 8081 и измените URL проверки.
• Parse error: выполните php -l public/index.php и исправьте указанную строку до повторного запуска.
• Везде 404: проверьте рабочий каталог и наличие public/index.php в команде router script.
• Из другого компьютера не открывается: привязка к 127.0.0.1 разрешает только локальные соединения. Для этого урока это ожидаемо.

Самостоятельное задание и критерий готовности

Добавьте /version, возвращающий только версию, сохранив 404 для неизвестных путей. Зафиксируйте изменение отдельным коммитом. Попросите другого человека запустить проект по README. Практика завершена, если он получает ожидаемые ответы, а вы можете показать, какой коммит изменил поведение и как вернуться к предыдущему состоянию.

Для уточнения поведения используйте официальные справочники встроенного PHP-сервера, readonly-классов и Git. Основные действия практикума приведены здесь целиком; документация нужна для расширения и проверки деталей вашей версии.

Статья может содержать партнёрские ссылки. Это не влияет на стоимость для вас, но помогает развивать блог.