CLI-комбайн для Plesk

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

Так получается, что занимаясь администрированием панели управления хостингом Plesk, несмотря на веб-интерфейс, я все равно довольно много времени провожу в консоле. В конце концов, если я хочу поглядеть права на файл внутри домена vasya.com, не в file manager же идти. Если же взять боевой сервер под хорошей нагрузкой, то некоторые вещи еще сильнее хочется смотреть с консоли, вместо веб-интерфейса.

С одной стороны, занимаясь администрированием Unix/Linux систем на регулярной основе, привыкаешь использовать автокомлит, алиасы, начинаешь писать bash-скрипты для мелких рутинных задач. С другой стороны, если взглянуть на Plesk, то у него довольно богатый CLI-интерфейс, который встречается далеко не в каждой панели управления. Но странная вещь — пользоваться им, мягко говоря, не очень удобно, а для многих типичных административных задач он вообще оказывается бесполезен.

Желание как-то повлиять на ситуацию и провести некоторые улучшения в CLI зрело давно. Проводя половину времени в консоли, набираешь и набираешь очередные команды. Если взглянуть пристально на эти команды, то можно обратить внимание, что эти же самые команды встечаются в файле history и у других администраторов Plesk'а. А команды весьма и весьма многословные:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa
# /usr/local/psa/bin/domain ...
# /usr/local/psa/bin/sw-engine-pleskrun /usr/local...
# tail -f /var/log/sw-cp-server/error_log
...

Предыдущие упомянутые моменты послужили мотивацией попробовать что-то изменить. Кроме того, на решение повлияла в начале года попавшаяся мне книжка о создании command line приложений на Ruby (ее уже как-то пиарили на Хабре). Книжка, кстати, понравилась с тем, что воды там было по-минимуму, а в основном были примеры того, как делать хорошие консольные приложения. Не скажу, что узнал много нового, но книга именно систематизировала знания, разложив вещи по полочкам и послужив дополнительным стимулом применить эти знания.

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

Так появилась консольная утилита с весьма очевидным названием — "plesk", которая была призвана упростить выполнение ряда частых операций в CLI. Утилита идет в штатной поставке Plesk 11.5.

Но вернемся немного к теории. Если поглядеть на утилиты Unix/Linux, то их можно условно разделить на два класса: простые команды и command suites. Когда количество опций начинает превышать разумный предел и есть возможность разбить инструментарий на отдельные области, в этот момент и наступает необходимость в формировании command suite. Пример простой команды — это ls (есть множество опций, но команда — одна), а примеры command suites — это git или svn (есть множество подкоманд).

В контексте Plesk'а одна из проблем выглядела следующим образом. В директории /usr/local/psa/bin/ расположено больше сотни различных утилит. Набирать префикс /usr/local/psa/bin/ каждый раз очень не хочется. Делать "cd /usr/local/psa/bin/" — тоже. Запихать /usr/local/psa/bin/ в PATH еще менее симпатичная идея, потому что в PATH будет хаос и нельзя будет понять то ли это стандартная утилита, то ли утилита из состава Plesk. Выкинуть старый CLI-интерфейс и написать абсолютно новый за ближайшие выходные — утопично как в плане времени, так и в плане поддержки обратной совместимости. Логичный ответ на эту проблему — делаем command suite wrapper'ом над стандартным интерфейсом. Утилиту /usr/local/psa/bin/domain будем вызывать как "plesk bin domain". Для того, чтобы не запоминать названия подкоманд утилиты plesk и доступных утилит из bin'а, добавим bash completion. Чтобы стало еще удобней, добавим bash completion и для команд/опций самих утилит из bin'а.

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

# /usr/local/psa/bin/client -h
Usage: client command <login_name> ..
    Available commands:
    --create or -c     <login_name>    Creates a new customer account..

После этого набирал нужную мне команду (возвращаясь попутно к справочной информации, так как не все опции сразу удается запомнить):

# /usr/local/psa/bin/client --create ...

Теперь же вместо этого достаточно почаще нажимать Tab ;)

# plesk bin cl<TAB>
client       client_pref  cloning
# plesk bin client --create<TAB>
--create     --create-gapps-account

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

Следующий аспект — это shortcuts для частонабираемых, но длинных команд.

Вместо того, чтобы набирать довольно длинную команду для попадания в консольный MySQL-клиент:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa

