Как практиковаться начинающему DevOps-инженеру: путь от Linux до Kubernetes

Одна из главных сложностей начинающего DevOps-инженера — отсутствие понятного плана практики.

Можно пройти несколько курсов, изучить основы Linux, посмотреть уроки по Docker и Kubernetes, но всё равно не понимать, что именно делать руками и как соединить отдельные технологии в цельный проект.

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

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

Скачать презентацию

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

Во время практики обязательно фиксируйте всё, что делаете. Курс по Obsidian

Записывайте:

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

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

Можно вести заметки в Markdown, Notion, Obsidian или прямо в Git-репозитории проекта.

Полезно также сравнивать похожие инструменты. Например:

• GitLab CI и Jenkins;
• Docker Hub и собственный registry;
• Zabbix и Prometheus;
• ELK и Loki;
• Docker Compose и Kubernetes.

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

1. Создайте виртуальную машину

Первый шаг — подготовить сервер для экспериментов.

Есть несколько вариантов:

• установить VirtualBox, VMware или Hyper-V на своём компьютере;
• использовать старый компьютер или мини-сервер;
• арендовать недорогой VPS у облачного провайдера.

Для начала достаточно одной виртуальной машины.

В качестве операционной системы можно выбрать Ubuntu Server, Debian, AlmaLinux, Rocky Linux или другой распространённый дистрибутив.

Во время установки стоит самостоятельно разобраться:

• как выполняется разметка диска;
• как настраивается сеть;
• как создаётся пользователь;
• какие пакеты устанавливаются по умолчанию;
• как узнать IP-адрес сервера.

Не бойтесь сломать систему. Виртуальную машину можно восстановить из снимка или создать заново. Ошибки в учебной среде — одна из самых полезных частей практики.

2. Настройте SSH

После установки Linux настройте удалённое подключение к серверу.

Сначала можно использовать логин и пароль, но затем обязательно стоит перейти на SSH-ключи.

Практика должна включать:

• создание пары SSH-ключей;
• добавление публичного ключа на сервер;
• подключение без пароля;
• настройку файла SSH-клиента;
• изучение конфигурации SSH-сервера;
• проброс портов через SSH.

Полезно найти файл sshd_config, посмотреть его основные параметры и научиться безопасно перезапускать SSH-сервис после изменения конфигурации.

SSH-туннели также пригодятся в дальнейшем. Например, с их помощью можно получить доступ к сервису, который слушает только локальный интерфейс сервера и не открыт во внешнюю сеть.

3. Изучите базовую настройку Linux

После подключения необходимо привести систему в рабочее состояние.

Обновите пакеты и установите базовые инструменты:

• Git;
• curl;
• wget;
• текстовый редактор;
• сетевые утилиты;
• инструменты просмотра процессов и ресурсов.

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

• конфигурационные файлы;
• системные журналы;
• домашние директории пользователей;
• временные файлы;
• исполняемые файлы;
• данные сервисов.

Создайте отдельного пользователя, настройте ему права и доступ через sudo.

Потренируйтесь работать с:

• chmod;
• chown;
• группами пользователей;
• правами на файлы и директории.

Также стоит освоить базовую диагностику системы:

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

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

4. Выберите простое приложение

Для дальнейшей практики понадобится небольшой проект.

Не нужно сразу создавать сложную микросервисную архитектуру. Подойдёт простое приложение, которое:

• запускается на определённом порту;
• принимает HTTP-запросы;
• возвращает HTML или JSON;
• использует несколько переменных окружения;
• может писать логи.

Приложение может быть написано на Python, Go, Node.js, Java или другом языке. Можно взять готовый проект из открытого репозитория.

Главное, чтобы его можно было:

• запустить вручную;
• оформить как системный сервис;
• собрать в Docker-образ;
• развернуть через CI/CD;
• подключить к мониторингу;
• перенести в Kubernetes.

Это приложение станет основой всего учебного стенда.

5. Запустите проект вручную

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

Скачайте репозиторий и изучите документацию. Определите:

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

Установите зависимости и запустите проект.

После запуска проверьте:

• появился ли процесс;
• слушается ли нужный порт;
• отвечает ли приложение через curl;
• доступно ли оно с другого компьютера.

Если сервис не открывается, попробуйте определить причину:

• приложение не запущено;
• указан неправильный адрес прослушивания;
• порт закрыт firewall;
• соединение блокирует облачный провайдер;
• приложение завершилось с ошибкой.

Именно на этом этапе формируется навык диагностики, который особенно важен для DevOps-инженера.

6. Оформите приложение как systemd-сервис

Когда ручной запуск стабильно работает, создайте сервис systemd.

В unit-файле нужно указать:

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

После этого научитесь:

• запускать и останавливать сервис;
• включать автозапуск;
• проверять статус;
• перезапускать приложение;
• смотреть журналы через journalctl.

Полезно специально допустить ошибку в unit-файле и посмотреть, как systemd сообщает о проблеме.

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

7. Автоматизируйте сборку и развёртывание

Следующий этап — создание простого CI/CD-процесса.

Разместите проект в Git-репозитории и выберите инструмент автоматизации:

• GitLab CI;
• GitHub Actions;
• Jenkins;
• другой доступный CI/CD-сервис.

Для первого pipeline достаточно нескольких этапов:

1. получение исходного кода;
2. проверка или тестирование;
3. сборка;
4. развёртывание на сервере;
5. перезапуск приложения.

При использовании GitLab CI стоит разобраться, что такое GitLab Runner, где он выполняет задания и как получает доступ к серверу.

Главная задача — понять общий принцип: после изменения кода система автоматически выполняет заранее описанную последовательность действий.

