Глеб Гончаров

Сисадмин и девопс из Ульяновска

За что я ненавижу панели управления

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

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

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

Сейчас я расскажу почему старательно избегаю сервера с панелями управления.

Веб-интерфейс

Начинающим нравится веб-интерфейс из-за лёгкости работы с ним: не нужно запоминать команды и разбираться в сложных настройках. Я предпочитаю командный интерфейс — CLI.

Не функционально. Linux изначально проектировали для работы в командной строке, благодаря чему любой параметр системы можно изменить из терминала. Веб-интерфейс не заменяет командную строку: сложные вещи по-прежнему делают в ней. Да и несложные тоже.

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

Например, чтобы показать десять IP-адресов, отправивших больше всего POST-запросов, достаточно выполнить команду:

grep 'POST' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -n | head

Как такое сделать через веб-интерфейс — не ясно.

Не универсально. CLI выглядит одинаково и не изменяется, в то время как все панели выглядят по-разному. Причина тому — отсутствие спецификации. В CLI программы стандартизированы POSIX, это гарантирует одинаковую работу на разных операционных системах.

Сложно автоматизировать и кастомизировать

Зоопарк редакций. cPanel, Plesk, ISPManager, Vesta, DirectAdmin, Virtualmin, CentOS Web Panel, Ajenti, InterWorx, ZPanel и BlueOnyx — всё это панели управления. Список неполный: есть другие, но о них слышно реже. Они несовместимы друг с другом: у них разная программная архитектура, функциональность, консольные утилиты, версии ПО и пути до файлов.

Например, Plesk работает в Ubuntu и Debian, а DirectAdmin – нет. Virtualmin поддерживает работу с группой серверов, а Ajenti — нет. В ISPManager NGINX поставляют по умолчанию, а в cPanel для этого устанавливают стороннее расширение Engintron. Учесть нюансы непросто.

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

Сервер — не произведение искусства с неповторимой историей. Хороший админ это знает и старается снизить издержки на поддержку инфраструктуры.

Установка на чистый сервер. Если вы попытаетесь поставить панель на уже настроенный сервер, у вас скорее всего ничего не выйдет. Это может стать проблемой, когда вам нужно что-то донастроить или поменять. У вас не получится заменить одну панель на другую — после того, как удалите первую, придётся переустановить всю систему.

Не автоматизировать. Удобством можно пренебречь, когда работу можно автоматизировать. Чтобы быстрее настраивать и реже ошибаться, я описываю работу программ в системах управления конфигурациями — таких как Ansible или SaltStack.

Панель вставляет палки в колёса: при следующем сохранении она перезапишет изменения, внесённые вручную. Вот подключаетесь вы к серверу с cPanel, открываете конфиг Apache и видите в шапке файла:

#
#   Direct modifications to the Apache configuration file WILL be lost upon subsequent
#   regeneration of this configuration file, or an Apache update.
#

Если что-то поменяете, то в следующий раз придётся настраивать заново.

Разработчики cPanel предусмотрели включение одних файлов в другие, но это не решает мои задачи. Я по-прежнему хочу, но не могу изменять файл целиком — только дописывать конфигурации в начало или конец.

#   To have your modifications retained, you should create/edit administrator-specific
#   include files:
#
#       /etc/apache2/conf.d/includes/pre_main_global.conf
#       /etc/apache2/conf.d/includes/pre_virtualhost_global.conf
#       /etc/apache2/conf.d/includes/post_virtualhost_global.conf

Для автоматизации действий в панелях есть API. Например, в cPanel две версии API: старая и новая. В новой версии ответы в XML или JSON, а в старой — HTML, строки и числа. Выходит, теперь нужно писать код с обратной совместимостью между версиями. Если панелей несколько — то и между ними.

Сложно поддерживать

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

Согласно FHS, правильно хранить файлы веб-сайтов в директории /srv. Приемлимыми вариантами считаю /var/www (/var/www/html), как это делают сопровождающие пакетов в Debian или RedHat-подобных дистрибутивах. Логи привычно располагают в /var/log, а конфигурации nginx и apache — в /etc/nginx и /etc/apache2 (/etc/httpd) соответственно.

Не безопасно. Заключительный аргумент против — безопасность. Панели управления переусложнены, а простые вещи безопаснее сложных. Кроме того, панели управления редко обновляют. Причина в том, что администраторы боятся перезаписать изменения и сломать, что уже настроено и работает. Пользователям же как правило всё равно. В итоге такие сервера годами работают с уязвимым ПО.

Выводы

Работать с сервером через веб-интерфейс — всё равно, что программировать мышью. Возможности ни одной из панелей не покрывают мощь и гибкость команд в терминале.

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

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

Панель управления не заменяет админа: случись беда — разбираться ему. Сервер — это как самолёт: салон должен быть удобен для пассажиров, а кабина пилота — для командира судна. Доверьте работу профессионалу.