capistrano-bundle_rsyncを利用したデプロイ方式に変更しました - LCL Engineers' Blog
Webエンジニアの森脇です。LCLでは、Capitranoを利用してRailsアプリケーションのデプロイを行っていましたが、「capistrano-bundle_rsync」を利用する方式に変更しましたので、背景含めて紹介いたします。 デプロイの概要 capistranoを利用したデプロイでは、デプロイサーバではcapistranoを実行し、各Webサーバへsshでログインし、各種デプロイ関連処理を行います。 このデプロイ方式では、以下の問題がありました。 デプロイ中は各Webサーバのリソースを多く消費してしまうため、アクセスが多いときはデプロイができない デプロイ時間が、Webサーバのスペックへ依存してしまう。 そこで、デプロイサーバでbundle install,precompileを行い、各Webサーバにrsyncで配布する方式に変更しました。 実現方法 capistranoを拡張し
capistrano + nginx + Rails 環境で簡単にメンテナンス画面を表示する方法 - Qiita
はじめに サーバーのメンテナンス中には、503レスポンスと一緒にメンテナンス画面をレスポンスすることが多いと思います。 nginxのレイヤーで503レスポンスとメンテナンス画面を表示する仕組みと、それをcapistranoで操作する仕組みを作りました。 今まで、nginx + unicorn な環境でメンテナンスモードにするときには、いちいちnginxのnginx.confをいじって出していました。 綺麗ではないですし、オートスケール環境の時は全てのサーバーのnginx.confを修正するのも現実的ではないです。 ということで、capistranoで、 を実行すると、元に戻る機能を作ってみました。 turnoutというgemを使うとメンテナンス画面を簡単に出すことはできますが、turnoutの場合は、メンテナンスモードであってもRailsへアクセスしてメンテナンス画面を表示します。 例えば
CentOS7, Ruby on Rails 5, PumaでProducrion環境構築@VPS + Capistranoでのデプロイ - Qiita
CentOS7, Ruby on Rails 5, PumaでProducrion環境構築@VPS + CapistranoでのデプロイRubyRailsCentOSCapistrano はじめに プライベートでサービスを立ち上げるときには、今まではいつもherokuを使っていました。herokuはすべてがサービス化されていてすごい楽なんですけど、反面、コスパが悪くて、ちゃんとプライベートのサービスやるには向かねーなあって思ってました。 そんなわけで重い腰を上げて今回からは自分でVPSを使って環境構築してみることにしました。自分はサーバ設定まわりがとても苦手で、かつ、まとまった情報もあまりネットになく、けっこう苦労したので、普段qiitaとか書かないのですが、せっかくなのでまとめておきます。 CentOS7 + Ruby on Rails 5 + Pumaで動作。Capistranoでのデ
インフラ初心者がNginx+PumaのRails5アプリケーションをCapistrano3でデプロイした話 - Qiita
この記事はフロムスクラッチ Advent Calendar 2016の14日目の記事です。 プロローグ 上司（@idobee） 「明日からインフラチームで新しいアプリケーションのデプロイ周り整備してね。」 部下（@nrk_baby） 「はい、承知しました。」 こんなノリで現在新たに開発しているアプリケーションのデプロイ周りを整備することになりました。 ちなみに、筆者(@nrk_baby)自身はインフラ関連を専門的にやったこともなければNginxとApacheの違いも説明できませんし、PumaとUnicornの違いもよくわかっていない状態でした。 やったこと Capistrano3を使ってRails5アプリケーションをAWSのEC2インスタンスにデプロイし、ブラウザからアクセスしてアプリケーションが動作しているところまで確認しました。 色々とググりながら進んだものの、PumaとRails5と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
