Apache 2.2.0: использовать или подождать?

Apache 2.2.0 является основной версией сервера Apache и содержит множество важных изменений. Многие из этих изменений являются улучшением существующих модулей. Также было добавлено несколько новых модулей и произведены некоторые улучшения в архитектуре сервера. В этой статье мы расскажем о наиболее важных изменениях, а также подумаем, надо ли делать апгрейд до новой версии или лучше подождать.
Новая версия 2.2.0 - это не только обновленная версия существующего дерева. Для предоставления новой функциональности и для расширения старой было добавлено много нового кода.

изменения в конфигурации

Конфигурационный файл Apache со своими пользователями всегда был в непростых отношениях “любви и ненависти”. Некоторые любят единый “все-конфигурации-в-одном-файле” подход. Другие предпочитают разбить свои файлы и для вставки специфичных данных использовать механизм включений. Хотя это не влияет на саму конфигурацию, все же использование множества файлов легче для понимания и более удобно, так как позволяет вам поместить конфигурации каждого виртуального хоста в отдельный файл.

Конфигурационный файл Apache по умолчанию был сделан единым и часто содержал множество директив, которые некоторые пользователи не только не использовали, но и не понимали. Некоторые дистрибутивы Linux (например, Gentoo), по умолчанию разделяют конфигурационный файл. Сейчас это стало стандартной особенностью официального дистрибутива сервера.

Главный файл конфигурации httpd.conf как был, так и остался. В добавление к нему опционально включаются стандартные конфигурационные файлы со следующими элементами:
- управление многозадачностью сервера (MPM-конфигурация);
- многоязычные сообщения об ошибках;
- индекс каталогов;
- настройки языка;
- каталоги пользователей;
- информация о запросах/конфигурации (/server-info и /server-status);
- конфигурация виртуальных хостов;
- доступ к документации Apache;
- WebDAV;
- различные настройки по умолчанию;
- конфигурация SSL.

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

модули авторизации/идентификации

Хотя авторизация и идентификация сами по себе не изменились, модули, которые за них отвечали, были переделаны, а в некоторых случаях, чтобы легче сделать выбор компонентов, и переименованы. Также был добавлен новый модуль, который предоставляет авторизацию через LDAP
(mod_authnz_ldap).

Стандартные модули авторизации были изменены для создания логической связи между именами модулей и типами авторизации, которые они
предоставляют. Например, изначальный модуль mod_auth был разбит на mod_auth_basic и на mod_authn_file, который предоставляет API для идентификации с помощью файлов. Префикс модуля теперь показывает роль модуля в процессе авторизации/идентификации:
- mod_auth_* показывает, что модуль предоставляет механизм HTTP-идентификации (например, mod_auth_basic и mod_auth_digest и т.п.);
- mod_authn_* показывает, что модуль предоставляет собственный механизм идентификации (например, mod_authn_file и mod_authn_dbm);
- mod_authz_* показывает, что модуль предоставляет механизм авторизации (например, mod_authz_dbm и mod_authz_host);
- mod_authnz_* показывает, что модуль предоставляет механизмы идентификации и авторизации (например, новый модуль mod_authnz_ldap). В результате имеем интуитивно понятный набор модулей, с помощью которых можно полностью управлять поддержкой авторизации и идентификации на вашем сервере. Также это делает легче разработку пользовательских модулей идентификации и авторизации, которые вы можете легко интегрировать с существующими компонентами.

прокси/кэш

Новый модуль mod_proxy_balancer был добавлен, чтобы предоставить возможность балансировки нагрузки для главного модуля прокси mod_proxy. Балансировка нагрузки распределяет запросы между рабочими процессами, используя два метода: подсчет запросов и подсчет трафика. Первый метод считает число запросов и распределяет их между рабочими процессами так, чтобы каждый из процессов обслуживал одинаковое количество запросов. Второй метод в принципе работает так же, как и простой подсчет запросов, но в нем вы можете задать объем обрабатываемого трафика для каждого рабочего процесса отдельно так, чтобы определенные процессы обработали больший объем запросов, чем другие.

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

Новый модуль балансировки нагрузки прокси также включил дополнительный вывод статусной информации похожий на /server-status и /server-info. Работа модулей кэширования (mod_cache, mod_disk_cache и mod_mem_cache) редко детально рассматривается, и многие организации используют эти модули без всякого результата. Хотя эти модули предназначены для повышения производительности. Также в версию 2.2.0 включена новая программа, htcacheclean, которая очищает базу данных кэшированных документов. Она может запускаться как для единичной очистки БД, так и работать в качестве демона. Также она предоставляет статистику о размере каталога кэша.

фильтрация

Чтобы позволить фильтрам запускаться на основе некоторого условия, фильтр mod_filter был существенно переработан. Это поменяло старую модель, по которой документы просто фильтровались без всяких условий в соответствии с директивой AddOutputFilter или с помощью AddOutputFilterByType. Сейчас вместо добавления фильтров для конкретных типов файлов нужно создать требуемую цепочку фильтров – где выходные данные будут обрабатываться каждым фильтром цепочки. Такой подход требует задания доступных типов фильтров и, если необходимо, то и требования к источнику данных (тип файла). Также указываются используемые фильтры.

Объясним на примере, взятом в стандартной документации. Пример с SSI показывает, как изменился старый подход.
Было:

AddOutputFilter INCLUDES .shtml

Стало:

FilterDeclare SSI
FilterProvider SSI INCLUDES resp=Content-Type $text/html
FilterChain SSI

