Привет, Хабр! в этой статье я попытаюсь я максимально сжатом и доступном формате рассказать про свой небольшой опыт создания 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 и обучаться на нем чему только пожелаешь.
