DevOps-инженер с нуля: фундаментальный курс

Введение в философию и задачи DevOps

Почему в некоторых IT-компаниях релиз нового обновления занимает полгода, а в других — выходит каждые несколько часов? Ответ кроется не в размере команды и не в количестве денег, а в культуре и процессах. Именно здесь появляется DevOps — философия, которая навсегда изменила способ создания программного обеспечения.

Откуда взялся DevOps

До появления DevOps в IT-индустрии существовал чёткий водораздел между двумя лагерями. С одной стороны — разработчики (developers), которые писали код и хотели как можно быстрее внедрять новые функции. С другой — администраторы (operations), которые отвечали за стабильность серверов и боялись любых изменений, потому что каждое обновление могло сломать работающую систему.

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

Переломный момент наступил в 2008 году на конференции Agile Conference, где Патрик Дебуа (Patrick Debois) и Эндрю Шейфер (Andrew Shafer) обсудили идею «敏捷基础设施» — гибкой инфраструктуры. В 2009 году Дебуа организовал первую конференцию DevOpsDays в Бельгии, и термин DevOps закрепился в индустрии. Название сложилось из двух слов: Development (разработка) и Operations (эксплуатация).

> DevOps — это не должность, не инструмент и не технология. Это культура совместной работы, набор практик и философия, которая объединяет разработку и эксплуатацию в единый процесс поставки программного обеспечения. > > Atlassian DevOps Guide

Три принципа DevOps

Философия DevOps опирается на три ключевых принципа, которые часто называют «Три способа» (Three Ways), сформулированные Джином Кимом (Gene Kim) в книге «The Phoenix Project».

Первый принцип — Flow (Поток). Оптимизация потока ценности от идеи до клиента. Представьте конвейер на заводе: если на одном этапе деталь застревает на неделю, весь конвейер тормозит. В IT это означает сокращение времени от написания кода до его развёртывания в продакшене. Каждая задержка — ручное тестирование, согласование изменений, ожидание свободного сервера — это потери, которые нужно устранять.

Второй принцип — Feedback (Обратная связь). Информация о проблемах должна возвращаться к разработчику максимально быстро. Если баг обнаружен через три месяца после релиза, его исправление стоит в десятки раз дороже, чем если бы его нашли через пять минут после коммита. Автоматическое тестирование, мониторинг и алерты — инструменты быстрой обратной связи.

Третий принцип — Continuous Learning (Непрерывное обучение). Команда должна постоянно совершенствовать процессы. После каждого инцидента проводится postmortem — разбор полётов без поиска виноватых, с фокусом на системных причинах проблемы. Культура экспериментов и допустимости ошибок — фундамент инноваций.

Какие задачи решает DevOps-инженер

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

Автоматизация процессов. Вместо того чтобы вручную заливать код на сервер по FTP, DevOps-инженер создаёт автоматические пайплайны, которые собирают, тестируют и развёртывают приложение при каждом коммите. Это называется CI/CD — Continuous Integration / Continuous Delivery (непрерывная интеграция и непрерывная доставка).

Управление инфраструктурой. Серверы, сети, базы данных — всё это нужно настраивать, масштабировать и поддерживать. Современный подход — Infrastructure as Code (инфраструктура как код), когда конфигурация серверов описывается в файлах, которые можно версионировать и автоматически применять.

Контейнеризация и оркестрация. Приложения упаковываются в контейнеры — изолированные окружения, которые работают одинаково на любом сервере. Системы оркестрации вроде Kubernetes управляют сотнями контейнеров, обеспечивая отказоустойчивость и автомасштабирование.

Мониторинг и наблюдаемость. DevOps-инженер настраивает системы, которые отслеживают состояние инфраструктуры в реальном времени: нагрузку на процессор, количество ошибок, задержку ответа. Если что-то идёт не так — приходит оповещение до того, как пользователи заметят проблему.

Безопасность. В зрелых командах безопасность встраивается в пайплайн на каждом этапе — это называется DevSecOps. Сканеры уязвимостей проверяют код и контейнеры автоматически, а секреты (пароли, токены) хранятся в защищённых хранилищах, а не в исходном коде.

DevOps как культура, а не должность

Распространённое заблуждение — считать DevOps отдельной ролью, которую можно «нанять», и все проблемы решатся сами. На практике DevOps работает только когда вся команда разделяет его принципы.

