DevOps Инженер: Путь от новичка до Junior+

Введение в DevOps, администрирование Linux и основы компьютерных сетей

Добро пожаловать на курс «DevOps Инженер: Путь от новичка до Junior+». Вы стоите на пороге одной из самых востребованных и динамичных профессий в IT. В этой первой статье мы заложим фундамент, на котором будут строиться все ваши дальнейшие знания. Мы разберем, что такое DevOps на самом деле (спойлер: это не просто должность), почему Linux — это «родной язык» серверов, и как компьютеры находят друг друга в глобальной сети.

Что такое DevOps: Философия, а не инструмент

Многие новички ошибочно полагают, что DevOps — это человек, который умеет пользоваться Docker и Jenkins. На самом деле, DevOps (акроним от Development и Operations) — это методология, культура и набор практик, призванных объединить разработку программного обеспечения (Dev) и его эксплуатацию (Ops).

Стена непонимания

Традиционно в IT-компаниях существовало два изолированных лагеря:

Разработчики (Dev): Их цель — создавать новые функции, писать код и как можно быстрее доставлять изменения пользователям. Их девиз: «Изменения».

Системные администраторы (Ops): Их цель — обеспечить стабильность работы серверов и доступность сервиса. Любое изменение несет риск сбоя. Их девиз: «Стабильность».

Между ними возникала так называемая «Стена непонимания» (Wall of Confusion). Разработчики «перекидывали» код через стену администраторам, а те пытались запустить его, часто сталкиваясь с ошибками, которых не было на компьютерах разработчиков.

!Иллюстрация конфликта интересов Dev и Ops и решение проблемы через DevOps

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

Цикл DevOps

Процесс DevOps бесконечен и изображается в виде лемнискаты (знака бесконечности). Он включает в себя этапы:

* Plan (Планирование): Определение задач. * Code (Код): Написание кода. * Build (Сборка): Компиляция и сборка приложения. * Test (Тестирование): Автоматическая проверка качества. * Release (Релиз): Подготовка к выпуску. * Deploy (Развертывание): Установка на сервера. * Operate (Эксплуатация): Поддержка работы. * Monitor (Мониторинг): Сбор метрик и логов.

Математика надежности

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

Формула доступности выглядит следующим образом:

Где: * — Availability (Коэффициент готовности), вероятность того, что система будет работать в произвольный момент времени. * — Mean Time Between Failures (Среднее время между сбоями), среднее время, которое система работает нормально до возникновения поломки. * — Mean Time To Repair (Среднее время восстановления), среднее время, необходимое для обнаружения сбоя и восстановления системы.

Наша задача как инженеров — максимизировать (делать системы надежными) и минимизировать (быстро чинить, если что-то сломалось).

Linux: Операционная система облаков

Если Windows доминирует на домашних ПК, то Linux — безоговорочный король серверов и облачных вычислений. Более 90% всей облачной инфраструктуры мира работает на Linux. Понимание этой ОС — обязательный навык для уровня Junior+.

Почему Linux?

Open Source: Код открыт, его можно изучать и изменять.

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

Автоматизация: Linux создан для управления через командную строку (CLI), что идеально подходит для написания скриптов.

Архитектура Linux

Упрощенно Linux состоит из трех слоев:

* Hardware (Железо): Процессор, память, диски. * Kernel (Ядро): Сердце системы. Это программа, которая управляет железом и распределяет ресурсы между программами. * Shell (Оболочка): Интерфейс, через который пользователь взаимодействует с ядром. Самая популярная оболочка — Bash.

!Структура операционной системы Linux: от пользователя к железу

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

В Linux «все есть файл». Даже подключенная клавиатура или процесс в памяти представлены в виде файлов. В отличие от Windows с дисками C:, D:, в Linux единая иерархическая структура, начинающаяся с корня (/).

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

Основы компьютерных сетей

