Новый девайс!

Я знаю, что обещал сделать это в прошлые выходные. Но тогда меня стопорнуло отсутствие системы хранения — что не позволяло сделать полноценную систему автоматизации. Как работать с данными, если данных практически нет? Бессистемные данные — это все равно что мусор. Информационный шум, не более того.

В прошлые выходные я разработал концепцию хранения данных — и в течение недели реализовал ее в виде файлового хранилища в приватном git-репозитории. Пришло время поработать с этим! Процесс автоматизации объявляю открытым!

Лед тронулся, господа присяжные заседатели #

Я создал репозиторий scripts — и теперь в него будут переезжать все написанные ранее скрипты, постепенно. Все, что касается первичной настройки, развертывания, конфигурации безопасности и прочих рутинных операций.

Архитектура и безопасность #

Я разработал общую архитектуру скриптов — и, пожалуй, самым интересным вопросом оказался не «как написать скрипт», а «как сделать репозиторий публичным и не выстрелить себе в ногу».

Репозиторий скриптов — открытый. Это принципиальная позиция - публичность и опенсорс это наше кредо. А вот данные, с которыми он работает — в приватном хранилище. В скриптах ничего не сказано о хранилище, кроме того, что оно есть. Мы передаём информацию о хранилище через переменную окружения — записывая в нее путь к репозиторию с данными. Также мы поступаем и со всеми остальными секретами — пароли, SSH-ключи, адреса — живут в переменных окружения на Core-ноде.

Теперь скрипты будут получать чувствительные данные через параметры - а значит их можно смело выкладывать в опенсорс! В коде — ни одного захардкоженного значения. Это было одним из главных требований, и старые скрипты, написанные в духе “Давай сделаем это по-быстрому!”, честно говоря, его грубо нарушали.

Второе важное решение — разделение скриптов на два типа. Атомарные скрипты делают ровно одно действие: создать запись, добавить клиента на ноду, зафиксировать изменения. Оркестраторы собирают их в цепочки под конкретный сценарий. Это дает читаемость, переиспользуемость и — что особенно ценно — четкий путь миграции на Python в будущем. Атомарные скрипты станут функциями, оркестраторы — командами CLI. Фундамент уже заложен.

Первый прогон: новые устройства #

И первое, на чем я решил это опробовать — добавление новых клиентских устройств. Долгожданное.

Добавлять руками — это всегда больно: нужно менять данные в нескольких местах, и риск ошибки — одна неверно поставленная запятая или пробел в конфигах — может положить всю цепочку. С этим давно было нужно что-то сделать — и теперь у нас есть все возможности для этого.

Один вызов скрипта:

./devices/add.sh --user 2 --device "ios_3"

Скрипт сам находит пользователя в хранилище, генерирует UUID, определяет, на каких Entry-нодах этот пользователь обслуживается, добавляет клиента на каждую ноду по SSH, перезапускает сервис — и выдает готовую VLESS-ссылку. То, что раньше требовало ручного сбора параметров из пяти разных файлов и аккуратной работы с JSON-конфигами.

Первый же тест на боевой инфраструктуре, конечно, упал. Скрипт бодро отрапортовал «клиент добавлен, Xray active» — а клиент подключиться не смог. Оказалось, что heredoc-скрипты не доходили до удаленной ноды: пароль для sudo и тело скрипта конкурировали за один и тот же stdin. Классика удаленного выполнения через SSH — вроде бы все правильно, а потоки ввода перепутались. Починил, перепроверил — и дальше все пошло как по маслу. Пять устройств добавлены пятью вызовами, пять атомарных коммитов в хранилище — чистая, прозрачная история изменений.

Что дальше #

Мы положили начало системе управления пользовательскими устройствами и заложили фундамент под автоматизацию всех остальных процессов. Дальше — будем надстраивать на нем новые компоненты:

• Удаление и деактивация устройств.
• Синхронизация хранилища между нодами — push по таймеру с разрешением коллизий.
• Подготовка нод — от первоначальной настройки до развертывания сервисов.

И многое другое — планов у меня громадье!