AWS マネージド サービスで最も近いのはCodeDeployです。これにより、コマンド ラインまたは Web コンソールを介してEC2インスタンスでのデプロイを調整できます。しかし、これまでのところ、 CodeDeployはS3またはGitHubからアーティファクトをプルするだけです。今では、CodeCommitはCodePipelineやCodeDeployなどの他の関連する Amazon サービスから完全に分離されているように見えるため、適切な選択ではないようです。しかし、もちろん、Amazon のロードマップはそれらすべてを統合することです (これを行わないと意味がありません)。したがって、現時点では、 CodeCommitよりもGitHubを使用した方がよいでしょう。
しかし、GitHubを使用していないことを考えると、リポジトリとCodeDeployの間にCI (継続的インテグレーション) ソリューションが必要です。ソースからコードをプルし、おそらくテストをビルドまたは実行し、それをS3にプッシュしてCodeDeployに伝えます。たとえば、これを行うことができ、多くの外部サービスと統合できるCodeShipがあります。または、 Jenkinsのような独自のCIサーバーを使用して、その「接着剤」の役割を実行することもできます。(Jenkins はオープンソースであり、すべてのプラグインを備えている可能性があるため、おそらく最も柔軟なものになるでしょう。)
したがって、少し分解すると、ワークフローは次のようになります。
- コードをリポジトリにプッシュします。
- イベント (ブランチへのコミット、または新しいタグ、構成可能である必要があります) が発生するたびに、CIはそれをプルし、必要または必要なものを実行 (ビルド、テスト、パック) し、S3にプッシュします( tarball ファイル、通常);
- 設定方法に応じて、CIはCode DeployにEC2インスタンスにすぐにデプロイするよう指示するか、利用可能な新しいバージョンがあることを伝えるだけで、Web コンソールの CLI を介してデプロイを手動でトリガーできます。いつでも。
(実際には、CodeDeployはコードをEC2インスタンスにプッシュしません。代わりに、各EC2インスタンスは、ローカルに適用する新しいものがあるかどうかを知るために、 CodeDeployサーバーを定期的にプールするエージェントを実行する必要があります。とにかく、CodeDeploy は調整し、エージェントからフィードバックを取得します。であるため、 CodeDeploy側では 100% アクティブで、インスタンス側では 100% パッシブであるかのように機能します)。
最も「クリーンな」AWS ソリューションはCodeCommit -> CodePipeline -> CodeDeploy、または単にCodeCommit -> CodeDeployですが、これらのサービスは現時点では完全に統合されていません。
あなたの場合、現在最も単純で実行可能なソリューションはGithub -> CodeDeployです。それと異なるものは、私が提供した例(CodeShip、Jenkinsなど)のように、途中でいくつかの中間ステップが必要になります。