DevOps-инженер: от основ культуры до построения автоматизированного CI/CD конвейера

Философия DevOps: преодоление разрыва между разработкой и эксплуатацией

«На моем компьютере всё работает!» — эта фраза хотя бы раз звучала в любой IT-компании. Представьте ситуацию: команда программистов полгода трудилась над новой системой рекомендаций для крупного интернет-магазина. Накануне «Черной пятницы» код передают системным администраторам для запуска. Администраторы загружают обновление на сервер, и... сайт падает. Программисты винят администраторов («вы неправильно настроили сервер»), администраторы винят программистов («ваш код потребляет всю память»). Магазин теряет миллионы рублей каждую минуту, пока две команды выясняют отношения.

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

Две конфликтующие вселенные

Исторически сложилось так, что процесс создания IT-продукта был разделен на два изолированных лагеря: Разработку (Development, или Dev) и Эксплуатацию (Operations, или Ops).

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

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

Характеристика	Разработка (Dev)	Эксплуатация (Ops)
Главная цель	Скорость выпуска новых функций (Time to Market)	Стабильность и доступность системы (Uptime)
Отношение к изменениям	Изменения — это прогресс и ценность для бизнеса	Изменения — это главный источник сбоев и риска
Рабочая среда	Локальный ноутбук с идеальными условиями	Реальные серверы с непредсказуемой нагрузкой

Из-за этого конфликта интересов между отделами вырастает невидимая преграда, которую в индустрии назвали Стеной непонимания (Wall of Confusion).

Разработчики «перебрасывают» готовый код через эту стену, не заботясь о том, как он будет работать под реальной нагрузкой. А администраторы, получая непонятную программу без инструкций, пытаются заставить её работать, категорически сопротивляясь любым последующим обновлениям, чтобы не сломать хрупкое равновесие.

Рождение DevOps: разрушение стены

В 2009 году на конференции Velocity инженеры Джон Оллспоу и Пол Хэммонд из Flickr выступили с докладом «10+ развертываний в день: сотрудничество Dev и Ops». Для индустрии того времени, где релизы происходили раз в полгода и сопровождались бессонными ночами, это звучало как фантастика.

Они доказали: если объединить усилия тех, кто пишет код, и тех, кто его запускает, можно обновлять систему десятки раз в день без потери стабильности. Бельгийский IT-консультант Патрик Дебуа, вдохновившись этой идеей, организовал первую конференцию «DevOpsDays». Так появился термин DevOps.

DevOps — это набор практик, объединяющих разработку ПО (Dev) и IT-эксплуатацию (Ops). Его цель — сократить цикл разработки систем и обеспечить непрерывную поставку высококачественного программного обеспечения.

DevOps не отменяет системных администраторов и не заставляет программистов тянуть сетевые кабели. Он меняет процесс так, чтобы обе команды работали над одной общей целью — быстрой и безопасной доставкой ценности конечному пользователю.

Культура важнее инструментов: фреймворк CALMS

Многие новички думают, что если установить Docker и GitLab, компания автоматически станет «DevOps-ориентированной». Это ошибка. Инструменты бесполезны без правильного мышления.

Чтобы описать суть DevOps, соавтор книги «The DevOps Handbook» Джез Хамбл предложил аббревиатуру CALMS. Это пять столпов, на которых держится вся методология.

1. Culture (Культура)

Это фундамент. Главный культурный сдвиг — переход к общей ответственности. Если сайт падает, это проблема не только Ops, но и Dev. Разработчики начинают дежурить по ночам вместе с администраторами, чтобы понимать, как их код ведет себя в реальности.

Важнейший элемент культуры — безавиноватые разборы полетов (Blameless Post-Mortems). Когда происходит авария, команда ищет не «кто виноват», а «почему система позволила человеку совершить эту ошибку» и «как автоматизировать процесс, чтобы это не повторилось».

2. Automation (Автоматизация)

Если задачу нужно выполнить больше одного раза — напишите для этого скрипт. Ручной труд (настройка серверов, копирование файлов, тестирование) порождает человеческие ошибки. В DevOps автоматизируется всё: от проверки кода до развертывания целых дата-центров. Именно здесь вступают в игру инструменты вроде Ansible, Terraform и CI/CD конвейеры, которые мы будем детально изучать в следующих главах.

3. Lean (Бережливое производство)

Заимствованный из производственной системы Toyota, этот принцип гласит: избавляйтесь от потерь и делайте изменения маленькими порциями. Вместо того чтобы выкатывать огромный релиз из 100 новых функций раз в год (что гарантированно приведет к сбоям), лучше выпускать по одной функции каждый день. Маленькое изменение легко протестировать, а если оно сломает систему — его легко откатить назад.

4. Measurement (Измерение)

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

5. Sharing (Обмен знаниями)

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

Бесконечная петля DevOps

Философия CALMS на практике реализуется через непрерывный жизненный цикл приложения. Традиционно разработка была линейной (водопадной): спланировали, написали, протестировали, отдали клиенту, забыли.

В DevOps процесс визуализируют в виде знака бесконечности — DevOps Infinity Loop.

Этот цикл состоит из двух половин, которые непрерывно перетекают друг в друга:

Левая петля (Dev):

Plan (Планирование): Сбор требований и постановка задач.
Code (Написание кода): Разработчики пишут код и сохраняют его в систему контроля версий (Git).
Build (Сборка): Код автоматически компилируется в готовое приложение.
Test (Тестирование): Автоматические тесты проверяют, не сломалось ли что-нибудь.

Правая петля (Ops):

Release (Релиз): Готовая и проверенная версия приложения помечается как готовая к отправке.
Deploy (Развертывание): Автоматизированная доставка приложения на рабочие серверы.
Operate (Эксплуатация): Поддержание работы инфраструктуры, масштабирование серверов.
Monitor (Мониторинг): Сбор метрик и логов. Данные из мониторинга перетекают обратно в этап Plan, чтобы разработчики знали, что нужно исправить или улучшить в следующем цикле.

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

Что дальше?

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

Абсолютное большинство серверов в мире работают под управлением операционной системы Linux. Поэтому, прежде чем переходить к сложным инструментам автоматизации, наш следующий шаг — спуститься на уровень операционной системы и освоить командную строку Linux и базовые принципы компьютерных сетей.

Командная строка Linux и сетевые основы как фундамент работы инженера

Десять развертываний кода в день, о которых инженеры Flickr рассказывали на заре DevOps, физически невозможны, если для каждого обновления нужно открывать графические окна, кликать мышкой и копировать файлы вручную. Графический интерфейс (GUI) создан для удобства человека, но он абсолютно враждебен к автоматизации. Чтобы выстроить непрерывный конвейер, нам нужен интерфейс, который одинаково хорошо понимает и человек, и машина. Этот интерфейс — командная строка.

Почему Linux и почему без графики?

В мире серверов и облачной инфраструктуры безоговорочно доминирует Linux. Это связано не только с тем, что система бесплатна, но и с её архитектурной философией, заложенной ещё в эпоху Unix.

Фундамент этой философии держится на двух правилах:

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

Когда вы работаете в терминале, вы общаетесь с системой напрямую, без прослоек, которые могут зависнуть или скрыть от вас важную ошибку. Текст детерминирован: команда rm -rf /tmp/cache выполнится на тысяче серверов абсолютно идентично. Именно поэтому командная строка (CLI) — это первый и главный инструмент DevOps-инженера.

Анатомия команды и стандартные потоки

Любое взаимодействие в терминале строится по простому синтаксису: утилита -флаги аргументы

Например, команда ls -l /var/log вызывает утилиту просмотра директорий (ls), передает ей флаг детального вывода (-l) и указывает аргумент — путь к папке (/var/log). Но настоящая магия начинается, когда мы понимаем, как программы обмениваются данными.

Каждая программа в Linux при запуске автоматически получает три канала связи — стандартные потоки:

stdin (стандартный ввод) — то, откуда программа читает данные (по умолчанию клавиатура).
stdout (стандартный вывод) — куда программа отправляет успешный результат (по умолчанию экран).
stderr (стандартный вывод ошибок) — куда отправляются сообщения о сбоях (тоже экран, но логически отделен от stdout).

Конвейер (Pipe): объединение утилит

Поскольку программы выводят текст, а другие программы умеют читать текст, мы можем соединить их. Оператор | (pipe, труба) берет stdout левой команды и передает его в stdin правой.

Представьте, что у нас есть огромный файл логов веб-сервера access.log, и нам нужно узнать, сколько раз пользователи столкнулись с ошибкой 404 (страница не найдена). Мы не будем открывать файл в редакторе. Мы построим конвейер:

cat access.log | grep "404" | wc -l

Здесь cat читает файл и выплевывает его текст. grep ловит этот текст, оставляет только строки с текстом "404" и передает дальше. wc -l (word count с флагом lines) считает количество полученных строк и выдает итоговое число. Мы только что создали новую программу из трех существующих.

Сети: как серверы находят друг друга

Умение управлять одним сервером бесполезно, если он изолирован. DevOps-инженер постоянно работает с распределенными системами: балансировщики нагрузки общаются с веб-серверами, а те — с базами данных.

Чтобы системы могли взаимодействовать, им нужна система координат.

IP-адрес и Порт

Если сервер — это многоквартирный дом, то IP-адрес — это адрес этого дома на улице (например, 192.168.1.10). По IP-адресу пакеты данных находят нужный физический или виртуальный сервер в сети.

Но на одном сервере может работать множество программ: веб-сервер, база данных, почтовый сервис. Как входящий запрос понимает, к какой именно программе он адресован? Для этого существует порт — номер квартиры в нашем доме (от 1 до 65535).

Сочетание IP-адреса и порта ( $IP:Port$ ) называется сокетом. Это конечная точка любого сетевого соединения.

Исторически закрепились стандартные порты для популярных сервисов:

80 — HTTP (незашифрованный веб-трафик)
443 — HTTPS (зашифрованный веб-трафик)
5432 — база данных PostgreSQL

DNS: телефонная книга интернета

Людям сложно запоминать IP-адреса. Мы хотим писать gitlab.com, а не 172.65.251.78. Системой перевода человекочитаемых доменных имен в машинные IP-адреса занимается DNS (Domain Name System).

Когда вы запускаете скрипт, обращающийся к внешнему API, система сначала делает запрос к DNS-серверу: "Какой IP у этого домена?", получает ответ, и только затем формирует пакет, отправляя его на нужный IP и порт.

Базовый набор инструментов диагностики

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

1. Проверка связности: ping Команда ping 8.8.8.8 отправляет крошечные ICMP-пакеты ("эхо-запросы") на указанный IP. Если сервер отвечает, значит, базовый сетевой маршрут между вашим компьютером и сервером существует. Сервер "жив".