DevOps-инженер связывает серверы между собой. Без понимания сетей вы не сможете настроить взаимодействие между базой данных и веб-приложением.

Модель взаимодействия

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

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

Представьте, что сервер — это многоквартирный дом.

* IP-адрес: Это адрес самого дома (например, 192.168.1.5). Он позволяет найти конкретный компьютер в сети. * Порт: Это номер квартиры в этом доме. На одном сервере может работать веб-сайт (обычно порт 80 или 443), база данных (порт 5432) и SSH для управления (порт 22).

Когда вы вводите адрес сайта, ваш браузер стучится в конкретный «дом» (IP) и в конкретную «квартиру» (Порт).

DNS (Domain Name System)

Людям сложно запоминать цифры вроде 142.250.185.78. Нам проще запомнить google.com. DNS — это телефонная книга интернета, которая переводит понятные человеку доменные имена в IP-адреса, понятные компьютеру.

Модель OSI (Упрощенно)

Для диагностики проблем сетевые инженеры используют модель OSI. Для старта вам нужно понимать разницу между:

Транспортный уровень (L4): Отвечает за доставку данных (протоколы TCP и UDP). TCP гарантирует доставку (как заказное письмо), UDP — нет (как стриминг видео, где потеря кадра не критична).

Прикладной уровень (L7): То, с чем работают приложения (HTTP, FTP, SSH).

> «В сети нет облаков, есть только чужие компьютеры» — Популярная поговорка среди системных администраторов.

Связь компонентов

Теперь объединим все три темы. Работа DevOps-инженера уровня Junior+ выглядит так:

Вы пишете код для автоматизации (DevOps подход).

Этот код запускается в командной строке (Linux).

Скрипт настраивает правила, по которым приложение будет доступно пользователям через интернет (Сети).

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

Заключение

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

Готовы проверить свои знания? Переходите к домашнему заданию.

Системы контроля версий Git и построение пайплайнов CI/CD

В предыдущей статье мы заложили фундамент, разобравшись с философией DevOps, операционной системой Linux и основами сетей. Теперь пришло время перейти к инструментам, которые превращают написание кода из хаоса в упорядоченный производственный процесс. Сегодня мы поговорим о «машине времени» для кода (Git) и автоматическом заводском конвейере (CI/CD).

Git: Фундамент современной разработки

Представьте, что вы пишете дипломную работу. У вас появляются файлы diplom_final.doc, diplom_final_v2.doc, diplom_tochno_final.doc. Это — примитивный контроль версий. В профессиональной разработке, где над одним проектом работают десятки людей, такой подход приведет к катастрофе.

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

Основные понятия Git

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

Репозиторий (Repository): Хранилище вашего проекта. Это папка, где лежат файлы кода и скрытая папка .git, содержащая всю историю изменений.

Коммит (Commit): Фиксация изменений. Это «снимок» (snapshot) состояния файлов в конкретный момент времени. У каждого коммита есть уникальный идентификатор (хэш) и сообщение автора.

Ветка (Branch): Параллельная линия разработки. Основная ветка обычно называется main или master. Для новой фичи создается отдельная ветка, чтобы не сломать основной код.

Слияние (Merge): Процесс объединения изменений из одной ветки в другую.

!Визуализация процесса ветвления и слияния (Branching and Merging) в Git

Жизненный цикл кода в Git

Для DevOps-инженера важно понимать, как код попадает на сервер. Обычно используется рабочий процесс (workflow), похожий на этот:

Разработчик клонирует репозиторий (git clone).

Создает новую ветку (git checkout -b feature-new).

Пишет код и сохраняет изменения (git commit).

Отправляет ветку на удаленный сервер, например, GitHub или GitLab (git push).

Создает запрос на слияние (Pull Request / Merge Request), чтобы коллеги проверили код.

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

Так как мы работаем в Linux, взаимодействие с Git происходит через консоль:

CI/CD: Автоматизация рутины

