🛠 Микроинфраструктура
Один из сайд-эффектов профдеформации, который я на себе наблюдаю, — это желание сделать инфраструктуру личных проектов похожей на реальное продакшн-окружение, зачастую срисованное с текущего места работы. Есть, правда, одно серьёзное различие: у меня нет денег, чтобы содержать 10-20 серверов(инстансов, whatever) только лишь для поддержки порядка в трёх-четырёх персональных проектах, поэтому сходство если и есть, то внешнее и абсолютно номинальное.
В целом же я следую сейчас довольно краткому набору правил: "писать как можно меньше кода" и "использовать по возможности стандартные средства, доступные в текущем окружении". До перезапуска блога я занимался в основном тем, что допиливал различные компоненты системы не только до состояния "можно пользоваться", но и "сражает наповал все мои воображаемые ветряные мельницы". Проекты никуда не двигались(они и сейчас не особо-то и двигаются), а заниматься техническим онанизмом я через какое-то время устал. Это вовсе не означало, что мне хотелось бросить все проекты в том состоянии, в котором они были. Это означало, что пришло время выкинуть старую инфраструктуру и переписать всё так, чтобы оно удовлетворяло текущим потребностям и не было дорогим(в данном случае важны и время, и бюджет) в эксплуатации. Звучит знакомо, не так ли? Это и есть эволюция.
Пройдусь, пожалуй, по списку:
Конфигурация
Было: ничего из готовых решений не устраивало; хотелось, чтобы утилита конфигурации являла собой либо один бинарник, либо один скрипт, который запускается на целевой машине и делает заебись. Написал свою утилиту на Go, положил куда-то в общий доступ, сделал CNAME и делал как нынче модно curl | sh. Какое-то время это работало и даже нравилось, но потом моя "инфраструктура как код" превратилась в страшную лапшу из одного JSON-файла и множества списков и объектов в нём, а на сам проект я и вовсе забил большой болт.
Стало: не будет сюрпризом сказать, что я выбрал Ansible. Из поддерживаемых "живых" проектов вряд ли найдётся что-то более подходящее для конфигурации "один хилый VPS". Множество доступных модулей, готовое пространство решений, НЕ клиент-серверная модель, совершенно уродский и мозговыворачивательный синтаксис темплейтов, часто ломается совместимость при апгрейде версии, но жить при этом можно вполне комфортно.
Результат: для внесения изменений в конфигурацию теперь требуется не так много телодвижений, а при грамотном построении дерева проекта это делается теперь ещё и быстро. Всяко лучше, чем застрять головой в луже собственных недоделок.
Деплой
Было: когда воплощался проект старой инфраструктуры, мне хотелось сделать её очень завершённой и натуральной, что в переводе на простой язык означало "способ установки софта в систему не должен отличаться от такового в целевой операционной системе". То есть любая моя отрыжка должна была упаковываться в .deb и при этом соблюдать все правила и гайдлайны. Возбуждённый наличием начальных знаний о сборке пакетов и зависимостей для Debian, я стал заворачивать в пакеты буквально всё, даже сраные конфиги, даже если это был всего лишь один json-файл. То, что сейчас выглядит как килограммы окаменевшей перлятины, актуальное состояние которой волнует только "UNIX-ветеранов", тогда казалось верхом изящности и лаконичности. Технический онанизм в чистом виде, но на этом я не остановился. Мне посчастливилось узнать, что существует Travis CI и что он может собирать пакеты за меня. Ура, автоматизация! Снова бесчисленные дни и ночи были проведены за написанием никому не нужных скриптов, которые в конце концов я и выбросил. Ну хоть CI научился конфигурировать, и то неплохо.
Стало: post-receive хук в Git на целевой системе, который делает git pull && ./build.sh в целевой директории и ни капли более. По возможности никаких перезапусков сервисов и хаков в /etc/sudoers.d. Если сервис всё-таки нужен, то пишется Dockerfile, который собирается и запускается в Swarm там же. При желании выхлоп процесса сборки можно перенаправить в html-файл и выплюнуть ссылку на него в логе Git. Удобно, почти как тревис, только настраивать ничего не надо.
Результат: "Скорость охуевающая" © Лесь Подервянский. Для запуска проекта (сайт, блог, сервис) требуется от силы пять минут. TO DO: сделать шаблон post-receive для всех проектов и засунуть его в Ansible.
Сервисы
Было: здесь та же логика: раз всё есть пакет, значит всё должно быть и сервисом! Статический блог из десятка markdown-файлов? Сервис! Прокси для всяких API с тремя с половиной эндпоинтами? Сервис! HTTP-интерфейс для базы данных? Сервис! Репозиторий пакетов для Debian? Сервис! Бот для Telegram? И снова сервис! И да, всё это писалось, настраивалось, поддерживалось(какое-то время) и переписывалось вместо того, чтобы заниматься собственно ведением блога и всем остальным, ради чего это всё делалось. До сих пор удивляюсь, каким образом мне удалось избежать принудительного курса лечения галоперидолом при всём вышеописанном.
Стало: Остался только прокси для API, да и тот всего с одним эндпоинтом. Выглядит как inetd родом из 2019 года; позволяет запускать bash-скрипты через интернет, а большего мне и не надо.
Результат: Меньше головной боли о том, что может свалиться с undefined is not an object, крепче сон, шелковистее волосы. Если что-то можно не делать сервисом, то лучше так и поступить. Ещё лучше — задавать себе почаще вопрос "а надо ли оно мне вообще?"
Мониторинг
Было: какая-то дикая мультикомпонентная поебень под названием Sensu. Гарантировала совместимость с Nagios, что означало скрипты! Огромная гора совместимых скриптов, которые можно было взять и установить! На деле же я писал их все самостоятельно, а ещё и поддерживал до кучи CRUD, который требовал Redis, API, агент, веб-интерфейс и всю эту прочую энтерпрайзную срань. И всё это ради мониторинга статического блога и его сателлитов.
Не, конечно сам по себе Sensu может быть и удобен, и приятен, но совсем не на таких масштабах.
Стало: сначала хотел вообще написать пачку кронов и забыть о них, но потом понял, что желательно бы ещё алерты, статусы, вот это всё. Взял monit. Вроде работает. Наделал темплейтов, засунул в Ansible, задеплоил. Пока нравится.
Результат: работаю над тем, чтобы оповещения не были нужны вовсе. На таких масштабах как персональная VPS отвлекаться на мелочи вроде обновления сертификатов или ядра ОС — преступная расточительность.
Сторейдж
Было: как и полагается всякому задроту, у меня есть свой домашний сервер. Место на диске стоит дорого у облачных провайдеров, поэтому я решил расширить его за счёт NFS-шары, подключенной через mesh-vpn. Складывалось ощущение, что трафик идёт из Амстердама не в Берлин, а куда-то в Танзанию, то есть пользоваться как сторейджем этим было невозможно, но я упорно превозмогал. А через месяц пришёл счёт за электричество и глаза мои от этого стали чуть более квадратные.
Стало: не стал жадничать и заказал Hetzner Storage Box на два терабайта.
Результат: скорость тоже так себе, но хотя бы работает стабильнее и голову парить бэкапами дисков не надо.
В заключение хочу сказать, что хоть я и трачу на поддержку персональной инфраструктуры гораздо меньше времени, чем это было раньше, возиться с ней изредка всё же бывает приятно. Хотя бы чтобы убедиться, что она таки работает и приносит ощутимую пользу.
Sat, 16 Nov 2019 17:52:23 +0100
RSS // Telegram // Статистика