AWSでCI/CDパイプラインを構築する

はじめに こんにちは。なかやまです。業務で、CI/CDパイプラインを構

はじめに

こんにちは。なかやまです。
業務で、CI/CDパイプラインを構築しました。
CI/CDとは何なのか・AWS環境でパイプラインを構築するにはどうしたらいいのかなどについて書きました。
軽く書くつもりが、思ったより長くなったので時間がある人だけ、読んでいただけると幸いです。(#^.^#)


目次

  • CI/CDってなに?ざっくりとした解説
  • AWSでCI/CDパイプラインを構築するには
  • CI/CDパイプラインの例

CI/CDってなに?ざっくりとした解説

CI/CDとは・・・

ChatGPTが答えてくれました。
「開発からリリースまで自動でつなぐ仕組み」です。

CI(継続的インテグレーション):プログラムの変更を少しずつ、こまめにまとめてチェックすること。
CD(継続的デリバリー/継続的デプロイ):その変更を自動でテストして、問題がなければすぐに環境にリリースすること。

です。

この一連の流れを自動でつないでくれる仕組みを「CI/CDパイプライン」と呼びます。

CI/CDパイプラインを使うと、こんな良いことがあります!

★早く・安全に新機能を届けられる
→ 手動でチェックするよりずっと早く、ミスが減る。

★エンジニアの負担が減る
→ 毎回のテストやリリース作業を自動化できるので、開発に集中できる。

★ユーザーにとっても嬉しい
→ バグ修正や新機能がすぐに反映されるので、快適なサービスが保たれます。

いいことづくしですね。

AWSでCI/CDパイプラインを構築するには

AWS CodePipelineというサービスを使用します。
AWS CodePipelineの公式ドキュメントには以下のような説明があります。
「素早く確実性のあるアップデートのためにパイプラインの継続的デリバリーを自動化」
(https://aws.amazon.com/jp/codepipeline/)
直訳感すごいですね。
これからCodePipelineについて、簡単に説明します。

CodePipelineでは、以下のようなステップを自動化できます!

コードの取得(GitHubなどから)

ビルド(CodeBuildなどでプログラムを組み立てる)

テスト(自動で動作確認)

承認(環境へデプロイする前に、手動での承認(または却下)を入れることができる)

デプロイ(環境に反映)

CodePipelineではこれらを「ステージ」としてつなげて、コードに変更があるたびに自動で流れるように設定できます。

↓ステージの流れはこんな感じです。

各ステージで使用するAWSのサービスについて説明します。


🍀ソースステージ
S3(ストレージサービス。容量単価は安め。)
ECR(コンテナイメージを補間するサービス。)
などのAWSサービスや、
AzureDev Ops
Git Hub
などの外部リポジトリが利用できます。

🍀ビルド・テストステージ
主に、CodeBuildを利用します。
CodeBuildは、ソースコードをビルドしたり、テストやデプロイを自動で実行してくれるサービスです。
ビルドプロジェクトでは、「どんな環境で?」「どんな設定で?」ビルドを行うかを指定します。
また、buildspecファイルを使って、CodeBuildに「どんな手順で処理を進めるか」を指示します。
このファイルには、インストール・ビルド・テスト・デプロイといった流れをYAMLまたはJSON形式で記述します。

🍀承認ステージ
自動で流れてきたパイプラインの途中で、
「この内容でリリースして大丈夫?」と人が確認して、承認を押したら次のステージ(デプロイなど)に進む仕組みです。
自動の中に「人の目」をはさむ安全ステップです。

🍀デプロイステージ
CodeDeploy
CloudFormation

が利用されることが多いです。
CodeDeploy…アプリケーションを環境に自動でデプロイするサービス。(ブルーグリーンデプロイというものがある。個人的にこの言葉、すごく語呂が良いと思う。)
CloudFormation…インフラの設計図(テンプレート)をコードで記述し、AWSリソースを自動で構築・管理できるサービスです。テンプレートはYAMLまたはJSON形式で記述され、これをもとに「スタック」と呼ばれる単位でリソースがデプロイされます。

それぞれのステージで何のサービスを使うべきかは、要件によって異なります。

CI/CDパイプラインの例

業務で、「S3バケットにCloudFormationテンプレートが配置されると、自動的にAWSリソースをプロビジョニングするパイプライン」を構築しました。
今回はそのパイプラインの簡易版を作ってみます。

必要なサービスは主に、
・CodePipeline
・S3
・EventBridge
・CodeBuild
・CloudFormation

です。

構成図は、以下のようになります。

パイプラインの流れは以下の通り。
①ユーザーがS3バケットにCloudFormationテンプレートを配置する。
②EventBridgeが、S3バケットにオブジェクト(CloudFormationテンプレート)が配置されたことを検知し、CodePipelineを起動させる。
③CodeBuildがCLIコマンドを叩いて、CloudFormationへデプロイする。
④CloudFormationがテンプレートを基に、リソースを作成する。
※デプロイステージではCloudFormationを指定することもできますが、CodeBuild内でCloudFormationを操作するCLIコマンドを記述することで、より柔軟なデプロイが可能になります。

🤖🤖作業の流れ🤖🤖(細かい作業内容は割愛します。。)
必要なIAMロールを作成する
CodePipeline・CodeBuildが使うIAMロールを作成します。
CodePipelineにはCodeBuildを実行させる権限や、S3バケットを操作する権限など与えます。
CodeBuildにもS3バケットを操作する権限や、作成対象のリソースの作成権限、CloudFormationの実行権限などを与えます。

S3バケットを作る

CodePipelineのソースステージとなるS3バケットを作成します。

CodeBuildのビルドプロジェクトを作る


CodePipelineを作る

どのようなステージを作るか・ステージに何のサービスを使うかなどを設定します。
今回は、ビルドステージに上記で作成したCodeBuildプロジェクトを指定します。

EventBridgeルールを作る

今回は、「上記で作成したS3バケットにsource.zip(オブジェクトキーです)が配置されると、それを検知してCodePipelineを起動させる」というルールを作成します。

CodeBuildで使うbuildspecファイルを作る

これらの作業を行い・・・・CICDパイプラインが完成しました!

これはCodePipelineのコンソール画面です。

では、実際に動かしてみます。

動かすには、S3バケットCloudFormationテンプレートとビルドステージで使うbuildspecファイルを「source.zip」に固めて配置する必要があります。

CloudFormationテンプレート
S3バケットを作成するCloudFormationテンプレートを作成しました。
テンプレートの中身はこんな感じ。(s3-template.yml)

buildspecファイル
ビルドプロジェクトで使用するbuildスペックファイルはこんな感じです。
テンプレートをCloudFormationへデプロイする処理だけ書いています。
buildspecファイルは、もっともっと複雑な処理をコーディングすることが可能です。


ではこれらを「source.zip」に固め、CodePipelineのソースステージに指定しているS3バケットへ配置します。

すると、パイプラインが動き始め・・・

パイプラインの実行に成功しました。

CloudFormationのコンソールを見に行くと、CLoudFormationのスタックが作られていることが確認できます。

テンプレートで設定したS3バケットも作られていることが確認出来ました。


CI/CDパイプラインとCLoudFormationを使って、自動でサービスを構築することができました(^_^)

おわりに

以上でCI/CDパイプラインについてのブログは終わりにします。
登場したサービスは、本当に超浅~いところにしか触れていないので、気になった方はそれぞれのサービスについて調べてみてください。

ここまで読んだ人はほとんどいないと思いますが、一応。
読んでいただきありがとうございました。😁

コメントを残す

メールアドレスが公開されることはありません。