Востребованность open-source панели управления хостингом

Question

[Антон Пискунов]

В общем так исторически сложилось что я потрогал разные веб-интерфейсы для управления хостингом за те ~6 лет которые занимаюсь веб-разработкой.

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

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

Поверьте — это реально наболевшее после всех этих систем :)

Целевая аудитория: представителем которой являюсь я сам: фрилансеры, малые группы и веб-студии. То бишь никаких громоздких неработающих систем кластерности и прочих упоротых идей, все предельно просто, четко и функционально.

Юзкейс: рабочая машина с линухой для фрилансеров и программистов групп, боевые сервера (vps, vds, cloud — не требующие контроля железа) обслуживающие до 50-70 сайтов каждый.

Ориентированность функциональности на возможности и технологии: python, ruby, php, node, nginx, mongo, redis, percona, mariadb, mysql, exim, dovecot, proftpd, memcache и прочее ПО которое может потребоваться разработчику в наше время. Странно, но с этим ПО у нынешних систем управления хостингом большие беды. Могу ошибаться — поправьте пруфлинком.

Системы: debian-based т.к. это самая широкая группа внутри целевой аудитории. Ubuntu на рабочей машине, Debian на сервере — часто встречающаяся ситуация. Ну, а если проект будет кому-либо интересен, то люди пулл-реквестами добьют и остальные системы.

Внимание вопрос: имеет смысл заниматься этим?

Comments

[Антон Пискунов]

Со всеми которые можно найти у хостеров. Плюс с пяток экзотичных систем которые рекомендовали коллеги, знакомые, фрилансеры с которыми общался. Видел не только хостинговые панельки, но еще и просто управление сервером или мониторинги (Ajenti и иже с ним).

«Тысячи их» (с)

Answer 1

[Николай Турнавиотов]

Есть такая штука как панель управления сервером Webmin.
Знаете, почему такие вебпанели не любят все администораторы?
По одной простой причине — Есть софтинка Х версии 1.2.3
Ваша вебпанель её классно умеет готовить, настраивать, перезапускать.
Через неделю выходит новый билд 1.2.4 с критичными багфиксами и изменением дефолтных настроек нескольких параметров на диаметрально противоположные настройки, например.

1. Насколько быстро Вы об этом узнаете?
2. Насколько быстро Вы это отследите?
3. Насколько быстро Вы это исправите?
4. Действия Вашей программы, в случае если программа Х обновляется?
5. А если одновременно обновляется не программа Х, а два десятка, включая системные библиотеки, и формат скриптов запуска демонов?

А если выходит вообще новая версия 3.0.0 где опции разбиваются на три десятка конфигов?

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

Comments

[Антон Пискунов]

Настолько быстро — насколько будет позволять ситуация. Если продукт будет пользоваться популярностью, то почему бы не мониторить поддерживаемое ПО на постоянной основе? С внесением соответствующих изменений всё сложнее, особенно в случае намбер 5, но все можно решить.

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

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

Answer 2

[iborzenkov]

Полностью согласен с foxmuldercp
также добавлю, что обычно эти панели разводят срач в конфигах по принципу — зачем нам модульное программирование, когда есть блочное копирование.
В результате те-же конфиги апача/нгинкса из нормально разбитых по файликам кидаются в один файл который находится где-то в папке панели и инклудится где-то в конце основного (прошу заметить стандартного, из репы) конфига.

С учетом того что это для маленьких веб студий, то блин этим требованиям удовлетворяет настройка системы один раз, чтобы при добавлении папки с новым сайтом она автоматом подхватывалась (потому что маленькие студии не будут писать и на php и на ruby и на python сразу — они выберут что-то одно)
Если несколько готовых типовых шаблонов — сайты на php|ruby|node и консольная команда генерации конфигов из шаблонов. Я такое писал для php когда увидел какой ужас творит ISP — там два шаблона + sh + awk + табличка с сайтами — генерило на ура (но это конечно на коленке)
В особо запущенных случаях — подключение куска конфига из папки с сайтом и команда на рестарт. И не надо городить никаких панелей управления, потому что проще определить несколько правил расположения сайтов и настроить один раз.

Уже есть нормальная консоль управления сервером — ssh + конфиги, и не надо городить очередную поделку

Comments

[Антон Пискунов]

Относительно срачей в конфигах — сначала анализируем, потом предлагаем. Не перезаписываем все с горячей руки. Все конфиги кладутся соответственно рекомендациям разработчиков ПО. Никакого ISP-подобного треша в апачевских виртуалхостах (самый яркий пример).

Возможность настроить шаблоны ручками для разных доменов. Отслеживание версионности конфигов. Откаты.

[iborzenkov]

Кстати вполне возможно хорошим способом будет использование augears — там достаточно хороший фреймворк, юзаемый в puppet.

Answer 3

[switlle]

Я думаю это отличная идея.
У меня например есть масса vps которые выполняют роль «рабов». И иногда хочется не заморачиваться с ними вообще. Купил его — и настроить по-быстрому под нужные параметры.
Было бы хорошо, если бы у вас в наборе можно было все из коробки нужное развернуть. Например, сначала выбрал что и с чем хочешь связать (можно либо гибкие либо стандартные варианты), и скрипты сами делают первоначальную настройку окружения под себя. Это было бы действительно идеально.
А остальные мелочи уже через веб.

Comments

[Антон Пискунов]

Спасибо за поддержку. Учту пожелание, подумаю — в нём есть рациональное зерно.

[Николай Турнавиотов]

В этом варианте — действительно есть смысл.
Хотя вон есть systemimager, puppet и т.п