| Подход без DevOps | Подход с DevOps | |---|---| | Разработчики пишут код и «перекидают через стену» администраторам | Разработчики и администраторы работают вместе от начала до конца | | Релизы раз в квартал, с боями | Релизы каждый день, предсказуемо | | Ошибки ищут виноватых | Ошибки анализируют системно | | Инфраструктура настраивается вручную | Инфраструктура описывается кодом | | Мониторинг — «а давайте посмотрим логи» | Мониторинг — автоматический с алертами |

Представьте ресторан. Без DevOps — повар готовит блюдо, ставит на подоконник, и официант забирает, когда заметит. С DevOps — повар и официант работают бок о бок, блюдо передаётся мгновенно, а менеджер видит на экране, сколько заказов в работе и где bottleneck.

Зачем начинать с философии, а не с инструментов

Многие новички бросаются изучать Docker, Kubernetes и Jenkins, не понимая, зачем эти инструменты нужны. Это как покупать молоток, не зная, что строишь дом. Без понимания философии DevOps инструменты превращаются в бессмысленный набор команд.

Когда вы понимаете, что цель — сократить время от идеи до работающего продукта в руках пользователя, — каждый инструмент обретает смысл. Docker нужен, чтобы приложение работало одинаково везде. Kubernetes — чтобы оно не падало при пиковых нагрузках. CI/CD — чтобы обновления выходили быстро и безопасно.

Именно поэтому этот курс начинается с философии. Дальше вы освоите Linux, Git, Docker и CI/CD — но каждый раз будете понимать, какую именно проблему DevOps решает каждый инструмент.

Основы Linux и работа в командной строке

Почему практически все серверы в мире, от небольших сайтов до инфраструктуры Google и Amazon, работают на Linux? Потому что эта операционная система бесплатна, надёжна, безопасна и — что критически важно для DevOps — управляется целиком через командную строку. Без владения Linux и терминалом путь в DevOps закрыт.

Почему DevOps-инженеру нужен именно Linux

Linux — это семейство операционных систем с открытым исходным кодом, построенных на ядре, которое Линус Торвальдс (Linus Torvalds) начал разрабатывать в 1991 году. Сегодня Linux работает на более чем 90% серверов в облаке, на всех суперкомпьютерах TOP500 и на большинстве контейнеров Docker.

Для DevOps-инженера Linux важен по трём причинам. Во-первых, продакшен-среда — это почти всегда Linux-сервер. Даже если вы разрабатываете на Windows или macOS, ваш код в итоге запустится на Linux. Во-вторых, все ключевые инструменты DevOps — Docker, Kubernetes, Ansible, Terraform — проектировались под Linux. В-третьих, философия Unix, на которой построен Linux (маленькие программы, делающие одну вещь хорошо, и соединённые конвейерами), — это та самая философия автоматизации, которая лежит в основе DevOps.

Файловая система Linux

В отличие от Windows с дисками C: и D:, в Linux всё — единое дерево каталогов, начинающееся с корня /. Вот ключевые директории, которые нужно знать:

| Путь | Назначение | |---|---| | / | Корень файловой системы | | /home | Домашние каталоги пользователей | | /etc | Конфигурационные файлы системы | | /var/log | Логи (журналы) систем и приложений | | /tmp | Временные файлы | | /usr/bin | Установленные программы | | /opt | Стороннее программное обеспечение |

Представьте, что файловая система — это здание. /etc — это кабинет администратора, где лежат все инструкции. /var/log — это журнал охраны, куда записывается всё, что происходит. /home — это квартиры жильцов (пользователей).

Базовые команды терминала

Терминал — это текстовый интерфейс для управления компьютером. Вместо кликов мышкой вы вводите команды. Вот те, без которых не обойтись ни одному DevOps-инженеру.

Навигация по файловой системе:

Работа с файлами и каталогами:

Чтение файлов:

Команда tail -f особенно важна для DevOps: она позволяет наблюдать за логами приложения в реальном времени. Когда что-то ломается на сервере, именно с этой команды начинается диагностика.

Права доступа и пользователи

Linux — многопользовательская система. Каждый файл принадлежит пользователю и группе, и у него есть три набора прав: для владельца, для группы и для всех остальных.

Первая часть -rwxr-xr-- читается так: r — read (чтение), w — write (запись), x — execute (исполнение). Первые три символа — права владельца, следующие три — группы, последние — всех остальных.

