はじめに
前回はCodeBuildを利用してSystems ManagerでAnsibleを実行してみましたが、今回は今まで作成してきたサービスを繋ぎ合わせて、CodeCommitへのプッシュを契機にCodeBuildを実行、Slackへ通知を行ってみようと思います。
CodePipelineとは
CI（継続的インテグレーション）、CD（継続的デリバリ）を実現するために、特定の操作を契機とした連携処理を設定するためのサービスです。
例えば、CodeCommitへのプッシュを契機に、ソースコードのビルドやビルド後のデプロイ等の作業を一気通貫で自動で行うように繋ぎ合わせるサービスがCodePipelineとなります。
今回の構成
その１で掲載した構成図から少し書き換えていますがCodePipelineで繋ぎ合わせて以下のような構成を作ってみようと思います。
図だけだと分かりづらいので、手順の流れを書くと以下のようになります。
- クライアント端末から
CodeCommitへプッシュ -
CodeCommitへのプッシュを契機にCodePipelineがCodeBuildを実行 -
CodeBuildからSystems Manager（Ansible）を実行（チェックのみ） - クライアント端末から
CodePipelineのページに行き、承認処理を実行 -
CodeBuildからSystems Manager（Ansible）を実行（反映）
Slackへの通知については上記のそれぞれのタイミングで通知されるようになっています。
CodePipelineの作成
CodePipelineのダッシュボードから「パイプラインを作成する」を選択してCodePipelineを作成していきます。
パイプライン名は任意ですが、今回はssm_ansible_pipelineとし、サービスロールは新しく作成しておきます。
前述の通りCodeCommitへのプッシュを契機とするため、ソースはCodeCommit、リポジトリは「その2」で作成したssm_ansible、ブランチはmaster、その他はデフォルトのまま次へ進みます。
ビルドステージでは「その4」で作成したssm_ansible、その他はデフォルトのまま次へ進みます。
デプロイは今回CodeBuild経由で実行するSystems Managerで実行するため、デプロイステージはスキップします。
「パイプラインを作成する」で作成すると、一旦現在までの状態で一連のPipelineが実行されるため、処理を見届けてエラーとならなければOKです。
通知ルールの作成
ここまででCodeCommit→CodeBuildの実行はできましたが、「通知ルール」を作成して、特定のトリガーでSlackへ通知するようにします。
CodePipelineの成功画面の上部に「このpipelineの通知ルールを作成する」のボタンがあるので、そちらから通知ルールを作成していきます。
トリガーするイベントは、あまりチェックを付けすぎてもうるさいだけなので、CodePipelineがSucceededかFailedだけチェックを付けておきます。
「ターゲット」は、「AWS Chatbot (Slack)」を選び、「その3」で作成したChatbotのチャンネル名を選択して「Submit」で作成します。
ここでチャンネル名を選んで「Submit」をすることで裏ではCodePipelineからの通知用のSNSトピックの作成とChatbotへのSNSトピックの結びつけが行われています。
「CodeStarNotifications-[Chatbotチャンネル名]-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx」と言った名前のSNSトピックが自動で作成されるため、見知らぬSNSトピックだからといって削除しないようにしてください。（私は削除してハマりました・・・）
承認処理の追加
CodeBuildによるSystems Manager（Ansible）の実行後、一旦人のチェックを行うため承認処理を追加しようと思います。
先程作成したパイプラインに処理を追加するためには、CodePipelineのダッシュボードより、「パイプライン・CodePipeline」→「パイプライン」→「先程作成したパイプライン名」を選択し、「編集」から処理を追加できます。
既存のステージを編集して、ステージ内に処理を追加することもできますが、今回は新たにステージを追加して承認処理を追加します。
承認処理なので名前は「Approval」にしておきます。（日本語不可）
ステージを追加すると、作成した「Approval」が追加されるため、「アクショングループを追加する」を選択し、以下のように設定します。
SNS通知先は別の通知先にすることもできますが、今回はテストなので先程のトリガー通知先と同じSlackチャンネルにしました。
反映処理の追加
最初に実施したCodeBuildでは、AnsibleをDry-Run（チェックモード）で動かしていたため、対象インスタンスへの反映は行われていませんが、承認処理を行った後、実際に対象インスタンスへ設定を反映するようにします。
具体的には「その4」で変数設定によりCHECK: Trueをしていましたが、この変数を上書きしてCHECK: Falseとすることで反映処理を実行するようにします。
先ほどと同様、「ステージを追加する」より、今回は「Apply」というステージ名を付け、以下のようなCodeBuildのアクションを作成します。
忘れてはいけないのが「環境変数 - オプショナル」よりCHECK変数を指定してFalseとしておくことが必要です。
buildspec.ymlの中でも環境変数として CHECKの設定を行っていますが、ここで指定する環境変数はCodePipeline実行時にbuildspec.ymlの中の環境変数を上書きするため、ここで CHECKをFalseとすることで、Apply処理でAnsibleが動作する仕組みです。
すべて完成すると、最初に作成していた「Source」、「Build」ステージの下に以下「Approval」、「Apply」が追加されていることが確認できるかと思います。
一連の動作確認
ここまでで一連の処理は設定できたので、実際にCodeCommitへのプッシュ契機で動作するか確認してみます。
ただ、何も変更していない状態でのプッシュだと反応しないため、処理に影響が出ない変更を行った上でプッシュします。
うまくCodePipelineが設定できていれば以下のように承認処理まで進むはずです。
承認後、後続の処理が動きはじめ、エラーなく終了すれば完了です。
今回、CodePipelineのSucceededとFailedのときに通知するよう設定していたため、「その3」で設定したSlackのチャンネルには以下のように通知が飛んでいるかと思います。（赤枠が今回通知されたメッセージ）
おわりに
5回に渡りCodePipelineを使用したCI/CDの構成を組んでみましたが、１回のイベント契機で某ピタゴラスイッチのように続けて処理がされるところを見るのは楽しいですね。
処理を繋げていくこと自体は今に始まったことではなく、昔から行われてきたことですが、今のように画面上からサービスを繋ぎ合わせたり、簡単な命令文を書くだけで様々な処理を繋げられるという点が、CI/CDと言った言葉が生まれて流行っている理由なんだろうなと感じました。