DevOps: от Linux к автоматизации

Фундамент: администрирование Linux, сети и автоматизация с Bash и Git

Добро пожаловать в курс DevOps: от Linux к автоматизации. Мы начинаем наше путешествие с самого основания. Представьте, что вы строите небоскреб. Инструменты вроде Docker, Kubernetes или Jenkins — это этажи, окна и коммуникации. Но Linux, сети и скрипты — это бетонный фундамент. Без прочного фундамента здание рухнет при первой же нагрузке.

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

Почему Linux?

В мире серверов Linux занимает доминирующее положение. Более 90% облачной инфраструктуры работает на Linux. DevOps-инженер, не знающий консоли (терминала), подобен хирургу, который боится крови. Графический интерфейс (GUI) на серверах часто отсутствует для экономии ресурсов и повышения безопасности. Вашим главным инструментом станет CLI (Command Line Interface).

!Структура взаимодействия пользователя с ядром Linux через оболочку

Навигация и управление файлами

В Linux все есть файл. Даже аппаратные устройства представлены в виде файлов. Файловая система имеет древовидную структуру, начинающуюся с корня /.

Основные команды, которые должны быть в вашей мышечной памяти:

* ls -la: показать список файлов (включая скрытые) с детальной информацией. * cd /путь/к/папке: сменить директорию. * mkdir project: создать новую папку. * rm -rf folder: удалить папку и всё её содержимое (будьте осторожны с этой командой!). * cat file.txt: вывести содержимое файла на экран. * grep "error" log.txt: найти слово "error" в файле log.txt.

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

Одна из частых причин проблем при деплое (развертывании) приложений — неверные права доступа. В Linux система прав базируется на трех действиях: чтение (read), запись (write) и исполнение (execute).

Права назначаются для трех групп: владелец файла (User), группа владельца (Group) и все остальные (Others).

Математика прав доступа

Права доступа часто записываются в восьмеричной системе счисления. Это тот случай, когда нам пригодится простая математика для понимания того, как компьютер интерпретирует ваши команды chmod.

Значение права доступа для каждой группы рассчитывается по формуле:

Где: * — итоговое числовое значение прав для одной группы (от 0 до 7). * — флаг чтения (1, если разрешено, 0, если нет). * — флаг записи (1, если разрешено, 0, если нет). * — флаг исполнения (1, если разрешено, 0, если нет).

Например, права rwx (чтение, запись, исполнение) дают:

Где: * — итоговое значение (полный доступ). * — наличие соответствующего права.

Если мы хотим дать владельцу полные права (7), группе — только чтение и исполнение (5), а остальным — ничего (0), мы используем команду:

Управление процессами и мониторинг

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

Для мониторинга в реальном времени используйте htop. Это более удобная и красочная версия классического top.

!Интерфейс мониторинга htop

Если процесс завис, его нужно принудительно завершить. Для этого используется команда kill вместе с PID (Process ID), который можно узнать через ps aux или тот же htop.

Сети и SSH

DevOps невозможен без сетей. Вы будете постоянно подключаться к удаленным серверам. Стандарт де-факто для этого — протокол SSH (Secure Shell).

Чтобы подключиться к серверу:

Для проверки доступности узла используйте ping, а для проверки доступности конкретного порта или веб-сервиса — curl или telnet.

Пример проверки ответа от веб-сервера:

Автоматизация с Bash

Главное правило DevOps: если вы делаете что-то дважды, автоматизируйте это. Bash-скрипты — это клей, который соединяет команды Linux в автоматические сценарии.

Любой скрипт начинается с шебанга (shebang) — указания интерпретатора:

Сохраните этот код в файл check_site.sh, дайте ему права на исполнение (chmod +x check_site.sh) и запустите (./check_site.sh). Вы только что создали простейший инструмент мониторинга.

Контроль версий с Git

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

!Основной рабочий процесс Git

Базовый цикл работы (Git Flow) выглядит так:

Инициализация: git init (создает репозиторий в папке).

Добавление файлов: git add script.sh (переносит файл в зону подготовки/Staging).

Фиксация изменений: git commit -m "Добавлен скрипт проверки сайта" (сохраняет снимок состояния).

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

> Git — это машина времени для вашего кода. Не пренебрегайте коммитами. — Линус Торвальдс, создатель Linux и Git.

Заключение

Сегодня мы заложили первый камень в фундамент вашей карьеры DevOps. Вы узнали, как управлять Linux, рассчитывать права доступа, писать простые скрипты на Bash и сохранять их в Git. Это базовые навыки, которые будут использоваться в каждом следующем модуле.

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

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