Изменение прав:

Команда sudo (substitute user do) позволяет выполнять команды с правами суперпользователя:

Пакетный менеджер и установка ПО

В Linux программы устанавливаются через пакетные менеджеры — специальные утилиты, которые скачивают, устанавливают и обновляют программное обеспечение из репозиториев.

В семействе Debian/Ubuntu используется apt:

В семействе CentOS/RHEL — yum или dnf:

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

Конвейеры и перенаправления

Одна из самых мощных концепций Linux — конвейеры (pipes). Символ | передаёт вывод одной команды на вход другой:

Эта цепочка: взять содержимое лога → отфильтровать строки с «error» → посчитать количество строк. Три простые команды дают точный ответ на вопрос «сколько ошибок было в системе».

Перенаправление вывода в файл:

Представьте, что каждая команда — это рабочий на конвейере. Один режет, другой клеит, третий упаковывает. Передавая деталь от одного к другому (|), вы получаете готовый продукт без единого лишнего движения.

Процессы и управление сервисами

Каждая запущенная программа в Linux — это процесс с уникальным идентификатором (PID).

Система systemd управляет сервисами в большинстве современных дистрибутивов. Понимание systemctl — базовый навык: DevOps-инженер постоянно запускает, останавливает и перезапускает сервисы при развёртывании.

Редакторы: nano и vim

Для редактирования файлов прямо в терминале используются текстовые редакторы. Nano — простой и интуитивный: достаточно знать, что Ctrl+O сохраняет, а Ctrl+X выходит. Vim — мощный, но с крутой кривой обучения. Минимальный набор для Vim:

Для начинающего DevOps-инженера nano достаточно. Но со временем vim окупит каждую минуту обучения: редактирование конфигов на удалённом сервере через SSH — повседневная задача, и vim справляется с ней быстрее любого другого инструмента.

SSH — удалённое подключение

SSH (Secure Shell) — протокол для безопасного удалённого доступа к серверу. Это главный инструмент DevOps-инженера: практически всё управление инфраструктурой происходит через SSH.

Пароли для SSH — плохая практика. Стандарт индустрии — SSH-ключи: пара из закрытого (private) и открытого (public) ключа. Открытый ключ кладётся на сервер, закрытый остаётся у вас. Даже если кто-то перехватит ваш открытый ключ, он не сможет подключиться без закрытого.

Linux и командная строка — это не просто инструменты, это среда, в которой живёт DevOps. Каждая команда, которую вы освоите здесь, будет использоваться в Docker, Git, CI/CD и всех последующих темах курса.

Системы контроля версий и основы Git

Представьте, что вы работаете над документом, и каждый раз при сохранении предыдущая версия безвозвратно исчезает. Вы случайно удалили важный абзац — и вернуть его невозможно. Знакомо? Именно эту проблему решают системы контроля версий (Version Control Systems, VCS). А Git — самая распространённая из них, без которой немыслим ни один DevOps-процесс.

Что такое контроль версий и зачем он нужен

Система контроля версий — это инструмент, который отслеживает все изменения в файлах проекта, сохраняет историю этих изменений и позволяет нескольким людям работать над одним проектом одновременно, не мешая друг другу.

Представьте книгу, которую пишут пять авторов. Без контроля версий они пересылают файлы по почте, путаются в названиях «книга_финал_2_настоящий_финал.docx» и случайно перезаписывают правки друг друга. С Git каждый автор работает в своей ветке, а потом изменения аккуратно объединяются. Если что-то пошло не так — можно вернуться к любой предыдущей версии за секунды.

Для DevOps-инженера Git важен не только как инструмент разработчика, но и как фундамент автоматизации. Конфигурация инфраструктуры, пайплайны CI/CD, манифесты Kubernetes — всё это хранится в Git-репозиториях. Когда вы коммитите изменение в конфигурацию, CI/CD-система автоматически применяет его к инфраструктуре. Git — это точка входа в мир автоматизации.

Установка и первоначальная настройка

Git предустановлен в большинстве Linux-дистрибутивов. Если нет:

Первичная настройка — указать имя и email, которые будут привязаны к каждому коммиту:

Три области: рабочая директория, индекс, репозиторий

Чтобы понять Git, нужно представить три «зоны», в которых могут находиться файлы.

Рабочая директория (working directory) — это ваши файлы на диске, с которыми вы работаете.