Answer 4

[Ilya Evseev]

Для начала напишите хабраобзор тех панелей, с которыми имели дело, и перечислением их недостатков.
Чтобы было понятно, из-за чего потребовалась разработка нового продукта.
Для операторов есть RootPanel, Joonte, MultiCabinet.
Для клиентов Ajenti, OpenPanel, ZPanel и т.д.
Они все Вам не понравились?

Comments

[Антон Пискунов]

У каждого есть плюсы и минусы. С некоторыми можно жить, с некоторыми — нет.
Полностью удовлетворяющего меня решения я еще не видел.

О хабраобзоре я подумаю — мысль дельная.

Answer 5

[Andrey]

Антон, а лицензирование какое? Платное, бесплатное?

Comments

[Антон Пискунов]

Бесплатное. Полный опенсорс и свобода. У меня нет цели сделать на этом денег, тут цель исправить своё неудобство и если это будет интересно кому-то другому, то поделиться наработками.

Вопрос монетизации будет поднят только когда проект выйдет на уровень фуллтаймовой занятости. Ну… Если это когда-нибудь случится :D

Answer 6

[Алексей Сундуков]

>python, ruby, php, node, nginx, mongo, redis, percona, mariadb, mysql, exim, dovecot, proftpd,
>memcache и прочее ПО которое может потребоваться разработчику в наше время.

Тогда не стоит. Как уже было упомянуто выше, проблема с панелью не в том, чтобы её написать, а в в том, чтобы её поддерживать. Адекватно это делать не на фултайме командной разработчиков нереально (вы же не будете отслеживать все релизы поддерживаемого ПО и тут же бросаться доделывать панель). Можно бить себя в грудь, утверждая, что у меня конечно же получится создать правильную архитектуру, но тогда получается, что все остальные команды, пишущие панели, настолько некомпетентны, что не смогли прийти к этой правильной архитектуре.

Рекомендую начать с малого, написав панель управления связкой nginx+php-fpm (версий 5.2-5.5)+mysql+какой-то_ftp+какой-то_dns через которую можно управлять vhost-ми, в идеале с возможностью трансформаций htaccess-ов в готовые конфигурации nginx. В крайнем случае хотя бы apache за nginx.

P.S. А чем та же OpenPanel не угодила?
P..P.S. Работая и разработчиком, и у хостера сам не раз думал и даже делал простой прототип панели. Но трезвая оценка говорит, что написать нормальную панель поддерживающую целую группу ПО да еще и разных версий не на фултайме обречено на провал. А фултайм ни кто оплачивать не хочет в условиях, когда готовые панели уже есть.

Comments

[Антон Пискунов]

Поддерживать тяжелее чем писать. Всегда так было и всегда так будет — я прекрасно это осознаю. Так же я частично согласен с вашими аргументами про некомпетентность коллег, но… Если так рассуждать, то зачем нам разные языки если есть асм и си? Или зачем такое количество CMS на PHP?

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

У меня есть пара теорий и идей как можно снять с плеч панели ответственность за ПО и оставить только функцию контроля, но пока я в стадии написания ТЗ и до проверки идей еще достаточно далеко. Если всё получится, то у панели будет реальная киллерфича. Надеюсь.

[Алексей Сундуков]

>то зачем нам разные языки если есть асм и си
Затем, что на PHP, RoR, ...,… выходит дешевле и быстрее. Дешевле в смысле комплексно: сложность поддержки, стоимость разработчиков. Абсолютно просто экономический расчет.

>Или зачем такое количество CMS на PHP?
Ни одна из них не может конечному клиенту (не разработчику!) предоставить требуемый функционал за приемлемый для него бюджет.

>это незачем в моей ЦА — им предоставляют DNS провайдеры.
Эту аудиторию обычно устраивает ISP либо люди вовсе могут сделать сами все из консоли. Имхо, правильное направление — кнопка «создать сайт». Должен создаваться vhost, база для сайта, ftp изолированный аккаунт, создаваться записи на уровне DNS. Ибо DNS нужен даже тем, кто может их и сам прописать. Просто нужно логиниться и делать это все руками сейчас, а панель бы могла это автоматизировать. Лично я на протатипе использовал API от reg.ru. Тут можно и домен создать, и все нужные для него записи в DNS зафигачить.

>как можно снять с плеч панели ответственность за ПО и оставить только функцию контроля
Парсинг с лексером? Все равно остается вопрос интерпретации (на туже валидность и допустимые значения) распарсеных сущностей. И мы снова упираемся в суппорт панели для разных версий. Имхо, бесперспективный вектор.

Киллерфича любой панели должна быть большая кнопка «Сделать все хорошо». Просто у каждой ЦА она должна быть своя (решать разные задачи).

Answer 7

[spotifi]

И нашим и вашим?

PaaS это называется.
Существует давно уже.

P.S.:
Кто ваша целевая группа?

Тому, кто действительно нуждается в управлении своим софтом, но не хочет/не умеет это делать - путь в PaaS.

Тому, кто умеет - путь в DevOps.

Настолько универсальную панель создать невозможно, так как существуют многие варианты запуска серверов хотя бы с одним Python или PHP. Всем не угодишь.

Comments

[Антон Пискунов]

Вопросу два года, масенький.

[spotifi]

Антон Пискунов:
И что? С тех пор что-то принципиально изменилось в мире разворачивания малых веб-сайтов, админы которых и являются основными потребителями панелей управления хостингами? А в мире хардкорных монстров и тогда применялись и сейчас применяются совсем другие подходы.