Многоязычное развертывание PSGI-web - PullRequest
7 голосов
/ 18 мая 2011

Я планирую разработать одно веб-приложение с PSGI / Plack. (вероятно, с Танцор, но пока не решил).

Приложение должно быть utf8, многоязычное (с Locale :: Maketext) и (ofc) будет содержать несколько статических страниц на данном языке. Моя идея заключается в том, чтобы развернуть его в разных языковых доменах, таких как en.example.com, de.example.com и т. Д. Само приложение простое, в основном оно будет заполнять шаблоны только локализованным текстом и некоторыми другими (легкими) функциями.

Как лучше всего развернуть приложение one для нескольких поддоменов на нескольких языках на одной физической машине?

Мое текущее исследование закончилось этим решением: необходимо использовать Apache и его виртуальные серверы на основе имен для каждого языкового поддомен.

<VirtualHost en.example.com>
    ServerName en.example.com
    DocumentRoot /path/to/site/en/files
    <Location />
        SetHandler perl-script
        PerlResponseHandler Plack::Handler::Apache2
        PerlSetVar psgi_app /path/to/site/en/en.psgi
    </Location>
</VirtualHost>

Вопросы:

  • Какое лучшее решение?
  • Существует ли какое-либо решение со Starman или другим чистым Perl-сервером? Если да, то как? Обратный прокси?
  • Будет ли решение для чистого Perl лучше (быстрее)?
  • я должен рассмотреть какое-то другое решение? (fcgi, nginx и т. д ...)

Любые другие идеи / вещи, которые могут повлиять на саму разработку ?

Ответы [ 2 ]

8 голосов
/ 19 мая 2011

Используйте Plack :: App :: URLMap для настройки виртуального хоста в Starman (или любых других PSGI-совместимых веб-серверах):

use Plack::App::URLMap;
my $en_app = generate_app('en');
my $ru_app = generate_app('ru');

my $app = Plack::App::URLMap->new;
$app->map("http://en.example.com/" => $en_app);
$app->map("http://ru.example.com/" => $ru_app);
$app->to_app;

в generate_app вы можете установить / настроить все необходимое для возврата нового приложения PSGI. Если вы хотите использовать один и тот же экземпляр $ app, но хотите динамически изменять поведение, вы можете сделать это, написав промежуточное ПО PSGI, например:

my $app = sub { MyApp->run(@_) };
my $en_app = sub {
   my $env = shift;
   $env->{'myapp.language'} = 'en';
   $app->($env);
};
my $ru_app = sub { ... }; # same

Обратите внимание, что вы, вероятно, захотите поместить Starman позади прокси-сервера, и в этом случае вам нужно настроить внешний интерфейс (nginx / Apache / lighttpd и т. Д.) Для пересылки заголовка Host:, как он есть, на сервер.

3 голосов
/ 18 мая 2011

Я не думал, что есть «лучший» способ, просто много разных способов, и у каждого есть свои плюсы и минусы.

Настройка Apache, как вы сделали, возможна, и я не понимаю, почему это должно быть плохо. Другой способ - «смонтировать» каждое приложение к пути. Это дополнительно описано здесь: http://suryahunter.com/wiki/hunter/perl_ironman/mount_multiple_apps_with_plack

Если вы обычно используете PSGI / Plack, вы можете использовать любой веб-сервер, а также Starman или другие веб-серверы Perl. Какой из них вы используете, зависит от вас. Используйте тот, где вы считаете, что он имеет лучшую производительность, или тот, который вы знали лучше всего.

Также подумайте, что когда вы запускаете свой сервер, вы, вероятно, захотите автоматически запустить ваше приложение, и у Apache, Nginx, LightTPD, ... уже есть сценарии запуска. Если вы также хотите разместить другие веб-сайты, возможно, лучше использовать один из этих веб-серверов.

Я предпочитаю FastCGI для запуска вашего приложения. С FastCGI ваше приложение запускается независимо от вашего веб-сервера, а также может запускаться с другими правами пользователя вместо mod_perl, где все приложения работают под тем же пользователем, что и пользователь Apache. Это также дает вам преимущество в том, что вы можете перезапустить приложение, не перезапуская весь веб-сервер (Apache).

Что ж, и благодаря этой независимости вам, вероятно, понадобится больше оперативной памяти для запуска одного и того же объема приложений, потому что вы запускаете свои приложения несколько раз вместо использования совместного использования, которое дает вам Apache / mod_perl.

В конце концов, это зависит от ваших потребностей в том, что лучше.

...