Индекс (staging area) — это «сборочная площадка», куда вы отбираете файлы для следующего коммита. Не всё, что изменилось, нужно фиксировать в одном коммите — вы выбираете конкретные файлы или даже конкретные строки.

Репозиторий (repository) — это база данных Git, где хранится полная история всех коммитов.

Переход между зонами:

Представьте письмо. Рабочая директория — это черновик на столе. Индекс — это конверт, в который вы положили нужные страницы. Коммит — это опускание конверта в почтовый ящик. После этого письмо (коммит) навсегда сохранено в истории.

Базовые команды Git

Инициализация и клонирование:

Работа с изменениями:

Просмотр истории:

Работа с удалённым репозиторием:

Ветвление и слияние

Ветки (branches) — это параллельные линии разработки. Основная ветка обычно называется main (раньше — master). Когда вы создаёте новую функцию, вы создаёте отдельную ветку, работаете в ней, а потом сливаете обратно в main.

Представьте, что main — это магистральная дорога. Ветка — это объездной путь, на котором вы строите новый мост. Пока мост строится, основная дорога работает как обычно. Когда мост готов, вы соединяете его с магистралью (merge). Если мост получился кривым — вы просто закрываете ветку, и магистраль не пострадала.

Конфликты слияния возникают, когда два человека изменили одну и ту же строку в одном файле. Git не может решить, чья версия правильная, и просит вас разрешить конфликт вручную. В файле появляются маркеры:

Вы выбираете нужный вариант (или комбинируете оба), удаляете маркеры и делаете коммит.

Pull Requests и Code Review

На практике никто не сливает ветки напрямую в main. Вместо этого создаётся Pull Request (на GitHub) или Merge Request (на GitLab) — запрос на слияние, который проходит code review: другие члены команды проверяют код, оставляют комментарии и одобряют или запрашивают изменения.

Это не бюрократия, а защитный механизм. Pull Request позволяет:

Gitignore и хранение секретов

Файл .gitignore указывает Git, какие файлы и директории не нужно отслеживать. Например, файлы с паролями, логи, временные файлы, папки с зависимостями:

Золотое правило: никогда не храните пароли, токены и секретные ключи в Git. Даже если репозиторий приватный, секреты могут попасть в логи CI/CD или в руки к сотруднику с доступом. Для секретов существуют отдельные инструменты: HashiCorp Vault, AWS Secrets Manager, встроенные секреты GitHub/GitLab.

Теги и версионирование

Теги (tags) — это метки на конкретных коммитах, обычно используемые для обозначения версий релизов:

В CI/CD-пайплайнах теги часто используются как триггеры: создание тега v* запускает сборку и публикацию релиза.

Практический сценарий для DevOps

Вот как выглядит типичный рабочий день DevOps-инженера с Git:

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

Git — это не просто инструмент для хранения кода. Это нервная система DevOps-процессов, связывающая разработку, тестирование и развёртывание в единый поток.

Контейнеризация приложений с Docker

Почему приложение, которое идеально работает на ноутбуке разработчика, отказывается запускаться на сервере? Потому что на сервере другая версия ОС, другой набор библиотек, другие настройки. Эта проблема — «на моей машине работает» — мучила индустрию десятилетиями. Docker решил её раз и навсегда, и сегодня контейнеризация — один из столпов DevOps.

Что такое контейнеризация

Контейнеризация — это подход к упаковке приложения вместе со всеми его зависимостями (библиотеками, конфигурациями, средой выполнения) в изолированный контейнер, который запускается одинаково на любом сервере.

Отличие от виртуальной машины (VM) критически важно. Виртуальная машина эмулирует целую операционную систему со своим ядром — это тяжело и медленно. Контейнер разделяет ядро хост-системы и изолирует только процессы, файловую систему и сеть. Результат: контейнеры стартуют за секунды (а не минуты), потребляют мегабайты (а не гигабайты) и на одном сервере могут работать десятки контейнеров.

| Характеристика | Виртуальная машина | Контейнер Docker | |---|---|---| | Время запуска | Минуты | Секунды | | Размер образа | Гигабайты | Мегабайты | | Изоляция | Полная (своё ядро) | На уровне процессов | | Плотность на сервере | 5–10 машин | 50–100 контейнеров |

Установка Docker

На Ubuntu/Debian:

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

Проверка установки:

