Как я создавал homelab для учебы на DevOps-инженера

В феврале 2022-го стало ясно, что надо приобретать профессию, востребованную за пределами России. На тот момент я жил в Москве и успешно практиковал как юрист. За плечами у меня была работа в крупнейшей юридической фирме и годы преподавания в университете. Но еще до того, до поступления на юрфак, большую часть своего времени я посвящал компьютерам. Я буквально фанател от всего, что с ними связано. По книгам изучал Basic и Pascal, занимался дизассемблированием программ и знакомился с Linux. И даже после того, как судьба привела меня в юриспруденцию, я не оставил этой своей страсти. Так что сфера, в которую я хотел уйти, была понятна – оставалось только выбрать специальность.

Потратив несколько дней на изучение вариантов, я решил пойти в DevOps-инженеры. Хотя за несколько лет до этого я прошел на Stepik несколько курсов по Python, системное администрирование привлекало меня больше разработки, а DevOps-практики казались чем-то вроде переднего края администрирования.

Начал я с того, что выбрал один большой курс по DevOps и несколько хороших курсов по отдельным технологиям (Gitlab CI/CD, Ansible, Kubernetes). Я понимал, как важно выбрать хорошего учителя. В каком-то смысле это даже важнее выбора предмета. Мне очень понравилось, как излагает материал Nana Janashia. Плюсом стало то, что она преподает на английском, так что на язык сразу ложится вся нужная терминология. Я потом из любопытства просмотрел учебные материалы по DevOps с некоторых российских платформ, и был поражен тем, как много там воды и как мало структуры. В общем, Nana – one love, рекомендую.

DevOps-практики, как известно, требуют освоения длинного ряда инструментов, и если с каким-нибудь git можно экспериментировать практически на любой машине, то Nexus или Jenkins надо ставить на сервер. Они требовательны к ресурсам, и бесплатным t2.micro на AWS не обойтись. Конечно, можно получить 3 month trial от Google Cloud, но он потребуется позже для игр с managed Kubernetes. Так что я решил сделать из своего десктопа homelab. Дальше о том, что я сделал, с какими проблемами столкнулся и как их решил.

Аппаратная часть

Сам я работал почти только на iMac, а PC был у меня на подхвате. Я собрал PC больше от того, что заскучал по временам, когда посвящал сборке и настройке железа дни напролет, чем потому что он мне был действительно нужен. Тем не менее, мощная получилась машина: на AMD 5950X с Nvidia RTX 3080. Изначально памяти поставил только 16gb. Для сервера с несколькими виртуалками этого маловато, поэтому первым делом я добавил еще столько же. А надо было ставить все 64. Другим небольшим усовершенствованием стала установка HDMI dummy plug, которая заставляет систему думать, что к видеокарте подключен монитор. Это важно для подключения к удаленному рабочему столу.

По железу это все, больше никаких нововведений я не производил. В тот момент я уже планировал отъезд из России, так что десктоп был перевезен к знакомым, подключен и оставлен на неотапливаемом балконе. Я нашел несколько постов о том, что ничего плохого с ним произойти не должно, однако с наступлением зимы задумываюсь о том, как удаленно отключить вентиляторы в корпусе. Не так это просто, потому что в качестве базы я поставил ESXi 7.0.

Гипервизор

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

Сначала выяснилось, что ESXi не имеет драйверов для моей сетевой карты. Это логично, ведь enterprise-class гипервизор совершенно не предназначен для того, чтобы ставить его на десктоп с геймерской материнкой. Счастье, что одни умельцы написали для Intel I225-V драйвер, а другие инструкцию о том, как патчить дистрибутив ESXi.

Дальше пришлось разобраться с тем, как обеспечить прямой доступ виртуалки к жесткому диску. Для этого надо зайти на ESXi по SSH (Host – Actions – Services – Enable SSH) и посмотреть название нужного диска в /vmfs/devices/disks/. Затем запустить с соответствующими параметрами следующую команду: vmkfstools -z /vmfs/devices/disks/t10.ATA_____Hitachi_HDT725025VLA380_______________________VFL104R6CNYSZW Hitashi250.vmdk. Дальше можно монтировать получившийся файл как диск для виртуальной машины.

