AWS Elastic Beanstalk で Rails3アプリをデプロイするまで
まだ資料が少ないようなので、備忘録を置いておきます。 環境： Mac OS X 10.8 Mountain Lion ruby 1.9.3p194 Rails 3.2.8 おおまかなステップ 1.Elastic Beanstalk の利用登録（AWSへのユーザ登録） 2.Beanstalk の設定（AWSのウェブGUI） 3.eb（AWS Elastic Beanstalk Command Line Tool ）のインストール（ローカル環境） 4.Railsアプリのデプロイ 5.EC2インスタンスの設定（SSH接続） 1.Elastic Beanstalk の利用登録（AWSへのユーザ登録） 1-1.Amazon Web Serviceからサインアップ。以下略。 2.Beanstalk の設定（AWSのウェブGUI） 2-1.AWS Management Console から Elasti
Rails 初心者が Capistrano3 で AWS EC2 にデプロイするためにがんばったこと。 - Qiita
追記 http://qiita.com/kizashi1122/items/6e22b2a27fa4da487884 に更新版を載せました。 はじめに 最初に構成ですが、以下のとおりです。 クライアント Mac 上の仮想環境(CentOS) Capistrano3 もここで動きます サーバ EC2(AWS) 構成管理 Github ミドルウェアは、以下のとおりです。Nginx は yum でインストールしておいてください。 Nginx Unicorn Capistrano3 で、クライアントからコマンド一発でサーバにデプロイすることを目的としてます。 しかし、Capistrano3 や Unicorn 関連の情報は Web 上にたくさんあり、それぞれ少しずつ設定が違ってたりして部分的につまみ食いすると設定に食い違いがでてしまって動かなくなります。 私はまだまだ初心者ですがとりあえず動くとこ
opsworksでnginxのログをltsvで出力する - Qiita
場面 nginxのログをtd-agentでtailするときにltsvにしたい 見るところ log_formatの定義箇所 https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/nginx/templates/default/nginx.conf.erb#L15-L17 定義したlog_formatを呼び出す箇所 https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/unicorn/templates/default/nginx_unicorn_web_app.erb#L9-L15 やってみる stack settingsのcustom jsonいじるだけでできる。必要なのは2点。 node[:nginx][:log_format]["<
OpsWorksの予期せぬ挙動に備える - Qiita
この記事の問題はopsworks-agentが自動でアップデートされてしまうというのが原因で引き起こされていましたが、現在（2015/07/06）は手動で利用するバージョンを指定してアップデート出来るようになったのでこの記事の問題が置き無さそうです！！ヨカッタですね！！ http://blogs.aws.amazon.com/application-management/post/TxLZ972TREEZ4A/Manage-agent-updates-on-AWS-OpsWorks-managed-instances OpsWorksを利用していて意図せず本番環境のRubyのバージョンが上がってエラーが出るという障害に遭遇してしまったので詳細を共有します。 TL;DR OpsWorksは、こちらが意図しないタイミングでサーバー内に保存されているCustom Cookbooksを最新に更新し
【中級編】drone.io + exrmで今日から始めるElixir on Phoenixホットデプロイ入門 - Qiita
何これ？ 皆さん、おはこんばんちは。 前回の記事、CentOS + Erlang + Elixir + PhoenixのDockerイメージで今日から始めるElixir on Phoenix入門に引続き、Elixir/Phoenixについての入門記事です。 入門なのに中級編です。 今回は前回の予告通り、deployとci周りをやっつけます。 これができれば、Elixir/PhoenixでHello Worldは卒業して、 実際の開発をしていけると思います。 ゴールは、 プルリクでCI回してテストする プルリクをmasterにマージする リリースビルド作る GitHub Releases使って、tag切って実稼働用のバイナリ上げる ホットコードスワップ（ホットデプロイ）本番環境を無停止で更新する という一連の流れを全てGitHubのプルリクとマージだけで行うことです。 Jenkinsのように
AWSでデプロイとスケーリングを自動化する方法まとめ - Qiita
概要 AWSではアプリケーションのデプロイや、システムのスケーリングを自動化することができます。 しかしそれらを実現しようとすると、似たようなサービスの中から用途に合ったものを選ぶ事になると思います。 今回は選択肢となり得るサービスを挙げて、それぞれの出来る事、出来ない事をベースに比較していこうと思います。 比較の軸 以下のように、評価軸を設けました。 サービスの機構として提供されているものは◯とします。 機構として提供されているが、使い難いものは△とします。(例: AWS CLIを利用した場合のみ利用可能など) 機構としては提供されていないが、別の機構などを組み合わせることで容易に実現可能なら△とします。 別の機構などを組み合わせても辛い場合や、実現不可能なら×とします。 デプロイ自動化 まずはアプリケーションのデプロイを自動化するサービスの比較を行います。 以下の4つの選択肢があります
チャット経由でデプロイする[新編] - Qiita
Rubotyを利用してチャット経由でデプロイする方法を示した チャット経由でデプロイする - Qiita の続編です。 デプロイ方法 おさらいしておくと、デプロイ自体はr7kamura/ruboty-githubでやっている。あらかじめ1vs1チャットでQiitanにGitHubのアクセストークンを教えておくと、教えてくれた人の命令に従って、Pull Requestを作ったりMergeしてくれたりするようになる。デプロイしたいときはQiitan経由でmasterからproductionブランチにPull Requestを出す。Pull RequestがMergeされてproductionブランチが変更されると、Circle CIがデプロイを始める。 デプロイ禁止 最近ちょっと進化して、サーバがおかしいとかでデプロイを禁止させたいときに止めてくれるようになった。ある発言を別の発言として認識す
チャット経由でデプロイする - Qiita
最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育
Hubot と Jenkins をつかって heroku への Deploy 環境を用意した - Qiita
はじめに 過去に Hubot と CircleCI をつかって Heroku への Deploy 環境を用意したネタを投稿したことはありましたが、体験期間を過ぎてしまったので Jenkins server を用意して CI 環境を用意しました 前提な話 これをやるために必要な環境とかその辺の話 Jenkins server (VPS) ローカルとかでもいいけど hubot でみんなが使えるようにしたかったので vps にしました 構築系の話は他にわかりやすい資料がたくさんあったので今回は割愛します GitHub ぎっはぶぎっはぶ Hubot 動作環境 (Heroku) hubot を vps におけばいいじゃないかってなりそうだけど個人的なサービスを Heroku で公開していくことを想定して Deploy 環境を VPS にしてそこから Heroku へ Deploy できるようにしたい
HerokuにデプロイしたHobotをIdlingさせない方法 - Qiita
HubotをHipchatやIdobataなどのチャットと連携して利用すると、GithubやTravis、New Relicなどのサービスからの通知をチャットで受け取れて便利です。 その際のデプロイ先としてHerokuが非常に便利なのですが、放置しているとアイドリングしてしまいます。 それでは困るので定期的にリクエストを飛ばすスクリプトを書いて対応していたのですが、もっと簡単な方法があったので紹介します。 Herokuの環境変数HEROKU_URLにHubotのデプロイ先のURLを設定するだけです。 処理はHubotのrobot.coffeeに書いてあり、HEROKU_URLが設定してあれば20分に1回 http://yourapp.herokuapp.com/hubot/pingにPOSTするようになっています。 https://github.com/github/hubot/blob/
プライベートリポジトリを激安にCI出来るCircle CIが凄い。 - Qiita
@takehiro に教えて貰ったCircle CIを使ってみるともの凄く良くて、とてもお勧めなので記事を書きました！ Circle CIって何？ Travis CIと同機能でWebでのUIが若干違うサービスです。 CIとしての仕事はきちんと行えます。 Circle CIの使い方 https://circleci.com/ にアクセスします。 Githubアカウントでサインアップを行います。 画面に従って進むとプロジェクトをfollowする画面が表示されます。 CIしたいプロジェクトをfollow後、"Done Managing Repos"をクリックします。 ここでは"camelmasa/spree"を選択します。 するとfollowしたプロジェクト一覧のテスト結果の画面が表示される様になります。 これでCIが出来る環境が整いました！ 後はgithubにpushする毎にCIが実行される様
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scala+PlayでAmazon Elastic Beanstalkの開発 - Qiita
sidekiqの使い方 - Qiita
【mkdirからデプロイまで3分】Sinatra+Haml+Sass+Coffee でサクッとHerokuに公開して捨てるwebアプリ - Qiita
Node.jsのアプリをHerokuにデプロイするときポート番号に気をつけなくちゃいけない - Qiita
デプロイツールfabric+cuisineで冪等性保証 - Qiita
Herokuに手っ取り早く静的サイトをデプロイする(node版) - Qiita