Команда docker run hello-world скачает минимальный образ, запустит контейнер, выведет приветственное сообщение и завершится. Если это сработало — Docker установлен корректно.

Образы и контейнеры: ключевое различие

Образ (image) — это шаблон, «замороженный снимок» приложения со всеми зависимостями. Он неизменяемый (immutable): вы не можете изменить образ после создания — только создать новый.

Контейнер (container) — это запущенный экземпляр образа. Из одного образа можно запустить сколько угодно контейнеров — каждый будет независимым.

Аналогия: образ — это рецепт блюда, а контейнер — это готовое блюдо на тарелке. Рецепт не меняется, но по нему можно приготовить сотню порций.

Базовые команды Docker

Работа с образами:

Работа с контейнерами:

Команда docker exec -it web bash — ваш главный друг при отладке. Она открывает интерактивную оболочку внутри контейнера, где вы можете проверить файлы, переменные окружения и сетевые настройки.

Персистентность данных: volumes

Контейнеры по умолчанию эфемерны: всё, что записано внутри, исчезает при удалении контейнера. Для хранения данных между перезапусками используются тома (volumes):

Теперь данные PostgreSQL хранятся в томе db_data вне контейнера. Даже если вы удалите контейнер и создадите новый с тем же томом — данные сохранятся. Это фундаментальный принцип: контейнеры — stateless, данные — в volumes.

Dockerfile: сборка собственных образов

Dockerfile — это инструкция по сборке собственного образа. Это текстовый файл с пошаговыми командами:

Разбор по строкам:

Сборка образа:

Точка в конце — путь к контейксту сборки (текущая директория). Docker прочитает Dockerfile из этой директории и создаст образ myapp:1.0.

Слои и кэширование — важная оптимизация. Docker выполняет каждую инструкцию Dockerfile как отдельный слой. Если вы сначала скопируете код (COPY . .), а потом установите зависимости (RUN pip install), то при любом изменении кода зависимости будут переустанавливаться заново. Поэтому сначала копируем requirements.txt, устанавливаем зависимости, а потом копируем код — так слой с зависимостями закэшируется.

Docker Compose: многоконтейнерные приложения

Реальные приложения редко состоят из одного контейнера. Обычно есть веб-сервер, база данных, кэш и другие сервисы. Docker Compose позволяет описать всю систему в одном YAML-файле:

Запуск всей системы:

Одна команда — и у вас работает веб-приложение с базой данных и кэшем. Это именно тот уровень автоматизации, к которому стремится DevOps.

Сети в Docker

Docker автоматически создаёт изолированные сети для контейнеров. Сервисы из одного docker-compose.yml могут обращаться друг к другу по имени сервиса: web подключается к базе данных по адресу db:5432, а не по IP-адресу. Docker сам разрешает имена через встроенный DNS.

Регистр образов: Docker Hub и приватные регистры

Готовые образы публикуются в регистрах (registries). Публичный — Docker Hub (hub.docker.com), где доступны официальные образы Nginx, PostgreSQL, Redis и тысяч других приложений. Для собственных образов в компаниях используются приватные регистры: GitLab Container Registry, Amazon ECR, Harbor.

Публикация образа в регистр — это мост между локальной сборкой и CI/CD-пайплайном, который автоматически развернёт приложение на сервере.

Типичные ошибки начинающих

Самая частая ошибка — хранить данные внутри контейнера без volumes. После docker rm все данные теряются безвозвратно. Вторая — собирать образы без .dockerignore: в контейнер попадают .git, node_modules, логи и прочий мусор, раздувая образ. Третья — запускать контейнеры от root внутри образа без необходимости, что снижает безопасность.

Docker — это не просто инструмент, это новый способ думать о приложениях. Вместо «установить и настроить» — «запустить контейнер». Вместо «работает на моей машине» — «работает везде». Именно этот сдвиг мышления делает контейнеризацию краеугольным камнем DevOps.

Автоматизация и CI/CD процессы

Почему некоторые команды выпускают обновления каждый день, а другие — раз в квартал, и каждый релиз превращается в стрессовую ночь с пиццей и энергетиками? Разница не в таланте разработчиков, а в степени автоматизации. CI/CD — это конвейер, который берёт код из репозитория и доставляет его до пользователей без ручного вмешательства. Это сердце DevOps, и понимание CI/CD — ключевой навык для старта карьеры.

От ручного деплоя к автоматическому конвейеру

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