Сетевые взаимодействия

Мой первоначальный план был прост – арендовать статичный IP-адрес и пользоваться функцией port forwarding для распределения трафика между виртуалками. Практически сразу стало ясно, что домашний роутер (даже перепрошитый на openWRT) дает очень скромные возможности. К тому же меня волновала безопасность. Не помешал бы хороший файерволл и Intrusion Detection System (IDS). Все, о чем я мог мечтать, я нашел в виде pfSense, а затем OPNsense.

Я использовал pfSense несколько месяцев, и единственное, что меня удручало в нем – сильно устаревший и не очень продуманный интерфейс. Простые действия требовали слишком много кликов. В какой-то момент я решил попробовать OPNsense, и остался уже совершенно доволен. Тем более по нему есть отличная книга от человека, который постоянно использует этот фаерволл в проде.

Так что вслед за первоначальным планом возник следующий: трафик приходит на домашний роутер и перенаправляется на OPNsense (DMZ). Там он проходит через файерволл, IDS и дальше поступает на reverse-proxy (HAproxy можно установить как плагин для OPNsense). Reverse-proxy в зависимость от прописанных правил, как правило основываясь на доменном имени, направляет трафик на ту или другую виртуальную машину.

Виртуальные машины

Раньше у меня в основном были сервера на Debian. Теперь мне показалось хорошей идеей получить опыт с Enterprise Linux. К счастью, у Red Hat есть Developer program, позволяющая бесплатно использовать RHEL со всеми наворотами. Единственная проблема с RHEL возникла, когда они ушли из России и видимо запретили обновления с российских айпишников. Проблема решилась поднятием tinyproxy на зарубежном сервере и прописыванием его в конфигах yum/dnf.

Именно на RHEL было решено поставить все DevOps-инструменты. Сначала я еще развлекался тем, что разворачивал приложения прямо на ОС, но довольно быстро понял, что контейнеры все-таки удобнее. В результате сейчас Jenkins, Grafana, Nexus и Gitlab крутятся в докере. Вместе они потребляют около 10gb RAM. В целом для этой виртуалки я выделил 14gb памяти и 6 ядер процессора. Наиболее прожорлив Gitlab, и именно его в принципе было ставить необязательно. Пользоваться вполне можно gitlab.com, поставив к себе на сервер только gitlab-runner. Но поскольку во многих компаниях gitlab хостится на своих серверах, мне хотелось попробовать поработать именно в self-hosted конфигурации.

Преимущества

Хорошие курсы по DevOps дают множество упражнений, но часто они будто существуют в вакууме: вот тебе простое приложение, сделай из него docker image, загрузи в репозиторий и задеплой. Я решил попробовать что-то более реальное. На моем Debian-сервере хостились сайты с LAMP-стэком. Я решил, что отличной идеей будет перенести их в docker и развернуть в Kubernetes. Homelab открывает бесконечное пространство для бесплатных экспериментов.

Учиться когда у тебя под рукой есть собственный сервер очень удобно. Понятно, что всегда можно арендовать все необходимое в облаке. Однако облачный провайдер принимает множество забот на себя, и для тебя они остаются за кадром. Кроме того, ты всегда должен будешь помнить о том, какие ресурсы используешь и сколько за них платишь. В результате проще после выполнения упражнения уничтожать все с чем работал. Может в этом и есть свои плюсы – это стимулирует освоение Terraform и Ansible – но мне homelab больше по душе.

Статья получилась несколько сумбурной, но если кого-то из junior’ов вроде меня она вдохновит на создание своей домашней лаборатории, я буду считать свою задачу выполненной. Более опытным инженерам буду благодарен за советы и указания на ошибки.