ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
Passenger + monit でリリース作業をより簡単にする方法 - よかろうもん！
PassengerでRAILSアプリを運用しているなら、アプリのリリース時には、${RAILS_ROOT}/tmp/restart.txt を配置/更新することで、ほぼダウンタイム無し(httpdの再起動なしのため)にリリースしているかと思います。 ただ、アプリケーションのソースコードの影響範囲が、Railsアプリのみだけなら、restart.txtの仕組みだけでよいかもしれません。しかし、パフォーマンスを考慮し非同期処理を行うためにdelayed_jobを利用していたり、メール送信流量を制限するためにar_sendmailなどを利用している場合は、それぞれのデーモンの再起動を行う必要があります。 ＃delayed_jobについては、id:mat_aki(@mat_aki)が紹介している「Railsで非同期処理を行うには"Delayed_job"がおすすめ」がわかりやすいと思います。 その
アプリケーションに依存するバッチを"アプリケーションで自動生成"してcronに登録する方法 - よかろうもん！
バッチ処理で一括処理を行うようなアプリケーションは多いかと思います。 ですがこのバッチ処理の設定をするときに、以下のようなシーンで悩まされることが多々あります。 マニュアル関連の問題として、 マニュアルを読みあさらないとわからない バッチに関する情報が更新されていない 運用に発生しがちなミスとして、 開発者と運用者の間の情報共有でバッチに関する情報が抜け落ちていた などがあります。 これらは、情報の散乱/更新忘れ/伝達ミスなどで発生しますが、もしこれらのバッチ処理に関する情報を"アプリケーションで管理しておき、そのバッチ処理の設定作成までをアプリケーション開発者に任せ、コマンド一発で自動的に設定を生成することができれば"前述したような課題は解決するはずです。 この課題を解決するツールに、"whenever"という gem があります。 ではさっそく、使い方の解説を。 はじめにgemをインス
GOD - mongrel監視
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
クックパッドのシステム構成 « クックパッド開発者ブログ
クックパッドのhashikemです。 弊社でも開発者ブログを始めることになりました。よろしくお願いします。 初めての記事なので、軽くクックパッドのシステム構成を説明します。 まず、OSはCentOSを使用しています。いざというときにRedHatに乗り換えられることを重視しましたが、CentOSのままの運用で、無事に現在にいたっています。 フロントのWebサーバはApache2.2です。nginx など、他の可能性も考えたのですが、mod_proxy_balancer, mod_rewriteなどの運用経験から、Apacheを使用しています。 アプリケーションはRails2.0です。以前はColdFusionで独自のフレームワークを作って構築していたのですが、アジャイルさを追求したフレームワークであるというメリットに惹かれてRailsへと移行しました。 各アプリケーションサーバでmongre
連載：オープンソースなシステム自動管理ツール Puppet｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
ヽ( ・∀・)ノくまくまー(2007-06-05)
● 1. 一戸建てタイプ そのアプリ用に専用のマシンを準備できるケース。例えば、アクセス数が少ないβリリース時などは mongrel を直接80ポートで運用することもあるだろう。そして、負荷の増加、またはマルチコアを活かすという次の段階で、cluster 化した mongrel を扱う必要に迫られた場合、このタイプになる。この場合、フロントの仕事はバック(Rails)への割り振りだけだが、そのためにわざわざ Apache2 を持ち出すのは仰々しいと感じるかもしれない。そんな人にお奨めしたいのが Pound サーバだ。いきなり Apache から話が逸れてしまうが、このケースだとリアルでお奨めである。 Pound + mongrel Pound はリバースプロキシ用のWebサーバであり、特化しているだけあって、必要最低限かつ直感的で簡単な設定で済むため、敷居が低いのが魅力だ。それでいて、デジ
ウノウラボ Unoh Labs: RackでWebアプリのWebサーバー依存を無くす
rack-logo posted by (C)komagata komagataです。 仕事でも使う必要が出てきたのでRubyの勉強をしています。WebアプリケーションでRubyを使おうとしていきなり躓いたのがApache、WEBrick、Mongrel等、実行環境毎の設定やAPIの違いです。 Rubyを普段使っている人には常識過ぎるのか情報が少なく、FastCGIで単に「Hello, World」を表示させるのにも一苦労でした。（Railsでは簡単に動くのが悔しい） そんな実行環境毎のAPIの差を吸収してくれるRackというライブラリを知ったので試してみました。 RackはRuby版WSGIと呼ばれているそうです。WSGIとはWeb Server Gateway Interfaceの略でWeb ServerとWeb Applicationの間のInterfaceを定めたPython界の仕
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
We Ain't Seen Nothin' Yet. : Railsの運用方法紹介ページまとめ