Kanji
・クラウドエンジニア / フリーランス ・1993年生まれ ・愛媛県出身 / 東京都渋谷区在住 ・AWS歴5年 プロフィールの詳細
目次
AWS CodePipeline について、公式のユーザーガイドでは以下の通り定義されています。
AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、視覚化、自動化するために使用できる継続的デリバリーサービスです。 ソフトウェアリリースプロセスのさまざまなステージを素早くモデル化して設定できます。 CodePipeline はソフトウェアの変更を継続的にリリースするために必要なステップを自動化します。 引用元： AWS CodePipeline とは - AWS CodePipeline
AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、視覚化、自動化するために使用できる継続的デリバリーサービスです。 ソフトウェアリリースプロセスのさまざまなステージを素早くモデル化して設定できます。 CodePipeline はソフトウェアの変更を継続的にリリースするために必要なステップを自動化します。
AWS Code Commit について、公式のユーザーガイドでは以下の通り定義されています。
AWS CodeCommit は、Amazon Web Services がホストするバージョン管理サービスで、アセット (ドキュメント、ソースコード、バイナリファイルなど) をクラウドにプライベートに保存および管理するために使用できます 引用元： AWS CodeCommit とは - AWS CodeCommit
AWS CodeCommit は、Amazon Web Services がホストするバージョン管理サービスで、アセット (ドキュメント、ソースコード、バイナリファイルなど) をクラウドにプライベートに保存および管理するために使用できます
AWS CodeBuild について、公式のユーザーガイドでは以下の通り定義されています。
AWS CodeBuild は、 クラウドでのフルマネージドビルドサービスです。CodeBuild はソースコードをコンパイルし、単体テストを実行して、すぐにデプロイできるアーティファクトを生成します。 CodeBuild では自分のビルドサーバーをプロビジョニング、管理、スケールする必要がありません。 Apache Maven、Gradle などの一般的なプログラミング言語とビルドツール用のパッケージ済みのビルド環境を提供します。 ビルド環境をカスタマイズして、CodeBuild で独自のビルドツールを使用することもできます。 CodeBuild はピーク時のビルドリクエストに合わせて自動的にスケーリングします。 引用元： AWS CodeBuild とは - AWS CodeBuild
AWS CodeBuild は、 クラウドでのフルマネージドビルドサービスです。CodeBuild はソースコードをコンパイルし、単体テストを実行して、すぐにデプロイできるアーティファクトを生成します。 CodeBuild では自分のビルドサーバーをプロビジョニング、管理、スケールする必要がありません。 Apache Maven、Gradle などの一般的なプログラミング言語とビルドツール用のパッケージ済みのビルド環境を提供します。 ビルド環境をカスタマイズして、CodeBuild で独自のビルドツールを使用することもできます。 CodeBuild はピーク時のビルドリクエストに合わせて自動的にスケーリングします。
AWS CodeDeploy について、公式のユーザーガイドでは以下の通り定義されています。
CodeDeploy は、Amazon EC2 インスタンスやオンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービスです。 以下のような、ほぼ無制限の多様なアプリケーションコンテンツをデプロイできます。 ・コード ・サーバーレス AWS Lambda 関数 ・ウェブファイルおよび設定ファイル ・Executables ・パッケージ ・スクリプト ・マルチメディアファイル 引用元： CodeDeploy とは - AWS CodeDeploy
CodeDeploy は、Amazon EC2 インスタンスやオンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービスです。 以下のような、ほぼ無制限の多様なアプリケーションコンテンツをデプロイできます。
・コード ・サーバーレス AWS Lambda 関数 ・ウェブファイルおよび設定ファイル ・Executables ・パッケージ ・スクリプト ・マルチメディアファイル
GitHub について、公式のウェブサイトでは以下の通り定義されています。
GitHubは、ユーザのみなさんからヒントを得て作成された開発プラットフォームです。 オープンソースプロジェクトやビジネスユースまで、GitHub上にソースコードをホスティングすることで数百万人もの他の開発者と一緒にコードのレビューを行ったり、 プロジェクトの管理をしながら、ソフトウェアの開発を行うことができます。 引用元： GitHub Japan | GitHub
GitHubは、ユーザのみなさんからヒントを得て作成された開発プラットフォームです。 オープンソースプロジェクトやビジネスユースまで、GitHub上にソースコードをホスティングすることで数百万人もの他の開発者と一緒にコードのレビューを行ったり、 プロジェクトの管理をしながら、ソフトウェアの開発を行うことができます。
CI/CD パイプラインで管理する資材の候補として、アプリケーションのソースコード、インフラストラクチャのコード (IaC)、およびアプリケーションのビルドやデプロイに必要な設定ファイルなどが挙げられます。 これらの資材を利用してデプロイしたアプリケーションやインフラストラクチャは、開発中だけでなく運用中も CI/CD パイプラインを通じてコードで管理する必要があります。 開発者、運用者のスキルセットや運用を考慮し、CI/CD パイプラインで管理する資材をコードで管理できるかどうかを検討します。 例えば、以下のようなケースでは CI/CD パイプラインの管理対象外にすることを検討します。
CI/CD パイプラインで管理するコード資材は、AWS CodeCommit や GitHub などのリポジトリサービスで管理します。 AWS CodeCommit および AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy は AWS が提供するサービスであり、既存でコード資材を管理しているリポジトリサービスがなければ AWS CodeCommit を利用することが第一候補となるでしょう。 ただし、以下の通り AWS CodeCommit は 2024年7月25日をもって新規のお客様からのアクセスを停止することが決定されております。
慎重に検討を重ねた結果、2024年7月25日をもってAWS CodeCommitへの新規のお客様からのアクセスを停止することを決定いたしました。 AWS CodeCommitをご利用の既存のお客様は、引き続き通常通りサービスをご利用いただけます。 AWSはAWS CodeCommitのセキュリティ、可用性、パフォーマンスの向上に引き続き投資いたしますが、新機能の導入は予定しておりません。 和訳元： How to migrate your AWS CodeCommit repository to another Git provider | AWS DevOps & Developer Productivity Blog
慎重に検討を重ねた結果、2024年7月25日をもってAWS CodeCommitへの新規のお客様からのアクセスを停止することを決定いたしました。 AWS CodeCommitをご利用の既存のお客様は、引き続き通常通りサービスをご利用いただけます。 AWSはAWS CodeCommitのセキュリティ、可用性、パフォーマンスの向上に引き続き投資いたしますが、新機能の導入は予定しておりません。
今後いつ AWS CodeCommit が利用できなくなるかは不明ですが、既存で AWS CodeCommit を利用していない場合は、他のリポジトリサービスで管理することを推奨します。 データベースと比較するとそこまで移行難易度は高くありませんが、一度利用を開始するとなかなか他のサービスに移行しづらくなるため、 社内ルールや利用できる機能、セキュリティ要件、将来性などを考慮し、慎重に選定しましょう。
CI/CD パイプラインで管理する資材は、以下のようなケースで同じコードを利用して複数の環境やリソースにデプロイするケースがあります。
これらに対応する手段として、以下のような方法があります。
それぞれの方法について、以下で詳しく説明します。
GitHub Flow、git-flow などのブランチ戦略を採用している場合、開発環境、ステージング環境、本番環境などの複数の環境に対して、それぞれ異なるブランチを利用することができます。 例えば、main ブランチを本番環境、develop ブランチをステージング環境、feature ブランチを開発環境として利用することができます。 この場合、各ブランチの更新をトリガーに CI/CD パイプラインを実行し、各環境にデプロイすることができます。 feature ブランチは開発者が自由に命名して利用するため、動的な CI/CD パイプラインの実行が必要です。 例えば、AWS Prescriptive Guidance では、以下のようなパターンが紹介されています。
AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline - AWS 規範ガイダンス
メリットとして、ブランチの内容を確認すれば、どの環境にどのコードがデプロイされているかを把握しやすくなります。
デメリットとして、ブランチの数が増えると CI/CD パイプラインの数も増えるため、管理が煩雑になる可能性があります。 また、ブランチのフローが複雑になりがちなため、Git の習熟度が低い開発者にとっては、ブランチの管理が難しくなる可能性があります。
1つのブランチを利用して、複数の環境やリソースにデプロイする方法です。 例えば、main ブランチを更新時、開発環境、ステージング環境、本番環境に同じコードを一括でデプロイすることができます。
メリットとして、ブランチの数が少なくなるため、CI/CD パイプラインの管理が容易になります。
デメリットとして、すべての環境に同じコードを一括でデプロイするため、 一度開発環境にデプロイしテストしてからステージング環境、本番環境にデプロイするなどの段階的なデプロイが難しくなります。
アプリケーションで利用するリソースではなく、セキュリティサービスや監視サービスなど、インフラのリソースをデプロイする場合に利用することを推奨します。
手動実行ジョブを利用して、ビルド/デプロイ成果物を再利用し、複数の環境やリソースにデプロイする方法です。 例えば、開発環境にデプロイしたアプリケーションのビルド成果物を再利用して、ステージング環境や本番環境にデプロイすることができます。 この方法では、CI/CD パイプラインの実行後に手動でジョブを実行することで、必要な環境やリソースにデプロイすることができます。
メリットとして、ビルド/デプロイ成果物を再利用するため、同じコードを複数の環境やリソースにデプロイすることができます。 また、ジョブ実行を行う CI/CD パイプラインの数は同時実行必要な数だけ用意するだけで良いので、CI/CD パイプラインの数を抑えることができます。
デメリットとして、一度 CI/CD パイプラインを実行してビルド/デプロイ成果物を生成した後に、手動でジョブを実行する必要があるため 段階的にデプロイする分作業が増える可能性があります。
CI/CD パイプラインの仕組みをどこまで作り込むか次第で、かなり汎用性の高い CI/CD パイプラインを構築することができます。
CI/CD パイプラインで管理する資材と利用する主なツールは、以下のようなものがあります。
これらのデプロイツール、ビルド/静的解析ツールを利用して、CI/CD パイプラインで管理する資材をデプロイやビルド、静的解析を行います。
注意点として、これらのツールによってビルド/デプロイ処理が自動化されるからと言って、ツールの学習が不要になるわけではありません。 運用時にはパラメータファイルを変更する手順を確立しておくことで、ツールの学習コストを抑えることができますが 開発時には、CI/CD パイプラインによるビルド/デプロイのみでなく、切り分けのために自社環境でのビルド/デプロイを行うこともあるため、ツールの学習は必要です。 開発者のスキルセットや運用を考慮し、CI/CD パイプラインで利用するツールを選定します。
ツールが決まった後は、CI/CD パイプラインのステップを検討します。
ステップ検討方法については準備中です。
CI/CD パイプラインで実行するツールが決まったら、続いてはそのツールで管理する資材、資材の管理者、デプロイ先を決定します。 例えば、AWS CLI (Cloud Formation) を利用して AWS リソースをデプロイする場合、以下のように整理いたします。
ここで整理する際には、どの資材をどのチームが管理するか、どの環境にデプロイするかを明確にしておくことが重要です。 管理する資材毎にどのレポジトリで管理するかは次の「④ コードレポジトリの分割単位」で検討します。
CI/CD パイプラインで管理する資材をどのようにコードレポジトリで分割するかを検討します。 分割する観点として、以下のようなものがあります。
基本的に「1. 機能」で分割することによって、「2. 管理者」「4. ライフサイクル」の分割も同時に行うことができます。 必要に応じて、「4. ライフサイクル」については「1. 機能」の中でも更に細分化することを検討します。 例えば、Network Firewall を分割する際に初期構築時にのみデプロイするリソース、運用時にデプロイするリソースに分割することによって、 ファイアウォール自体が削除されてしまうリスクを回避することができます。ここでは「管理する資材」をより細かく細分化して整理します。
「3. デプロイ先」については、前述した「① 複数の環境/複数のリソースをデプロイする方法」で検討した結果を踏まえて、どのように分割するかを検討します。 これも例を挙げると、GuardDut では以下のように共通アカウントと各環境アカウントで分割することができます。
分割したコードレポジトリ毎に CI/CD パイプラインを構築する場合、CI/CD パイプライン毎に権限を設定します。 CI/CD パイプラインの権限は、管理者毎にどの権限は許可できないかをまず整理し、そこから更に権限を制限するか検討します。 例えば、基盤チーム、開発チーム、運用チームの3つのチームがある場合、以下のように権限を設定することができます。
CI/CD パイプラインの権限はあまり細かく制限しすぎないことが重要です。 権限を細かく制限しすぎると、CI/CD パイプラインの実行に必要な権限が不足してしまい、デプロイが失敗する可能性があります。 また、CI/CD パイプラインの実行自体をプルリクエストや承認フェーズを利用することで制限することもできるため、内部不正の対策として厳密に制限することは推奨しません。 制限するとしても、以下の AWS 管理ポリシーを利用して、必要な権限を許可することを推奨します。
AWS 管理ポリシー - AWS 管理ポリシー