「Server::Starterに対応するとはどういうことか」の補足 : sonots:blog
PSGI アプリを supervisord + Server::Starter で動作させる - Hatak::Techlog
PSGI で動作する Perl の Web アプリをデプロイする環境をどのように作ろうかと思って試してみたので、その手順をまとめてみます。 記事を書きかけて放置してしまっていたので、diff が古かったりするのはご愛敬で。。 構成の概要 今回構築しようと思う構成は次の通りです。 PSGI を用いた簡単な Web アプリ アプリを動作させる Perl とそのモジュール群は perlbrew + Carton で管理 複数のシステムを同一サーバで動かす可能性もあるため分離しておきたい Carton 使ってみたい アプリケーションサーバには Server::Starter + Starman を利用 Hotdeploy できるようにするため Server::Starter のプロセスは Supervisord で管理 supervisord の導入 スーパーサーバーSupervisorの導入手順
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ - blog.nomadscafe.jp
PSGI/Plack/PSGIアプリケーションを動かす時に一番使われているのは plackup でしょう。 $ cat app.psgi use Plack::Builder; use MyApp; my $app = MyApp->psgi_app; builder { enable 'ServerStatus::Lite', => ..; $app; }; $ plackup -E production -s Starlet --max-workers 30 --port 5000 -a app.psgi plackup コマンドの -s にハンドラ名を指定して起動します。本番環境では -E や $ENV{PLACK_ENV} を指定してStackTraceやLintといった開発に便利なPlack::Middlewareが追加されないようにする必要がありますね。 Starmanの場合は
2013年4月に行った Perl5 Census Japan 2013から「YAPC::Asia Tokyoで聞いてみたい話はありますか」という設問に対しての答えを一部抜粋、編集したもの。かぶっている内容は、それが登場した回数がわかるようにわざと出してます 募集時のエントリ：http://lestrrat.ldblog.jp/archives/26619095.html 集計時のエントリ：http://lestrrat.ldblog.jp/archives/27060688.html
運用 開発が終わった後のデプロイ方法や監視方法 パッケージングやアプリケーションのデプロイメント、パフォーマンスチューニングなど daemontoolsなどの管理ツールをServer::Starterをかまして実際の運用でどうやって使っているのかなど Perlを使う時に一番困るのは、言語そのものではなく運用環境だったりします。PHPはmod_phpですぐに動くのですがperlの場合、mod_perlは時代遅れな雰囲気ですし、ModPerl2::Registryなど設定しないとapache handlerを実装しないといけないので敷居が高い。daemontoolsやStarletを使うための設定やrunファイルなどの情報はちょっと調べた程度では出ませんし、古かったりします。このあたり優れたインフラエンジニアやオペレーションエン>ジニアがいれば問題ないのですが、ほとんどの会社でそんな人はいませ
Upstart を使ってお手軽 daemon 化
こんにちは。斎藤です。 手元でちょちょいと作ったプログラムや、 init スクリプトの無いOSSを daemon として動作させ続けたい事、ありませんか？そんなときに便利なのが Upstart です。daemontoolsの代わりとしても使えます。 今回は設定方法を中心に、解説していきます。 ※CentOS 6.3 (x86_64) で検証しています はじめに Upstart とは何か UpstartのWikiによると、"/sbin/init"デーモン(例えばSysVinit)を置き換えるものであり、イベントベースでタスクやサービスを起動・停止できるようにしたものである、と述べられています。また、特徴として、SysVinitと比べ「設定が簡単」「起動が早くなる」などが挙げられています。 Upstart のメリット 3つのメリットがあると、私は考えています。 起動・終了制御が容易 仮にABE
スーパーサーバーSupervisorの導入手順メモ | Glide Note - グライドノート
daemontoolsの代替として最近使い出したスーパーサーバーSupervisorの導入方法をいつも忘れるのでメモ。ほとんど@hibomaが社内Wikiにまとめてた内容のパクリですが、自宅サーバ構築とかで外から見ようと思っても見えないので。いつもありがとう、ひろやん!! 導入環境はScientific Linux 6.1です。(Upstart経由での起動の部分を、init経由での起動にすればCentOS 5系でも動作するかと思います) Supervisorの導入 easy_installでも良いんですが、pipで導入 sudo yum -y install python-setuptools sudo easy_install pip sudo pip install supervisor log用ディレクトリと、conf用ディレクトリを用意 デフォルトだと/tmp配下にログが吐かれる
Plack時代のReverse proxyによるサーバー運用方法 ~YAPC::Asia2010の復習(後編)~ | hirobanex.net
後編を書く前に、YAPC::Asia2011が終わってしまったので、変な勘違いをされるかとやめようかと思ったのですが。。。とりあえず、YAPC::Asia2010の復習として、Plack時代のPerlによるサーバ運用では、わりと一般的なリバースプロクシによる運用を、このブログの実例で報告します。 前置き:plackupはわかったけど、実際どうするの? 「Perlは遅い」の原点だったApacheのcgi時代は終わりを告げ、Apacheに依存したmod_perl時代も終りを告げました。Plackを使えば、CGIだろうとmode_perlだろうとPerlのスタンドアローンサーバーであろうと、かなり汎用的に動かせる時代です。mod_perlとかFastCGI前から使っていれば、あるいは、「Rubyではふんふん、Pythonではふんふん」とか語れれば、いろいろな歴史をしっているからすぐ実践しやすいと
perlbrew の環境で daemontools を使うためのメモ - punitan (a.k.a. punytan) のメモ
既出かもしれないけれどもメモ。 perlbrew で構築した環境で /usr/bin/perl と ~/perl5 のバージョンが違う場合 run スクリプトで環境変数を export してあげないと perlbrew の利点を活かしきれない。ちなみに bash を中心に扱っているので、自分の環境に合わせて読み替えてください。 run にどう書くか perlbrew init したときに ~/.bashrc に追記した source の行があるはずなのでそれを辿って export を run にコピペしてやればよい。 手元の環境では $ cat ./bashrc ..snip... if [ -f /etc/bash_completion ]; then . /etc/bash_completion fi source /home/puny/perl5/perlbrew/etc/bashr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
