В предыдущей статье я представил в достаточной мере примечательные выложенные в сети отчеты компаний, активно использующих mod_perl. Возможно, вас это удивит, но вы с легкостью можете получить подобные удивительные результаты, если тоже переведете свои сервисы на использование mod_perl. В действительности, чтобы начать работать с mod_perl, вам потребуется не более 30 минут - то самое время, которое необходимо, чтобы прокомпилировать и настроить сервер на нормальной машине и запустить его.
В этой статье я продемонстрирую вам пошаговую установку и сценарии настройки, и готов поспорить, что вы сможете произвести первоначальную настройку статически прокомпилированного mod_perl без чтения каких-либо иных документов. Разумеется, позже вам захочется (и понадобится) прочесть документацию, но думаю, вы со мной согласитесь, что это исключительно круто, - запросто справляться с чем-либо, практически ничего не зная о новой технологии.
Установка mod_perl проводилась на многих широко известных платформах Unix, так что, даже если вы работаете с нестандартной системой, у вас не должно возникнуть проблем с построением первоначального сервера mod_perl.
Если вы пользователь Windows, то самым простым для вас будет использовать бинарный пакет, выложенный на . Оттуда же вы можете скачать и RPM-версию для Linux, и текущую версию с CVS. Как бы там ни было, я всегда рекомендую начинать строить mod_perl с самого начала, и как вы сами скоро убедитесь, сделать это очень просто.
Устанавливать mod_perl легко
Чтож, давайте начнем процесс установки. Если вы опытный пользователь Unix, то вам не нужно пояснять значения приведенных ниже команд. Просто скопируйте и вставьте их, и ваш сервер будет установлен.
Я буду использовать значок % как приглашение shell'а.
% cd /usr/src % lwp-download http://www.apache.org/dist/httpd/apache_1.3.20.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-1.26.tar.gz % tar -zvxf apache_1.3.20.tar.gz % tar -zvxf mod_perl-1.26.tar.gz % cd mod_perl-1.26 % perl Makefile.PL APACHE_SRC=../apache_1.3.20/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make && make test && make install % cd ../apache_1.3.20 % make install
Это все!
Что остается сделать - так это добавить несколько строк в файл настройки Apache httpd.conf, запустить сервер и наслаждаться mod_perl.
Если у вас возникли проблемы при выполнении какого-либо из приведенных выше пунктов - не отчаивайтесь, в следующем разделе по каждому пункту будут даны подробные пояснения.
Подробности установки mod_perl
Если у вас не хватает смелости попробовать использовать пункты, приведенные в предыдущем разделе, или вам просто необходимо побольше разобраться, прежде чем приступить к делу, тогда давайте углубимся в детали процесса установки. Если же вы успешно установили mod_perl, следуя краткому сценарию, данному в предыдущем разделе, тогда можете пропустить этот раздел и перейти к следующему.
Прежде чем мы приступим, хочу напомнить, что, чтобы установить файлы в защищенных областях, вы должны стать пользователем root. Если у вас нет прав доступа root'а, тогда вы можете установить файлы в вашу рабочую директорию home. Об особенностях данного метода мы поговорим в будущих статьях. Я также предполагаю, что у вас в наличии имеется уже установленные perl и gcc компиляторы или как эквивалент - компилятор для C.
Пусть все построения производятся в директории /home/stas/src. Тогда мы переходим в эту директорию.
% cd /home/stas/src
Теперь мы установим исходники последних дистрибутивов Apache и mod_perl. Если у вас уже установлен модуль LWP(также известный как libwww и выложенный на CPAN), тогда у вас должна быть утилита lwp-download, частично имитирующая ваш любимый браузер и позволяющая вам скачивать файлы из Internet'а. Вы можете использовать любой другой способ, чтобы раздобыть эти файлы. Просто убедитесь, что вы сохранили все файлы в директории /home/stas/src, поскольку так вам проще будет следовать процессу установки из приведенного выше примера. Разумеется, вы можете установить все пакеты где угодно в вашей системе.
Посетив директории содержащие дистрибутив: и , вы можете убедиться, что устанавливаете самые новые стабильные версии. Как вы уже догадались, первая из указанных ссылок - главная директория с дистрибутивом Apache, а вторая - с mod_perl.
Распакуйте оба исходника. Вам необходимо распаковать сжатые файлы. В дополнение к непосредственной цели использования для упаковки и распаковки файлов, применив опцию -z с помощью утилиты GNU tar можно декомпрессовать файлы, сжатые утилитой gzip.
% tar -zvxf apache_1.3.20.tar.gz % tar -zvxf mod_perl-1.26.tar.gz
Если вы используете не GNU tar, а другую утилиту, то существует вероятность, что вам не удастся распаковать сжатые файлы, тогда вам придется делать это в два этапа. Сначала разверните сжатые пакеты с помощью:
В mod_perl задается множество параметров. В данном сценарии мы собираемся использовать те, которые позволят вам делать с помощью mod_perl практически все. Когда вы узнаете о mod_perl побольше, вы сможете точно регулировать список параметров, передаваемых для Makefile.PL. В будущих статьях я подробно рассмотрю все имеющиеся опции.
Выполнение perl Makefile.PL ... проверит соответствие необходимым условиям и сообщит вам, какие пакеты программного обеспечения отсутствуют в вашей системе. Если у вас не установлены какие-либо пакеты Perl, то вам нужно их установить, прежде чем приступить к работе. Все они выложены на CPAN и их можно запросто скачать и установить.
Если вы выбрали установку mod_perl с помощью модуля CPAN.pm, то он установит вам все недостающие модули. Чтобы сделать это, укажите для CPAN.pm установить модули Bundle::Apache.
Этот шаг также выполняет скрипт ./configure из исходника дистрибутива Apache (абсолютно для вас незаметно), который создает файлы настройки Apache. Если вам нужно передать параметры для скрипта Apache ./configure, то передайте их как опции для perl Makefile.PL .... В будущих статьях мы поговорим обо всех имеющихся опциях.
Теперь вы должны построить httpd, который будет выполняться с помощью утилиты make.
% make
Эта команда создает файлы с расширением mod_perl, устанавливает их в исходное дерево Apache и строит выполняемый httpd (собственно web-сервер), компилируя все необходимые файлы. По завершении процесса выполнения команды make вернитесь в начальную директорию дистрибутива mod_perl.
Команда make test выполняет различные проверки mod_perl в только что построенном выполняемом httpd.
% make test
Эта команда запускает сервер на нестандартном порту (8529) и проверяет, все ли части построенного сервера работают корректно. Если что-нибудь не в порядке, то процесс вам об этом сообщит.
Команда make install завершает процесс установки mod_perl, устанавливая все файлы Perl, необходимые для запуска mod_perl и , конечно, документацию для сервера (man'ы).
% make install
Вы можете использовать последовательность следующего вида:
% make && make test && make install
Это упрощает установку, так как вам не приходится ждать завершения выполнения одной команды, прежде чем запустить следующую. Если же устанавливаете mod_perl впервые, то лучше делать все шаг за шагом.
Если же вы выбрали способ "все в одном", то вам следует знать, что если слетит команда make, то не выполнится ни make test, ни make install. А если упадет make test, то не выполнится make install.
В заключение, вернитесь в начальную директорию дистрибутива Apache, запустите команду make install чтобы создать дерево директорий Apache и установите заголовочные (*.h) файлы Apache, файлы настройки по умолчанию (*.conf), исполняемый файл httpd и еще несколько других программ.
% cd ../apache_1.3.20 % make install
Имейте ввиду, что, как и при простой установке Apache, все файлы настройки, оставшиеся от предыдущей установки, не будут переписаны в процессе. Вам не нужно делать резервные копии рабочих файлов настройки перед новой установкой.
Когда завершится процесс выполнения команды make install, она сообщит вам, как запустить только что построенный сервер (путь к утилите apachectl, которая используется для осуществления контроля над сервером) и где установлены файлы настройки. Запомните, а лучше запишите и то и другое, поскольку эта информация вам понадобится. На моей машине есть два таких важных пути:
Итак, мы завершили построение и установку mod_perl для Apache. Следующими пунктами нужно будет настроить httpd.conf, написать небольшой тест-скрипт, запустить сервер и проверить, что тестовый скрипт работает.
Настройка и запуск сервера mod_perl
Сначала - самое главное. Нужно убедиться, что наш сервер Apache построен корректно и мы можем с его помощью обрабатывать простые файлы в формате HTML. Для чего это нужно? Чтобы сократить до минимума число потенциальных любителей доставлять неприятности, если вдруг обнаружится, что mod_perl не работает. После того, как вы выясните, что Apache может обрабатывать файлы формата HTML, больше об этом можете не беспокоиться. И если что-нибудь не так с mod_perl, то вы исключили возможность того, что не в порядке бинарный код httpd или первоначальные настройки. Вы знаете, что вы можете подключаться к тому порту, на прослушивание которого вы настроили ваш сервер, и что броузер, с помощью которого вы осуществляете проверку в полном порядке. И еще раз повторю, что при первой установке mod_perl вам следует придерживаться этих указаний.
Настройте Apache так, как вы всегда это делаете. Установите Port, User, Group, ErrorLog и другие директивы в файле httpd.conf (помните, в конце предыдущего раздела я просил вас запомнить месторасположение этого файла?). Используйте настройки, предлагаемые по умолчанию, изменяйте только в случае необходимости. Параметры, которые необходимо изменить самостоятельно это: ServerName, Port, User, Group, ServerAdmin, DocumentRoot и некоторые другие. Перед каждой директивой вы обнаружите вспомогательные подсказки. Если сомневаетесь - следуйте этим подсказкам.
После того как вы отредактировали файл настройки, самое время запустить сервер. Один из способов запустить и остановить работу сервера - использовать утилиту apachectl. Запустите сервер с помощью:
% /usr/local/apache/bin/apachectl start
И остановите его с помощью:
% /usr/local/apache/bin/apachectl stop
Учтите, что вы должны иметь права root'а, когда запускаете сервер, если сервер настроен на порт 80 или другой привилегированный порт (<1024).
После того, как вы запустите сервер, проверьте в файле error_log (его месторасположение по умолчанию - /usr/local/apache/logs/error_log), что сервер на самом деле запущен. Не полагайтесь всецело на записи состояния apachectl. Вы должны увидеть примерно следующее:
[Thu Jun 22 17:14:07 2000] [notice] Apache/1.3.20 (Unix) mod_perl/1.26 configured -- resuming normal operations
Теперь направьте свой броузер, как это настроено директивой ServerName, на
или .
Если вы установили директиву Port со значением, отличным от 80, то поместите номер этого порта в конец имени сервера. Если вы использовали порт 8080, то проверьте сервер с помощью
или
Вы должны будете увидеть печально известную страницу "It worked" - она же файл index.html, которую команда make install устанавливает для вас в исходном дереве Apache. Если вы не видите этой страницы, значит что-то не в порядке и вам следует проверить содержимое файла error_log. Путь к файлу error_log вы обнаружите при просмотре директивы ErrorLog в файле настройки httpd.conf.
Если все работает так, как должно, тогда отключите сервер, откройте файл httpd.conf в вашем любимом редакторе и прокрутите в конец файла, куда мы добавим директивы конфигурации mod_perl (разумеется, вы можете поместить их где угодно в файле).
Предполагая, что все скрипты, которые должны будут выполняться сервером под mod_perl, вы разместили в директории /home/httpd/perl/, добавим следующие директивы конфигурации:
Alias /perl/ /home/httpd/perl/ PerlModule Apache::Registry <Location /perl> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On allow from all </Location>
Сохраните измененный файл.
Данная настройка приводит к тому, что каждая ссылка, начинающаяся с /perl будет обрабатываться модулем Apache mod_perl. Она будет использовать обработчик из модуля Apache::Registry в Perl.
Создание директории для скриптов
Теперь создайте директорию /home/httpd/perl/, если таковая еще не существует. Для того чтобы вы и Apache могли читать, делать записи и выполнять файлы, мы должны корректно установить права доступа. Вы можете справиться с ситуацией просто выполнив:
% chmod 0777 /home/httpd/perl
Это очень, очень небезопасно, и вы ни в коем случае не должны пользоваться этим способом на рабочей машине. Так можно поступить, если вы просто хотите потренироваться и всего лишь обыграть сложные ситуации. Когда усвоите, что и как работает, вы должны установить строгую систему прав доступа к файлам, обрабатываемым Apache. В будущих статьях мы поговорим о том, как должным образом установить права доступа к файлам.
Скрипт ``mod_perl rules'' Apache::Registry
Как вы, должно быть, знаете, mod_perl позволяет повторно использовать написанные на Perl скрипты CGI, которые ранее использовались модулем mod_cgi. Поэтому наш первый тестовый скрипт может быть таким простым как:
Сохраните этот скрипт в файле /home/httpd/perl/mod_perl_rules1.pl. Обратите внимание, что строка #!/usr/bin/perl в mod_perl не нужна, но если хотите, можете ее сохранить. А следующий скрипт можно использовать вот таким образом:
Конечно, вы можете написать такой же скрипт используя Apache Perl API:
mod_perl_rules2.pl ------------------ my $r = shift; $r->send_http_header('text/plain'); $r->print("mod_perl rules!\n");
Сохраните этот скрипт в файле /home/httpd/perl/mod_perl_rules2.pl. Теперь сделайте оба скрипта читаемыми и выполняемыми для сервера. Помните, что когда вы выполняете скрипты из shell, то они выполняются под тем именем пользователя, под которым вы вошли в систему. Если же вы пытаетесь запустить скрипты при помощи запросов, то Apache должен иметь возможность читать и выполнять их. Так что мы делаем скрипты доступными для чтения и выполнения каждому:
Если вы не хотите, чтобы остальные пользователи могли прочесть ваш скрипт, тогда добавьте себя в ту группу, в которой работает сервер (как это определено директивой Group), а затем сделайте этот скрипт принадлежностью группы и установите строгие права доступа. Например, на своей машине я запускаю сервер из-под группы httpd и в этой группе (помимо сервера) есть только я. Так что я могу поступить следующим образом:
Первая команда определяет принадлежность файлов группе httpd, вторая - устанавливает должные права доступа для чтения и выполнения.
Это надежный способ, исходя из расчета, что для сервера у вас есть отдельная группа с собственным именем.
Также помните, что все содержащие скрипт директории должны быть доступны серверу для чтения и выполнения.
Так как файл mod_perl_rules1.pl по сути является обычным скриптом Perl, то вы можете проверить его из командной строки.
% perl /home/httpd/perl/mod_perl_rules1.pl
В строке вывода вы увидите следующее:
mod_perl rules!
Второй скрипт вы не сможете проверить из командной строки, поскольку он использует mod_perl API, доступный только при работе с сервера под mod_perl.
Убедитесь, что сервер запущен и с помощью вашего любимого броузера выполните следующие запросы:
или
В обоих случаях в ответ вы увидите следующее:
mod_perl rules!
Если вы видите это - мои поздравления! У вас работает сервер mod_perl.
Если вы вместо порта 80 используете порт 8080, тогда вы должны будете использовать эти ссылки:
или
В случае localhost это получится только если броузер работает на той же машине, что и сервер. Если это не так, тогда для этого теста используйте реальное имя сервера. Например:
Если возникли какие-либо проблемы, тогда посмотрите записи об ошибках в файле error_log.
Теперь пришло время переместить ваши скрипты CGI из директории /somewhere/cgi-bin в /home/httpd/perl/ и увидеть, насколько быстрее они работают, когда запрашиваются из только что настроенного базового URL'а (/perl/). Если раньше доступ к скрипту вы получали указывая /cgi-bin/test.pl, то теперь он доступен из /perl/test.pl.
Некоторые из ваших скриптов, возможно, не будут работать так сразу, и для нормальной работы под mod_perl потребуется их немного отладить или даже частично переписать. Но если вы не грешите небрежностью в программировании, то все шансы за то, что скрипты будут работать и без каких-либо изменений.
При возникновении проблем со скриптами лучше всего будет в файле httpd.conf заменить Apache::Registry на Apache::PerlRun, поскольку последний способен выполнять даже очень некорректно написанные скрипты. Поместите в файл httpd.conf вместо существующих нижеприведенные директивы конфигурации и перезапустите сервер:
PerlModule Apache::PerlRun <Location /perl> SetHandler perl-script PerlHandler Apache::PerlRun Options ExecCGI PerlSendHeader On allow from all </Location>
Теперь ваши скрипты должны работать даже в том случае, если что-либо в них не устраивает mod_perl. Мы обсудим эти нюансы в следующих статьях.
Perl-модуль "mod_perl rules" Apache
mod_perl готов для работы как со скриптами, так и с обработчиками. Я даже уже начал показывать использование скриптов в mod_perl , поскольку гораздо проще, если CGI-скрипты вы уже написали ранее, а наиболее отлаженным механизмом в mod_perl является написание программ обработки. Но не пугайтесь. Как вы увидите через мгновение, писать программы обработки так же просто, как скрипты.
Чтобы создать модуль обработчика в mod_perl все, что мне нужно сделать - это заключить код, который я использовал для скрипта, в подпрограмму handler, добавить предписание вернуть код состояния серверу при успешном окончании работы подпрограммы и поместить объявление пакета в начало кода.
Если вы привыкли, то, как и со скриптами, можно использовать CGI API:
или Apache Perl API, позволяющий вам более тесно взаимодействовать с ядром Apache, обеспечивая наличие API, который не доступен под обычным Perl. Конечно, для приведенного мной простейшего примера хорош любой способ, но когда вам понадобится воспользоваться API, следует использовать эту версию кода:
ModPerl/Rules2.pm ---------------- package ModPerl::Rules2; use Apache::Constants qw(:common); sub handler{ my $r = shift; $r->send_http_header('text/plain'); print "mod_perl rules!\n"; return OK; } 1; # satisfy require()
Создайте директорию с именем ModPerl в одной из директорий в @INC (например, /usr/lib/perl5/site_perl/5.005), и поместите в нее файлы Rules1.pm и Rules2.pm, которые содержат код из приведенных выше примеров.
Чтобы выяснить, что из себя представляют директории @INC выполните:
Теперь добавьте приведенный ниже фрагмент в файл httpd.conf, чтобы настроить mod_perl выполнять подпрограмму ModPerl::Rules::handler во всех случаях, когда вы делаете запрос к mod_perl_rules1:
Очевидно, что следующим вашим вопросом будет "Это все, что мне нужно знать о mod_perl?"
Ответ: "и да, и нет".
Что касается "да":
Так же, как и в случае с Perl вам нужно знать совсем не много, чтобы делать действительно классные штуки. Представленные здесь установки дают вам возможность намного быстрее запустить ваш счетчик посетителей и гостевую книгу, и вызвать удивление ваших друзей, как правило даже не меняя отдельные строки кода.
Что касается "нет":
50-ти кратное увеличение скорости появления отзывов в вашей гостевой книге - это, конечно, здорово. Но если вы организуете навороченный сервис для тысяч одновременно действующих пользователей, то, учитывая высокий уровень конкуренции между аналогичными сетевыми службами, промедление в несколько миллисекунд может стоить вам клиента или даже нескольких.
Конечно, когда вы проверяете отдельный скрипт и являетесь единственным пользователем, то вас не очень-то заботит перерасход времени на ответ равный миллисекунде-другой. Но это становится реальной проблемой, когда эти миллисекунды накапливаются на вашем рабочем сайте, где сотни пользователей одновременно генерируют запросы к различным скриптам вашего сайта. Современные пользователи - народ неблагодарный - если существует, пусть даже менее милый их сердцу, сайт, предоставляющий аналогичные услуги, но чуть-чуть быстрее - вполне вероятно, что они переметнутся туда.
Проверка скриптов на незагруженной машине может ввести вас в заблуждение. Все может выглядеть просто превосходно. Но когда вы перенесете их на рабочую машину, все будет происходить не так гладко, как на той машине, где происходила разработка. Зачастую при загруженных службах у вас просто не хватало памяти. Вам следует научиться оптимизировать код, чтобы использовать меньше памяти и научиться разбивать память.
Отладка - это то, о чем люди предпочитают не говорить как о процессе весьма утомительном. И если вы мните себя web-программистом, то вы просто обязаны сделать процесс отладки более простым и эффективным. Эта задача не настолько примитивна, как отладка CGI-скриптов, а в mod_perl даже более сложная (до тех пор, пока вы не поймете как это делать - тогда она внезапно станет простой).
В mod_perl есть много приспособлений для работы с базами данных, недоступных в mod_cgi. Среди прочих наиболее значимой являются постоянные соединения.
Вам следует знать, как обеспечить непрерывную работу вашей службы и уметь быстро восстановить все, если возникнут какие-либо проблемы.
В заключение скажу, что самым важным является Apache-Perl API, дающий вам возможность делать с полученным запросом все что угодно - даже вмешиваться в процесс запроса на любой стадии. Это придает вам исключительную гибкость и позволяет создавать такие вещи, о которых вы даже и не мечтали работая с простым mod_cgi.
Есть еще много всего, что нужно узнать о mod_perl и web-программировании в целом. В следующих статьях я расскажу обо всем этом подробнее.
Благодарности
Огромное спасибо Эрику Чолету (Eric Cholet) за рецензирование этой статьи.
Ссылки
URL сайта Apache:
URL сайта mod_perl:
CPAN - развернутая сеть архивов по Perl. URL главного сайта: . Зеркала CPAN есть более чем на 100 сайтах по всему миру. (http://cpan.org/SITES.html)