2. Проверка доступности сервиса: curl Сервер может пинговаться, но веб-сайт на нем может лежать. curl -I https://example.com отправляет реальный HTTP-запрос к приложению. Если в ответ приходит статус 200 OK, значит, веб-сервер работает и готов отдавать данные.

3. Взгляд изнутри: ss (или netstat) Если вы зашли на сам сервер и хотите понять, действительно ли ваше приложение запустилось и слушает нужный порт, используется команда ss -tuln. Она покажет таблицу всех открытых портов. Если вы не видите в выводе порта 80, значит, ваш веб-сервер даже не запустился, и проблема не в сети, а в конфигурации самого приложения.

Мы разобрали, как управлять системой через текст и как системы связываются друг с другом по сети. Это базовый алфавит инженера. Однако, когда конфигурационные файлы становятся сложными, а над ними работает целая команда, возникает риск хаоса: кто изменил файл конфигурации Nginx вчера вечером? Чтобы этот хаос контролировать, нам потребуется система управления версиями.

Управление версиями и стратегии ветвления в Git для совместной работы

Представьте сервер, на котором крутится критически важный bash-скрипт. В понедельник утром вы заходите по SSH, чтобы добавить в него новую функцию, и обнаруживаете, что скрипт наполовину переписан, не работает, а в конце файла красуется комментарий: «Вася, я тут поправил сеть, доделай остальное». Кто такой Вася, когда были внесены изменения и как вернуть скрипт в рабочее состояние — неизвестно. Именно из-за таких ситуаций культура DevOps невозможна без системы контроля версий.

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

От хаоса к распределенному контролю

Долгое время системы контроля версий были централизованными. Существовал один главный сервер, хранящий историю. Если у инженера пропадал интернет, он не мог сохранить свои изменения. Если сервер выходил из строя, история проекта могла быть утеряна навсегда.

В 2005 году сообщество разработчиков ядра Linux столкнулось с кризисом инструментов для совместной работы.

Чтобы решить эту проблему, Линус Торвальдс за пару недель написал первую версию Git. Главной инновацией стала распределенная архитектура (DVCS — Distributed Version Control System). В Git нет единой точки отказа. Когда вы клонируете репозиторий на свой компьютер, вы скачиваете не только текущие файлы, но и абсолютно всю историю изменений с самого первого дня. Ваш локальный компьютер становится полноценной резервной копией всего проекта.

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

Анатомия коммита и три состояния файла

Базовая единица истории в Git — это коммит (commit). Коммит — это не разница между файлами, а полноценный снимок (snapshot) состояния всего проекта в конкретный момент времени. К каждому коммиту прикреплен автор, дата, текстовое описание и уникальный идентификатор (хэш).

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

Рабочая директория (Working Directory) — это обычные файлы на вашем диске, которые вы открываете в редакторе. Вы можете менять их, удалять, ломать. Git видит эти изменения, но пока не сохраняет их в историю.
Индекс (Staging Area) — это «зона подготовки». Сюда вы добавляете измененные файлы, которые хотите включить в следующий коммит.
Репозиторий (Repository) — скрытая папка .git, где хранятся сами коммиты (снимки). То, что попало сюда, останется в истории навсегда.

Процесс сохранения выглядит так: вы редактируете файлы в рабочей директории. Затем с помощью команды git add отправляете нужные изменения в индекс. И только потом командой git commit делаете снимок индекса, который навсегда сохраняется в репозитории.

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

Зачем нужна промежуточная зона индекса? Она позволяет собирать коммиты логически. Если вы одновременно исправили баг в настройках сети и написали новый скрипт для базы данных, вам не нужно сохранять это одним куском. Вы можете добавить в индекс только сетевые файлы, сделать коммит «Исправлен сетевой баг», а затем добавить скрипт БД и сделать второй коммит.

Ветвление: параллельные вселенные

Если коммиты — это точки во времени, то ветки (branches) — это параллельные линии времени. Ветвление — это мощнейший инструмент Git, который позволяет инженерам работать над разными задачами, не мешая друг другу.

По умолчанию в Git есть главная ветка, которая обычно называется main (или master). В ней должен находиться стабильный, рабочий код.

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

Когда работа завершена и протестирована, происходит слияние (merge). Git берет изменения из вашей ветки и аккуратно вплетает их обратно в main.

Стратегии совместной работы: GitFlow против Trunk-Based

Технически Git позволяет создавать ветки как угодно. Но когда в команде 10, 50 или 100 человек, хаос возвращается на новом уровне: инженеры создают десятки веток, работают в них месяцами, а при попытке слить их воедино возникают тысячи конфликтов (когда два человека изменили одну и ту же строку кода по-разному).

Чтобы избежать этого, команды договариваются о правилах игры — стратегиях ветвления. В мире DevOps исторически сложились два главных подхода.

Характеристика	GitFlow	Trunk-Based Development (TBD)
Суть	Строгая иерархия множества веток (`main`, `develop`, `feature`, `release`, `hotfix`).	Все работают в одной главной ветке (Trunk/main) или создают очень короткоживущие ветки.
Жизненный цикл ветки	Дни, недели или месяцы.	Часы, максимум 1-2 дня.
Слияние кода	Редкое, часто болезненное (Merge Hell).	Постоянное, конфликты решаются сразу, пока они маленькие.
Идеально подходит для	Коробочного ПО с редкими релизами (раз в полгода).	Облачных сервисов, DevOps и непрерывной доставки (CI/CD).

GitFlow был популярен в начале 2010-х годов. Это тяжеловесный процесс, где код проходит через множество инстанций перед тем, как попасть в продакшен. Он дает иллюзию контроля, но сильно замедляет поставку ценности.

Trunk-Based Development — это стандарт современной DevOps-культуры. Инженеры делят большие задачи на микро-изменения и вливают их в главную ветку (Trunk) по несколько раз в день. Это требует высокой дисциплины и покрытия кода автоматическими тестами, но взамен команда получает невероятную скорость и отсутствие гигантских конфликтов слияния.

Trunk-Based Development — это обязательное условие для построения настоящей системы непрерывной интеграции (Continuous Integration).

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

Виртуализация и контейнеризация: глубокое погружение в Docker

«У меня на компьютере всё работает!» — эта фраза десятилетиями была главным символом Стены непонимания между разработкой и эксплуатацией. Благодаря Git мы научились гарантировать, что у всех инженеров на руках находится абсолютно идентичный исходный код. Но код не висит в вакууме. Ему нужна операционная система, определенная версия языка программирования, специфические системные библиотеки и переменные окружения. Если у разработчика стоит Python 3.10 и Ubuntu, а на боевом сервере — Python 3.8 и CentOS, идеальный код из ветки main неизбежно сломается при запуске.

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

Виртуальные машины: изоляция любой ценой

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

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

Этот подход дает идеальную безопасность и изоляцию, но имеет критические недостатки для непрерывной поставки:

Избыточность: Каждая гостевая ОС потребляет гигабайты диска и сотни мегабайт оперативной памяти просто для поддержания собственной работы, еще до запуска полезного приложения.
Медлительность: Запуск ВМ — это полноценная загрузка операционной системы, занимающая минуты. В мире, где приложения должны масштабироваться за секунды при наплыве трафика, это недопустимо долго.

Контейнеризация: легкость и общие ресурсы

Инженеры задались вопросом: зачем нам запускать десять копий ядра Linux на одном сервере, если всем приложениям нужно примерно одно и то же?

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

Эта магия работает благодаря двум механизмам ядра Linux:

Namespaces (пространства имен): обманывают процесс, создавая для него иллюзию, что он один в системе. Процесс видит только свою файловую систему, свои сетевые интерфейсы и свое дерево процессов.
Cgroups (контрольные группы): жестко ограничивают ресурсы. Можно сказать контейнеру: «ты имеешь право использовать не более 512 МБ оперативной памяти и 20% времени процессора».

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

Характеристика	Виртуальная машина (VM)	Контейнер
Изоляция	Аппаратная (полная)	На уровне процессов ОС
Гостевая ОС	Есть (полноценная)	Нет (использует ядро хоста)
Размер	Гигабайты	Мегабайты
Время старта	Минуты	Миллисекунды

Docker: стандарт упаковки приложений

Сама технология контейнеров существовала в Linux давно (например, LXC), но была сложна в настройке. Революцию совершил Docker — инструмент, который сделал работу с контейнерами невероятно простой и ввел удобный стандарт упаковки.

В основе Docker лежат два неразрывных понятия, которые часто путают новички:

Образ (Image): Неизменяемый шаблон, файл, содержащий файловую систему ОС, библиотеки, зависимости и сам скомпилированный код приложения. Если проводить аналогию с Git, то образ — это коммит. Он статичен.
Контейнер (Container): Запущенный экземпляр образа. Вы берете статический образ, запускаете его, и он становится живым процессом — контейнером. Из одного образа можно запустить сотни идентичных контейнеров.

Слоистая архитектура образов

Docker-образы не являются монолитными файлами. Они состоят из слоев (layers). Каждый слой — это набор изменений в файловой системе.

Когда Docker скачивает образ, он скачивает его послойно. Если у вас уже есть образ Ubuntu, и вы скачиваете образ веб-сервера, который тоже базируется на Ubuntu, Docker не будет скачивать базовую ОС второй раз — он переиспользует существующий слой. Это колоссально экономит место на диске и ускоряет доставку (деплой) приложений.

Dockerfile: инфраструктура как код

Чтобы создать свой образ, DevOps-инженер пишет Dockerfile — текстовый файл с инструкциями. Это первый шаг к подходу «Инфраструктура как код» (IaC). Вместо того чтобы писать инструкцию в Wiki «установите Python, затем выполните команду...», мы описываем это машиночитаемым языком.

Рассмотрим типичный Dockerfile для веб-приложения:

# 1. Задаем базовый слой (официальный образ Python)
FROM python:3.9-slim

# 2. Указываем рабочую директорию внутри будущего контейнера
WORKDIR /app

# 3. Копируем файл зависимостей с хоста в контейнер
COPY requirements.txt .

# 4. Запускаем установку зависимостей
RUN pip install -r requirements.txt

# 5. Копируем весь остальной исходный код
COPY . .

# 6. Указываем команду, которая выполнится при старте контейнера
CMD ["python", "server.py"]

Каждая директива (FROM, COPY, RUN) создает новый слой.

Обратите внимание на порядок: почему мы сначала копируем только requirements.txt (шаг 3), устанавливаем пакеты (шаг 4), и лишь затем копируем весь остальной код (шаг 5)? Это сделано ради кэширования. При пересборке образа Docker проверяет, изменились ли файлы. Исходный код приложения меняется постоянно, а список зависимостей — редко. Если бы мы скопировали всё сразу на шаге 3, любое изменение в коде инвалидировало бы кэш, и Docker заново скачивал бы все библиотеки из интернета. Разделение шагов позволяет пересобирать образ за доли секунды.

