
capistrano を使用したデプロイのベストプラクティスを探しています。
まず、私が以前どのようにデプロイメントを行っていたかについて簡単に説明したいと思います。
capistrano は開発者のコンピュータにローカルにインストールされています。capistrano オプションを使用してゲートウェイを展開します:gateway
。最初は、オプションを使用するとゲートウェイホストへの ssh 接続のみが必要になると考えていました:gateway
が、ssh 接続が必要であることがわかりました (公開鍵) をデプロイ先となるすべてのホストに送信します。
アプリケーションをデプロイするための便利で安全な方法を見つけたいと思います。
例えば、新しい開発者が仕事を始める場合、彼の公開鍵ゲートウェイサーバーのみで、すべてのアプリケーションサーバーではありません。一方で、特定のサーバーへの接続は許可しません。sshゲートウェイの場合、開発者であるために、デプロイメントのみを行う必要があります。
capistrano を使用したデプロイのベストプラクティスをご存知の場合は、ぜひお知らせください。
答え1
Capistrano は、ssh がすべての管理の基盤であるという前提で最初から設計されています。ゲートウェイとして使用されるマシンは、ssh 接続の受け入れと発行の両方を行う必要があります。これを回避する方法はありません。開発者はゲートウェイへの ssh アクセスを取得します。
いくつかの要件があります:
- デプロイメントターゲットの承認済みキーリストに新しい開発者を簡単に追加できます
- 開発者にゲートウェイボックス上の完全なターミナルを提供したくない
デプロイメント ターゲットのキー処理方法を決定する必要があります。ここでは、主に 2 つのオプションがあります。
- 汎用キーを使用すると、全員が 1 つ取得し、それがイメージ/ターゲットに焼き付けられます。
- 特定のキーを使用すると、全員が独自のキーを取得し、authorized_keysリストを次のように管理します。傀儡またはシェフ。
2 番目のオプションは最も安全ですが、構成管理システムが導入されている場合に最も効果的です。構成管理システムは必ず使用してください。ゲートウェイ サーバーの authorized_keys ファイルも提供できます。
開発者がシステムに SSH 接続した後に実行できる操作を制限するオプションがいくつかあります。
Capistrano がゲートウェイで実際にどのように動作するかに応じて、これらのうちのいくつかが動作を妨げる可能性があるため、テストが必要です。機能するには完全なシェルが必要な可能性があります。