На первом этапе pipeline не должен быть сложным. Важнее добиться его стабильной и понятной работы.

8. Контейнеризируйте приложение

После этого можно переходить к Docker.

Сначала разберитесь с базовыми понятиями:

• контейнер;
• образ;
• слой образа;
• Dockerfile;
• registry;
• volume;
• проброс портов.

Напишите Dockerfile для приложения:

• выберите базовый образ;
• скопируйте файлы проекта;
• установите зависимости;
• укажите рабочую директорию;
• добавьте команду запуска.

Соберите образ и запустите контейнер.

Проверьте:

• доступно ли приложение;
• правильно ли проброшен порт;
• передаются ли переменные окружения;
• отображаются ли логи;
• сохраняются ли необходимые данные;
• корректно ли контейнер перезапускается.

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

9. Настройте хранение Docker-образов

Готовый образ необходимо хранить в registry.

Для начала можно использовать Docker Hub или встроенный registry GitLab.

Практика может выглядеть так:

1. собрать образ;
2. добавить тег;
3. отправить образ в registry;
4. удалить локальную копию;
5. скачать образ заново;
6. запустить контейнер из загруженного образа.

После этого можно поднять собственный Docker Registry.

Для более продвинутого стенда подойдёт Nexus Repository или аналогичное решение.

Важно понять полный путь артефакта: CI/CD-система собирает образ, отправляет его в registry, а целевой сервер скачивает нужную версию и запускает её.

10. Освойте Docker Compose

Если приложение использует несколько компонентов, опишите их в Docker Compose.

Например, стенд может включать:

• основное приложение;
• базу данных;
• nginx;
• систему мониторинга;
• сервис сбора логов.

В compose-файле можно описать:

• контейнеры;
• сети;
• volumes;
• переменные окружения;
• зависимости;
• пробрасываемые порты.

После этого всё окружение должно запускаться одной командой.

Попробуйте полностью остановить проект, удалить контейнеры и восстановить его только на основе compose-файла и документации.

Docker Compose особенно удобен для локальной разработки, тестовых стендов и небольших проектов.

11. Добавьте nginx и HTTPS

Следующий шаг — приблизить стенд к реальной инфраструктуре.

Установите nginx и настройте его как reverse proxy.

Пользователь будет отправлять запрос на nginx, а nginx — передавать его приложению, которое работает на внутреннем порту.

Разберитесь:

• как устроена конфигурация nginx;
• как проверить её перед перезапуском;
• где находятся access- и error-логи;
• как настроить несколько виртуальных хостов;
• как передавать заголовки приложению.

При наличии домена можно направить его на сервер и подключить SSL-сертификат.

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

12. Подключите мониторинг

Недостаточно просто запустить сервис. Необходимо понимать, что с ним происходит.

Для практики можно выбрать:

• Zabbix;
• Prometheus;
• Grafana;
• Node Exporter;
• другой инструмент мониторинга.

Начните с базовых метрик:

• загрузка процессора;
• использование оперативной памяти;
• свободное место на диске;
• сетевой трафик;
• доступность сервера;
• состояние приложения.

После этого настройте оповещение.

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

Полезно специально остановить сервис и проверить, действительно ли мониторинг заметит проблему.

13. Организуйте централизованное логирование

Для сбора и анализа логов можно использовать ELK, Loki или другое решение.

Настройте передачу журналов:

• приложения;
• nginx;
• контейнеров;
• системных сервисов.

После этого попробуйте:

• найти все ошибки;
• отфильтровать записи по времени;
• выполнить поиск по адресу запроса;
• найти события конкретного сервиса;
• проследить последовательность действий пользователя.

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

14. Напишите документацию

Документация — обязательная часть учебного проекта.

Опишите:

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

Документация должна быть понятна человеку, который раньше не видел ваш проект.

Хороший критерий: сможете ли вы сами через несколько месяцев развернуть стенд только по собственному README?

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

15. Перенесите приложение в Kubernetes

Когда вы разобрались с Linux, systemd, Docker и CI/CD, можно переходить к Kubernetes.

Для первого знакомства подойдут:

• Minikube;
• K3s;
• Kind;
• другой локальный или облегчённый кластер.

Изучите основные объекты:

• Pod;
• Deployment;
• Service;
• Namespace;
• ConfigMap;
• Secret;
• Ingress.

Разверните в Kubernetes то же приложение, которое до этого запускалось вручную, через systemd и Docker Compose.

Создайте Deployment, откройте доступ через Service, а затем настройте Ingress.

После этого можно подключить мониторинг и посмотреть логи контейнеров.

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

Итоговый маршрут практики

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

1. создать виртуальный сервер;
2. настроить Linux и SSH;
3. запустить приложение вручную;
4. оформить его как systemd-сервис;
5. автоматизировать сборку и развёртывание;
6. собрать Docker-образ;
7. отправить образ в registry;
8. описать окружение через Docker Compose;
9. настроить nginx и HTTPS;
10. подключить мониторинг;
11. организовать сбор логов;
12. написать документацию;
13. развернуть приложение в Kubernetes.

Необязательно использовать именно перечисленные инструменты. GitLab можно заменить GitHub Actions или Jenkins, Zabbix — Prometheus, а ELK — Loki.

Главное — пройти весь путь самостоятельно и понимать назначение каждого компонента.

Важно не просто скопировать готовые конфигурации, а уметь объяснить:

• как они работают;
• как проверить их состояние;
• где искать логи;
• что делать при сбое;
• как восстановить сервис.

Именно такая практика превращает отдельные знания о Linux, Docker и Kubernetes в реальный навык DevOps-инженера.