doll/README.ru.md

# Чем это должно стать?

Утилитарным сервисом, работающим по принципу puppet-а, в упрощённом виде. Есть сервер, есть клиенты. Каждый клиент может
забрать с сервера только свои конфиги. На сервере описаны конфиги для отдельных хостов, групп серверов и сервисов,
которые находятся, напрмер, под управлением системы контроля версий, типа hg или git.

## А когда уже можно будет это всё заценить?

Сроков нет - проект никем и ничем не спонсируется. В зависимости от того, насколько прорывным будет исследование
возможностей lua и прочих модулей go. Это такой пет-проджект, для интереса. ЕСли от этого будет и польза это будет
потрясающе.

## Краткая история, зачем оно появилось?

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

Старая версия, например 2.7, была ещё относительно простой в обслуживании, но просто ужасной в плане запуска серверной
части. С ростом количества серверов, c-шный руби начинал нещадно тормозить, выжирая процессор. Приходилось брать всякие
извращения типа jruby. Который был конечно быстрее, но поскольку это java то сервер становился более прожорливым к
памяти, да и java-приложения обладают ограниченной портабельностью, особенно теперь, когда версии jvm каждый год теряют
в обратной совместимости, а собирать-портировать новые версии jvm под старые системы - то ещё удовольствие.

Далее, в рубях всё довольно грустно с запуском веб-приложений, несмотря на то, что руби имеет в своём распоряжении
rails. Паппет-сервер написан не как rails-приложение и из этого растут трудности с со сборкой-запуском этого приложения.
Для того, чтобы собрать работающий *правильно* паппет-сервер, надо собирать как руби, так и кучу его модулей и в эту
систему вписывать дистрибутив паппета.

Понятное дело, что с каждой новой версией аппетиты паппета растут как на дрожжах и на текущий момент это довольно жирный
монстр.

Условно говоря, последняя более-менее приемлемо работающая версия была 2.7, с кучей своих багов, однако этой версии уже
больше 10 лет, она была написана ещё для рубей 1.8, кое-как заводилась на 1.9. Да и вцелом у неё были ощутимые проблемы
с производительностью, что не удивительно, ведь это приложение было написано полностью на рубях.

Да и клиент паппета тоже не то чтобы скромный сервис в своих аппетитах по памяти и по процессору.

Какое-то время назад у меня возникла идея "опаппетить" свои домашние сервера, на сей раз в более приятной манере, я
решил присмотреться, что у нас есть на "рынке" систем управления конфигурациями. А там всё те же участники:
puppet, chef, ansible, saltstack, cfengine.

И у всех этих утилит есть или были свои болячки. И одна из самых неприятных - портабельность. То есть даже ansible,
который пытаются продавать как "безагентный" на самом деле вполне себе агентный, просто агент у него эфемерный - это
питон, которому на ввод вдувают довольно портабельный код.

Но тем не менее, одним из самых удачных на мой взгляд является именно паппет, потому что он не только сетапит хосты, но
и поддерживает конфиги в определённом состоянии. То есть агентская часть запускается на регулярной основе и если в
отслеживаемых конфигах обнаруживаются изменения, то они меняются на место, а ответственные сервисы перезапускаются.

И вот, отсюда у меня родилась идея, а почему бы не написать свой инструмент такого же плана, но только более примитивный.
Его задачей будет регулярная проверка отслеживаемых конфигов и восстановление состояния.

По сути, тот же паппет, но на диете.

## Какова механика в общих чертах?

С клиента на сервер поступает запрос, в этом запросе клиент описывает что у него за система, как его
зовут и прочие такие "факты" общего характера. Ему в ответ возвращается огромный json, в котором будет описано, какие
конфиги куда положить, какие сервисы надо рестартануть.

Из нюансов, агент должен уметь показывать diff того, что поменялось.

## Что насчёт dashboard-а?

Я не силён в красивые dashboard-ы. Идея заключается в том, чтобы схитрить и предоставить простенькое http-api для
выяснения состояний управляемых серверов и прочих таких вещей, чтобы можно было взять систему мониторинга и запросто
прикрутить к ней все интересные метрики, составить там свой dashboard, собирать какую-то стату и так далее - всё красиво
и даже есть "стандартная" система оповещений. :)

## Почему взят lua в качестве скриптового языка?

Всё просто - на go существует несколько реализаций этого яп. В том числе github.com/yuin/gopher-lua мне показалась
интересной в плане того, что там есть возможность создавать свои модули для lua на go. Как минимум, можно будет создать
свой клиент для http(s) и json, которые могут понадобится для написания темплейтов. А также можно будет создать свой
модуль, позволяющий подгружать переменные из гошного адресного пространства в lua-шное.

## Ну и как успехи в реализации этого "альтернативного паппета"?

Все успехи в этом репозитории.

Пока что всё сводится к исследованию того, что могут современные библиотеки и обвешивании всего этого костылями для
получения кусков работающего кода, который уже можно использовать как компоненты для целевой системы.

На текущий момент, изучаем возможности интерпретатора lua, что по сути должно стать в итоге тем яп, на котором будет
написана скриптовая часть темплейтов.