Теперь достаточно набрать:

# plesk db

Иногда возникает необходимость узнать версию Plesk'а на машине. Архитектуру машины. Имя дистрибутива. Да и версию микроапдейта, если установлен, узнать не помешает. Для этого придется набрать немало команд:

# cat /etc/issue
CentOS release 5.9 (Final)..

# cat /usr/local/psa/version 
11.5.22 CentOS 5 115130325.19

# cat /usr/local/psa/.revision 
319415

# uname -a
Linux hp-demo...

# cat /root/.autoinstaller/microupdates.xml
...

Теперь достаточно набрать одну небольшую команду и получить всю информацию разом:

# plesk version 
Product version: 11.5.30 Update #6
    Update date: 2013/07/19 07:42
     Build date: 2013/07/11 12:00
   Build target: Debian 6.0
       Revision: 323071
   Architecture: 32-bit
Wrapper version: 1.0

Но простых shortcut'ов мало, поэтому идем дальше. Допустим нам хочется поглядеть содержимое той или иной таблицы. Достаточно набрать:

# plesk db show misc
+-------------------------------------+----------------------------------------------------------------+
| param                               | val                                                            |
+-------------------------------------+----------------------------------------------------------------+
| FullHostName                        | unknown                                                        |
| actionlog_rot_num_periods           | 30                                                             |
...

Если вывод превышает размер экрана, то будет использован постраничный просмотр. Те кто пользовался svn log и git log поймут, о какой разнице идет речь. Добиться такого поведения можно, например, используя команду " | less --quit-if-one-screen --no-init".

У панели есть различные конфигурационные файлы. Упростить их открытие на редактирование тоже можно:

# plesk conf panel.ini

И мы уже находимся в Vim и можем вносить изменения. Достигается это с помощью обычного proc_open.

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

# plesk log --all 
Log files: /usr/local/psa/var/log/maillog /var/log/sw-cp-server/..

==> /usr/local/psa/var/log/maillog <==
Jul 22 17:25:43 ay postfix/anvil[25376]: statistics: max connection count 1 for (smtp:1.164.98.84) at Jul 22 17:22:21
..

==> /var/log/sw-cp-server/error_log <==

==> /usr/local/psa/admin/logs/httpsd_access_log <==

...

Свежий взгляд на старые проблемы дает интересные результаты. В 370 строчек кода wrapper'а уместилось довольно много идей в стремлении упростить те или иные моменты.

Еще один важный — это документация.

Если вызвать утилиту без параметров, то должна быть выдана краткая справка. Однако справка точно не должна быть вида "Usage: command [options]" (этим страдают некоторые из штатных утилит Plesk'а). Все-таки немного подробностей не помешает, а именно — перечисление опций, список подкоманд, если есть. Для command suites должна присутствовать подкоманда help и возможность выполнить command help subcommand. По сути это некоторая замена мануалу с возможность фильтрации информации. И конечно же, true Unix-утилита обязательно должна иметь man-страничку. Да, теперь можно набрать, "man plesk" :) Вообще, именно благодаря man'ам, пользователь может изучить тонкости работы утилиты и получить дополнительную информацию, такую как примеры использования, комбинации опций и т.п. Если вы задались целью создать собственный command suite, то не забудьте о usage, help subcommand и man page. Хоть написание справки — одно из нелюбимых программистами занятий.

Возвращаясь к утилите "plesk". У любого человека есть возможность поучаствовать в ее развитии. Plesk разрабатывает очень небольшая команда разработчиков. С другой стороны, администраторов пользующихся Plesk'ом — на несколько порядков больше. Так как утилита призвана в первую очередь упростить жизнь в CLI для администраторов, то она идет с открытым исходным кодом, а репозиторий-mirror есть на GitHub — github.com/sibprogrammer/plesk-ctl Если у вас есть какая-то замечательная идея и вы можете ее воплотить, то есть шанс, что этот функционал окажется в upstream'е. Чтобы минимизировать зависимости, утилита была написана на PHP — языке, используемом для работы веб-интерфейса панели (хоть я и ярый сторонник Ruby и JS :)). С другой стороны, PHP довольно популярен, поэтому выбор этого языка может только поспособствовать развитию утилиты.

P.S. Для любителей визуального восприятия — презентация на SlideShare.

Автор: SibProgrammer

Источник