puppet — типичный overkill. Возможно, кто-то таки потратил время и нервы на его изучение и остался им доволен… И, на секундочку, — все «блекджеки и шлюхи» puppet-а — именно в мощи мета-языка, которым описываются конфиги, GUI там постольку поскольку…
Будет ли свой мета-язык, сравнимый по мощи с puppet-овским у данного сервиса? Тогда с него и надо было начинать. Пока что подход, выбранный авторами, — дать визуальную картинку на первый план и комментарии типа «Можно использовать свои сервера, а можно разворачивать на наших. Второй вариант предпочтительнее, снимает кучу головняка.» — отпугнет большинство админов и билд-инженеров.
Ну поймите же, что деплоймент проектов средней сложности сопоставим по сложности с написанием кода приложений (по сути им и является). До сих пор все попытки визуализировать создание кода с помощью визуальных представлений с треском проваливались. В фильмах конечно все красиво, но на то они и фильмы, что в реальности код пишут руками, а админят из ком. строки. Вашу идею можно сравнить с 3д-файл менеджерами — все баловались, да красиво, да как в фильме, но нафиг никому не нужно. Нарисовать связи можно и в Open Visio каком-нибудь, не ради же красивой картинки вы задумали весь проект?
Рассмотрим пример.
Для инициализации своих серверов я использую иерархию скриптов. Общие скрпиты, которые необходимо выполнять на всех нодах (это всякие мелочи и ньюансы типа вида командной строки, установка пакетов вроде htop, screens, zabbix-agent и т.п., тюнинг параметров ОС) и узко-специальные, для каждой конкретной ноды.
Оставим в стороне скрипт общего назначения (только он один тянет где-то на 200 строк), перейдем к узко-специальному.
Узел с реляционной БД. Скрипт инициализации занимает ~120 строк.
— Установка сервера БД (postgres) из репозитория
— Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
— Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
— Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
— Развертывание самой БД из SQL скриптов (3 разные схемы)
— Набивка базы данными из дампов
— Создание директорий, установка прав
— Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
— Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач
Ах да, все это я хочу чтобы стояло на ZFS с соотв. тюнингом под БД моего размера, при этом ОС я тоже хочу выбрать себе сам.
В каком месте ваше решение призвано упростить жизнь? Конечно, можно оставить лазейку для «выполнить кастомный скрипт какой угодно сложности», но это уже надувательство, друпальщина…
Кто вообще конечный пользователь вашего продукта? Админ\билд-инженер? Забудьте, вы никогда не перетащите эту категорию из командной строки в гуйню. Неопытный начинающий пользователь? Тоже не выстрелит — неопытный начинающий пользователь споткнется сразу после кружочка WAN и nginx (см. вашу первую картинку).
Перечитал два раза и так и не понял что же вы предлагаете (посему все что дальше — возможно следствие неправильно истолкованной идеи, но уж извините, как написали так и понял). Комментарии поразили еще больше — такое чувство что это не хабр, а новостное агенство средней степени желтизны.
Если вы реально сталкивались с граблями при построении систем малой и средней степени сложности — как пришли к идее универсализации? В реальных, даже самых простых проектах деплой любого из серверов — это кастомный скрипт немалого размера…
Да, можно и нужно автоматизировать развертывание своей системы (есть даже должность такая — билд-инженер), но это не поддается шаблонизации, по определению! Сколько систем — столько и разных манипуляций с настройками, архитектур и стеков.
Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.
Давайте уж графический построитель любого приложения — натянул на экран модуль обработки входящих соединений, 10 обработчиков на все случаи жизни, модуль логгирования (соединяем палочкой с сервером логов) — чего уж там… фейсбук-киллер готов!
P.S. Если вы предлагаете хостинг, настройку и сопровождение — так и пишите, зачем все это заворачивать в Visio-like картинку с клеточками? Совершенно непонятно…
Как раз вчера, загрузив Minion Rush подумалось о «психологии скорости взаимодействия». С аппстора грузиться основной модуль — 30 мб. Затем, сразу после запуска, еще столько же. И потом после заставки еще «чуть чуть»… При этом загрузка сопровождается шуточными комментами типа «ой, вот тут еще немного кода осталось подгрузить», «ржем над фотками на вашем устройстве… т.е. загружаем доп. ресурсы» и т.п.
После фразы «предстоящее событие нельзя рассматривать как Каспаров vs deep blue. У первого были хоть какие-то шансы» ожидал что шансов нет у человека, а статья говорит об обратном.
Столько же, но при этом он будет действительно кроссплатформенным (с автоматическим выбором лучшего асинхронного механизма для данной платформы, коих побольше, чем просто «линукс» и «виндоус»).
В статье, со словами «кроссплатформенный» и «неблокирующие сокеты» в заголовке, должно быть как минимум упоминание о libev/libevent, а вообще странно что вы их не захотели использовать в реализации.
Скажу так — это была не единственная причина (гораздо более важными являлись размеры сообщества, кол-во портов, поддерживаемое оборудование и т.п.). Более того, случилось это в 2010 (тогда закладки в столь широко используемом ПО были в новинку) и что вдвойне обидно — случилось это с «самой защищенной из всех ОС» — именно «защищенность» была отличительной особенностью OpenBSD, можно даже сказать — ее единственной изюминкой (Only two remote holes in the default install, in a heck of a long time! — до сих пор заявлено на главной странице проекта), и при этом специально встроенная закладка, причем не в сторонней либе, а именно в спец. фреймворке используемом исключительно в данной ОС.
До сих пор мне не известны другие подобные вопиющие случаи, дело тут не в кошечках вовсе.
И сразу вопрос — как ее все-таки убрать? Вы писали, что «Через функцию удаления, доступную в самом CyberSafe.», но я не вижу такой опции, подскажите. UPD. Уже нашел, забавный способ.
Будет ли свой мета-язык, сравнимый по мощи с puppet-овским у данного сервиса? Тогда с него и надо было начинать. Пока что подход, выбранный авторами, — дать визуальную картинку на первый план и комментарии типа «Можно использовать свои сервера, а можно разворачивать на наших. Второй вариант предпочтительнее, снимает кучу головняка.» — отпугнет большинство админов и билд-инженеров.
Для инициализации своих серверов я использую иерархию скриптов. Общие скрпиты, которые необходимо выполнять на всех нодах (это всякие мелочи и ньюансы типа вида командной строки, установка пакетов вроде htop, screens, zabbix-agent и т.п., тюнинг параметров ОС) и узко-специальные, для каждой конкретной ноды.
Оставим в стороне скрипт общего назначения (только он один тянет где-то на 200 строк), перейдем к узко-специальному.
Узел с реляционной БД. Скрипт инициализации занимает ~120 строк.
— Установка сервера БД (postgres) из репозитория
— Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
— Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
— Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
— Развертывание самой БД из SQL скриптов (3 разные схемы)
— Набивка базы данными из дампов
— Создание директорий, установка прав
— Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
— Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач
Ах да, все это я хочу чтобы стояло на ZFS с соотв. тюнингом под БД моего размера, при этом ОС я тоже хочу выбрать себе сам.
В каком месте ваше решение призвано упростить жизнь? Конечно, можно оставить лазейку для «выполнить кастомный скрипт какой угодно сложности», но это уже надувательство, друпальщина…
Кто вообще конечный пользователь вашего продукта? Админ\билд-инженер? Забудьте, вы никогда не перетащите эту категорию из командной строки в гуйню. Неопытный начинающий пользователь? Тоже не выстрелит — неопытный начинающий пользователь споткнется сразу после кружочка WAN и nginx (см. вашу первую картинку).
Если вы реально сталкивались с граблями при построении систем малой и средней степени сложности — как пришли к идее универсализации? В реальных, даже самых простых проектах деплой любого из серверов — это кастомный скрипт немалого размера…
Да, можно и нужно автоматизировать развертывание своей системы (есть даже должность такая — билд-инженер), но это не поддается шаблонизации, по определению! Сколько систем — столько и разных манипуляций с настройками, архитектур и стеков.
Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.
Давайте уж графический построитель любого приложения — натянул на экран модуль обработки входящих соединений, 10 обработчиков на все случаи жизни, модуль логгирования (соединяем палочкой с сервером логов) — чего уж там… фейсбук-киллер готов!
P.S. Если вы предлагаете хостинг, настройку и сопровождение — так и пишите, зачем все это заворачивать в Visio-like картинку с клеточками? Совершенно непонятно…
До сих пор мне не известны другие подобные вопиющие случаи, дело тут не в кошечках вовсе.