В предыдущей статье мы заложили фундамент: освоили Linux, научились работать в терминале и писать Bash-скрипты. Теперь представьте, что вы написали идеальный скрипт или приложение на своем ноутбуке. Оно работает великолепно. Вы отправляете его коллеге или пытаетесь запустить на сервере, и... оно падает с ошибкой. Почему? Разные версии библиотек, другая операционная система, отсутствующие зависимости. Знакомая ситуация, которая породила фразу: «Но на моей машине это работает!».

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

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

Раньше, чтобы изолировать приложения друг от друга, использовали виртуальные машины (VM). Виртуальная машина — это как отдельный дом. У нее есть свой фундамент, стены, крыша и полная копия операционной системы. Это надежно, но очень «тяжело» и дорого по ресурсам.

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

!Сравнение архитектуры виртуальных машин и контейнеров Docker

Главный инструмент контейнеризации сегодня — Docker.

Основы Docker: Образы и Контейнеры

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

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

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

Dockerfile: Инструкция по сборке

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

Допустим, у нас есть простой скрипт на Python app.py. Напишем для него Dockerfile:

Основные команды Docker

Теперь, когда у нас есть инструкция, перейдем к практике в терминале.

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

Мы превращаем Dockerfile в готовый образ. Флаг -t задает имя (тег) образа.

Запуск контейнера:

* -d: Detached mode (запуск в фоновом режиме). * -p 5000:5000: Проброс портов. Порт 5000 на вашем компьютере перенаправляется на порт 5000 внутри контейнера.

Просмотр запущенных контейнеров:

Остановка контейнера:

Docker Compose: Управление оркестром из двух инструментов

Реальные приложения редко состоят из одного контейнера. Обычно это веб-сервер, база данных, кэш (Redis) и так далее. Запускать их по одному через docker run долго и неудобно.

Здесь на сцену выходит Docker Compose. Он позволяет описать все сервисы в одном файле docker-compose.yml.

Пример:

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

Kubernetes: Когда контейнеров становится слишком много

Docker отлично справляется с запуском контейнеров на одном сервере. Но что, если у вас Google или Netflix? У вас тысячи серверов и десятки тысяч контейнеров. Как следить за тем, чтобы если один сервер сгорел, контейнеры переехали на другой? Как обновлять приложение без остановки работы?

Для этого нужен оркестратор. Стандарт индустрии — Kubernetes (часто сокращают как K8s).

Kubernetes — это дирижер огромного оркестра. Вы не говорите ему: «Запусти этот контейнер на сервере №5». Вы говорите: «Мне нужно, чтобы всегда работало 3 копии моего приложения», и K8s сам решает, где и как их разместить.

!Упрощенная схема кластера Kubernetes

Основные объекты Kubernetes

В K8s мы оперируем не контейнерами напрямую, а абстракциями более высокого уровня.

Pod (Под): Минимальная единица в K8s. Это «чехол» для одного или нескольких тесно связанных контейнеров. Обычно: 1 Под = 1 Контейнер.

Deployment (Развертывание): Управляет Подами. Именно здесь мы указываем, сколько копий (реплик) приложения нам нужно. Если Под «умрет», Deployment создаст новый.

Service (Сервис): Сетевой интерфейс. Поды приходят и уходят, их IP-адреса меняются. Сервис дает стабильный адрес, по которому можно обращаться к группе Подов.

Математика ресурсов в кластере

При планировании кластера Kubernetes важно понимать, сколько ресурсов потребляют ваши приложения, чтобы не перегрузить узлы (Nodes). Допустим, мы хотим развернуть приложение и зарезервировать ресурсы.

Общее потребление памяти для микросервиса можно рассчитать по формуле:

Где: * — общий объем оперативной памяти, необходимый для всех копий приложения. * — количество реплик (копий) приложения (Replica count). * — запрашиваемая память для одного контейнера (Memory Request). * — накладные расходы системы на обслуживание одного пода (обычно небольшая величина).

Например, если нам нужно 5 реплик (), каждая требует 200 Мб (), а накладные расходы примем за 10 Мб (), то:

Где: * — итоговое потребление памяти в Мб. * — количество реплик. * — память на контейнер. * — накладные расходы.

Это помогает DevOps-инженеру понять, сколько серверов нужно добавить в кластер.

Пример манифеста Kubernetes

Конфигурация в K8s описывается в YAML-файлах (манифестах). Вот пример простого Deployment:

