AWSのCI/CDパイプラインを始める方法
もし現在、すべてのサーバーを最新の状態に保つためにシステム管理の面で苦労しているのであれば、肩の荷を軽くする時が来たかもしれません。継続的デプロイメントパイプラインを使って配信プロセスを自動化してみてください。
CI/CDとは何ですか？
継続的インテグレーション、継続的デリバリー（CI/CD）は、頻繁（しばしば毎日）のコード更新を行い、新しいリリースを構築・テストし、変更を迅速かつ効率的に本番サーバーに展開することに関するものです。
これは、DevOps文化の核心を包括する非常に広い用語です――開発者の頭の中から新しいコードをサーバーに流し込むプロセスを合理化します。通常、CI/CDはパイプラインと呼ばれるツールキットを使用して実装され、これはソースからデプロイメントまでの全プロセスを自動化するツールのセットです。
これはAWSがそのCodeSuiteツールで提供するもので、特にそのようなパイプラインを実装するのに適した位置にあります。なぜなら、通常あなたのプロダクションサーバーはEC2上で稼働しているため、デプロイメントステージがより簡単で統合されるからです。
AWSのCodeSuiteツール
CodeSuiteは、いくつかの異なるツールで構成されています。最初は、AWSの管理されたソース管理サービスであるCodeCommitがあります。競合他社に比べて少し使い勝手が悪く、機能も豊富ではありませんが、複数のリモートを持つGitの設定が簡単なので、パイプラインの残りを使う予定があるなら、利用する価値があります。CodeCommitは非常に寛大な無料使用枠があるため、あまり料金が発生しないでしょう。
次はCodeBuildです。これは、ソースコード管理をCodeCommit（またはGitHub/BitBucket）から取得し、ソースからビルドを行い、プロセス中に提供したテストを実行します。ビルドにはEC2サーバーを使用し、ビルドが実行されている間はその費用を支払う必要があります。複雑なプロジェクトでは、迅速なビルドのために強力なマシンが必要な場合があります。
ビルドが完了すると、アプリケーションはデプロイメントの準備が整います。この段階はCodeDeployで処理されます；「デプロイメントグループ」を作成し、その中に任意の数のEC2インスタンスまたはオートスケーリンググループ全体を含めることができます。ここがAWSのパイプラインが本当に光るところです。
CodeDeployを使用すると、デプロイメントの処理方法を微調整できます。一度に全て、半分のグループ、数分ごとに10％などのプリセットがあり、これらはすべて、予期しないバグによるアプリケーションのダウンタイムを最小限に抑えるために設計されています。すべてのサーバーが自動的に更新されるのは素晴らしいことですが、CodeDeployはロードバランサーに接続して、更新中のインスタンスへのトラフィックを削減することもできます。健康なホストの最小数を確保するための段階的なロールアウト戦略と組み合わせることで、プロダクションの更新はストレスフリーになります。
これらすべては単一のパイプラインにまとめられており、ソースコントロールを監視し、リリースブランチに変更をプッシュするたびに自動的にパイプラインが実行されるようにトリガーされます。これにより、コードがすべてのサーバー上にビルド、テスト、デプロイされます。
パイプラインの設定方法
まず、コードをCodeCommitにアップロードする必要があります。CodeCommitをプライマリソース管理の他に別のリリースリモートとして設定することをお勧めします。GithubやBitBucketを使用している場合は、代わりにリポジトリに直接接続できますが、CodeCommitは完全にAWSのソリューションであり、IAMコンソールを通じてサーバー更新への組織のアクセスを管理することを可能にします。
次に、CodePipelineコンソールに移動して始めましょう。「パイプラインの作成」をクリックし、名前と説明を入力します。
パイプラインの各ステージにはいくつかの設定が必要です。最初はソースステージで、CodeCommit、Github、BitBucketに接続します。後の二つはOAuthを介してアカウントを接続する必要がありますが、CodeCommitは直接接続します。使用しているリポジトリとリリース用のブランチを選択してください。CodeCommitをセカンダリリモートとして使用している場合は、ここでマスターを選択することになるでしょうが、サードパーティのプロバイダーを使用している場合は、別のリリースブランチを設定したいかもしれません。
ブランチオプションの下に、このパイプラインが自動的に実行される設定があります。デフォルトでは、指定したリリースブランチに新しいコミットがプッシュされるたびに実行されます。これを変更することもできますが、おそらくこれが望ましい設定です。
次は、ビルドステージです。CodePipelineは、Jenkinsと組み込みのCodeBuildの両方をサポートしています。すでにJenkinsをビルド用に使用している場合は、AWSに接続するためにCodePipelineプラグインをインストールする必要があります。それ以外の場合は、「プロジェクトを作成」をクリックしてダイアログを開くことでCodeBuildを設定できます。
CodeBuildには設定することがたくさんあるため、セットアップに関するガイドを読んで、詳細を学ぶことができます。完了すると、ダイアログは閉じてCodePipelineのセットアップに戻ります。
次のステージはデプロイメントです。CodePipelineは、いくつかの異なるデプロイオプションをサポートしています。特に、AWS CloudFormationやElastic Container Serviceを使用している場合は、それらに直接更新をデプロイできます。一般的なEC2およびLambdaのデプロイには、CodeDeployを使用する必要があります。
CodeDeployは多くの設定を必要とするため、設定を行うための完全なガイドを読むことができます。簡単に言うと、EC2サーバー、オートスケーリンググループ、またはLambda関数で構成されるデプロイメントグループを作成し、デプロイメントの設定---すべて一度に、半分一度になど---を選択します。CodeDeployはそれ以外のすべてを処理し、トラフィックが更新中のサーバーにルーティングされないようにロードバランサーを調整し、常に健康なホストの数を維持することで、サービスが更新のためにダウンしないようにします。
完了したら、CodePipelineに戻り、設定したデプロイメントを選択します。これで全ての設定が完了し、次に進んでパイプラインを起動する前にレビューすることができます。
パイプラインを作成すると、最初のビルドが自動的に実行されます。ビルド中にエラーが発生した場合、パイプラインは停止し、サーバーは更新されません。
ソースコントロールで新しいコミットを作成することで、パイプラインの更新検出をテストできます。すべてが問題なければ、パイプラインは自動的に再度開始し、変更をサーバーに展開します。
パイプラインはいつでも戻って編集できますし、CodeBuildやCodeDeployの設定を調整することもできます。ビルドエラーが発生している場合は、buildspecファイルがすべてを正しく処理していることを確認する必要があります。