Сетевое взаимодействие: проброс портов

Когда контейнер запущен, он находится в своей изолированной виртуальной сети. Вспомним сетевые основы: чтобы обратиться к веб-серверу, нам нужны IP-адрес и порт.

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

При запуске контейнера из командной строки мы явно указываем, какой порт хоста связать с портом контейнера:

docker run -p 8080:80 my-web-app

В этой записи -p 8080:80 означает: «Возьми порт 8080 на физическом хосте и перенаправляй весь приходящий на него трафик на порт 80 внутрь этого контейнера». Теперь, открыв в браузере http://localhost:8080, вы попадете прямо в приложение.

Упаковав приложение в Docker-образ, мы получили предсказуемый артефакт. Нам больше не важно, на чем написано приложение — на Java, Go или Node.js. Для сервера эксплуатации это теперь просто «черный ящик», который запускается стандартной командой docker run. Это открывает нам путь к автоматическому развертыванию десятков и сотен таких ящиков — задаче, к которой мы перейдем в следующих главах.

Инфраструктура как код (IaC): автоматизация развертывания с Terraform

Представьте, что вы упаковали приложение в идеальный Docker-контейнер. Теперь вам нужно развернуть его в облаке, причем сразу в трех окружениях: для тестирования, для staging и для production. Если вы откроете веб-интерфейс облачного провайдера и начнете вручную создавать виртуальные машины, настраивать сети, пробрасывать порты и подключать диски, это займет несколько часов. А что, если через месяц вам понадобится точная копия production-среды в другом дата-центре? Ручная настройка инфраструктуры — это медленно, невоспроизводимо и неизбежно ведет к человеческим ошибкам.

Чтобы решить эту проблему, DevOps-инженеры применяют подход Infrastructure as Code (IaC) — Инфраструктура как код.

От кликов мышкой к коду

Суть IaC проста: мы описываем серверы, базы данных, сети и права доступа в виде текстовых файлов. Эти файлы мы храним в системе управления версиями (Git), точно так же, как исходный код приложения.

Инфраструктура как код (IaC) — это управление вычислительной инфраструктурой и ее описание через машиночитаемые конфигурационные файлы, а не через физическую настройку оборудования или интерактивные инструменты управления.

Перенос инфраструктуры в код дает три фундаментальных преимущества:

Версионирование. Вы всегда знаете, кто, когда и зачем изменил настройки фаервола (благодаря истории коммитов).
Воспроизводимость. Поднять точную копию серверов можно одной командой за пару минут.
Автоматизация. Создание серверов можно встроить в конвейер CI/CD.

Существует множество инструментов IaC (AWS CloudFormation, Pulumi, Ansible), но индустриальным стандартом для выделения ресурсов (provisioning) стал Terraform от компании HashiCorp.

Декларативный подход: говорим «что», а не «как»

Главная особенность Terraform — декларативный язык описания конфигурации (HCL — HashiCorp Configuration Language). Чтобы понять его силу, нужно сравнить два подхода к автоматизации.

Характеристика	Императивный подход (Bash-скрипты, CLI)	Декларативный подход (Terraform)
Суть	Описание пошагового алгоритма действий.	Описание желаемого конечного результата.
Пример из жизни	«Пройди 100 метров, поверни направо, поднимись на 3 этаж».	«Я хочу оказаться по адресу: ул. Ленина, 5, кв. 10».
Пример в IT	`aws ec2 run-instances --image-id ami-123 --count 1`	`resource "aws_instance" "web" { ami = "ami-123" }`
Повторный запуск	Если запустить скрипт 5 раз, он создаст 5 одинаковых серверов (если не написать сложную логику проверок).	Если запустить код 5 раз, Terraform проверит реальность и ничего не сделает — сервер уже существует.

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

Архитектура Terraform: как он общается с облаками

Terraform сам по себе не создает серверы. Он лишь вычисляет, что нужно сделать, и отправляет правильные запросы к API облачных провайдеров (AWS, Google Cloud, Яндекс Облако) или других систем (Docker, GitHub, Kubernetes).

Система состоит из трех ключевых компонентов:

Terraform Core (Ядро). Бинарный файл, который читает ваш конфигурационный код и сравнивает его с текущим состоянием инфраструктуры.
Providers (Провайдеры). Плагины, которые транслируют команды ядра в API конкретного сервиса. Для AWS нужен один провайдер, для Docker — другой.
State (Файл состояния). Локальная или удаленная база данных (обычно файл terraform.tfstate), в которой Terraform запоминает, какие именно реальные объекты он создал.

Зачем нужен State-файл?

Когда вы пишете в коде resource "aws_instance" "web", облако возвращает идентификатор созданного сервера (например, i-0abcd1234). Terraform записывает эту связь в State-файл: «блок кода "web" = реальный сервер i-0abcd1234».

При следующем запуске Terraform заглянет в State-файл, увидит этот ID, спросит у облака «как там поживает i-0abcd1234?» и поймет, нужно ли что-то менять.

Жизненный цикл инфраструктуры

Работа с Terraform строится вокруг строгого цикла команд. Вы не просто «запускаете скрипт», вы планируете и применяете изменения.

terraform init — инициализация рабочего каталога. Terraform анализирует код, определяет, какие провайдеры нужны, и скачивает их.
terraform plan — сухое выполнение (dry run). Terraform сравнивает ваш код, State-файл и реальное облако, а затем выводит план: что будет создано (зеленый +), изменено (желтый ~) или удалено (красный -). На этом этапе ничего не ломается.
terraform apply — применение изменений. Если план вас устраивает, вы подтверждаете его, и провайдеры отправляют запросы в API. State-файл обновляется.
terraform destroy — удаление всех ресурсов, описанных в конфигурации. Удобно для временных тестовых стендов.

Практика: пишем первый конфигурационный файл

Давайте посмотрим, как выглядит реальный код на языке HCL. Создадим файл main.tf, который развернет виртуальную машину в облаке AWS.

# 1. Указываем, какой провайдер нам нужен
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# 2. Настраиваем провайдер (например, регион)
provider "aws" {
  region = "eu-central-1"
}

# 3. Описываем желаемый ресурс (сервер)
resource "aws_instance" "my_server" {
  ami           = "ami-0abcdef1234567890" # Образ ОС (например, Ubuntu)
  instance_type = "t2.micro"              # Размер сервера (CPU, RAM)

  tags = {
    Name        = "DevOps-Course-Server"
    Environment = "Production"
  }
}

В этом коде блок resource — это фундамент IaC. Первое слово в кавычках ("aws_instance") — это тип ресурса, который понимает провайдер. Второе слово ("my_server") — это локальное имя ресурса, по которому на него можно ссылаться в других частях вашего кода.

Если завтра нам потребуется изменить размер сервера на более мощный, мы просто поменяем t2.micro на t3.large в коде, закоммитим это в Git и выполним terraform apply. Terraform сам поймет, что сервер нужно перезапустить с новыми параметрами.

От инфраструктуры к конфигурации

Terraform блестяще справляется с задачей provisioning — выделением ресурсов (создать сервер, настроить сеть, выделить диск). Но когда сервер запущен, он пуст. На него нужно установить Docker, скопировать файлы приложения, настроить Nginx и запустить контейнеры.

Можно ли сделать это через Terraform? Да, с помощью так называемых provisioners, но это считается плохой практикой. Terraform не умеет эффективно управлять внутренним состоянием операционной системы.

Для настройки «внутренностей» серверов (Configuration Management) используется другой класс инструментов, работающий в тандеме с Terraform. Изучением такого инструмента мы займемся на следующем шаге.

Управление конфигурациями и оркестрация серверов с помощью Ansible

Представьте: скрипт Terraform успешно отработал, и облачный провайдер выдал вам IP-адреса 50 новеньких виртуальных машин. Инфраструктура готова. Но внутри этих машин — лишь голая операционная система. Чтобы они превратились в работающий кластер веб-серверов, на каждый нужно зайти по SSH, обновить пакеты, установить Nginx, скопировать конфигурационные файлы, настроить фаервол и запустить службу. Если делать это вручную, уйдут часы, а вероятность опечатки в одном из конфигов стремится к 100%.

Здесь заканчивается зона ответственности Terraform (создание ресурсов) и начинается территория управления конфигурациями (Configuration Management). Наша задача — автоматизировать настройку внутреннего состояния серверов так, чтобы конфигурация 50 машин занимала столько же усилий, сколько настройка одной. И главным стандартом индустрии для этой задачи стал Ansible.

Разделение труда: Provisioning против Configuration Management

Частая ошибка начинающих инженеров — пытаться сделать всё одним инструментом. Terraform может выполнять скрипты внутри созданных машин, а Ansible умеет создавать виртуальные машины в облаке. Но их архитектура заточена под разные задачи.

Характеристика	Terraform (Provisioning)	Ansible (Configuration Management)
Главная цель	Создать «железо» (виртуальное), сеть, диски, базы данных.	Настроить ОС, установить ПО, разложить файлы, запустить службы.
Метафора	Строительство дома (фундамент, стены, коммуникации).	Ремонт и расстановка мебели внутри готового дома.
Управление состоянием	Хранит жесткий маппинг в State-файле. Если удалить ресурс из кода, Terraform удалит его из облака.	Не хранит централизованный State. Проверяет текущее состояние прямо на сервере в момент запуска.

Ansible принимает эстафету там, где Terraform заканчивает работу. Terraform отдает список IP-адресов созданных серверов, а Ansible подключается к ним и превращает пустые Linux-коробки в полезные узлы системы.

Архитектура Ansible: Push-модель и отсутствие агентов

Исторически системы управления конфигурациями (Puppet, Chef) работали по Pull-модели. На каждый управляемый сервер нужно было установить специальную программу-агента. Этот агент постоянно работал в фоне, периодически стучался на центральный мастер-сервер, скачивал новые инструкции и применял их. Это создавало проблему курицы и яйца: чтобы автоматизировать настройку сервера, нужно сначала как-то установить на него агента.

Ansible совершил революцию, выбрав Agentless (безагентную) архитектуру и Push-модель.

Ansible не требует установки никакого дополнительного ПО на управляемые серверы (Managed Nodes). Всё, что ему нужно — это стандартный доступ по SSH и установленный Python (который есть в 99% дистрибутивов Linux по умолчанию).

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

Вы запускаете Ansible на своем ноутбуке или сервере CI/CD (Control Node). Он берет ваши инструкции, транслирует их в небольшие Python-скрипты, проталкивает (Push) их по SSH на целевые серверы, выполняет там, собирает результаты и удаляет за собой скрипты.

