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 больше по душе.
