3

Railsアプリ（ deploy_revisionを使用）をデプロイするためにCapistranoからChefに移動していますが、ベストプラクティス（または一般的なプラクティス）の問題がわかりません。グーグルであまり見つけられませんでした。

Capistranoと「プッシュ」モデルを使用すると、アプリケーションを複数のサーバーにデプロイするときに、デプロイメントの失敗がいつ発生したかを簡単に認識し、すべてのサーバーに一度にデプロイメントをロールバックできます。Capistranoはまた、各アプリサーバーにメンテナンスページを表示し、すべてのサーバーに正常にデプロイするか、デプロイメントをロールバックしない限り、そのメンテナンスページを削除しません。

Chefと「プル」モデルでは、各サーバーがわずかに異なる時間に更新をフェッチしている可能性があります。データベースサーバーがアプリケーションコードを更新し、アプリケーションサーバーよりも数分早くデータベース移行を実行することになりかねません。したがって、障害を特定し、ビルドが（すべてのサーバーで）最後に正常にデプロイされたバージョンにロールバックされることを確認するための優れた方法は本当にありません。

私はここにいくつかのオプションがあることを知っています：

  1. chef-clientをデーモン化しないでください。cronを使用して毎晩または毎時実行します。（一部のサーバーが成功し、1つだけが問題に遭遇した場合でも、すべてのサーバーにロールバックすることはできません。）
  2. chef-clientをデーモン化しないでください。deploy_revisionは使用しないでください。ナイフsshまたはcapistrano-chefを介して実行します。（シェフの魅力の一部である「プル」モデルではなく、「プッシュ」モデルに戻りました。）
  3. chef-clientをデーモン化し、相互に通信するカスタムレシピを作成します。（熱心ではありません。）
  4. リラックス。ご心配なく。エラーを発生させてから修正します。（ここでもわくわくしません。）

これらのいずれかを構築し始めることができましたが、構築に多くの時間を費やす前に、フィールドでの大規模な展開で何が機能したかを知りたいと思っていました。あなたは何をした？

4

2 に答える 2

3

プルは、構成のドリフトの問題に対処するのに適しています。オンデマンドでの展開（および潜在的なロールバック）には、プッシュの方が適しています。これらをチェックしてください（私はそれらを使用していません）：

https://github.com/etsy/deployinator

http://www.rackspace.com/blog/rackspace-open-sources-dreadnot/

于 2013-01-09T05:56:18.913 に答える
1

シェフのdeploy_revision戦略を介してRORアプリをデプロイしましたが、少し成功しました。プル戦略のタイミング制御の制限を克服するために行う最も簡単なことは、次のように要約されるデプロイスクリプトを作成することです。

  • chef-clientを停止します（デーモンが処理を行わないようにするため）
  • chef-clientを手動で実行します（これによりデーモンも再起動します）

または、怠惰な場合は、実行するだけでchef-clientデーモンについて心配する必要はありません。

次に、を使用knife-sshして、該当するノードでこれらのコマンドを実行します。最終的には、デプロイに関連するすべての構成がchefによって管理されますが、必要に応じてデプロイを開始できます。

ボーナスポイントについては、これらすべてをJenkinsタスクにパッケージ化します。jenksをchefクライアントとして構成し、アプリのプロジェクト内で「DeploytoStaging」タスクを作成する必要があります。これで、クリックしてタスクを実行でき、シェフを話さないチームメートが簡単にデプロイを実行できます。さらに多くのボーナスポイントを得るには、ビルドが成功した後に自動デプロイするようにjenkinsをセットアップしてください！

于 2013-03-01T20:02:56.557 に答える