![http://kwatch.houkagoteatime.net/blog/2014/12/20/postgresql-features/](https://cdn-ak-scissors.b.st-hatena.com/image/square/db604e58ab94cc004d52e3ee4940586d0420c0fc/height=288;version=1;width=512/http%3A%2F%2Fimage.gihyo.co.jp%2Fassets%2Fimages%2Fcover%2F2014%2Fthumb%2FTH160_9784774167091.jpg)
こんばんは。クライアントワーク(受託開発)チームのnobu_ohtaです。 この記事は tech.kayac.com Advent Calendar 2014 17日目です。 この記事では、弊社クライアントワーク(受託開発)チームで production 環境で Rails の database.yml と secrets.yml をどう運用しているかを紹介したいと思います。 この話題最近ちょくちょく見かけますが、@mirakuiさんがやっているPodcastの Admins Bar #3: Fluentd, Rails, ActiveRecord でも取り上げられています。 なぜ機密情報をハードコードしないほうがいいか Rails 4.1からsecrets.ymlやdatabase.ymlで機密情報は直書きせずに環境変数から読む設定ファイルが生成されるようになりました。 アプリのリポジト
イントロ CircleCI からテストが通ったら capistrano 使って deploy させたい。 けど、対象サーバーは IP 制限がかかっている。CircleCI の IP なんてコロコロ変わるし、どうしたらいいんや... って話。 これができると、PR を github ボタンでマージしたら、自動(当然テストも通した後)で deploy されるので、非常に嬉しい。 方針 before deploy awscli を使い security group の inbound に自分自身の ip を付与 CircleCI の内部から IP address を割り出して、コマンドラインで一時的にinboud に追加させる deploy コマンド(bundle exec cap deploy)を実行 after deploy awscli を使い security group から ip を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く