Интернет технологии -> Perl -> Программирование на PERL

mod_perl за 30 минут. Часть II

Настройка и запуск сервера 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. Поэтому наш первый тестовый скрипт может быть таким простым как:

mod_perl_rules1.pl
------------------
print "Content-type: text/plain\r\n\r\n";
print "mod_perl rules!\n";

Сохраните этот скрипт в файле /home/httpd/perl/mod_perl_rules1.pl. Обратите внимание, что строка #!/usr/bin/perl в mod_perl не нужна, но если хотите, можете ее сохранить. А следующий скрипт можно использовать вот таким образом:

mod_perl_rules1.pl
------------------
#!/usr/bin/perl
print "Content-type: text/plain\r\n\r\n";
print "mod_perl rules!\n";

Конечно, вы можете написать такой же скрипт используя 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 должен иметь возможность читать и выполнять их. Так что мы делаем скрипты доступными для чтения и выполнения каждому:

% chmod 0755   /home/httpd/perl/mod_perl_rules1.pl \
                                         /home/httpd/perl/mod_perl_rules2.pl

Если вы не хотите, чтобы остальные пользователи могли прочесть ваш скрипт, тогда добавьте себя в ту группу, в которой работает сервер (как это определено директивой Group), а затем сделайте этот скрипт принадлежностью группы и установите строгие права доступа. Например, на своей машине я запускаю сервер из-под группы httpd и в этой группе (помимо сервера) есть только я. Так что я могу поступить следующим образом:

% chown stas.httpd /home/httpd/perl/mod_perl_rules1.pl \
                 /home/httpd/perl/mod_perl_rules2.pl

% chmod 0750   /home/httpd/perl/mod_perl_rules1.pl \
                 /home/httpd/perl/mod_perl_rules2.pl

Первая команда определяет принадлежность файлов группе 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:

ModPerl/Rules1.pm
  ----------------
  package ModPerl::Rules1;
  use Apache::Constants qw(:common);

  sub handler{
    print "Content-type: text/plain\r\n\r\n";
    print "mod_perl rules!\n";
    return OK;
  }
  1; # satisfy require()

или 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 выполните:

% perl -le 'print join "\n", @INC'

На моей машине выводится следующее сообщение:

/usr/lib/perl5/5.6.1/i386-linux
  /usr/lib/perl5/5.6.1
  /usr/lib/perl5/site_perl/5.6.1/i386-linux
  /usr/lib/perl5/site_perl/5.6.1
  /usr/lib/perl5/site_perl
  .

Теперь добавьте приведенный ниже фрагмент в файл httpd.conf, чтобы настроить mod_perl выполнять подпрограмму ModPerl::Rules::handler во всех случаях, когда вы делаете запрос к mod_perl_rules1:

PerlModule ModPerl::Rules1
  <Location /mod_perl_rules1>
    SetHandler perl-script
    PerlHandler ModPerl::Rules1
  </Location>

Теперь можете направить запрос на

и так же, как в случае со скриптами mod_perl_rules.pl в качестве ответа вы увидите:

mod_perl rules!

Чтобы протестировать второй модуль <ModPerl::Rules2> добавьте такую же настройку, только замените все 1 на 2:

PerlModule ModPerl::Rules2
  <Location /mod_perl_rules2>
    SetHandler perl-script
    PerlHandler ModPerl::Rules2
  </Location>

И для проверки используйте сылку:

Это все, что мне нужно знать о mod_perl?

Очевидно, что следующим вашим вопросом будет "Это все, что мне нужно знать о mod_perl?"

Ответ: "и да, и нет".

Что касается "да":

• Так же, как и в случае с Perl вам нужно знать совсем не много, чтобы делать действительно классные штуки. Представленные здесь установки дают вам возможность намного быстрее запустить ваш счетчик посетителей и гостевую книгу, и вызвать удивление ваших друзей, как правило даже не меняя отдельные строки кода.

Что касается "нет":

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

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

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

Отладка - это то, о чем люди предпочитают не говорить как о процессе весьма утомительном. И если вы мните себя web-программистом, то вы просто обязаны сделать процесс отладки более простым и эффективным. Эта задача не настолько примитивна, как отладка CGI-скриптов, а в mod_perl даже более сложная (до тех пор, пока вы не поймете как это делать - тогда она внезапно станет простой).

В mod_perl есть много приспособлений для работы с базами данных, недоступных в mod_cgi. Среди прочих наиболее значимой являются постоянные соединения.

Вам следует знать, как обеспечить непрерывную работу вашей службы и уметь быстро восстановить все, если возникнут какие-либо проблемы.

В заключение скажу, что самым важным является Apache-Perl API, дающий вам возможность делать с полученным запросом все что угодно - даже вмешиваться в процесс запроса на любой стадии. Это придает вам исключительную гибкость и позволяет создавать такие вещи, о которых вы даже и не мечтали работая с простым mod_cgi.

Есть еще много всего, что нужно узнать о mod_perl и web-программировании в целом. В следующих статьях я расскажу обо всем этом подробнее.

Благодарности

Огромное спасибо Эрику Чолету (Eric Cholet) за рецензирование этой статьи.

Ссылки

URL сайта Apache: http://www.apache.org/

URL сайта mod_perl: http://perl.apache.org/

CPAN - развернутая сеть архивов по Perl. URL главного сайта: http://cpan.org/. Зеркала CPAN есть более чем на 100 сайтах по всему миру. (http://cpan.org/SITES.html)