Привет, Хабр! в этой статье я попытаюсь я максимально сжатом и доступном формате рассказать про свой небольшой опыт создания homelab.
Важное замечание: на момент написания статьи все виртуальные машины и сервисы были развернуты, a скриншоты я делал уже с боевого сервера, так что не удивляйтесь, если я буду писать о том, что развернул 2 виртуалки, а на скриншоте их будет больше десяти.
Какой опыт я имел на тот момент:
Арендовал кучу VPS для хостинга всего, до чего доходили руки.
Ковырял Raspberry и Arduino.
Настраивал простейшие сети в ВУЗе, в конечном итоге имел почти полный доступ к всей внутренней сети и мог делать что угодно. Здесь нужно отдельное пояснение. Хоть руки и чесались сделать конфетку из старой сети и доступ у меня ко всему был, в итоге я остановился на администрировании отдельного кабинета, так как мне было банально страшно что-то сломать. Возможно, это и была первая причина сборки домашней лабы.
Состав homelab
Первоначально необходимо понять, для чего нам нужна лаба. От этого будем отталкиваться. У меня были 2 основные задачи:
Попробовать те новые продукты, с которыми я не работал
Собрать систему, которая будет информировать о плачевном состоянии этих самых продуктов.
Изначально я прошелся по авито в поисках 1u серверов. Денег мне особо тратить не хотелось (а кому хочется?) да и опыта в таких покупках у меня тоже не было. Выяснилось, что большинство таких железок продается без жестких дисков / ssd и оперативной памяти. Докупать не хотелось, лень и перспектива головной боли при поисках комплектующих для Б/Ушного сервера меня не впечатлила. Кроме того, его где-то надо было хранить, а расположение одноюнитого сервера на шкафу или тумбе как будто бы не особо хорошая идея.
Второй прогон по Авито натолкнул меня на версии домашнего сервера в форм факторе обычного ПК. Из плюсов: его можно было поставить рядом с рабочим компьютером и подключить к монитору. В какой-то момент я уже готов был собирать в таком виде, но столкнулся с тем, что потенциальный сервер будет шуметь, а работать он должен 24/7. Мне было как раз все равно, а вот жена не оценила бы. По этой же причине отвалился и вариант из первого поиска.
Выигрышный вариант
В очередной беседе с коллегами услышал о мини-ПК и предположил, что его покупка решит все мои проблемы, а именно:
Не сильно отразится на цифрах в квитанции за электроэнергию.
Не будет шуметь.
Расположить его можно куда угодно, хоть рядом с роутером повесить.
Из недорогих вариантов можно было найти вот такой аппарат:
На момент покупки стоимость варьировалась в диапазоне от 20 до 30 тыс. рублей. Докупив самую дешевую плашку оперативки на 16 Гб и самый дешевый SSD на 500 Гб, я запустил его.
Начало работы с homelab
Запустить это конечно хорошо, но как...
Передо мной возник вопрос о выборе инструментов с которыми я планирую работать. В качестве гипервизора я выбрал Proxmox 7.4. На тот момент уже вышла 8 версия, но ее я не скачивал из-за предубеждения о том, что последняя версия скорее всего еще сырая. Как оказалось не зря, но об этом дальше. Выбор пал именно на Proxmox по двум причинам. Во-первых, это тот же самый линукс, во-вторых, с ESXi я уже встречался и возвращаться к нему было как-то неинтересно что ли. В итоге скачал образ, подключил монитор, клавиатуру и витую пару через всю квартиру к неттопу. После нехитрых операций гипервизор работал, проверку закончил на пинге восьмерок (8.8.8.8).
После успешной установки я столкнулся с первой проблемой. Во время установки сервера на свое почетное место на шкафу в дальнем углу рядом с роутером я подключил его по витой паре к своему соседу. Сел за компьютер и попытался открыть веб интерфейс проксмокса, он, в свою очередь, старательно сопротивлялся. Выглядело все так, как будто сервер не подключен к сети. Эта ситуация ввела меня в ступор, так как на тот момент локалка у меня была плоская и никаких запрещающих правил на роутере не было. Начал искать проблему на роутере.
Во вкладке с DHCP я обнаружил информацию о присвоении адреса для моей коробочки и начал размышлять уже о том, насколько правильно у меня прошла первоначальная настройка гипервизора, ведь во время установки сервер был точно так же подключен по витой паре и имел доступ в интернет, а значит и в локальной сети он точно присутствует.
Тщательные поиски решения меня привели на один белорусский форум, на котором я узнал, что доступ между узлами, подключенными напрямую к портам роутера провайдера по меди и устройствами в беспроводной сети разграничен. Для того, чтобы настроить обратное мне нужно войти в режим "Суперадмина". Логин и пароль я нашел на том же самом форуме... Сделал настройки и успешно сменил пароли.
На данном этапе мы пришли к некоторому промежуточному результату. Сервер работает, виртуализация доступна, доступ в интернет есть.
Ин��раструктура
Помимо купленного сервера у меня уже были 2 арендованные VPS. На одной из них у меня был развернут сервер X-ray по статье, которая уже недоступна на хабре по некоторым законодательным причинам. Другая находилась в России и использовалась уже как OpenVPN сервер для связи с домашним компьютером при необходимости. Друг с другом они у меня никак не связаны, и если с ними что-то произойдет, то я узнаю либо от появившейся ошибки в подключении либо от самого хостинга.
Поразмыслив об этом и о перспективах развития своего сервера я принял следующий план работ:
Развернуть систему мониторинга состояния для своих VPS;
Развернуть пару витруальных рабочих столов (Windows 10 / Ubuntu);
Сделать хоть какое нибудь разграничение доступа;
Развернуть несколько контейнеров под личные задачи.
Плановое размещение виртуалок/контейнеров
Решил начать с мониторинга. Очевидным решением сразу показался Zabbix, он простой и интуитивно понятный, вполне подойдет для простых задач.
Руководствуясь своей безупречной интуицией, я создал виртуальную машину вручную и выделил ей следующие ресурсы:
что привело к следующим результатам:
В свою защиту хочу сказать, что мне это абсолютно никак не мешало, и это была первая виртуалка на сервере. Временное решение оно на то и временное, его потом заменят.
Сервер заббикса был установлен и настроен, такая же ситуация нарисовалась и с агентом забикса на X-Ray сервере.
Кроме того, я сделал минимальные оповещения в телеграмм при проблемах с пингами до VPS с Xray-cервером.
Рядом разметились виртуалки в Win10 и Ubuntu
Эти две машины объединяет подключение к одному и тому же мной созданному интерфейсу с названием"vmbr104". Тут мы плавно подошли к Pfsense. Изначально я планировал спрятать контейнеры и виртуальные машины за ним и при необходимости разрешить необходимый доступ от своего ноутбука / компьютера.
на этом моменте имеем:
2 виртуальные машины которые спрятаны за Pfsense (На самом деле на скриншотах с описанием Win10/ubuntu машин только ubuntu спрятана, я забыл отключить интерфейс который связывает Win10 с внешней локальной сетью);
админка pfsense доступена только из внутренней сети за самим pfsense;
машины доступны с моего компьютера и ноутбука только из моей домашней сети через Port Forwarding;
Замечание
Будьте осторожны с настройками интерфейсов для виртуальной машины вашего Pfsense - есть риск потерять доступ к веб интерфейсу Proxmox. В интернете есть огромное количество гайдов по настройке, например это.
Кроме того при установке Pfsense у меня пропал адрес гипервизора из DHCP роутера, но это все лирика.
Мониторинг работы Xray-прокси
Конкретно этот кейс я постараюсь расписать подробнее, потому что я пока не находил статей с похожим случаем.
Вариант не является идеальным в исполнении, но у него есть одно неоспоримое преимущество - он работает.
Дано:
Наша VPS c установленным 3X-UI по недостурной на хабре статье, но доступной в README файле в репозитории проекта;
Мощности нашего гипервизора.
Задача:
При отсутствии доступа до ресурсов, которые нам обеспечивает наш прокси, получать об этом уведомление в телеграм или хотя бы видеть это на каком-нибудь дашбордике.
Создаем LXC контейнер с Ubuntu, выделяем минимальное количество ресурсов
Устанавливаем Xray-core (репозиторий). Авторы предлагают нам элементарную установку в 1 строку
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
Далее нам необходимо описать свое подключение в json'e. Путь до файла конфига отобразится в конце установки
Так как я использую Vless + Reality, то я иду снова в репозиторий ядра Xray и ищу минимальный пример конфига для этой версии клиента. Вот здесь можно найти все возможные примеры конфигураций.
{ "log": { "loglevel": "debug" }, "inbounds": [ { "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "udp": true }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls", "quic" ], "routeOnly": true } } ], "outbounds": [ { "protocol": "vless", "settings": { "vnext": [ { "address": "123.456.789.0",//Сюда вписываем ip сервера "port": 443, // Порт, параметр из ключа клиента "users": [ { "id": " ", //Должен совпадвть с id на сервере, параметр из ключа клиента "encryption": "none", "flow": "xtls-rprx-vision" } ] } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "fingerprint": "chrome", "serverName": "microsoft.com", //из ключа клиента "publicKey": "", //из ключа клиента "spiderX": "/", // из ключа клиента "shortId": "" // из ключа клиента } }, "tag": "proxy" } ] }
Перезагружаем службу и проверяем что конфиг файл импортировался без ошибок
Служба работает, устанавливаем proxychans4 и редактируем конфиг файл уже для него
apt install proxychains4 nano /etc/proxychains4.conf
В конце файла добавляем локалхост с портом, который указан в inbounds::port в описании конфига Xray и ставим в начале SOCKS5. Главное чтобы новая строчка стояла выше остальных. Так как остальные строчки мне вообще не были нужны, я их удалил. Получилось следующим образом:
Осталость только по Api какого нибудь сайта проверить свой адрес через проксичейнс
proxychains4 curl 'https://api.ipify.org?format=json'
В качестве результата выполнения команды нам должен вывалиться адрес нашего прокси-сервера. У меня так и произошло.
На этом моменте мы вспоминаем как много ресурсов тратит наш заббикс на простые пинги и решаем устранить проблему. Переходим на Prometheus в связке с Grafana.
Отличную статью по этому инструменту можно найти вот здесь. Дл�� отслеживания метрик доступности недоступных ресурсов из дома через наш прокси мы используем blackbox exporter, который можно запустить через proxychains.
Далее на скриншоте я совместил некоторые панели. Показатели потребления русурсов Прометеусом и Графаной. Также на изображении показатели некоторых метрик в Графане, которые я пронумеровал для удобства.
Пронумерованные метрики:
доступность некоторого недоступного из РФ ресурса от VPS за рубежом, на котором поднят X-ray сервер;
доступность некоторого недоступного из РФ ресурса из дома через наш ранее поднятый контейнер x-ray клиента;
доступность контейнера с пустым Nginx web-сервером для линых нужд от VPS за рубежом, на котором поднят X-ray сервер;
доступность контейнера с пустым Nginx web-сервером через наш ранее поднятый контейнер x-ray клиента (т.е. один контейнер проверяет соседний из другой страны).
Сразу можно заметить, что 2 контейнера графаны и прометеуса портебляют меньше, чем ВМ с заббиксом, тут кроется наша микропобеда.
Кусочек DevOps
Все мы сталкивались с мыслью, что иногда проще все разрушить и постоить заново. Потратив значительный промежуток времени разворачивая и уничтожая виртуальные машины и контейнеры, я начал приходить к мысли, что вручную повторять один и тот же процесс разворачивания одинаковых виртуалок ни к чему хорошему не приведет. Под огромным психологическим давлением и парой банок темного нефильтрованного пришлось описать новые раворачиваемы инстансы в Terraform.
В начале статьи я упоминал, что не зря поставил версию 7.4 гипервизора. Дело в том, что на момент установки Proxmox была проблема в его работоспособности версии 8 и доступного провайдера Terraform. Проблема была одна и очень серьезная - провайдер не работал. Используя интернет и очередную статью (Terraform для LXC и ВМ), я описал структуру для быстрого старта новой ВМ или контейнера.
terraform { required_providers { proxmox = { source = "Telmate/proxmox" version = "2.9.14" } } } provider "proxmox" { pm_api_url = "https://Адрес_проксмокса:8006/api2/json" pm_api_token_id = "terraform@pam!terraform" pm_api_token_secret = "Сгенерированный_в_проксмоксе_ключ" pm_otp = "" } resource "proxmox_lxc" "lxc-test" { features { nesting = true } hostname = "Ваш_очередной_контейнер" network { name = "eth0" bridge = "vmbr0" ip = "адрес_с_маской" gw = "шлюз" } rootfs { storage = "local-lvm" size = "размер_диска" } ostemplate = "ваш_образ_контейнера" password = "пароль_для_рута" target_node = "pve" vmid = ид_контейнера start = "true" unprivileged = true ostype = "ubuntu" ssh_public_keys = <<ваш_паблик_кей connection { type = "ssh" host = "адрес" user = "root" private_key = file("~/.ssh/id_rsa") timeout = "50s" }
Всю секретную информацию можно было спрятать в отдельных файлах и переменных окружения, но для удобста публикации я собрал все в один.
Заключение
По итогам эксплуатации минисфорум отключался ровно 1 раз. Причиной являлось отключение электричества. Аптайм на момент написания статьи - 115 дней. На момент предыдущего отключения - 57 дней. В качестве проверки на стресс я запускал все установленные ВМ и контейнеры и забивал все ресурсы. В таком режиме малыш простоял неделю и не имел никаких огорчающих последствий. При грамотном распределении ресурсов имеем тихое и скромное по электропитанию устройство, которое можно держать включенным 24/7 и обучаться на нем чему только пожелаешь.