Применив этот файл командой kubectl apply -f deployment.yaml, Kubernetes создаст 3 пода и будет следить за их жизнью.

Заключение

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

В следующей статье мы объединим все знания и построим CI/CD пайплайн — автоматический конвейер, который будет брать ваш код из Git, тестировать его, упаковывать в Docker-образ и отправлять в production.

Построение процессов непрерывной интеграции и доставки (CI/CD)

Мы прошли долгий путь. Мы начали с командной строки Linux, научились писать скрипты на Bash, упаковали наши приложения в Docker-контейнеры и даже узнали, как Kubernetes управляет ими. Но пока что между написанием кода и его запуском на сервере лежит «ручная» пропасть. Вы должны сами собрать образ, сами его протестировать и сами запустить команду обновления в кластере.

В этой статье мы построим мост через эту пропасть. Мы превратим рутину в автоматический конвейер. Добро пожаловать в мир CI/CD.

Что такое CI/CD?

CI/CD — это не просто набор инструментов, это философия разработки. Она расшифровывается как Continuous Integration (Непрерывная Интеграция) и Continuous Delivery/Deployment (Непрерывная Доставка/Развертывание).

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

!Этапы прохождения кода от разработчика до продакшена

CI: Непрерывная Интеграция

Это первая часть конвейера. Ее цель — как можно чаще объединять код всех разработчиков в общую ветку (например, main или master) и проверять, не сломалось ли чего.

Главные правила CI:

Частые коммиты: Разработчики сливают код несколько раз в день.

Автоматическая сборка: При каждом изменении система пытается собрать проект.

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

Если на этапе CI возникает ошибка (тест упал или код не компилируется), конвейер останавливается, и разработчик получает уведомление. Это называется Fail Fast (падай быстро) — лучше найти ошибку сейчас, чем через неделю на сервере клиента.

CD: Непрерывная Доставка и Развертывание

Здесь часто возникает путаница, так как CD может означать две вещи:

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

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

Сердце CI/CD — это пайплайн (трубопровод). Это сценарий, который описывает шаги, которые должен пройти ваш код. Самые популярные инструменты для этого: GitLab CI, Jenkins, GitHub Actions.

Рассмотрим структуру типичного пайплайна на примере GitLab CI (файл .gitlab-ci.yml), так как он очень нагляден.

Пайплайн состоит из Stages (этапов) и Jobs (задач).

Разберем, что здесь происходит:

Test: Мы берем чистый Python-контейнер, ставим зависимости и запускаем тесты. Если они провалятся, следующие шаги не начнутся.

Build: Если тесты прошли, мы используем Docker (внутри Docker!) чтобы собрать образ нашего приложения и отправить его в реестр (Registry).

Deploy: Мы используем утилиту kubectl (которую изучили в прошлой статье), чтобы сообщить кластеру Kubernetes: «Эй, у нас новая версия v1, обновись!».

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

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

Например, если вы компилируете программу на Java или Go на этапе build, то полученный бинарный файл — это артефакт. Его нужно передать на этап deploy. Без явного указания каждый этап запускается в чистом окружении и ничего не знает о файлах предыдущего этапа.

Метрики эффективности CI/CD

Как понять, что ваш DevOps-процесс работает хорошо? Для этого существуют метрики DORA (DevOps Research and Assessment). Одна из ключевых метрик — Lead Time for Changes (Время внесения изменений).

Мы можем выразить это время простой формулой:

Где: * (Lead Time) — время, прошедшее от фиксации кода до его появления в продакшене. * — момент времени (timestamp), когда код был успешно развернут и стал доступен пользователям. * — момент времени, когда разработчик сделал коммит в репозиторий.

Чем меньше значение , тем быстрее ваш бизнес реагирует на рынок. В элитных DevOps-командах это время составляет менее одного часа.

Еще одна важная метрика — Change Failure Rate (Процент неудачных изменений). Она показывает надежность вашего конвейера.

Где: * — процент неудачных развертываний (Change Failure Rate). * — количество развертываний, которые привели к сбою в работе сервиса (требовали отката или хотфикса). * — общее количество развертываний за период.

Если ваш высок, значит, ваши тесты на этапе CI недостаточно хороши.

Практические советы для новичков

Не храните секреты в коде. Никогда не пишите пароли от баз данных или ключи API в файле .gitlab-ci.yml. Используйте переменные окружения (Environment Variables) в настройках вашего CI-инструмента.