Если Git — это сейф для кода, то CI/CD — это робот, который берет код из сейфа, проверяет его и доставляет пользователю. Аббревиатура расшифровывается как Continuous Integration (Непрерывная интеграция) и Continuous Delivery/Deployment (Непрерывная доставка/развертывание).

Continuous Integration (CI)

Главная цель CI — как можно раньше найти ошибки. Как только разработчик отправляет код в репозиторий (делает git push), автоматически запускается процесс:

Сборка (Build): Код компилируется (если язык требует этого, например, Java или Go) или собирается в Docker-образ.

Тестирование (Test): Запускаются автотесты (unit-тесты, линтеры). Если тест падает, разработчик сразу получает уведомление.

> «Если это больно, делайте это чаще» — Джез Хамбл, автор книги Continuous Delivery, о принципе частых интеграций.

Continuous Delivery vs Deployment (CD)

Эти термины часто путают, но разница есть:

* Continuous Delivery (Непрерывная доставка): Код автоматически проходит все тесты и готов к релизу. Но кнопка «Развернуть на продакшн» нажимается человеком вручную. * Continuous Deployment (Непрерывное развертывание): Полная автоматизация. Если тесты прошли, код сам улетает к пользователям без участия человека.

!Этапы автоматического пайплайна: от кода до развертывания

Анатомия Пайплайна (Pipeline)

Пайплайн — это сценарий, описывающий шаги CI/CD. В большинстве систем (GitLab CI, GitHub Actions, Jenkins) он описывается в YAML-файле.

Пример простой логики пайплайна:

Здесь мы видим прямую связь с предыдущей лекцией: внутри секции script выполняются обычные команды Linux (echo, scp, запуск скриптов).

Метрики эффективности DevOps (DORA)

Как понять, что ваш CI/CD работает хорошо? Инженеры используют метрики DORA (DevOps Research and Assessment). Поскольку DevOps — это инженерная дисциплина, мы можем выразить эффективность математически.

Одной из ключевых метрик является Частота развертывания (Deployment Frequency). В простейшем случае это количество релизов за период времени.

Однако более интересна метрика Change Failure Rate (CFR) — процент развертываний, которые привели к сбою.

Где: * — Change Failure Rate (Коэффициент сбоев изменений), процент неудачных релизов. * — Failures (Количество сбоев), число развертываний, потребовавших хотфикса или отката. * — Total Deployments (Общее количество развертываний), суммарное число всех релизов за выбранный период.

Наша цель как Junior+ специалиста — стремиться к тому, чтобы росло (частые релизы), а стремился к нулю.

Еще одна важная метрика — Lead Time for Changes (Время внесения изменений). Это время, прошедшее от момента коммита до момента, когда код заработал в продакшене.

Где: * — Lead Time (Время выполнения), общее время доставки изменения. * — Time of Deployment (Время развертывания), момент времени, когда код попал на сервер. * — Time of Commit (Время коммита), момент времени, когда разработчик зафиксировал код.

Автоматизация CI/CD напрямую уменьшает , исключая ручные проверки и ожидания.

Инструменты CI/CD

На рынке существует множество инструментов. На уровне Junior+ вы должны уверенно владеть хотя бы одним из них и понимать принципы работы остальных:

GitLab CI: Один из самых популярных инструментов. Встроен прямо в GitLab. Конфигурируется через файл .gitlab-ci.yml.

GitHub Actions: Аналог от GitHub. Быстро набирает популярность благодаря огромному магазину готовых экшенов.

Jenkins: «Дедушка» CI/CD. Очень мощный, но сложный в настройке и поддержке. Требует знания Groovy для написания сложных пайплайнов.

Связь с предыдущими темами

Давайте соберем пазл:

* Linux: Пайплайны CI/CD запускаются на серверах (раннерах), которые работают на Linux. Команды внутри пайплайна — это Bash-скрипты. * Сети: Чтобы CI-сервер мог «выкатить» код на продакшн-сервер, между ними должна быть сетевая связность (настроенные SSH-ключи, открытые порты, правила Firewall). * Git: Является триггером. Пайплайн запускается не по расписанию, а по событию (push в репозиторий).

Заключение

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

В следующей статье мы перейдем к технологии, которая перевернула мир IT и сделала CI/CD по-настоящему эффективным — мы поговорим о контейнеризации и Docker.

А пока — проверьте, насколько хорошо вы усвоили материал.

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

В предыдущих статьях мы прошли путь от настройки Linux-сервера и понимания сетей до написания кода и автоматизации его проверки через CI/CD. Однако, даже с настроенным пайплайном, мы часто сталкиваемся с классической проблемой разработчика: «Но на моем компьютере это работало!».

Почему так происходит? У разработчика стоит Python 3.9, а на сервере 3.8. У разработчика одна версия библиотеки, а в продакшене — другая. Сегодня мы решим эту проблему раз и навсегда с помощью технологии, которая стала стандартом де-факто в индустрии — Docker.

Эволюция: От Виртуальных Машин к Контейнерам

Чтобы понять величие Docker, нужно вспомнить, как мы жили до него. Раньше, чтобы изолировать приложения друг от друга (например, чтобы один сайт не «уронил» другой), использовали Виртуальные Машины (VM).

Проблема Виртуальных Машин

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

Свое виртуальное «железо».

Свою полноценную операционную систему (Guest OS).

Само приложение.

Это очень расточительно. Операционная система может занимать гигабайты места и «съедать» гигабайт оперативной памяти просто чтобы существовать.

Решение: Контейнеризация

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

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

Математика эффективности

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

Для виртуальных машин формула выглядит так:

Где: * — Overhead (Общие затраты ресурсов) для виртуальных машин. * — количество запускаемых приложений. * — Resources App (ресурсы, нужные приложению). * — Resources OS (ресурсы, нужные для работы гостевой ОС).

Для контейнеров Docker формула меняется:

Где: * — Overhead (Общие затраты ресурсов) для контейнеров. * — Resources Engine (ресурсы, потребляемые самим Docker Daemon), которые пренебрежимо малы по сравнению с .

Именно поэтому на одном и том же сервере можно запустить 5 виртуальных машин или 50 контейнеров Docker.

Основные понятия Docker

Docker оперирует тремя главными сущностями. Запомните их как «Три кита»:

Dockerfile (Рецепт): Текстовый файл с инструкциями, как собрать приложение.

Image (Образ): Готовое «блюдо», приготовленное по рецепту. Это неизменяемый шаблон, содержащий код, библиотеки и зависимости.

Container (Контейнер): Запущенная копия образа. Это живой процесс, с которым можно взаимодействовать.

1. Пишем Dockerfile

Представьте, что мы хотим упаковать простое Python-приложение. Создадим файл с именем Dockerfile (без расширения):

Каждая строка здесь создает новый слой (layer). Docker использует кэширование: если вы изменили только код (COPY . .), но не трогали зависимости, Docker не будет заново выполнять RUN pip install, а возьмет готовый слой из кэша. Это ускоряет сборку (Build) в разы.

2. Сборка Образа (Build)

Теперь превратим этот текст в бинарный образ.

Здесь флаг -t задает имя (tag), а точка . указывает, что Dockerfile лежит в текущей папке.

3. Запуск Контейнера (Run)

Самый волнительный момент — запуск.

Разберем магию флагов: * -d (detach): Запустить в фоновом режиме (не занимать консоль). * -p 8080:5000 (publish): Проброс портов. Мы говорим: «Все запросы на порт 8080 моего компьютера перенаправь на порт 5000 внутри контейнера». * --name: Даем контейнеру понятное имя, чтобы не обращаться к нему по ID.