CI/CD расшифровывается как Continuous Integration / Continuous Delivery (а иногда Continuous Deployment). Эти два понятия решают разные, но связанные задачи.

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

Continuous Delivery (CD) — непрерывная доставка. После успешной CI-стадии приложение автоматически подготавливается к релизу. Оно может быть развёрнуто в один клик (или автоматически), потому что все проверки уже пройдены.

Continuous Deployment (CD) — непрерывное развёртывание. Более радикальный вариант: если все тесты пройдены, приложение автоматически выходит в продакшен без участия человека.

> CI/CD — это не просто пайплайн. Это договорённость команды: мы не мёрджим код, который не прошёл тесты, и мы не боимся релизов, потому что наш конвейер проверяет всё за нас. > > Martin Fowler on Continuous Integration

Структура CI/CD-пайплайна

Типичный пайплайн состоит из последовательных стадий (stages), каждая из которых выполняется только при успехе предыдущей.

Стадия 1 — Сборка (Build). Исходный код компилируется или интерпретируется, зависимости устанавливаются, артефакт (Docker-образ, бинарный файл, пакет) формируется. Если код не компилируется — пайплайн останавливается.

Стадия 2 — Тестирование (Test). Запускаются автоматические тесты: модульные (unit tests), интеграционные, end-to-end. Также могут выполняться линтинг (проверка стиля кода), анализ безопасности и проверка покрытия тестами.

Стадия 3 — Развёртывание (Deploy). Артефакт доставляется на целевое окружение: сначала на staging (тестовый сервер), а затем, после дополнительных проверок или ручного одобрения, — на production (сервер, обслуживающий реальных пользователей).

Каждая стадия работает в изолированном окружении — обычно в Docker-контейнере или на выделенном раннере (вычислительном агенте). Это гарантирует, что результаты сборки не зависят от локальной машины разработчика.

GitHub Actions: CI/CD прямо в репозитории

Если ваш код хранится на GitHub, проще всего начать с GitHub Actions — встроенной системы CI/CD. Конфигурация описывается в YAML-файле в директории .github/workflows/.

yaml stages: - build - test - deploy

build_image: stage: build image: docker:24 services: - docker:24-dind script: - docker build -t CI_COMMIT_SHORT_SHA . - docker push CI_COMMIT_SHORT_SHA

run_tests: stage: test image: python:3.12-slim script: - pip install -r requirements.txt - pytest tests/ --junitxml=report.xml artifacts: reports: junit: report.xml

deploy_production: stage: deploy image: alpine:latest script: - apk add --no-cache openssh-client - ssh -o StrictHostKeyChecking=no deploy@CI_REGISTRY_IMAGE:{{ secrets.DOCKER_USERNAME }} password: {{ github.sha }}

Команда sed подставляет тег образа в манифест Kubernetes, а kubectl apply применяет обновлённый манифест к кластеру. Kubernetes сам обновляет поды: запускает новые контейнеры, проверяет их здоровье и останавливает старые. Пользователи не замечают перерыва — это называется rolling update.

Секреты и безопасность в пайплайнах

CI/CD-пайплайны имеют доступ к продакшен-инфраструктуре, поэтому их безопасность критична. Основные правила:

Мониторинг пайплайнов

Пайплайн — это тоже система, которую нужно мониторить. Обе платформы предоставляют визуальный интерфейс: зелёный — успешно, красный — провал. Но в зрелых командах настраивают дополнительные оповещения: при падении пайплайна в main приходит уведомление в Slack или Telegram, ответственный инженер реагирует немедленно.

Метрики, которые стоит отслеживать: время сборки (если растёт — пора оптимизировать), частота деплоев (чем выше — тем лучше работает CI/CD), время восстановления (MTTR) — как быстро команда исправляет сломанный пайплайн.

Практический совет для начинающих

Не пытайтесь настроить идеальный пайплайн с первого раза. Начните с минимального варианта: один workflow, одна стадия — просто запустить тесты при пуше. Когда это заработает, добавьте сборку Docker-образа. Потом — деплой на staging. Потом — автоматический деплой в продакшен. Итеративный подход — это и есть дух DevOps: маленькие шаги, быстрая обратная связь, непрерывное улучшение.

CI/CD — это не просто технический инструмент. Это способ мышления, при котором каждый коммит — это потенциальный релиз, а каждый релиз — рутинная, предсказуемая операция, а не лотерея.