Объявление цепочки фильтров дает нам возможность добавлять фильтры в конкретные места в цепочке и даже указать, какой фильтр необходимо удалить, основываясь на некотором условии. Например, вы хотите добавить SSI для любых данных, кроме данных, полученных из CGI. Это можно сделать добавлением фильтра SSI в цепочку, а когда запрос направлен на CGI-скрипт – использовать цепочку без SSI.

поддержка баз данных

Раньше для использования баз данных с модулями Apache требовалось дополнительное программирование, дабы сделать обертку, обеспечивающую доступ к конкретной базе данных. Например, если вы хотите создать идентификацию с помощью MySQL или PostgreSQL, то вам надо использовать модуль, который предоставляет интерфейс для SQL БД. За счет дополнительного программирования и вопросов производительности это решение виделось многим не очень привлекательным.

В Apache 2.2 существует модуль mod_dbd, который предоставляет соединения с базой данных, используя стандартный интерфейс. Модуль использует интерфейс apr_dbd, что означает, что соединения с базой данных могут обрабатываться в контексте нитей путем предоставления пула доступных соединений. Это должно помочь увеличить гибкость и улучшить производительность модулей, нуждающихся в соединении с базой данных.

Заметьте, что модуль не предназначен для доступа к базам данных динамическими веб-сайтами, но в будущем это может быть реализовано через интерфейсы таких модулей, как mod_perl и mod_php.

изменения в разработке модулей

В интерфейсе создания модулей для Apache также появилось несколько внутренних изменений.
Логирование ошибок соединения сделало возможность сохранения ошибок, связанных с соединениями.
Новые хуки теста конфигурации предоставляют результаты проверки конфигурации во время ее тестирования.
В нитевых МП-модулях размер стека может быть изменен.
Обработка протокола выполняется в выходных фильтрах. Также теперь фильтры могут передать обязанность установки выходного типа модулю mod_filter. Хук монитора позволяет модулям автоматически запрашивать выполнение регулярных задач.
Был изменен интерфейс регулярных выражений, а библиотека PERL-совместимых регулярных выражений (PCRE) была обновлена до версии 5.
Новый DBD-фреймворк сделал работу с SQL БД легче, но теперь необходимо переделать собственные модули для работы с БД.

изменения в программе

Несколько улучшений были внесены в программное окружение сервера Apache. Был добавлен новый параметр командной строки для httpd, позволяющий облегчить отладку модулей.
C помощью параметра l всегда можно было отобразить список модулей встроенных в httpd, например:

$ httpd –l

Compiled in modules:

core.c
prefork.c
http_core.c
mod_so.c

Но этот список показывает только те модули, которые встроены в бинарники сервера. Динамически загруженные модули (DSO) не отображаются. С помощью параметра –L можно вывести список модулей, у которых есть директивы в файле конфигурации, но он не будет содержать модули без директив. Новый параметр командной строки –M отображает список всех модулей - и тех, которые статически слинкованы с сервером, и тех, которые загружены при запуске. Также выводится тип модуля (static или shared):

httpd -M

Loaded Modules:

core_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
authn_anon_module (shared)
env_module (shared)
expires_module (shared)
headers_module (shared)
mime_module (shared)
negotiation_module (shared)
setenvif_module (shared)
log_config_module (shared)
logio_module (shared)
cgi_module (shared)
alias_module (shared)
rewrite_module (shared)
userdir_module (shared)
info_module (shared)
status_module (shared)
actions_module (shared)
autoindex_module (shared)
dir_module (shared)
ext_filter_module (shared)
deflate_module (shared)
include_module (shared)

Syntax OK

Этот список гораздо полезней при возникновении проблем во время разработки модулей.

Модули prefork, worker и event теперь позволяют серверу совершить “мягкую перезагрузку”, во время которой занятые процессы не завершаются немедленно, а прекращаются по мере завершения обработки текущего запроса. Вы также можете указать тайм-аут в конфигурации, используя директиву GracefulShutdownTimeout, после которого сервер завершит обработку всех запросов, не смотря на их статус.

переходить мне на новую версию или лучше подождать?

Дилемма выбора между переходом на новую версию и продолжением использования текущей версии осталась.
С одной стороны Apache 2.2.0 - это только новый релиз уже стабильной и хорошо оттестированной версии сервера Apache. Первая официальная версия ветки Apache 2.0 – 2.0.35 была выпущена в Апреле 2002. Большинство ошибок уже исправлено. С этой стороны версия 2.2.0 является продолжением стабильной ветки разработки сервера.

Тем не менее, изменения в модулях авторизации могут заставить немного усомниться в целесообразности использования версии 2.2.0 без дополнительного тестирования. Конечно же, изменения в конфигурации означают, что вам необходимо будет провести собственные тесты сервера перед использованием Apache 2.2.0 в реальном окружении – особенно если ваш веб-сайт сильно нагружен операциями идентификации и авторизации. Также следует быть осторожным при переходе на новую версию, если вы используете модули сторонних производителей. Изменения в движке регулярных выражений и API требуют некоторой переработки старых модулей. Если ваши модули используют SQL-интерфейсы для MySQL или других БД, вам необходимо использовать новый интерфейс mod_dbd вместо вашего решения.

В целом текущий выбор таков:
Apache 2.0.55 - последний стабильный релиз перед 2.2.0.
Apache 2.2.0 - последний релиз сервера Apache в целом.
Apache 1.3.34 - последний релиз Apache 1.x.



ServerWatch. Перевод Сипягина Максима.