Святая троица Ansible: Inventory, Modules, Playbooks

Чтобы Ansible выполнил работу, ему нужно ответить на три вопроса: Где выполнять? Чем выполнять? Что именно делать? За это отвечают три базовых компонента.

1. Inventory (Где выполнять?)

Инвентори — это адресная книга ваших серверов. Это простой текстовый файл (часто в формате INI или YAML), где IP-адреса или доменные имена сгруппированы по логическим ролям.

[webservers]
192.168.1.10
192.168.1.11

[databases]
192.168.1.20

[all:vars]
ansible_user=ubuntu

В этом примере мы создали две группы. Теперь мы можем сказать Ansible: «накати обновление только на webservers», и он проигнорирует базу данных.

2. Modules (Чем выполнять?)

Модули — это рабочие инструменты Ansible. Вместо того чтобы писать длинные bash-скрипты с кучей проверок (if grep -q "nginx" ...), вы используете готовые модули. В Ansible встроены тысячи модулей для любых задач: apt для управления пакетами, copy для файлов, service для управления демонами, postgresql_db для баз данных.

Модуль берет на себя всю грязную работу по определению того, как выполнить задачу на конкретной ОС.

3. Playbooks (Что именно делать?)

Плейбук — это сценарий, написанный на человекочитаемом языке YAML. Он связывает группы из Inventory с Модулями. Плейбук состоит из «плеев» (plays), а каждый плей — из задач (tasks).

---
- name: Настройка веб-серверов
  hosts: webservers
  become: yes # Выполнять задачи с правами root (sudo)

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

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

Когда вы запускаете этот плейбук, Ansible читает его сверху вниз и выполняет задачи последовательно на всех серверах группы webservers.

Идемпотентность: почему мы не используем shell

Мы уже сталкивались с концепцией идемпотентности в инфраструктуре как коде. Идемпотентность означает, что вы можете запустить один и тот же код сто раз, и результат будет точно таким же, как после первого запуска, без побочных эффектов или ошибок.

Ansible декларативен. В плейбуке выше мы не говорим «выполни команду apt-get install nginx». Мы говорим: «состояние пакета nginx должно быть present (присутствовать)».

Если вы запустите этот плейбук на чистом сервере, Ansible установит Nginx (статус changed). Если вы запустите его через пять минут снова, Ansible подключится к серверу, проверит наличие Nginx, увидит, что он уже установлен, и ничего не сделает (статус ok).

В Ansible есть модуль shell, который позволяет выполнить любую произвольную команду Linux. Но его использование считается антипаттерном именно потому, что shell слеп и не обладает идемпотентностью по умолчанию.

Масштабирование логики: Ansible Roles

Пока мы настраиваем один Nginx, плейбук на 20 строк выглядит отлично. Но реальная настройка сервера может включать десятки шагов: создание пользователей, настройка логирования, установка сертификатов, деплой приложения. Если свалить все задачи в один YAML-файл, он превратится в нечитаемую «простыню» на тысячи строк.

Для решения этой проблемы Ansible использует Роли (Roles). Роль — это способ разбить сложный плейбук на независимые, переиспользуемые компоненты со строго заданной структурой директорий.

Вместо одного файла вы создаете структуру:

roles/nginx/tasks/main.yml — только задачи установки Nginx.
roles/nginx/templates/nginx.conf.j2 — шаблоны конфигурационных файлов.
roles/database/tasks/main.yml — задачи настройки БД.

Тогда ваш главный плейбук превращается в элегантный манифест:

---
- name: Настройка кластера
  hosts: webservers
  roles:
    - common_security  # Базовая безопасность для всех серверов
    - nginx            # Веб-сервер
    - app_deploy       # Деплой нашего кода

Роли позволяют командам инженеров делиться кодом. Вам не нужно писать роль для установки MySQL с нуля — вы можете скачать готовую, проверенную тысячами людей роль из Ansible Galaxy (официального репозитория сообщества) и просто передать ей свои переменные.

Подводя итоги

Инструменты вроде Terraform и Ansible решили фундаментальную проблему эксплуатации: серверы больше не являются уникальными «домашними питомцами», которых бережно настраивают руками и боятся перезагрузить. Они стали «скотом» (концепция Pets vs Cattle) — безликими ресурсами, которые можно уничтожить и воссоздать с нуля за пару минут, потому что весь процесс их рождения и настройки описан в коде.

Теперь, когда у нас есть автоматизированная инфраструктура и настроенные серверы, нам не хватает последнего звена: как сделать так, чтобы код, который пишут разработчики, автоматически тестировался и попадал на эти серверы? Мы вплотную подошли к сердцу DevOps — конвейерам CI/CD.

Непрерывная интеграция (CI): автоматизация сборки и тестирования в GitLab CI/CD

Представьте команду из десяти разработчиков, которые сливают свой код в общую ветку пять раз в день. Если после каждого git push кто-то должен вручную запускать линтеры, прогонять тесты и собирать Docker-образ, этот человек больше ничем не будет заниматься. Хуже того, однажды он забудет запустить тесты, и сломанный код отправится на сервер. Инфраструктура у нас уже описана кодом, серверы настроены, но процесс проверки самого приложения остается ручным. Нам нужен робот, который будет мгновенно и безошибочно реагировать на каждое изменение в репозитории.

Что такое Непрерывная интеграция (CI)

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

CI — это логическое продолжение стратегии Trunk-Based Development. Если мы требуем от разработчиков часто коммитить небольшие изменения в главную ветку, мы обязаны обеспечить им «сеть безопасности». CI гарантирует, что новый коммит не сломал существующую логику и соответствует стандартам качества команды.

Суть CI можно свести к простому правилу: ни одна строчка кода не считается готовой, пока она не прошла автоматическую проверку в чистом, изолированном окружении.

Архитектура GitLab CI: Разделяй и властвуй

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

Система состоит из двух ключевых компонентов:

GitLab Server (Координатор). Это веб-интерфейс, база данных и хранилище Git-репозиториев. Сервер знает, что и когда нужно сделать. Он отслеживает коммиты, хранит историю выполнения пайплайнов и показывает красивые зеленые галочки или красные крестики в браузере. Но сам сервер никогда не выполняет код пайплайна.
GitLab Runner (Исполнитель). Это отдельный процесс (часто запущенный на совершенно другом сервере или в контейнере), который подключается к GitLab Server, запрашивает у него задачи, выполняет нужные команды (например, npm install или pytest) и отправляет логи обратно на сервер.

Зачем нужно такое разделение?

Безопасность. Выполнение стороннего (и потенциально уязвимого) кода происходит в изолированной среде Runner'а, а не на сервере, где лежат исходники всех проектов компании.
Масштабируемость. Если пайплайнов становится слишком много, вы просто добавляете новые Runner'ы на дополнительных виртуальных машинах.
Разнообразие сред. Вы можете настроить один Runner на Linux для сборки Docker-образов, второй на macOS для сборки iOS-приложений, а третий на Windows для C#-проектов. Сервер будет раздавать задачи соответствующим исполнителям.

Анатомия пайплайна: `.gitlab-ci.yml`

Чтобы GitLab узнал, как именно тестировать ваш код, в корне репозитория создается файл .gitlab-ci.yml. Это декларативное описание вашего пайплайна (Pipeline) — конвейера автоматизации.

Пайплайн состоит из двух основных структурных единиц: Стадий (Stages) и Задач (Jobs).

Job (Задача) — это конкретный скрипт, который нужно выполнить (например, «запустить тесты базы данных»).
Stage (Стадия) — это логическая группировка задач (например, стадия «Тестирование»).

Правило выполнения пайплайна простое, но строгое:

Стадии выполняются последовательно. Следующая стадия не начнется, пока не завершится предыдущая. Если стадия упала, пайплайн останавливается.
Задачи внутри одной стадии выполняются параллельно (если есть достаточное количество свободных Runner'ов).

Базовый синтаксис

Давайте посмотрим, как это выглядит в коде. Файл .gitlab-ci.yml пишется на языке разметки YAML.

# 1. Объявляем порядок стадий
stages:
  - lint
  - test

# 2. Описываем задачу проверки стиля кода
flake8_job:
  stage: lint
  image: python:3.10-slim
  script:
    - pip install flake8
    - flake8 .

# 3. Описываем задачу unit-тестов
pytest_job:
  stage: test
  image: python:3.10-slim
  script:
    - pip install pytest
    - pytest ./tests

Обратите внимание на ключевое слово image. Чаще всего GitLab Runner настраивается для работы с Docker-экзекьютором (Docker Executor). Это значит, что для выполнения каждой задачи Runner создает новый, абсолютно чистый Docker-контейнер из указанного образа, клонирует туда код из Git, выполняет команды из блока script, а затем безвозвратно удаляет контейнер.

Это решает проблему "It works on my machine" на уровне CI: тесты всегда проходят в стерильной, предсказуемой среде.

Управление состоянием: Артефакты и Кэш

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

Представьте конвейер для приложения на Go или C++. На стадии build вы компилируете бинарный файл. На стадии test вы хотите его запустить. Но стадия test запустится в новом, чистом контейнере — бинарного файла там не будет!

Для решения этой проблемы существуют два разных механизма, которые новички часто путают.

Артефакты (Artifacts)

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

compile_code:
  stage: build
  script:
    - make bin/app
  artifacts:
    paths:
      - bin/app
    expire_in: 1 week # Чтобы не переполнять диск сервера

Кэш (Cache)

Кэш — это файлы, которые сохраняются между разными запусками пайплайнов для ускорения работы. Например, скачивание зависимостей (npm install или pip install) может занимать минуты. Чтобы не качать интернет заново при каждом коммите, мы кэшируем директорию с библиотеками. Кэш обычно хранится локально на самом Runner'е или в облачном хранилище (например, AWS S3).

test_frontend:
  stage: test
  cache:
    key: frontend-deps
    paths:
      - node_modules/
  script:
    - npm install
    - npm run test

Главное отличие: Артефакты используются для передачи результатов работы внутри одного пайплайна (и гарантированно доставляются). Кэш используется для ускорения работы между разными пайплайнами (и не гарантирует своего наличия — если кэш удалится, пайплайн просто выполнится медленнее, но не сломается).

Синтез: полноценный CI-пайплайн

Теперь соберем воедино наши знания о Linux CLI, Docker и GitLab CI. Напишем практический пайплайн, который проверяет код и собирает готовый к развертыванию Docker-образ.

stages:
  - test
  - package

# Общие настройки для всех задач тестирования
default:
  image: python:3.10-slim
  cache:
    key: python-deps
    paths:
      - .cache/pip

# Задача 1: Линтер (стадия test)
lint_code:
  stage: test
  script:
    - pip install flake8
    - flake8 .

# Задача 2: Тесты (стадия test, выполняется параллельно с lint_code)
run_tests:
  stage: test
  script:
    - pip install pytest
    - pytest ./tests

# Задача 3: Сборка Docker-образа (стадия package)
build_image:
  stage: package
  # Для сборки образа внутри CI используется специальный образ docker:cli
  image: docker:cli
  # Указываем, что задача выполняется только при пуше в ветку main
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  script:
    - docker build -t myapp:latest .
    # (В следующей главе мы добавим команду docker push)

В этом конвейере мы реализовали классический CI-процесс. При любом пуше в репозиторий параллельно запускаются тесты и проверка стиля кода. Если хотя бы одна из этих проверок падает, пайплайн прерывается. Если обе проходят успешно, и изменения были слиты в ветку main, запускается стадия package, которая собирает Docker-образ, используя написанный нами ранее Dockerfile.

Мы автоматизировали проверку и сборку. У нас есть готовый, протестированный артефакт (Docker-образ). Следующий логический шаг — автоматически доставить этот образ на наши серверы, настроенные через Ansible. Этот процесс называется Непрерывной доставкой (CD), и именно к нему мы перейдем далее.

Непрерывная доставка (CD): стратегии деплоя и управление артефактами

Пайплайн отработал, тесты пройдены, линтеры не нашли ни одной ошибки, а Docker-образ успешно собран. Зеленая галочка в GitLab CI радует глаз. Но для конечного пользователя продукта ничего не изменилось — он всё ещё видит старую версию сайта. Возникает главный вопрос: где сейчас находится собранный образ и как безопасно, не прерывая работу пользователей, заменить им старую версию на «боевом» сервере (production)?

В этой статье мы перейдем от Непрерывной интеграции (CI) ко второй части аббревиатуры CI/CD — Непрерывной доставке.

Container Registry: дом для ваших артефактов

В прошлой главе мы выяснили, что результатом работы CI-пайплайна является артефакт. В мире современной разработки таким артефактом чаще всего выступает Docker-образ.

Но Docker-образ, собранный на временном GitLab Runner, исчезнет вместе с удалением контейнера раннера, если его никуда не сохранить. Нам нужно централизованное хранилище, откуда сервер production сможет этот образ скачать. Такое хранилище называется Container Registry (Реестр контейнеров).

Если Git-репозиторий хранит исходный код, то Container Registry хранит готовые к запуску бинарные артефакты (образы). Самый известный публичный реестр — Docker Hub. Однако компании используют приватные реестры (GitLab Container Registry, AWS ECR, Nexus), чтобы скрыть проприетарный код.

Процесс сохранения артефакта выглядит так:

CI-пайплайн собирает образ: docker build -t myapp:v2.0 .
CI-пайплайн авторизуется в реестре: docker login ...
CI-пайплайн отправляет образ в хранилище: docker push myapp:v2.0

Теперь образ $v2.0` надежно сохранен. Осталось доставить его на сервер.

Delivery против Deployment: в чем разница?

Буквы «CD» в термине CI/CD часто вызывают путаницу, так как могут расшифровываться двояко. Разница между ними заключается всего в одном клике мыши, но этот клик определяет культуру всей компании.

Continuous Delivery (Непрерывная доставка): Код автоматически собирается, тестируется и подготавливается к релизу. Он загружен в Container Registry и готов к развертыванию в любую секунду. Однако сам процесс деплоя на production запускается вручную (например, релиз-менеджером по кнопке «Deploy» в GitLab).
Continuous Deployment (Непрерывное развертывание): Полная автоматизация. Если разработчик сделал коммит в главную ветку и тесты прошли успешно, код автоматически, без участия человека, улетает на production.

«Если вы боитесь нажать кнопку деплоя в пятницу вечером, значит, ваша система Continuous Deployment недостаточно хороша. Цель CD — сделать релизы скучным и рутинным событием».

Jez Humble, соавтор книги "Continuous Delivery"

Для новичков и критически важных финансовых систем стандартом является Delivery. Deployment — это высший пилотаж (как у Amazon или Netflix, которые делают тысячи автоматических релизов в день), требующий идеального покрытия тестами.

Стратегии деплоя: как обновить систему без боли

Представим, что на сервере запущен контейнер с версией $v1.0$ . Нам нужно запустить $v2.0$ . Самый примитивный подход (стратегия Recreate) — остановить старый контейнер, скачать новый образ и запустить его.

Проблема очевидна: пока скачивается и запускается новый образ, приложение недоступно. Возникает downtime (время простоя). Для интернет-магазина в период распродаж минута простоя стоит десятки тысяч долларов. Поэтому инженеры используют стратегии развертывания без простоя (Zero-Downtime Deployment).

Rolling Update (Постепенное обновление)

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

Мы выключаем один сервер с версией $v1.0$ , обновляем его до $v2.0$ и возвращаем в строй. Затем берем следующий.

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

Blue/Green Deployment (Сине-зеленое развертывание)

Если приложение не поддерживает одновременную работу двух разных версий, используют стратегию Blue/Green.

У нас есть две абсолютно идентичные инфраструктуры.

Blue (Синяя) — текущая активная среда, куда идет $100\%$ пользовательского трафика. Здесь работает версия $v1.0$ .
Green (Зеленая) — точная копия инфраструктуры, но скрытая от пользователей.

Мы спокойно развертываем версию $v2.0$ в Зеленой среде. Тестировщики могут зайти туда по специальному внутреннему адресу и всё проверить. Когда мы уверены, что всё работает идеально, мы просто переключаем маршрутизатор (балансировщик). Трафик мгновенно перенаправляется с Синей среды на Зеленую.

Плюсы: Мгновенное переключение. Если в новой версии обнаружится критический баг, откат (rollback) осуществляется таким же мгновенным переключением маршрутизатора обратно на Синюю среду. Минусы: Дорого. Вам нужно оплачивать двойной объем серверов, даже если вторая среда большую часть времени простаивает.

Canary Release (Канареечный релиз)

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

В IT канареечный релиз означает, что мы направляем на новую версию $v2.0$ лишь малую долю реального трафика — например, $5\%$ . Остальные $95\%$ пользователей продолжают работать с проверенной $v1.0$ .

DevOps-инженер внимательно следит за графиками мониторинга (ошибки 500, время ответа). Если у этих $5\%$ пользователей всё хорошо, трафик на новую версию постепенно увеличивают: $10\% \to 25\% \to 50\% \to 100\%$ . Если пошли ошибки — новую версию немедленно «убивают», а весь трафик возвращается на старую.

Реализация CD в GitLab CI/CD

Давайте свяжем теорию с практикой и добавим стадию доставки в наш .gitlab-ci.yml, который мы начали писать в прошлой главе.

Мы добавим две новые задачи: отправку образа в Registry и сам деплой.

stages:
  - test
  - build
  - deploy

# ... (задачи test и build из прошлой главы) ...

push_to_registry:
  stage: build
  image: docker:20.10.16
  script:
    - docker build -t my-registry.com/myapp:$CI_COMMIT_SHORT_SHA .
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASS my-registry.com
    - docker push my-registry.com/myapp:$CI_COMMIT_SHORT_SHA

deploy_to_production:
  stage: deploy
  image: alpine:latest
  script:
    # Здесь мы используем SSH для подключения к серверу и обновления контейнера
    - apk add --no-cache openssh-client
    - ssh user@production-server "docker pull my-registry.com/myapp:$CI_COMMIT_SHORT_SHA && docker run -d -p 80:80 my-registry.com/myapp:$CI_COMMIT_SHORT_SHA"
  environment:
    name: production
  when: manual # Это превращает процесс в Continuous Delivery!

Обратите внимание на два важных момента:

Мы используем встроенную переменную $CI_COMMIT_SHORT_SHA (короткий хэш коммита Git) в качестве тега для Docker-образа. Это гарантирует, что каждый образ уникален и мы всегда знаем, из какого именно кода он собран.
Директива when: manual в задаче deploy_to_production. Пайплайн остановится после сборки образа и будет ждать. Только когда человек зайдет в интерфейс GitLab и нажмет кнопку «Play», скрипт пойдет на сервер по SSH и запустит новую версию.

Мы построили мост от написания кода до его появления на сервере. Однако в нашем скрипте деплоя используется простой SSH-доступ к одному серверу. Если серверов десятки, а контейнеров сотни, ручное управление через SSH становится невозможным. Для управления таким масштабом индустрия использует оркестраторы.

Оркестрация контейнеров: архитектура и базовые объекты Kubernetes

Представьте, что у вас 5 серверов, на которых крутятся 50 Docker-контейнеров с микросервисами вашего приложения. Внезапно у одного из серверов сгорает материнская плата. Вместе с ним умирают 10 контейнеров: часть базы данных, кэш и сервис авторизации. Как быстро вы сможете подключиться по SSH к оставшимся серверам, вычислить, чего именно не хватает, и запустить упавшие контейнеры вручную? Минуты? Часы? А если ночью трафик резко вырастет и потребуется запустить еще 20 копий сервиса авторизации?

Управлять контейнерами вручную или через простые скрипты на масштабе невозможно. Нам нужна система, которая будет следить за состоянием серверов, сама перезапускать упавшие приложения, распределять нагрузку и проводить обновления без простоев.

Такая система называется оркестратором, а безоговорочным стандартом оркестрации в современной IT-индустрии является Kubernetes (часто сокращают до K8s).

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

Архитектура: мозг и мускулы кластера

Kubernetes не устанавливается на один компьютер. Он объединяет группу серверов в единую вычислительную сеть — кластер. Чтобы кластер работал как единый организм, его узлы (серверы) делятся на две логические группы: управляющие (мозг) и рабочие (мускулы).

Control Plane (Управляющий слой)

Это набор компонентов, которые принимают глобальные решения о кластере (например, на каком сервере запустить новый контейнер) и реагируют на события (например, запускают новый контейнер, если старый упал).

В Control Plane входят:

API Server — «входная дверь» кластера. Все команды от инженеров (через утилиту kubectl) или от систем CI/CD поступают сюда. Это единственный компонент, с которым мы общаемся напрямую.
etcd — база данных кластера. Хранит абсолютно всю информацию о том, что сейчас происходит в системе. Если API Server — это уши и рот кластера, то etcd — его память.
Scheduler (Планировщик) — диспетчер. Когда вы просите запустить новое приложение, Scheduler оценивает свободные ресурсы на серверах и решает, куда именно его поместить.
Controller Manager — супервизор. Он непрерывно сравнивает желаемое состояние системы (которое вы описали) с фактическим (которое есть сейчас). Если они различаются, он отдает команду исправить ситуацию.

Worker Nodes (Рабочие узлы)

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

Kubelet — «прораб» на стройке. Он получает приказы от API Server и следит за тем, чтобы нужные контейнеры на его сервере работали исправно.
Kube-proxy — сетевой регулировщик. Настраивает правила маршрутизации, чтобы контейнеры могли общаться друг с другом и с внешним миром.
Container Runtime — программа, которая умеет запускать контейнеры (например, Docker или containerd).

Базовые объекты: на каком языке говорит Kubernetes

Вспомните декларативный подход из Terraform: мы не пишем скрипты «как сделать», мы описываем «что хотим получить». Kubernetes работает точно так же. Мы передаем в API Server YAML-файлы (манифесты), в которых описано желаемое состояние инфраструктуры.

Чтобы писать эти манифесты, нужно знать базовые сущности (объекты) Kubernetes.

1. Pod (Под): минимальная единица

Вы могли бы подумать, что K8s управляет Docker-контейнерами. Это не совсем так. Kubernetes оборачивает один или несколько контейнеров в логическую капсулу, которая называется Pod.

Зачем нужна эта обертка? Иногда двум разным контейнерам нужно работать в неразрывной связке. Например, один контейнер — это веб-сервер (Nginx), а второй — программа, которая собирает его логи и отправляет в систему мониторинга (Logstash). Если поместить их в один Pod, они будут делить общий IP-адрес, общую память и смогут общаться друг с другом по localhost.

Pod — это как стручок гороха. Контейнеры внутри него — это горошины. Они всегда рождаются вместе, живут на одном сервере (Worker Node) и умирают вместе.

2. Deployment: менеджер подов

Поды смертны. Если сервер упадет, Pod исчезнет навсегда. Kubernetes не будет его перезапускать.

Поэтому мы почти никогда не создаем Pod напрямую. Вместо этого мы создаем объект Deployment (Развертывание). Вы говорите Deployment'у: «Я хочу, чтобы всегда работало 3 копии (реплики) вот такого Пода».

Deployment берет на себя всю грязную работу:

Самовосстановление (Self-healing): Если один Pod умирает (из-за ошибки в коде или падения сервера), Controller Manager замечает, что реплик стало 2 вместо 3, и Deployment мгновенно создает новый Pod на здоровом узле.
Масштабирование: Если нагрузка выросла, вы просто меняете в манифесте цифру с 3 на 10.
Обновления без простоев: В прошлой главе мы обсуждали стратегию Rolling Update. Deployment реализует её из коробки.

3. Service: стабильный адрес в изменчивом мире

Поскольку Поды постоянно создаются и удаляются (при обновлениях или сбоях), их IP-адреса постоянно меняются.

Представьте, что у вас есть микросервис Frontend, который должен отправлять запросы к микросервису Backend. Если Backend состоит из трех Подов, и их IP-адреса меняются каждый день, как Frontend поймет, куда слать запрос?

Эту проблему решает объект Service (Сервис). Service — это стабильный, неизменный IP-адрес и DNS-имя, которое привязывается к группе Подов. Кроме того, Service работает как балансировщик нагрузки (Load Balancer).

Когда Frontend обращается к сервису Backend, Service сам решает, на какой именно из трех живых Подов перенаправить этот конкретный запрос.

Существует три основных типа Service:

ClusterIP (по умолчанию) — сервис доступен только внутри кластера. Отлично подходит для баз данных и внутренних микросервисов.
NodePort — открывает определенный порт на каждом Worker Node. Позволяет достучаться до сервиса снаружи, обратившись к IP-адресу любого узла.
LoadBalancer — интегрируется с облачным провайдером (AWS, GCP, Яндекс.Облако) и заказывает у него внешний «железный» балансировщик, который будет направлять трафик из интернета в ваш кластер.

Как это выглядит на практике

Чтобы связать все концепции воедино, посмотрим на типичный манифест Kubernetes. В одном YAML-файле мы можем описать сразу и Deployment, и Service.

# Описываем Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 3               # Контроллер будет поддерживать ровно 3 Пода
  selector:
    matchLabels:
      app: web              # Deployment управляет Подами с такой меткой
  template:
    metadata:
      labels:
        app: web            # Вешаем метку на создаваемые Поды
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.21   # Docker-образ, который станет "горошиной" в стручке
        ports:
        - containerPort: 80

---
# Описываем Service
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer        # Делаем приложение доступным из интернета
  selector:
    app: web                # Service будет направлять трафик на Поды с этой меткой
  ports:
    - port: 80
      targetPort: 80

Обратите внимание на механизм Labels (меток) и Selectors (селекторов). Это клей, который связывает объекты в Kubernetes. Deployment знает, какими Подами управлять, потому что ищет метку app: web. Service знает, куда направлять трафик, потому что ищет ту же самую метку.

Резюме

Kubernetes забирает у инженера рутину. Мы больше не подключаемся к серверам, чтобы запустить контейнер. Мы общаемся с API Server, передавая ему декларативные манифесты. Deployment гарантирует, что нужное количество Подов всегда запущено и обновляется без простоев, а Service обеспечивает надежную сеть и балансировку, скрывая от нас хаос постоянно меняющихся IP-адресов.

Однако, передав управление умной системе, мы сталкиваемся с новой проблемой: кластер становится "черным ящиком". Если приложение начало тормозить, как понять, виноват ли код, нехватка памяти на Worker Node или сетевые задержки внутри Kube-proxy? В следующей главе мы разберем стек инструментов мониторинга и логирования, который позволит сделать инфраструктуру прозрачной.

Мониторинг, логирование и наблюдаемость систем: стек Prometheus и ELK

В предыдущей главе мы развернули приложение в Kubernetes: десятки Подов автоматически создаются, масштабируются и уничтожаются в зависимости от нагрузки. С точки зрения оркестрации это триумф. Но с точки зрения эксплуатации мы только что создали гигантский «черный ящик». Если прямо сейчас у 5% пользователей не проходит оплата, как мы об этом узнаем? И главное — как найдем причину среди сотен эфемерных контейнеров, которые, возможно, уже удалены контроллером?

Чтобы управлять системой, мы должны ее видеть. В этой статье мы превратим черный ящик в прозрачный механизм с помощью концепции наблюдаемости.

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

Исторически инженеры говорили о мониторинге — процессе сбора метрик, чтобы ответить на вопрос: «Работает ли система прямо сейчас?». Но в микросервисной архитектуре просто знать о падении недостаточно. Нам нужно ответить на вопрос: «Почему она не работает?».

Способность системы рассказывать о своем внутреннем состоянии по внешним данным называется наблюдаемостью (Observability). Она опирается на три фундаментальных типа данных:

Метрики (Metrics) — числовые значения, измеряемые с течением времени. Например: загрузка CPU, количество активных пользователей, частота HTTP-ошибок. Метрики идеальны для построения графиков и срабатывания тревоги (алертов).
Логи (Logs) — текстовые записи о конкретных событиях, произошедших в системе. Например: «Пользователь ID 402 не найден в базе данных в 14:05:01». Логи нужны для детального расследования (дебаггинга).
Трейсы (Traces) — путь одного конкретного запроса через все микросервисы от начала до конца.

В этой главе мы сфокусируемся на двух главных инструментах индустрии: Prometheus (для метрик) и стеке ELK (для логов).

Prometheus: сбор метрик в динамической среде

Prometheus — это стандарт де-факто для мониторинга в Kubernetes. Его главная архитектурная особенность заключается в том, как именно он собирает данные.

Существует два подхода к сбору метрик:

Push-модель: приложения сами отправляют (пушат) свои метрики на центральный сервер мониторинга.
Pull-модель: центральный сервер мониторинга сам регулярно опрашивает (пуллит) приложения и забирает у них метрики.

Prometheus использует Pull-модель. Почему это критически важно для Kubernetes?

Представьте, что у вас работает 1000 Подов, и вы используете Push-модель. Если сервер мониторинга зависнет на пару секунд, 1000 Подов начнут скапливать метрики, а затем одновременно отправят их, устроив серверу DDoS-атаку. В Pull-модели Prometheus сам контролирует нагрузку: он опрашивает сервисы по очереди с заданной частотой (например, раз в 15 секунд). Если сервис не ответил — Prometheus просто фиксирует это как факт недоступности.

Как Prometheus находит кого опрашивать?

В Kubernetes Поды постоянно меняют IP-адреса. Prometheus решает эту проблему с помощью механизма Service Discovery (обнаружение сервисов). Он напрямую подключается к API-серверу Kubernetes (Control Plane) и подписывается на события. Как только появляется новый Pod с нужными метками (Labels), Prometheus автоматически добавляет его IP-адрес в свой список опроса.

Exporters: переводчики метрик

Prometheus понимает данные только в своем специфическом текстовом формате. Но как получить метрики от базы данных PostgreSQL или самого сервера Linux, которые ничего не знают о Prometheus?

Для этого используются Экспортеры (Exporters) — небольшие программы-агенты, которые устанавливаются рядом с приложением. Они собирают локальные данные (например, использование диска) и отдают их по HTTP-протоколу в формате, понятном Prometheus. Самый популярный из них — Node Exporter, который собирает метрики операционной системы с Worker-узлов.

Alertmanager и проблема Alert Fatigue

Собрать метрики — половина дела. Нужно вовремя разбудить инженера, если что-то сломалось. В экосистеме Prometheus за это отвечает компонент Alertmanager.

Prometheus регулярно вычисляет правила на языке PromQL (Prometheus Query Language). Например, мы можем задать правило: если загрузка процессора $CPU \geq 80\%$ длится дольше 5 минут, отправить сигнал в Alertmanager. Тот, в свою очередь, маршрутизирует этот сигнал: отправляет сообщение в Slack, создает тикет в Jira или звонит дежурному инженеру через PagerDuty.

Здесь кроется главная ловушка мониторинга — Alert Fatigue (усталость от алертов).

Если вы установите слишком низкий порог срабатывания (например, реагировать на секундный скачок CPU), система будет присылать десятки ложных уведомлений в день. Инженеры привыкнут к «шуму» и начнут игнорировать канал с алертами. В итоге, когда произойдет реальная авария, на нее никто не отреагирует.

Хороший алерт всегда требует действия. Если инженер получает уведомление, смотрит на него и говорит «а, это нормально, само пройдет» — такой алерт нужно немедленно удалить или перенастроить.

Grafana: лицо ваших данных

Сам по себе Prometheus имеет очень аскетичный интерфейс, пригодный только для тестирования запросов. Для визуализации метрик индустрия использует Grafana — мощный инструмент построения дашбордов.

Grafana не хранит метрики. Она подключается к Prometheus как к источнику данных (Data Source), отправляет ему PromQL-запросы и отрисовывает полученные цифры в виде красивых графиков, спидометров и тепловых карт. Именно дашборды Grafana висят на больших экранах в офисах эксплуатации.

Централизованное логирование: стек ELK

Если метрики из Grafana показали нам, что произошел всплеск ошибок (например, количество HTTP-ответов 500 резко выросло), то для ответа на вопрос почему нам нужны логи.

В эпоху одного сервера мы могли зайти по SSH и прочитать файл /var/log/nginx/error.log. В Kubernetes это не работает:

Контейнеры эфемерны. Если Pod упал с ошибкой (CrashLoopBackOff), Kubernetes его пересоздаст. Логи старого контейнера исчезнут навсегда.
Искать ошибку вручную, перебирая логи 50 разных микросервисов, — невыполнимая задача.

Нам нужно собирать логи со всех машин в реальном времени и складывать их в единую надежную базу данных с возможностью быстрого полнотекстового поиска. Эту задачу решает стек ELK (Elasticsearch, Logstash, Kibana).

В отличие от Prometheus, системы логирования работают по Push-модели.

Компоненты ELK

Beats (или Fluentd / Promtail) — легковесные агенты-сборщики. Они устанавливаются на каждом узле Kubernetes (обычно как DaemonSet, чтобы гарантированно работать на каждой машине). Их задача — непрерывно читать файлы логов всех запущенных контейнеров и отправлять их дальше.
Logstash — конвейер обработки. Логи приходят в разных форматах: где-то это JSON, где-то обычный текст, где-то многострочные ошибки Java (stack trace). Logstash парсит эти строки, разбивает их на структурированные поля (дата, уровень ошибки, IP-адрес) и фильтрует мусор.
Elasticsearch — сердце системы. Это мощная поисковая система и NoSQL база данных. Она индексирует каждый кусок текста, позволяя искать нужное слово среди терабайтов логов за миллисекунды.
Kibana — веб-интерфейс для Elasticsearch. Здесь инженеры вводят поисковые запросы (например, показать все логи с level: ERROR и service: payment за последние 15 минут) и видят результаты.

Синтез: как выглядит расследование инцидента

Теперь, когда у нас есть и метрики, и логи, давайте посмотрим, как эти инструменты работают вместе во время реального сбоя:

Симптом: Пользователи массово загружают тяжелые отчеты. База данных начинает тормозить.
Метрики (Prometheus): Замечает, что время ответа сервиса отчетов превысило 2 секунды ( $Latency > 2s$ ).
Алерт (Alertmanager): Отправляет сообщение дежурному в Slack: [FIRING] High Latency on Report Service.
Визуализация (Grafana): Инженер переходит по ссылке из алерта в Grafana. На графике видно, что нагрузка на CPU базы данных уперлась в 100%, а количество HTTP 500 ошибок начало расти ровно в 14:30.
Поиск причины (Kibana): Инженер открывает Kibana, выделяет временной интервал с 14:28 до 14:35 и ищет логи сервиса отчетов со статусом ERROR.
Находка: Kibana моментально выдает логи с текстом ошибки: OutOfMemoryError: Java heap space при попытке выполнить конкретный SQL-запрос.
Решение: Инженер понимает, что проблема в неоптимизированном запросе, передает контекст разработчикам и временно увеличивает лимиты памяти для Пода.

Без стека Prometheus и ELK этот процесс занял бы часы ручного поиска вслепую. С настроенной наблюдаемостью причина находится за минуты.

В следующей главе мы поговорим о том, как защитить весь этот выстроенный конвейер — от кода до развернутых в Kubernetes подов — внедрив практики DevSecOps и управление секретами.

Безопасность в DevOps (DevSecOps): защита конвейера и секретов

В 2018 году стартап по аналитике данных совершил фатальную ошибку: разработчик случайно закоммитил в публичный репозиторий на GitHub конфигурационный файл, содержащий корневые ключи доступа к облаку AWS. Через 3 минуты боты-парсеры злоумышленников нашли этот ключ. Через 5 минут в облаке стартапа были запущены сотни самых мощных виртуальных машин для майнинга криптовалюты. К моменту, когда инженеры заметили аномалию, счет за услуги AWS превысил 100 000 долл. Эта история идеально иллюстрирует парадокс: мы построили конвейер CI/CD, который доставляет код в продакшен за минуты, но теперь любая уязвимость или утечка данных достигает пользователей с той же невероятной скоростью. Скорость DevOps стала скоростью катастрофы.

Концепция Shift-Left: безопасность как встроенная функция

Традиционно проверка безопасности происходила в самом конце цикла разработки. Команда писала код, тестировала его, готовила к релизу, и только перед самым запуском передавала проект в отдел информационной безопасности (Security). Безопасники находили критическую уязвимость, блокировали релиз и возвращали код на переделку. Это вызывало конфликты, срывало сроки и полностью противоречило философии непрерывной поставки.

Чтобы решить эту проблему, DevOps эволюционировал в DevSecOps. Главная идея этой трансформации описывается термином Shift-Left (Сдвиг влево).

Shift-Left — это практика переноса процессов тестирования и проверок безопасности на максимально ранние этапы жизненного цикла разработки (на левую часть временной шкалы проекта).

Вместо того чтобы ждать финального релиза, мы встраиваем автоматизированные проверки безопасности прямо в наш конвейер GitLab CI/CD. Разработчик делает коммит — конвейер не только собирает код, но и немедленно ищет в нем уязвимости. Безопасность перестает быть шлагбаумом в конце пути и становится непрерывным процессом.

Автоматизированные сканеры в конвейере

Чтобы реализовать Shift-Left на практике, в пайплайн добавляют специализированные задачи (Jobs), которые запускают различные типы анализаторов. Они работают на разных этапах конвейера и решают разные задачи:

SAST (Static Application Security Testing). Сканирует исходный код приложения до его компиляции или сборки. SAST ищет известные паттерны уязвимостей: например, отсутствие экранирования пользовательского ввода (что ведет к SQL-инъекциям) или использование небезопасных криптографических функций. Это самая ранняя проверка.
SCA (Software Composition Analysis). Современные приложения на 80% состоят из сторонних библиотек (пакеты npm, pip, maven). SCA-сканеры проверяют файл зависимостей вашего проекта и сверяют версии используемых библиотек с глобальными базами уязвимостей (CVE). Если вы используете старую версию библиотеки с известной дырой, пайплайн упадет.
Container Scanning. Анализирует собранный Docker-образ. Сканер проверяет базовый образ ОС (например, наличие уязвимостей в системных утилитах Ubuntu или Alpine) и установленные пакеты.
DAST (Dynamic Application Security Testing). Тестирование методом «черного ящика». DAST запускается на этапе, когда приложение уже развернуто в тестовой среде (например, в Kubernetes). Сканер имитирует действия хакера: пытается отправить вредоносные запросы, подменить заголовки или провести XSS-атаку на работающий сервис.

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

Проблема секретов: почему переменные окружения — не панацея

Даже если код написан идеально и не содержит уязвимостей, приложению нужно как-то подключаться к базе данных, обращаться к внешним API и расшифровывать сессии. Для этого нужны пароли, токены и сертификаты — всё это объединяется понятием секреты.

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

Первым шагом к исправлению обычно становится использование переменных окружения конвейера (например, CI/CD Variables в GitLab). Мы сохраняем пароль в настройках GitLab, а во время деплоя пайплайн подставляет его в манифест Kubernetes. Это лучше хардкода, но порождает новые проблемы:

Расползание секретов (Secret Sprawl). Секреты оседают в логах CI/CD, в истории сборок, в конфигурационных картах кластера.
Статичность. Пароль базы данных может не меняться годами. Если кто-то скопирует его сегодня, он сможет использовать его и через год.
Отсутствие аудита. Невозможно точно узнать, какое именно приложение или разработчик использовали конкретный пароль в 14:00 во вторник.

Динамическое управление секретами: HashiCorp Vault

Решением проблемы статических секретов становятся специализированные системы класса Secret Management. Индустриальным стандартом здесь является HashiCorp Vault.

Vault кардинально меняет парадигму: вместо того чтобы хранить один вечный пароль, он генерирует динамические секреты.

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

Как это работает в связке с Kubernetes:

Pod с приложением запускается в кластере. У него нет пароля от базы данных.
Приложение обращается к API Vault и подтверждает свою личность (аутентифицируется с помощью специального токена Kubernetes).
Vault проверяет права этого приложения и, если доступ разрешен, подключается к базе данных.
Vault создает в базе данных нового пользователя с уникальным логином и паролем, дает ему права только на нужные таблицы и устанавливает срок жизни (например, 1 час).
Vault возвращает эти уникальные данные приложению.
Приложение работает с базой. Через час Vault автоматически удаляет этого пользователя из базы данных. Если приложению нужно продолжить работу, оно должно запросить продление аренды (lease) или новый секрет.

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

Доверие к самому конвейеру: атаки на цепочку поставок

Внедряя DevSecOps, важно помнить: система CI/CD обладает колоссальной властью. GitLab Runner имеет права собирать код, пушить образы в Container Registry и применять манифесты в Kubernetes. Если злоумышленник взломает сервер CI/CD, он получит контроль над всей инфраструктурой. Это называется атакой на цепочку поставок (Supply Chain Attack).

Чтобы минимизировать этот риск, применяется принцип наименьших привилегий (Principle of Least Privilege). Конвейер не должен иметь административных прав («режима бога») в кластере Kubernetes. Для деплоя создается специальный сервисный аккаунт, права которого жестко ограничены с помощью механизма RBAC (Role-Based Access Control). Этому аккаунту разрешено изменять объекты Deployment и Service только в определенном пространстве имен (Namespace), но запрещено удалять узлы кластера или читать чужие секреты.

Безопасность в DevOps — это не разовая настройка антивируса. Это архитектурный подход, при котором проверки встроены в каждый шаг конвейера, секреты живут ровно столько, сколько необходимо, а права доступа выдаются по капле. В следующей главе мы объединим все изученные инструменты — от Git до Vault и Kubernetes — чтобы спроектировать финальную архитектуру отказоустойчивого пайплайна.

Проектирование отказоустойчивого пайплайна: синтез инструментов в единую систему

Разработчик отправляет код в репозиторий, идет наливать кофе, а через 15 минут его изменения уже обслуживают миллионы пользователей. Ни единого ручного клика, ни одного открытого SSH-доступа к серверу. Если в коде критическая уязвимость — сборка остановится. Если новый релиз потребляет слишком много памяти — система сама откатится на предыдущую версию. Как эта магия работает под капотом?

До этого момента мы изучали инструменты DevOps изолированно: Git для кода, Docker для изоляции, Terraform для облака, Kubernetes для оркестрации. Но настоящая ценность инженера заключается не в знании синтаксиса отдельных утилит, а в умении связать их в Golden Pipeline (золотой конвейер) — стандартизированный, безопасный и полностью автоматизированный путь доставки ценности.

В этой статье мы спроектируем итоговую архитектуру, где каждый изученный нами инструмент займет свое место в едином механизме.

Фундамент: подготовка сцены для приложения

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

Мы разделяем подготовку на два этапа, используя сильные стороны разных подходов:

Выделение ресурсов (Provisioning): Terraform обращается к API облачного провайдера (например, AWS). Он создает виртуальную сеть (VPC), настраивает правила фаервола и заказывает "голые" виртуальные машины. Terraform фиксирует это состояние в своем State-файле.
Настройка конфигурации (Configuration Management): Как только серверы запущены, в игру вступает Ansible. Он подключается к созданным машинам и превращает их в кластер Kubernetes: устанавливает Container Runtime, настраивает Kubelet и объединяет узлы в единую сеть.

В результате мы получаем готовый к работе кластер Kubernetes, описание которого полностью хранится в репозитории инфраструктурного кода.

Сборка и безопасность: конвейер GitLab CI

Фундамент готов. Теперь начинается жизненный цикл самого приложения. Точкой входа служит git push в главную ветку репозитория, который запускает пайплайн в GitLab CI/CD.

Современный пайплайн строится по принципу Shift-Left: мы проверяем безопасность и качество до того, как соберем артефакт.

Стадия Test & Sec (Тестирование и Безопасность): Параллельно запускаются модульные тесты и сканеры безопасности. SAST анализирует исходный код на наличие SQL-инъекций, а SCA проверяет зависимости (например, библиотеку log4j) на известные уязвимости. Если сканер находит критическую проблему — пайплайн падает, код не идет дальше.
Стадия Build (Сборка): Если код чист, GitLab Runner собирает Docker-образ. В качестве тега образа используется хэш коммита — это гарантирует однозначную связь между версией кода и артефактом.
Стадия Push (Сохранение): Собранный образ отправляется в Container Registry. Одновременно с этим запускается Container Scanning, чтобы убедиться, что базовый образ ОС внутри контейнера не содержит уязвимостей.

Доставка и динамические секреты

Артефакт лежит в Registry. Наступает этап Continuous Deployment — развертывание в кластере Kubernetes. Здесь возникает главная проблема безопасности: как передать приложению пароль от базы данных, не сохраняя его в коде?

В дело вступает HashiCorp Vault. Пайплайн не содержит самих секретов, он содержит лишь инструкции по их получению:

GitLab CI авторизуется в Vault, используя свой криптографический токен пайплайна.
Vault проверяет права и генерирует динамический секрет — логин и пароль для базы данных, которые будут действительны ровно 1 час.
GitLab CI передает эти временные учетные данные в Kubernetes в виде зашифрованного объекта.
Kubernetes применяет YAML-манифесты: обновляет объект Deployment, указывая новый тег Docker-образа.

Kubernetes начинает процесс Rolling Update. Он плавно гасит старые Поды и поднимает новые, передавая им динамические секреты. Пользователи не замечают простоя (Zero-Downtime).

Отказоустойчивость: петля обратной связи

Пайплайн не заканчивается на успешном деплое. В парадигме DevOps доставка — это лишь половина дела. Вторая половина — эксплуатация и наблюдаемость.

Отказоустойчивость системы описывается математически через коэффициент доступности:

A = \frac{MTBF}{MTBF + MTTR}

Где:

$A$ — доступность (Availability, те самые "девятки", например 0.999).
$MTBF$ — среднее время наработки на отказ (Mean Time Between Failures).
$MTTR$ — среднее время восстановления (Mean Time To Recovery).

DevOps-практики бьют по обеим частям формулы: качественное тестирование увеличивает время между сбоями ( $MTBF$ ), а автоматизация радикально снижает время восстановления ( $MTTR$ ).

Снижение $MTTR$ в нашей архитектуре обеспечивают два контура обратной связи: внутренний (Kubernetes) и внешний (Prometheus).

Внутренний контур: самовосстановление Kubernetes

Kubernetes постоянно сверяет желаемое состояние (описанное в манифестах) с фактическим. Для этого используются пробы (Probes):

Liveness Probe (проверка жизнеспособности): Kubelet периодически опрашивает эндпоинт приложения (например, /health). Если приложение зависло и не отвечает, Kubelet безжалостно убивает контейнер и запусками новый.
Readiness Probe (проверка готовности): определяет, готово ли приложение принимать трафик. Если Pod перегружен, проба не проходит, и Service временно перестает отправлять на него запросы пользователей.

Если из строя выходит целый физический сервер (Worker Node), Kubernetes замечает потерю связи и автоматически переносит все запущенные на нем Поды на другие доступные узлы кластера.

Внешний контур: наблюдаемость и автоматический откат

Что если приложение работает, пробы проходят, но новый код содержит логическую ошибку, из-за которой пользователи не могут добавить товар в корзину? Kubernetes этого не поймет — для него процесс жив.

Здесь включается стек мониторинга:

Prometheus собирает метрики со всех микросервисов (количество HTTP 500 ошибок, время ответа).
Alertmanager замечает, что после деплоя новой версии процент ошибок вырос с 0.1% до 15%.
Генерируется критический алерт. Он не только отправляет сообщение дежурному инженеру в Slack, но и дергает webhook в GitLab CI.
GitLab CI запускает пайплайн Rollback (отката), который возвращает Kubernetes к предыдущей, стабильной версии Docker-образа.

Так замыкается бесконечная петля DevOps: от написания кода до мониторинга и автоматической реакции на инцидент.

Путь одного коммита: резюме

Соберем все этапы в единую хронологию, чтобы увидеть, как инструменты передают эстафету друг другу:

Этап	Инструмент	Действие
Код	Git	Разработчик делает коммит и пушит код.
Проверка	GitLab CI + SAST/SCA	Запуск тестов, проверка кода и зависимостей на уязвимости.
Сборка	Docker	Упаковка приложения в неизменяемый образ.
Хранение	Container Registry	Сохранение образа с тегом, равным хэшу коммита.
Секреты	Vault	Генерация временных доступов к БД для нового релиза.
Деплой	Kubernetes	Плавное обновление Подов (Rolling Update) без простоя.
Контроль	Prometheus + ELK	Сбор метрик и логов с новой версии.
Реакция	Alertmanager	В случае аномалий — автоматический откат релиза.

Построенный нами Golden Pipeline — это не просто набор скриптов. Это техническое воплощение философии CALMS. Мы внедрили Автоматизацию (CI/CD), обеспечили Измерения (Prometheus/ELK), сократили потери времени (Бережливость) и создали среду, где разработка и эксплуатация говорят на одном языке кода.

Философия DevOps: преодоление разрыва между разработкой и эксплуатацией

Философия DevOps: преодоление разрыва между разработкой и эксплуатацией

Две конфликтующие вселенные

Рождение DevOps: разрушение стены

Культура важнее инструментов: фреймворк CALMS

1. Culture (Культура)

2. Automation (Автоматизация)

3. Lean (Бережливое производство)

4. Measurement (Измерение)

5. Sharing (Обмен знаниями)

Бесконечная петля DevOps

Что дальше?

Командная строка Linux и сетевые основы как фундамент работы инженера

Командная строка Linux и сетевые основы как фундамент работы инженера

Почему Linux и почему без графики?

Анатомия команды и стандартные потоки

Конвейер (Pipe): объединение утилит

Сети: как серверы находят друг друга

IP-адрес и Порт

DNS: телефонная книга интернета

Базовый набор инструментов диагностики

Управление версиями и стратегии ветвления в Git для совместной работы

Управление версиями и стратегии ветвления в Git для совместной работы

От хаоса к распределенному контролю

Анатомия коммита и три состояния файла

Ветвление: параллельные вселенные

Стратегии совместной работы: GitFlow против Trunk-Based

Виртуализация и контейнеризация: глубокое погружение в Docker

Виртуализация и контейнеризация: глубокое погружение в Docker

Виртуальные машины: изоляция любой ценой

Контейнеризация: легкость и общие ресурсы

Docker: стандарт упаковки приложений

Слоистая архитектура образов

Dockerfile: инфраструктура как код

Сетевое взаимодействие: проброс портов

Инфраструктура как код (IaC): автоматизация развертывания с Terraform

Инфраструктура как код (IaC): автоматизация развертывания с Terraform

От кликов мышкой к коду

Декларативный подход: говорим «что», а не «как»

Архитектура Terraform: как он общается с облаками

Зачем нужен State-файл?

Жизненный цикл инфраструктуры

Практика: пишем первый конфигурационный файл

От инфраструктуры к конфигурации

Управление конфигурациями и оркестрация серверов с помощью Ansible

Управление конфигурациями и оркестрация серверов с помощью Ansible

Разделение труда: Provisioning против Configuration Management

Архитектура Ansible: Push-модель и отсутствие агентов

Святая троица Ansible: Inventory, Modules, Playbooks

1. Inventory (Где выполнять?)

2. Modules (Чем выполнять?)

3. Playbooks (Что именно делать?)

Идемпотентность: почему мы не используем shell

Масштабирование логики: Ansible Roles

Подводя итоги

Непрерывная интеграция (CI): автоматизация сборки и тестирования в GitLab CI/CD

Непрерывная интеграция (CI): автоматизация сборки и тестирования в GitLab CI/CD

Что такое Непрерывная интеграция (CI)

Архитектура GitLab CI: Разделяй и властвуй

Анатомия пайплайна: .gitlab-ci.yml

Базовый синтаксис

Управление состоянием: Артефакты и Кэш

Артефакты (Artifacts)

Кэш (Cache)

Синтез: полноценный CI-пайплайн

Непрерывная доставка (CD): стратегии деплоя и управление артефактами

Непрерывная доставка (CD): стратегии деплоя и управление артефактами

Container Registry: дом для ваших артефактов

Delivery против Deployment: в чем разница?

Стратегии деплоя: как обновить систему без боли

Rolling Update (Постепенное обновление)

Blue/Green Deployment (Сине-зеленое развертывание)

Canary Release (Канареечный релиз)

Реализация CD в GitLab CI/CD

Оркестрация контейнеров: архитектура и базовые объекты Kubernetes

Оркестрация контейнеров: архитектура и базовые объекты Kubernetes

Архитектура: мозг и мускулы кластера

Control Plane (Управляющий слой)

Worker Nodes (Рабочие узлы)

Базовые объекты: на каком языке говорит Kubernetes

Анатомия пайплайна: `.gitlab-ci.yml`