Docker Compose: Дирижер оркестра

В реальной жизни приложение редко работает в одиночку. Обычно у вас есть: Backend (Python), Database (PostgreSQL) и Frontend (React). Запускать их тремя разными командами docker run, настраивать сеть между ними вручную — это ад.

Здесь на сцену выходит Docker Compose. Это инструмент для описания и запуска многоконтейнерных приложений.

Вместо кучи команд мы создаем один файл docker-compose.yml:

Теперь, чтобы поднять всю инфраструктуру, нужна всего одна команда:

Docker Compose автоматически:

Создаст общую сеть, чтобы web мог видеть db по имени хоста.

Поднимет базу данных.

Соберет и запустит ваше приложение.

!Docker Compose интерпретирует YAML-файл и создает изолированную среду из нескольких связанных сервисов.

Хранение данных (Volumes)

Контейнеры по своей природе эфемериды (временны). Если вы удалите контейнер, все файлы, созданные внутри него, исчезнут. Это отлично для кода (он не должен меняться внутри), но ужасно для Баз Данных.

Чтобы данные жили дольше контейнера, используются Volumes (Тома).

Volume — это папка на хост-машине (вашем сервере), которая «промонтирована» внутрь контейнера. Даже если контейнер сгорит и будет пересоздан, он подключится к тому же Volume и увидит свои данные.

В примере выше мы использовали db_data:/var/lib/postgresql/data. Это значит, что все, что PostgreSQL пишет в свою внутреннюю папку /var/lib/..., на самом деле сохраняется в безопасном месте на диске сервера.

Связь с CI/CD и DevOps

Теперь пазл складывается. Как выглядит современный пайплайн Junior+ инженера?

Code: Разработчик пишет код и Dockerfile.

Git: Отправляет изменения в репозиторий.

CI (GitLab/GitHub): Раннер запускает docker build, создавая образ.

Test: Раннер запускает тесты внутри этого контейнера. Это гарантирует, что тесты идут в том же окружении, что и продакшн.

Registry: Если тесты прошли, образ загружается в хранилище (Docker Hub или GitLab Registry).

CD: На боевом сервере выполняется docker pull (скачивание образа) и docker-compose up -d (перезапуск).

Заключение

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

Мы разобрали: * Разницу между VM и Контейнерами (и доказали эффективность формулой ). * Три кита Docker: Dockerfile, Image, Container. * Управление мульти-контейнерными приложениями через Docker Compose.

Но что делать, если у вас не один сервер, а десять? И на них нужно запустить тысячу контейнеров? Как следить, чтобы они не падали? В следующей части курса мы коснемся темы Оркестрации, хотя для уровня Junior+ достаточно глубокого понимания Docker Compose.

А пока — проверьте, готовы ли вы к работе с контейнерами.

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

В предыдущей статье мы научились упаковывать приложения в Docker-контейнеры и даже запускать их группами с помощью Docker Compose. Это был огромный шаг вперед. Но давайте будем честны: Docker Compose отлично подходит для локальной разработки или одного сервера, но что произойдет, если этот единственный сервер сгорит?

Ваше приложение станет недоступным. Бизнес потеряет деньги. Вы потеряете сон.

Чтобы избежать этого, в мире «взрослого» DevOps используется кластеризация — объединение множества серверов в единый вычислительный ресурс. А управляет этим ресурсом оркестратор. Сегодня мы поговорим о короле оркестрации — Kubernetes (или просто K8s).

Зачем нам оркестрация?

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

Оркестратор — это дирижер, который автоматически:

Запускает контейнеры на доступных серверах.

Перезапускает их, если они сломались.

Масштабирует количество копий приложения при росте нагрузки.

Балансирует трафик между ними.

Математика надежности

Почему запуск нескольких копий (реплик) приложения на разных серверах повышает надежность? Это описывается теорией вероятностей.

