Изучать DevOps только по документации сложно. Можно разобраться в Kubernetes, Ansible и CI/CD на уровне терминов и команд, но настоящее понимание обычно появляется тогда, когда система начинает вести себя не так, как ожидалось: сервис не отвечает, DNS не работает, виртуальная машина пересоздаётся с ошибкой, а сборка зависит от недоступного внешнего ресурса.
О том, как превратить теоретические знания в практический инженерный опыт с помощью собственной лаборатории, рассказывает Юрий Анфиногенов — автор курсов на Stepik и специалист с многолетним опытом настройки и поддержки серверов, автоматизации процессов и решения технических проблем.
Для DevOps-инженера лаборатория — не игрушка и не способ красиво разложить оборудование на полке. Это безопасная среда, где можно собирать, ломать, диагностировать, восстанавливать и повторять. Именно через такие циклы чтение документации постепенно превращается в инженерный опыт.
Я пришёл к этой мысли не сразу. Можно читать статьи и проходить курсы, но без собственной среды знания долго остаются теоретическими. Лаборатория помогает перейти от «я читал об этом» к «я уже сталкивался с похожей проблемой и понимаю, где искать причину».
Я пришёл к этой мысли не сразу. Можно читать статьи и проходить курсы, но без собственной среды знания долго остаются теоретическими. Лаборатория помогает перейти от «я читал об этом» к «я уже сталкивался с похожей проблемой и понимаю, где искать причину».
Документация нужна, но она не заменяет среду
Документация объясняет, как инструмент должен работать. Лаборатория показывает, как он работает в конкретной системе: с вашей ОС, вашей сетью, вашими дисками, ограничениями по памяти, вашим DNS и вашими ошибками конфигурации.
Например, можно прочитать, что Kubernetes Service выбирает pod по labels и selector. Но настоящее понимание приходит тогда, когда Service не отправляет трафик, вы открываете kubectl get endpoints, видите пустой список и находите несовпадение между label у pod и selector у Service. После такой ситуации Kubernetes перестает быть набором абстрактных YAML-файлов и становится системой с понятными и наблюдаемыми состояниями.
То же самое и с Linux. Можно знать, что df показывает занятое место в файловой системе, а du считает размер файлов в директориях. Но если вы однажды столкнулись с ситуацией, когда df показывает 100%, du не находит большой файл, а затем через lsof обнаруживается удаленный лог, который всё ещё удерживается процессом, то тема открытых файловых дескрипторов запоминается надолго.
Именно на таких связках: симптом → проверка → причина → исправление → вывод — и строится DevOps-навык.
Например, можно прочитать, что Kubernetes Service выбирает pod по labels и selector. Но настоящее понимание приходит тогда, когда Service не отправляет трафик, вы открываете kubectl get endpoints, видите пустой список и находите несовпадение между label у pod и selector у Service. После такой ситуации Kubernetes перестает быть набором абстрактных YAML-файлов и становится системой с понятными и наблюдаемыми состояниями.
То же самое и с Linux. Можно знать, что df показывает занятое место в файловой системе, а du считает размер файлов в директориях. Но если вы однажды столкнулись с ситуацией, когда df показывает 100%, du не находит большой файл, а затем через lsof обнаруживается удаленный лог, который всё ещё удерживается процессом, то тема открытых файловых дескрипторов запоминается надолго.
Именно на таких связках: симптом → проверка → причина → исправление → вывод — и строится DevOps-навык.
Почему локальность стала важной частью обучения
Для специалистов из России и других стран СНГ есть ещё один важный контекст. На внешние сервисы не всегда можно рассчитывать как на гарантированно доступные. Это касается container registry, пакетных репозиториев, SaaS GitLab/GitHub, облачных платформ, CDN, Helm Repository, Terraform/OpenTofu providers и других источников зависимостей.
Не стоит превращать это в политический разговор. Для инженера это прежде всего вопрос надежности и контроля. Если учебный стенд при каждой установке скачивает половину интернета, значит, вы не полностью контролируете свою инфраструктуру. Сегодня образ скачался, завтра registry недоступен, послезавтра изменилась версия, а через месяц лабораторную работу уже невозможно воспроизвести.
Поэтому полезно с самого начала привыкать к production-подходу: код хранится в Git, container images — в понятном registry, пакеты и зависимости кэшируются, версии фиксируются, а инфраструктура описана кодом, а не существует только в памяти инженера.
Не стоит превращать это в политический разговор. Для инженера это прежде всего вопрос надежности и контроля. Если учебный стенд при каждой установке скачивает половину интернета, значит, вы не полностью контролируете свою инфраструктуру. Сегодня образ скачался, завтра registry недоступен, послезавтра изменилась версия, а через месяц лабораторную работу уже невозможно воспроизвести.
Поэтому полезно с самого начала привыкать к production-подходу: код хранится в Git, container images — в понятном registry, пакеты и зависимости кэшируются, версии фиксируются, а инфраструктура описана кодом, а не существует только в памяти инженера.
Первый уровень: гипервизор на своем ПК
Начать можно без отдельного сервера. Для первых лабораторных работ достаточно гипервизора на рабочем ПК или ноутбуке.
Для старта подойдет любой доступный настольный гипервизор: VirtualBox или Hyper-V на Windows, VMware Fusion или UTM на macOS. Выбор конкретного продукта здесь не принципиален. Важно, чтобы вы могли создать Linux-машину, настроить сеть и при необходимости быстро вернуть её в исходное состояние.
Даже одной виртуальной машины достаточно, чтобы отработать базовые навыки администрирования Linux: работу с пользователями, службами, дисками, сетью, журналами и диагностикой процессов.
Для старта подойдет любой доступный настольный гипервизор: VirtualBox или Hyper-V на Windows, VMware Fusion или UTM на macOS. Выбор конкретного продукта здесь не принципиален. Важно, чтобы вы могли создать Linux-машину, настроить сеть и при необходимости быстро вернуть её в исходное состояние.
Даже одной виртуальной машины достаточно, чтобы отработать базовые навыки администрирования Linux: работу с пользователями, службами, дисками, сетью, журналами и диагностикой процессов.
Например, хорошая первая лабораторная может быть совсем простой: поднять Linux VM, установить nginx, проверить его через curl, посмотреть, какой порт он слушает через ss -lntp, найти unit с помощью systemctl status, затем сломать конфигурацию, посмотреть ошибку через journalctl и восстановить работу сервиса.
На бумаге это выглядит слишком просто. Но именно такие упражнения учат не бояться системы, понимать её состояние и искать причины проблем, а не просто выполнять команды по инструкции.
Одной виртуальной машины быстро становится мало
Одна VM отлично подходит для знакомства с Linux, но почти не учит сетевому взаимодействию. А DevOps-инженер почти никогда не работает с одной машиной — обычно это несколько узлов, сервисов и зависимостей.
Чтобы изучать сетевое взаимодействие, Ansible, Kubernetes и CI/CD, лучше иметь хотя бы две-три виртуальные машины. Именно тогда появляются реальные сценарии: закрытый порт, ошибка DNS, неправильный маршрут или сервис, доступный только через 127.0.0.1.
Чтобы изучать сетевое взаимодействие, Ansible, Kubernetes и CI/CD, лучше иметь хотя бы две-три виртуальные машины. Именно тогда появляются реальные сценарии: закрытый порт, ошибка DNS, неправильный маршрут или сервис, доступный только через 127.0.0.1.
Простой учебный стенд может выглядеть так:
- devops-control — Ansible, kubectl, OpenTofu;
- devops-node-01 — приложение или учебный сервис;
- devops-node-02 — второй узел для сетевых экспериментов.
Позже к ним можно добавить хранилище артефактов, мониторинг и Kubernetes.
Даже если начать только с двух VM, уже можно отработать важные сценарии: SSH-доступ, Ansible inventory, проверку TCP-портов, firewall, DNS, reverse proxy, доступ к registry, сбор метрик с нескольких узлов.
Даже если начать только с двух VM, уже можно отработать важные сценарии: SSH-доступ, Ansible inventory, проверку TCP-портов, firewall, DNS, reverse proxy, доступ к registry, сбор метрик с нескольких узлов.
Например, хорошая первая лабораторная может быть совсем простой: поднять Linux VM, установить nginx, проверить его через curl, посмотреть, какой порт он слушает через ss -lntp, найти unit с помощью systemctl status, затем сломать конфигурацию, посмотреть ошибку через journalctl и восстановить работу сервиса.
ss -lntp
ip addr
ip route
curl -v http://<server-ip>:80
sudo tcpdump -i <interface> port 80На бумаге это выглядит слишком просто. Но именно такие упражнения учат не бояться системы, понимать её состояние и искать причины проблем, а не просто выполнять команды по инструкции.
Ручное создание VM убивает мотивацию
На первых шагах нормально создавать виртуальные машины вручную. Это даже полезно: вы понимаете, из чего состоит VM, где настраиваются диск, сеть, ISO-образ, пользователь, SSH и hostname.
Но если каждый эксперимент начинается с ручной установки ОС, настройки пользователя, SSH-ключей, сети и пакетов, мотивация быстро падает. Уже через несколько повторений не хочется ломать стенд — появляется желание оставить его «как есть», потому что восстановление занимает слишком много времени.
Для учебной среды это плохой признак. Лаборатория должна быть воспроизводимой: её можно сломать, удалить и заново развернуть за несколько минут. Если стенд становится жалко трогать, он постепенно превращается не в учебную площадку, а в хрупкую рабочую систему, в которой страшно что-либо менять.
Отсюда простой инженерный вывод: чем быстрее восстанавливается стенд, тем смелее вы экспериментируете и тем быстрее набираетесь опыта.
Но если каждый эксперимент начинается с ручной установки ОС, настройки пользователя, SSH-ключей, сети и пакетов, мотивация быстро падает. Уже через несколько повторений не хочется ломать стенд — появляется желание оставить его «как есть», потому что восстановление занимает слишком много времени.
Для учебной среды это плохой признак. Лаборатория должна быть воспроизводимой: её можно сломать, удалить и заново развернуть за несколько минут. Если стенд становится жалко трогать, он постепенно превращается не в учебную площадку, а в хрупкую рабочую систему, в которой страшно что-либо менять.
Отсюда простой инженерный вывод: чем быстрее восстанавливается стенд, тем смелее вы экспериментируете и тем быстрее набираетесь опыта.
Vagrant: быстрые локальные VM без ручной рутины
Vagrant позволяет описать несколько локальных виртуальных машин в одном файле и поднимать одинаковый стенд без повторной установки ОС. Это удобный шаг от ручной виртуализации к инфраструктуре, описанной кодом.
Vagrant входит в экосистему HashiCorp, поэтому заранее проверьте доступность программы и готовых образов из вашей сети. Если с этим возникают сложности, можно использовать Multipass, шаблоны cloud-init в Proxmox или сразу перейти к OpenTofu.
Vagrant хорошо подходит для первых DevOps-лабораторий. На таком стенде удобно изучать Ansible, сетевое взаимодействие, настройку сервисов и работу нескольких узлов между собой.
Главная ценность Vagrant не столько в самом инструменте, сколько в привычке описывать инфраструктуру кодом. Если одинаковые машины приходится создавать снова и снова, лучше один раз зафиксировать их конфигурацию, чем каждый раз повторять одни и те же ручные действия.
Vagrant входит в экосистему HashiCorp, поэтому заранее проверьте доступность программы и готовых образов из вашей сети. Если с этим возникают сложности, можно использовать Multipass, шаблоны cloud-init в Proxmox или сразу перейти к OpenTofu.
Vagrant хорошо подходит для первых DevOps-лабораторий. На таком стенде удобно изучать Ansible, сетевое взаимодействие, настройку сервисов и работу нескольких узлов между собой.
Главная ценность Vagrant не столько в самом инструменте, сколько в привычке описывать инфраструктуру кодом. Если одинаковые машины приходится создавать снова и снова, лучше один раз зафиксировать их конфигурацию, чем каждый раз повторять одни и те же ручные действия.
OpenTofu/Terraform и Ansible: лаборатория как код
При переходе к Proxmox или облачной инфраструктуре виртуальные машины удобнее создавать с помощью OpenTofu или Terraform, а настройку операционной системы выполнять через Ansible.
Упрощенно роли можно разделить так:
OpenTofu/Terraform - создает виртуальные машины, диски и сети
Ansible - настраивает ОС, пакеты и службы
Git - хранит код, историю изменений и документацию
Такое разделение важно. OpenTofu/Terraform не должен превращаться в универсальный bash-скрипт для настройки всего внутри операционной системы. Его зона ответственности — инфраструктурные ресурсы. Ansible, наоборот, лучше использовать для настройки системы после создания виртуальных машин.
В учебной лаборатории такой подход даёт несколько преимуществ:
Конечно, три виртуальные машины можно создать и вручную. Но если пересоздавать их приходится регулярно, лучше один раз потратить время на освоение OpenTofu/Terraform и Ansible. Эти вложения окупятся уже после нескольких экспериментов.
В учебной лаборатории такой подход даёт несколько преимуществ:
- стенд можно быстро пересоздать;
- все изменения фиксируются в Git;
- эксперимент легко повторить даже спустя месяц.
Конечно, три виртуальные машины можно создать и вручную. Но если пересоздавать их приходится регулярно, лучше один раз потратить время на освоение OpenTofu/Terraform и Ansible. Эти вложения окупятся уже после нескольких экспериментов.
Локальные репозитории и хранилища артефактов
В лаборатории полезно проследить полный путь артефакта: от исходного кода и сборки до хранения, развертывания и отката.
В простом учебном сценарии всё часто выглядит так:
docker build → docker push → kubectl apply
Но в реальной инфраструктуре цепочка намного длиннее:
изменение кода -> сборка -> артефакт -> хранилище -> развертывание -> откат
Если вы хотите приблизить лабораторию к реальной эксплуатации, полезно развернуть локально хотя бы часть этой цепочки.
Для этого можно использовать:
В простом учебном сценарии всё часто выглядит так:
docker build → docker push → kubectl apply
Но в реальной инфраструктуре цепочка намного длиннее:
изменение кода -> сборка -> артефакт -> хранилище -> развертывание -> откат
Если вы хотите приблизить лабораторию к реальной эксплуатации, полезно развернуть локально хотя бы часть этой цепочки.
Для этого можно использовать:
- Gitea или GitLab — для хранения кода;
- GitLab Runner — для CI;
- Nexus Repository — для proxy, cache и hosted repositories;
- Docker/OCI Registry — для хранения container images;
- Harbor — если хочется глубже разобраться с container registry;
- MinIO — для сценариев с S3-совместимым хранилищем;
- локальный mirror или cache — для часто используемых зависимостей.
Nexus особенно полезен для понимания того, как устроено хранение артефактов. Через него можно изучить hosted, proxy и group repositories, кэширование зависимостей, хранение пакетов и работу инфраструктуры в ситуации, когда внешний источник становится недоступен.
Даже в домашней лаборатории стоит понимать, где хранится собранный образ, как он версионируется и как попадает в окружение. В рабочей инфраструктуре стенд нередко не имеет прямого доступа к внешним репозиториям, поэтому локальное хранение артефактов лучше изучить заранее.
Облако тоже полезно, но его лучше использовать дисциплинированно
Не у всех есть возможность держать домашний сервер. В этом случае хорошей альтернативой может стать облачный проект: несколько виртуальных машин, управляемый Kubernetes, объектное хранилище, управление доступом и сетевые правила.
Такой опыт полезен сам по себе, ведь именно в облаках сегодня работает значительная часть production-систем. Но важно не превращать облако в «песочницу», где всё настраивается вручную. Лучше сразу выстраивать работу так, чтобы инфраструктуру можно было легко воспроизвести.
Практический подход:
Иначе очень быстро возникает знакомая многим ситуация: ресурсы забыли выключить, счёт вырос, а через неделю уже невозможно вспомнить, что было создано вручную, а что — с помощью кода.
Такой опыт полезен сам по себе, ведь именно в облаках сегодня работает значительная часть production-систем. Но важно не превращать облако в «песочницу», где всё настраивается вручную. Лучше сразу выстраивать работу так, чтобы инфраструктуру можно было легко воспроизвести.
Практический подход:
- создать отдельный учебный проект;
- настроить бюджетные лимиты;
- описывать ресурсы через OpenTofu/Terraform;
- хранить код в Git;
- поднимать ресурсы только на время эксперимента;
- удалять их после завершения;
- фиксировать версии образов, providers и зависимостей.
Иначе очень быстро возникает знакомая многим ситуация: ресурсы забыли выключить, счёт вырос, а через неделю уже невозможно вспомнить, что было создано вручную, а что — с помощью кода.
Мой путь: почему я пришел к Proxmox
Рано или поздно виртуальные машины начинают мешать основной работе на ноутбуке, а лабораторию хочется держать постоянно доступной. В этот момент имеет смысл перенести её на отдельный сервер.
Для такой задачи хорошо подходит Proxmox. Он предоставляет удобный веб-интерфейс, поддерживает шаблоны, снимки виртуальных машин, виртуальные сети и программный интерфейс для автоматизации.
Для такой задачи хорошо подходит Proxmox. Он предоставляет удобный веб-интерфейс, поддерживает шаблоны, снимки виртуальных машин, виртуальные сети и программный интерфейс для автоматизации.
Когда виртуальные машины начинают мешать работе на ноутбуке, а лабораторию хочется держать доступной постоянно, имеет смысл перенести её на отдельный сервер. Для этого хорошо подходит Proxmox.
Для DevOps-лаборатории Proxmox даёт несколько важных возможностей:
Но начинать именно с Proxmox необязательно. Отдельный сервер требует дополнительных затрат, времени и базового понимания сетей, хранения данных и виртуализации. Если перейти к нему слишком рано, легко увлечься выбором железа, дисков, сетевых карт и схем хранения вместо того, чтобы получать практический опыт в DevOps.
Поэтому Proxmox лучше рассматривать как следующий этап развития лаборатории — когда возможностей двух-трёх локальных виртуальных машин уже начинает не хватать.
Для DevOps-лаборатории Proxmox даёт несколько важных возможностей:
- постоянные виртуальные машины, которые не зависят от рабочего ноутбука;
- шаблоны Linux VM;
- снапшоты;
- bridge-сети;
- управление виртуальными машинами через OpenTofu/Terraform.
Но начинать именно с Proxmox необязательно. Отдельный сервер требует дополнительных затрат, времени и базового понимания сетей, хранения данных и виртуализации. Если перейти к нему слишком рано, легко увлечься выбором железа, дисков, сетевых карт и схем хранения вместо того, чтобы получать практический опыт в DevOps.
Поэтому Proxmox лучше рассматривать как следующий этап развития лаборатории — когда возможностей двух-трёх локальных виртуальных машин уже начинает не хватать.
Как выглядит более зрелая учебная лаборатория
Зрелая лаборатория — это не обязательно дорогой сервер или сложная инфраструктура. Гораздо важнее, чтобы её можно было легко понять, воспроизвести и при необходимости полностью пересоздать.
Смысл не в том, чтобы сразу построить все блоки. Смысл в направлении развития: от ручных действий к описанной инфраструктуре, от случайных файлов к Git, от внешних зависимостей к контролируемым артефактам, от одноразовой установки к воспроизводимой среде.
Типичные ошибки
- Слишком сложный старт. Не пытайтесь сразу развернуть Kubernetes, GitLab, Nexus, мониторинг и GitOps.
- Ручное создание машин. После первых экспериментов переносите повторяемые действия в код.
- Отсутствие Git. Конфигурация, существующая только в истории команд, быстро теряется.
- Неконтролируемые зависимости. Фиксируйте версии и понимайте, откуда загружаются пакеты и образы.
- Страх сломать стенд. Лаборатория должна восстанавливаться быстрее, чем возникает желание оставить ее нетронутой.
Дорожная карта развития лаборатории
С чего начать практически
Начните с одной Linux-машины: настройте SSH, установите веб-сервер, проверьте открытый порт и журналы службы. Затем добавьте вторую машину и разберите сетевое взаимодействие между узлами.
Когда ручное создание стенда начнет повторяться, перенесите настройку в Ansible, а создание виртуальных машин - в Vagrant, OpenTofu или Terraform.
Proxmox, локальный репозиторий артефактов и Kubernetes стоит добавлять позже, когда для них появится конкретная учебная задача.
Главное - не ждать идеального стенда. Хорошая лаборатория начинается не с дорогого железа, а с повторяемого упражнения.
Когда ручное создание стенда начнет повторяться, перенесите настройку в Ansible, а создание виртуальных машин - в Vagrant, OpenTofu или Terraform.
Proxmox, локальный репозиторий артефактов и Kubernetes стоит добавлять позже, когда для них появится конкретная учебная задача.
Главное - не ждать идеального стенда. Хорошая лаборатория начинается не с дорогого железа, а с повторяемого упражнения.
Заключение
DevOps-лаборатория нужна не для красивой схемы и не для того, чтобы один раз поставить модный стек. Она нужна, чтобы регулярно получать инженерный опыт: создавать среду, проверять гипотезу, сталкиваться с ошибками, диагностировать, восстанавливать и автоматизировать.
Для инженеров из РФ и СНГ особенно важно контролировать внешние зависимости: понимать, откуда загружаются пакеты и образы, фиксировать версии и хранить критичные артефакты в доступном репозитории.
Главный критерий хорошей лаборатории прост: ее не страшно сломать, потому что вы понимаете, как ее восстановить.
Главный признак хорошей лаборатории прост: её не страшно сломать, потому что вы знаете, как быстро восстановить. Именно в такой среде появляются настоящие инженерные навыки.
Это первая статья из серии о создании собственной DevOps-лаборатории. В следующих материалах мы шаг за шагом разберём, как собрать учебный стенд: от локальных виртуальных машин и Vagrant до Proxmox, OpenTofu/Terraform, Ansible и локальной инфраструктуры для работы с Git, CI/CD и хранилищами артефактов.
Если хотите перейти к практике уже сейчас, обратите внимание на курсы автора на Stepik:
Для инженеров из РФ и СНГ особенно важно контролировать внешние зависимости: понимать, откуда загружаются пакеты и образы, фиксировать версии и хранить критичные артефакты в доступном репозитории.
Главный критерий хорошей лаборатории прост: ее не страшно сломать, потому что вы понимаете, как ее восстановить.
Главный признак хорошей лаборатории прост: её не страшно сломать, потому что вы знаете, как быстро восстановить. Именно в такой среде появляются настоящие инженерные навыки.
Это первая статья из серии о создании собственной DevOps-лаборатории. В следующих материалах мы шаг за шагом разберём, как собрать учебный стенд: от локальных виртуальных машин и Vagrant до Proxmox, OpenTofu/Terraform, Ansible и локальной инфраструктуры для работы с Git, CI/CD и хранилищами артефактов.
Если хотите перейти к практике уже сейчас, обратите внимание на курсы автора на Stepik:
- Terraform + Proxmox: практический курс — о создании и управлении виртуальными машинами и инфраструктурой как кодом на базе Proxmox.
- Ansible Mastery: Лаборатория автоматизации — об автоматизации настройки серверов, работе с inventory, playbook и создании воспроизводимых лабораторных стендов.