Идемпотентность. Ваши скрипты деплоя должны быть идемпотентны. Это значит, что если вы запустите скрипт деплоя 10 раз подряд, результат должен быть таким же, как после первого раза, и ничего не должно сломаться.

GitOps. Это современный подход, когда состояние вашей инфраструктуры полностью отражено в Git-репозитории. Если вы хотите изменить версию приложения в Kubernetes, вы не пишете команду в консоли, а меняете версию в YAML-файле в Git. CI/CD видит изменение и применяет его.

Заключение

Внедрение CI/CD — это поворотный момент. Вы перестаете быть «человеком, который копирует файлы на сервер» и становитесь инженером, который создает системы автоматической доставки ценности.

Теперь у нас есть приложение, которое работает в Linux, упаковано в Docker, управляется Kubernetes и автоматически обновляется через CI/CD. Но где живут эти серверы? Кто их создает? В следующей статье мы перейдем к Инфраструктуре как Код (IaC) и научимся создавать серверы и сети с помощью Terraform и настраивать их через Ansible, не заходя в панель управления облачного провайдера.

Инфраструктура как код (IaC): работа с Terraform и Ansible

Мы прошли большой путь: от ручного ввода команд в терминале Linux до автоматической сборки Docker-контейнеров и их деплоя через CI/CD. Но остался один важный вопрос: куда именно мы деплоим? Где живут наши кластеры Kubernetes и виртуальные машины?

Раньше системные администраторы заходили в панели управления облачных провайдеров (AWS, Google Cloud, Yandex Cloud) и вручную «накликивали» серверы. Это долго, дорого и чревато ошибками. Если администратор уволится, никто не вспомнит, какие галочки он нажимал при настройке сети.

Сегодня мы переходим к парадигме Infrastructure as Code (IaC). Мы будем описывать серверы, сети и диски в виде кода, сохранять их в Git и применять одной командой.

Что такое IaC?

Инфраструктура как код — это подход к управлению инфраструктурой через конфигурационные файлы, а не через ручную настройку.

Представьте, что вы строите дом.

Ручной подход: Вы приходите на стройку и пальцем показываете рабочим: «Здесь стену, здесь окно... ой, нет, окно чуть правее».

IaC: Вы даете прорабу детальный чертеж. Если дом сгорит, вы берете тот же чертеж и строите точную копию в другом месте.

В мире DevOps этот подход делят на два основных направления:

Provisioning (Создание ресурсов): «Дай мне 5 серверов, 1 базу данных и сеть». Лидер здесь — Terraform.

Configuration Management (Управление конфигурацией): «На этих 5 серверах установи Nginx, обнови ядро и создай пользователя». Лидер здесь — Ansible.

!Разделение ответственности между Terraform (создание) и Ansible (настройка).

Terraform: Строитель вашей инфраструктуры

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

Декларативный подход означает, что вы говорите «Я хочу три сервера», а не «Создай первый, потом второй, потом третий». Terraform сам решит, как это сделать.

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

Provider (Провайдер): Плагин, который учит Terraform общаться с конкретным облаком (AWS, Azure, Yandex Cloud, VMware).

Resource (Ресурс): Конкретный объект (виртуальная машина, диск, IP-адрес).

State (Состояние): Файл terraform.tfstate, в котором Terraform запоминает, что он уже создал. Это его «карта местности».

Пример кода