Допустим, вероятность отказа одного сервера (или контейнера) составляет . Если у нас работает только одна копия, вероятность падения системы равна . Если мы запускаем независимых копий, система упадет только тогда, когда упадут все копии одновременно.

Формула вероятности отказа всей системы выглядит так:

Где: * — вероятность отказа всей системы (всех реплик одновременно). * — вероятность отказа одной реплики (например, 0.1 или 10%). * — количество реплик.

Если (10%), то для одной реплики риск отказа 10%. Но для трех реплик ():

То есть вероятность отказа снижается до 0.1%. Именно эту математику реализует Kubernetes, позволяя легко управлять параметром .

Архитектура Kubernetes

Kubernetes — это не одна программа, а набор компонентов, работающих сообща. Глобально кластер делится на две части: Control Plane (Управляющий слой, «Мозг») и Worker Nodes (Рабочие узлы, «Мускулы»).

!Упрощенная схема архитектуры Kubernetes: управляющий слой и рабочие узлы.

1. Control Plane (Master Node)

Здесь принимаются все решения. Обычные приложения здесь не запускаются.

* API Server: «Секретарь» кластера. Единственный компонент, с которым общаемся мы (инженеры) и другие компоненты. Все команды проходят через него. * etcd: «Память» кластера. Это надежное хранилище ключ-значение, где лежит вся информация о состоянии кластера. Если вы потеряете данные etcd, вы потеряете кластер. * Scheduler (Планировщик): «Логист». Он видит, что нужно запустить новый контейнер, смотрит на свободные ресурсы рабочих узлов и решает: «Ты пойдешь на сервер №5». * Controller Manager: «Надзиратель». Он следит за тем, чтобы текущее состояние кластера соответствовало желаемому. Если вы просили 3 копии, а одна упала, он заметит это и даст команду создать новую.

2. Worker Nodes

Это обычные Linux-сервера, где работают ваши приложения.

* Kubelet: «Прораб». Агент, который работает на каждом узле. Он получает инструкции от API Server (например, «Запусти этот контейнер») и передает их Docker'у. * Kube-proxy: «Сетевик». Отвечает за сетевые правила, чтобы запросы из интернета доходили до нужных контейнеров. * Container Runtime: Собственно, сам Docker (или его аналоги, например, containerd), который крутит контейнеры.

Базовые объекты Kubernetes

В Docker мы оперировали контейнерами. В Kubernetes все немного сложнее. K8s использует свои абстракции. Давайте разберем «кирпичики», из которых строится приложение.

Pod (Под)

Самый маленький и простой объект Kubernetes. Kubernetes не запускает контейнеры напрямую, он запускает Поды.

> «Pod — это группа из одного или нескольких контейнеров, с общим хранилищем и сетью» — Официальная документация Kubernetes.

Зачем нужна эта прослойка? Иногда вам нужно, чтобы два контейнера работали как единое целое (например, основной сервер и вспомогательный агент для сбора логов). В Поде они будут делить один IP-адрес и смогут общаться через localhost.

Но в 95% случаев действует правило: 1 Pod = 1 Контейнер.

ReplicaSet (РепликаСет)

Поды смертны. Если Под умирает, он не воскресает. Чтобы обеспечить ту самую надежность (), нам нужен кто-то, кто будет следить за количеством копий.

ReplicaSet гарантирует, что в любой момент времени запущено указанное количество реплик Пода. Если вы сказали «хочу 3 реплики», а один сервер сгорел вместе с Подом, ReplicaSet тут же создаст новый Под на другом сервере.

Deployment (Деплоймент)

На практике мы редко создаем Поды или ReplicaSet вручную. Мы используем Deployment.

Deployment — это надстройка над ReplicaSet. Он позволяет не только держать нужное количество копий, но и обновлять их.

Представьте, что вышла версия приложения v2. Deployment плавно создаст новый ReplicaSet с версией v2, начнет запускать там поды, и по одному удалять поды из старого ReplicaSet (версии v1). Это называется Rolling Update — обновление без простоя.

