トップ «前の日記(2015/10/21 (水) ) 最新 次の日記(2015/10/23 (金) )» 編集 RSS feed

HsbtDiary


2015/10/22 (木) [長年日記]

rails の pull 型デプロイへの質問

昨日の発表直後は時間がなくて質問への受け答えがあまりできなかったんですが、発表後にぶらぶらしていた時にもらった質問が鋭い内容だったので紹介します。

  • No SSH ポリシーは反発もでたり、チームへの浸透は難しいのではないか
  • minne チームは選任のインフラエンジニアがおらず、アプリケーションの開発チームが兼務してインフラを作っていたので、コードでインフラを作るというのはすんなりと受け入れられた(と思う)
  • pull 型デプロイだと、更新漏れが起こったり、あるサーバーだけが調子わるくてデプロイが失敗したということが起こった時の検知が難しいと思うんですがどうやってますか
  • その通りで問題は把握しているがまだ具体的な解決策は作れてない状態。デプロイ後にコードのリビジョンなどを kvs に突っ込んで、サーバーすべてが更新されたことを検知してアラート、というような仕組みを考えている
  • stretcher のデプロイって一部だけですか?
  • サーバー全部です。もう稼働していて、チームのエンジニア、デザイナ全員が使ってます。つまり、全サーバーで consul と consul watch が動いてます。
  • 安定してますか?
  • 安定しています。
  • db:migrate とかどうやってますか?
  • 踏み台サーバーや staging にコードをデプロイして db:migrate だけ個別に実行しています。最初にカラムを消すとアプリケーションでエラーになることがあるので、削除は最後にするなどコードとの整合性をうまく調整しながら進めてます。

この cap task 群、OSS で公開したいなと思ってるんでもうちょいお待ち下さい...(微妙に密結合している箇所がある)

本日のツッコミ(全2件) [ツッコミを入れる]
# sorah (2015/10/23 (金) 02:02)

pull型、うちもプロセス自体のリビジョンとファイルシステムにある最新のリビジョンがズレてるとか、サービス全体でなんか複数のリビジョンあるんだけど、っていうので監視してるなー。

# hsbt (2015/10/23 (金) 10:49)

>うちもプロセス自体のリビジョンとファイルシステムにある最新のリビジョンがズレてるとか、サービス全体でなんか複数のリビジョンあるんだけど、っていうので監視<br><br>勉強になる〜