Допустим, мы хотим создать виртуальную машину в Docker (да, Terraform умеет управлять и Docker'ом):

Жизненный цикл Terraform

Работа с Terraform всегда состоит из трех команд:

terraform init — скачивает провайдеры (инициализация).

terraform plan — показывает, что будет сделано (сухой запуск). Он скажет: «Я добавлю 1 ресурс, изменю 0, удалю 0».

terraform apply — применяет изменения в реальности.

Математика масштабирования

При описании инфраструктуры важно понимать стоимость и лимиты ресурсов. Допустим, мы рассчитываем стоимость кластера виртуальных машин. Стоимость можно выразить формулой:

Где: * — итоговая стоимость инфраструктуры за единицу времени (например, час). * — количество серверов (инстансов). * — базовая цена одного сервера (CPU + RAM). * — размер диска в гигабайтах. * — цена за 1 гигабайт хранилища. * — стоимость сетевого трафика (часто плавающая величина).

Terraform позволяет менять переменную в коде, и через команду apply ваш счет за облако изменится согласно этой формуле.

Ansible: Настройка и управление

Terraform создал нам «голые» серверы. Теперь их нужно настроить: установить Docker, скопировать конфиги, запустить сервисы. Здесь вступает Ansible.

В отличие от многих аналогов, Ansible безагентный. Ему не нужно устанавливать специальные программы на целевые серверы. Все, что ему нужно — это доступ по SSH (который мы изучили в первой статье).

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

Inventory (Инвентарь): Текстовый файл, где перечислены IP-адреса ваших серверов.

Playbook (Плейбук): Файл в формате YAML, где описан сценарий действий.

Module (Модуль): Маленькая программа, выполняющая конкретное действие (например, apt для установки пакетов или copy для копирования файлов).

!Ansible подключается к узлам по SSH и выполняет задачи последовательно.

Пример Playbook

Напишем сценарий, который устанавливает веб-сервер Nginx на всех серверах из группы webservers:

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

Главное свойство Ansible (и Terraform) — идемпотентность. Это сложное слово означает простую вещь: повторное выполнение операции не меняет результат, если он уже достигнут.

Если вы запустите bash-скрипт mkdir folder дважды, второй раз он упадет с ошибкой «папка уже существует». Если вы запустите Ansible-задачу по созданию папки 100 раз, он создаст её только в первый раз, а в остальные 99 скажет «OK, уже готово» и ничего не сделает.

Terraform + Ansible: Идеальный дуэт

Часто новички спрашивают: «Что выбрать?». Ответ: используйте оба инструмента, но для разных целей.

| Инструмент | Роль | Аналогия | | :--- | :--- | :--- | | Terraform | Оркестрация ресурсов | Строительство стен, крыши, прокладка труб | | Ansible | Управление конфигурацией | Поклейка обоев, расстановка мебели, подключение техники |

Типичный рабочий процесс (Workflow) выглядит так:

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

Terraform передает список IP-адресов в Ansible.

Ansible заходит на эти IP-адреса, устанавливает Docker, Kubernetes или ваше приложение.

Практические советы

Не храните секреты в коде. Пароли от баз данных и ключи от облака не должны лежать в main.tf или playbook.yml. Используйте переменные окружения или специальные хранилища секретов (например, Ansible Vault).

Берегите state-файл Terraform. Если вы потеряете terraform.tfstate, Terraform «забудет», что он создал серверы, и при следующем запуске может создать их дубликаты или отказаться работать. Храните его в надежном удаленном хранилище (S3, GitLab Terraform State).

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

Заключение

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

Теперь у нас есть автоматизированная инфраструктура и настроенные приложения. Но как узнать, что они работают хорошо? Как увидеть нагрузку на CPU или количество ошибок 500? В следующей статье мы поговорим о Мониторинге и DevSecOps — глазах и ушах инженера.

Обеспечение надежности: мониторинг, логирование и основы DevSecOps

Мы прошли огромный путь. Мы начали с черного экрана терминала Linux, научились упаковывать приложения в контейнеры, построили автоматический конвейер CI/CD и описали всю инфраструктуру как код с помощью Terraform и Ansible. Казалось бы, работа закончена: приложение работает, серверы настроены.

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

В этой финальной статье курса мы добавим нашей системе глаза, уши и броню. Мы поговорим о наблюдаемости (Observability) и безопасности (DevSecOps).

Мониторинг: Пульс вашей системы

Мониторинг — это процесс сбора метрик о работе системы. Метрики — это числа, которые меняются во времени: загрузка процессора, количество свободного места на диске, количество запросов в секунду.

Четыре золотых сигнала

Инженеры Google SRE (Site Reliability Engineering) выделили четыре ключевых сигнала, за которыми нужно следить в первую очередь:

Latency (Задержка): Сколько времени занимает обработка запроса. Если сайт грузится 10 секунд, пользователи уйдут.

Traffic (Трафик): Насколько система нагружена (например, количество запросов в секунду).

Errors (Ошибки): Процент запросов, которые завершились неудачей (коды 500, 404).

Saturation (Насыщение): Насколько полно используются ресурсы (память, процессор). Если насыщение 100%, система скоро встанет.

Инструменты: Prometheus и Grafana

Стандартом индустрии для мониторинга в мире Kubernetes и микросервисов является связка Prometheus и Grafana.

Prometheus — это база данных временных рядов. Он работает по модели Pull*: раз в несколько секунд он «приходит» к вашим сервисам и спрашивает: «Как дела?». Сервисы отдают ему метрики. * Grafana — это инструмент визуализации. Она берет сухие цифры из Prometheus и строит красивые графики и дашборды.

!Архитектура сбора метрик с использованием Prometheus и Grafana

Математика доступности (SLA)

В бизнесе надежность часто измеряют в «девятках». Это называется SLA (Service Level Agreement) — соглашение об уровне обслуживания. Чтобы рассчитать доступность системы, используется формула:

Где: * — доступность (Availability) в процентах. * — время, когда сервис был доступен и работал корректно. * — общее время наблюдения (например, месяц или год).

Давайте посчитаем. Если в году 525 600 минут, и мы обещаем доступность 99.9% («три девятки»), сколько времени мы можем «лежать»?

Где: * — допустимое время простоя в минутах. * — общее количество минут в году. * — целевой процент доступности.

Итого: у нас есть всего 8 часов и 45 минут в год на все аварии и технические работы. Это жесткие рамки, требующие автоматического восстановления системы.

Логирование: История событий

Если мониторинг говорит «Что-то сломалось», то логи говорят «Почему это сломалось».

Лог — это текстовая запись о событии. Раньше мы смотрели логи командой cat /var/log/syslog. Но когда у вас 100 контейнеров, заходить на каждый невозможно. Нужна централизованная система логирования.

Стек ELK / EFK

Классическое решение для сбора логов:

Elasticsearch: База данных для хранения и быстрого поиска по тексту.

Logstash (или Fluentd): Сборщик логов. Он забирает логи из контейнеров, фильтрует их и отправляет в базу.

Kibana: Веб-интерфейс для поиска и просмотра логов.

Структурированные логи

Новички часто пишут логи так: 2023-10-05 Error: User admin failed to login

Это плохой лог. Компьютеру сложно его разобрать. Хороший тон — использовать JSON:

Такой лог позволяет легко отфильтровать все ошибки входа для конкретного пользователя или IP-адреса.

DevSecOps: Безопасность как код

Традиционно безопасность (Security) была «узким горлышком». Разработчики писали код, DevOps деплоили, а потом приходили безопасники, находили уязвимости и заставляли все переделывать. Это долго и дорого.

DevSecOps — это философия, где безопасность встраивается в процесс разработки с самого начала. Это называется принципом Shift Left (сдвиг влево по временной шкале проекта).

!Концепция Shift Left: перенос проверок безопасности на ранние этапы разработки

Основные практики DevSecOps

SAST (Static Application Security Testing): Проверка исходного кода на уязвимости. Например, поиск SQL-инъекций прямо в Git-репозитории.

Сканирование образов: Docker-образы часто содержат уязвимые библиотеки. Инструменты вроде Trivy или Clair проверяют образ на этапе сборки. Если найдена критическая уязвимость, CI/CD пайплайн останавливается.

Управление секретами: Никогда, запомните, никогда не храните пароли, API-ключи и сертификаты в коде. Если вы запушите файл .env с паролем от базы данных в GitHub, считайте, что вас уже взломали.

Для хранения секретов используйте: * Переменные окружения в CI/CD (GitLab CI Variables). * Kubernetes Secrets. * Специализированные хранилища: HashiCorp Vault.

Инцидент-менеджмент: Когда все пошло не так

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

Alerting (Оповещения)

Система мониторинга должна уметь отправлять уведомления (в Telegram, Slack, Email). Но здесь важно соблюдать баланс:

* Плохо: Получать уведомление на каждый чих сервера (CPU > 50%). Вы перестанете на них реагировать. * Хорошо: Получать уведомление, когда проблема влияет на пользователя (Сайт недоступен, Оплата не проходит).

Post-mortem (Разбор полетов)

После устранения аварии команда пишет отчет — Post-mortem. Главное правило: Blameless Culture (Культура без обвинений). Мы не ищем виноватого («Это Петя запушил плохой код!»). Мы ищем системную причину («Почему CI/CD пропустил плохой код?»).

Заключение курса

Поздравляю! Вы прошли путь от основ Linux до построения защищенной, автоматизированной платформы.

Давайте вспомним наш маршрут:

Linux и Bash: Мы научились управлять сервером.

Docker и K8s: Мы упаковали приложения и научились их оркестрировать.

CI/CD: Мы автоматизировали доставку кода.

IaC: Мы превратили инфраструктуру в код.

Monitoring & Security: Мы обеспечили надежность и защиту.

Теперь вы обладаете фундаментом Junior DevOps инженера. Но помните: DevOps — это не только инструменты, это культура постоянного обучения и улучшения. Практикуйтесь, ломайте (на тестовых стендах!), чините и автоматизируйте. Удачи!