Service (Сервис)

Поды эфемерны. Они рождаются и умирают, и каждый раз получают новый случайный IP-адрес. Как же направить запрос на сайт, если его IP меняется каждую минуту?

Service — это стабильный сетевой адрес (и DNS-имя) для группы Подов. Он работает как внутренний балансировщик нагрузки.

Вы обращаетесь к Сервису (например, по имени my-web-app), а он пересылает запрос на любой живой Под из этой группы.

!Взаимодействие объектов: Service направляет трафик на динамически меняющиеся Pods, управляемые Deployment.

Декларативный подход: YAML

Главная фишка Kubernetes — декларативность.

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

В Kubernetes мы описываем Желаемое состояние (Desired State) в виде YAML-файла. Мы говорим: «Я хочу, чтобы было 3 реплики nginx». Мы не говорим как это сделать. Kubernetes сам решает, как привести Текущее состояние (Actual State) к Желаемому.

Пример простейшего манифеста (описания) Пода:

Чтобы применить этот файл, используется утилита kubectl (читается как «куб-контрол» или «куб-ктл»):

Заключение

Kubernetes кажется сложным из-за обилия новых терминов. Но его суть проста: это робот, который следит, чтобы ваше «Желаемое состояние» (описанное в YAML) всегда совпадало с реальностью.

Мы разобрали:

Архитектуру: Мозг (Control Plane) и Мускулы (Worker Nodes).

Математику надежности: Как репликация снижает вероятность отказа по формуле .

Базовые объекты: Pod (атом), Deployment (управление версиями и масштабом), Service (стабильная сеть).

Теперь вы понимаете теорию. Но Kubernetes — это практика. В следующих материалах мы настроим свой первый локальный кластер и запустим в нем настоящее приложение.

А пока — проверьте, как вы усвоили архитектуру оркестратора.

Инфраструктура как код (Terraform, Ansible) и мониторинг систем

В предыдущих модулях мы прошли большой путь: от ручной настройки Linux и написания скриптов до упаковки приложений в Docker и управления ими через Kubernetes. Но остался один фундаментальный вопрос: откуда берутся сами серверы?

До сих пор мы подразумевали, что у нас уже есть виртуальные машины или кластер Kubernetes. В реальной жизни Junior+ инженер не заходит на сайт хостинг-провайдера и не «накликивает» серверы мышкой. Это долго, ненадежно и невозможно повторить точь-в-точь. Сегодня мы переходим к практике Infrastructure as Code (IaC) и учимся следить за здоровьем наших систем.

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

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

Проблема «ClickOps»

Представьте, что вам нужно создать тестовую среду, идентичную продакшену. Если вы настраивали продакшен вручную через консоль AWS или Yandex Cloud, вам придется по памяти воспроизвести сотни настроек. Вероятность ошибки стремится к 100%. Это явление иронично называют ClickOps.

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

Версионировать в Git.

Тестировать.

Использовать повторно.

Декларативный vs Императивный подход

* Императивный (Как сделать): «Создай сервер, потом установи Nginx, потом запусти сервис». Это Bash-скрипты. * Декларативный (Что получить): «Я хочу 3 сервера с Nginx». Система сама решает, как это сделать. Это Terraform и Kubernetes.

Terraform: Строитель фундамента

Terraform от HashiCorp — это стандарт де-факто для Provisioning (создания) инфраструктуры. Он позволяет описать ресурсы облака (AWS, Google Cloud, Azure, Yandex Cloud) на языке HCL (HashiCorp Configuration Language).

Как это работает?

Вы пишете файл main.tf, где описываете желаемое состояние. Terraform читает его, обращается к API облачного провайдера и создает ресурсы.

Пример создания виртуальной машины:

State File (Файл состояния)

Магия Terraform кроется в файле terraform.tfstate. Когда вы запускаете код, Terraform сохраняет информацию о созданных ресурсах в этот файл. При следующем запуске он сравнит ваш код с файлом состояния и реальной инфраструктурой.

Если вы измените memory = 4 на memory = 8, Terraform увидит разницу и просто изменит параметры существующей машины, а не будет создавать новую (если это возможно).

!Terraform берет код конфигурации и преобразует его в реальные облачные ресурсы, сохраняя состояние в state-файле

Ansible: Мастер настройки

Если Terraform создает «стены и крышу» (серверы и сети), то Ansible занимается «интерьером» (установкой софта, правкой конфигов, созданием пользователей). Это инструмент Configuration Management.

Архитектура без агентов

Главное преимущество Ansible — Agentless. Вам не нужно устанавливать специальный софт на управляемые серверы. Ansible подключается по SSH (как вы делали это руками) и выполняет команды.

Playbook и Идемпотентность

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

Пример Playbook для установки Nginx:

Если Nginx уже установлен, Ansible просто напишет «OK» и ничего не будет делать. Bash-скрипт в таком случае мог бы попытаться установить его заново и выдать ошибку.

Мониторинг: Глаза и уши инженера

Запустив инфраструктуру кодом, мы не можем оставить её без присмотра. Мониторинг отвечает на вопросы: «Работает ли сервис?» и «Как быстро он работает?».

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

Метрики (Metrics): Числовые данные во времени. Пример: загрузка CPU 45%, количество запросов 200/сек.

Логи (Logs): Текстовые записи событий. Пример: Error: Connection timeout at 14:00.

Трейсинг (Tracing): Путь одного запроса через множество микросервисов.

Prometheus и Grafana

Золотой стандарт мониторинга в Kubernetes и современном DevOps:

Prometheus: База данных временных рядов. Она собирает* (pull model) метрики с ваших сервисов каждые N секунд. * Grafana: Инструмент визуализации. Она берет цифры из Prometheus и рисует красивые графики.

!Пример того, как инженер видит состояние системы через дашборды Grafana

Математика надежности: SLA и Бюджет ошибок

В мониторинге мы часто оперируем понятием SLA (Service Level Agreement) — соглашение об уровне обслуживания. Например, мы обещаем доступность 99.9% в месяц.

Исходя из SLA, мы можем рассчитать Бюджет ошибок (Error Budget) — время, которое наш сервис может «лежать», не нарушая контракт.

Формула расчета допустимого времени простоя:

Где: * — Time down (допустимое время простоя), время, которое сервис может не работать. * — Total time (общее время периода), например, количество минут в месяце (около 43 200). * — Service Level Agreement (уровень доступности), выраженный в долях единицы (например, 0.999 для 99.9%).

Давайте посчитаем для месяца (30 дней) и SLA 99.9%:

Это значит, что у команды есть всего 43 минуты в месяц на сбои и технические работы. Мониторинг должен уведомить нас о проблеме мгновенно, чтобы мы не исчерпали этот бюджет.

Связь инструментов в единый пайплайн

Как выглядит рабочий процесс Junior+ DevOps инженера?

Terraform создает виртуальные машины и настраивает сеть.

Ansible заходит на эти машины, устанавливает Docker и копирует конфиги.

CI/CD (GitLab/Jenkins) собирает приложение и деплоит его в Docker.

Prometheus начинает собирать метрики с запущенного приложения.

Grafana показывает вам зеленые графики.

Заключение

Сегодня мы замкнули круг. Теперь вы знаете не только как писать и запускать код, но и как создавать среду для его работы с нуля, используя подход Infrastructure as Code. Мы разобрали разницу между Terraform (создание) и Ansible (настройка), а также научились считать бюджет ошибок, чтобы понимать цену каждого простоя.

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

Готовы проверить, насколько хорошо вы поняли принципы IaC? Переходите к заданиям.