AWS 19：CI/CD ― 自動で届ける

CI/CD：コードを置いたら、決まった道を自動で流れて届く

CI/CD は、コードの変更を決まった順番の工程に自動で流し、検査して、環境へ届ける仕組みです。工場のベルトコンベアにたとえられます。人が製品を1つずつ手で運ぶのではなく、コンベアに載せれば決まった検査と工程を通って出荷されます。

この一連の流れをパイプラインと呼びます。図の6つの段が、フォトログのパイプラインです。

大事なのは、道が1本で、毎回同じであることです。誰が出しても、急いでいても、同じ検査を通ります。

① push すると、ビルドとテストが自動で走る

開発者がコードを main ブランチ（Git で本番に出すコードを置く枝）に入れると、それを合図にパイプラインが起動します。図では、新しい版（v2）の小包がテストの段まで進んでいます。

テストに落ちた版は、そこで止まり、先へ進めません。作った人には通知が届きます。これが CI の役割です。「テストを飛ばして出してしまった」という事故が、仕組みとして起きなくなります。

テストに通った版は、次に試験環境（stg）へ出されます。stg で動作を確かめたら、承認の段で人がボタンを押し、本番へ進みます。

最初は承認を挟み、テストと監視（第17章）が育ってきたら外す、という進め方がよくあります。

成果物：一度だけ作り、名前を付けて使い回す

ビルドした結果を成果物（アーティファクト）と呼びます。CI/CD でとても大事な決まりが、成果物は一度だけ作り、どの環境にも同じものを出すことです。

図では、ビルドは1回だけ行い、できた成果物に photolog-3f9c2a1 という名前を付けています。この同じ成果物を、試験環境にも本番にも出します。

成果物の形は、アプリの動かし方で決まります。

名前には、Git のコミット ID（変更1回ごとに付く識別子）や版番号を使います。こうすれば「今、本番で動いているのはどの版か」「どの変更が入っているか」に、いつでも答えられます。

GitHub Actions：リポジトリの中にパイプラインを書く

パイプラインを動かす道具はいくつもありますが、コードを GitHub に置いているなら、GitHub Actions がいちばん手軽です。

GitHub Actions では、リポジトリ（コードの置き場所）の .github/workflows/ というフォルダに、YAML（第18章）でワークフロー（自動で行う手順）を書きます。図の左がその例です。

ワークフローを実行するマシンをランナーと呼びます。GitHub が用意するランナーは、実行のたびにまっさらな状態で起動し、終われば消えます。手元のパソコンのような「その人の環境の癖」が混ざりません。

ワークフローのファイル自体もコードなので、Git に履歴が残り、変更はレビューできます。

ここで1つ問題があります。最後の行の cdk deploy は、AWS を操作します。つまり、ランナーには AWS を触る権限が要ります。それをどう渡すかが、次の話です。

問題：ランナーに、AWS を触る権限をどう渡すか

以前よく使われていたのは、IAM ユーザーのアクセスキー（第3章）を作って、GitHub の「シークレット」（暗号化して保存する設定値）に入れておく方法です。

しかし第3章で見たように、アクセスキーは長く生きる鍵です。

デプロイ用の鍵は、本番を変えられる強い権限を持っています。これが漏れると、そのまま本番を壊されます。

本当に欲しいのは、「そのリポジトリの、その1回の実行のあいだだけ使える、すぐ期限が切れる鍵」です。そして、どこにも鍵を保存しておかずに済む方法です。それを実現するのが OIDC を使った連携です。

OIDC：GitHub が発行する「身分証」で、ロールをかぶる

OIDC（OpenID Connect）は、ある組織が発行した「身分証」を、別の組織が確かめて信用するための決まりです。ここでは、GitHub が発行した身分証を、AWS が確かめて信用するように設定します。

図の番号の順に流れを見ます。

渡される鍵は、短い時間（既定では1時間ほど）で切れます。ワークフローはその鍵で cdk deploy などを実行し、終われば鍵は使えなくなります。

準備として、AWS の IAM に「GitHub を身分証の発行元として信じる」という ID プロバイダーを1つ登録し、デプロイ用のロールを作っておきます。

誰にかぶらせるかは、ロールの信頼ポリシーで絞る

「GitHub の身分証なら信じる」だけでは危険です。GitHub には世界中の人のリポジトリがあり、誰のリポジトリでも GitHub の身分証はもらえるからです。そこで、ロールの信頼ポリシー（誰がこのロールをかぶってよいかを決める JSON、第3章）で、条件を絞ります。

図の左が、デプロイ用ロールの信頼ポリシーの主要部分です。

いちばん大事なのが `sub` です。これが無いと、他人のリポジトリのワークフローからでも、あなたのロールをかぶれてしまいかねません。IAM も、GitHub を信じるロールで sub の条件が無いものや、* だけのものは作らせない仕組みになっています。

もう1つ、ロールの権限そのものも絞ります。デプロイに要るのは、CDK のデプロイに必要な操作だけです。管理者権限を付けると、ワークフローが乗っ取られたときに、アカウント全体を差し出すことになります（最小権限、第3章）。

ワークフローで OIDC を使う

準備ができたら、ワークフローから OIDC を使います。図の設定で大事なのは次の3か所です。

ファイルのどこにも、鍵は書かれていません。ロールの ARN は秘密ではないので、書いてあっても問題ありません。

最後の行の --require-approval never は、CDK が「セキュリティに関わる変更を実行してよいか」と聞いてくる確認を省く指定です。パイプラインの中では人が答えられないためです。その代わり、変更はプルリクエスト（変更を取り込む前にレビューする仕組み）の段階で、cdk diff（第18章）の結果を見てレビューします。

図の @v4 のような、アクションの版の指定は、使うときに公式の最新の案内を確かめてください。

AWS 純正の道具：CodePipeline・CodeBuild・CodeDeploy

GitHub Actions を使わず、AWS の中でパイプラインを組むこともできます。AWS には、役割ごとに3つの道具があります。

どちらを選ぶかの目安です。

どちらを選んでも、成果物を1つ作る、鍵を置かない、入れ替え方と戻し方を決めておくという考え方は同じです。

入れ替え方①：一斉に入れ替えると、その間は止まる

成果物が本番の手前まで来ました。最後に、今動いている4台を、どうやって新しい版にするかを決めます。ここからは、図の ALB（第11章）とその後ろの4台を舞台に、入れ替え方を比べます。

いちばん単純なのは、全台を一斉に止めて、新しい版にするやり方です。

図では、4台すべてが「停止中」になっています。ALB は送り先が無いので、利用者にエラー（503）を返すしかありません。

試験環境や、夜中に止めてよい社内向けのサービスなら、これで十分なこともあります。でも、フォトログの本番のようにいつでも誰かが使っているサービスには向きません。

入れ替え方②：ローリング ― 数台ずつ順に入れ替える

ローリングは、何台かずつ順番に入れ替えるやり方です。図では、上の2台はもう新しい版（v2・緑）になり、3台目を入れ替え中、4台目はまだ古い版（v1・黄）です。

1台ずつの入れ替えは、次の順で進みます。

フォトログのように Auto Scaling を使っているなら、インスタンスの更新（Instance Refresh）という機能が使えます。起動テンプレート（第12章）の AMI を新しい版に替えてから実行すると、「最低何％の台を健全に保つか」を守りながら、古い台を新しい台へ順に入れ替えてくれます。途中で止めて確かめるチェックポイントや、失敗したときの自動の巻き戻しも設定できます。

入れ替え方③：ブルー/グリーン ― もう1組作って切り替える

ブルー/グリーンは、今の版の組（ブルー）はそのままにして、新しい版の組（グリーン）を丸ごと別に作るやり方です。

図では、ALB の青い矢印がグリーンの組へ向いています。ALB では、リスナー（第11章）の送り先のターゲットグループを替えることで切り替えます。

戻すのが速いことが、ブルー/グリーンの最大の価値です。CodeDeploy は、EC2 と Auto Scaling の組み合わせでもブルー/グリーンのデプロイを扱えます。

少しずつ流す：カナリア

ブルー/グリーンは「一瞬で全員を切り替える」ので、新しい版が壊れていると、その瞬間は全員が影響を受けます。そこで、最初は一部の利用者だけを新しい版に流すやり方があります。これをカナリアと呼びます（昔、炭鉱で有毒なガスに先に気づくためにカナリアを連れて入ったことから）。

図では、ALB が9割を今の版へ、1割を新しい版へ送っています。

ALB には、1つのリスナーから複数のターゲットグループへ、重みを付けてリクエストを分ける機能があります。これを使えば、割合を少しずつ変えられます。

カナリアは、監視（第17章）がしっかりしていてはじめて意味があります。「1割に流したが、壊れているかどうか誰も見ていない」では、ただ遅いだけのデプロイになってしまいます。

戻し方：壊れたら、前の版をもう一度出す

どれだけ気をつけても、壊れた版が出ることはあります。大事なのは、戻し方を先に決めて、自動にしておくことです。図の番号の順に流れを見ます。

成果物に名前を付けて残しておいたのは、このためです。「前の版」がはっきりしていれば、戻すのは前の成果物でもう一度デプロイするだけです。

入れ替え方によって、戻す速さが違います。

1つ、戻しにくいものがあります。DB の形の変更（列を消す、名前を変える、など）です。新しい版と一緒に DB の列を消すと、前の版に戻したとき、前の版が使う列がもう無い、ということが起きます。そこで DB の変更は、「列を足す → 新しい版を出す → 古い列を使わなくなってから消す」のように、新旧どちらの版でも動く形で、数回に分けて行います。

フォトログのパイプライン

ここまでをまとめて、フォトログのパイプラインを決めます。

構成の変更（第18章の CDK のコード）も、同じパイプラインで流します。プルリクエストの段階で cdk diff の結果をレビューし、main に入ったら stg → 承認 → 本番の順に cdk deploy します。

こうして、アプリも構成も、main に入ったものだけが、同じ道を通って本番に届くようになりました。誰のパソコンからも、直接本番を変えることはありません。

AMI を焼く方式は、1回のビルドに時間がかかるのが弱点です。もっと速く、軽く届けたくなったら、第21章のコンテナが答えになります。

お金：実行した「分」に払う

CI/CD の道具は、多くが実行にかかった時間で課金されます。

単価と無料枠は、それぞれの料金ページで確認してください。

いちばん忘れやすいのは、成果物がたまり続けることです。毎日何度もビルドすると、AMI や zip がどんどん増えます。「直近の10個だけ残す」のように決めて、S3 のライフサイクル（第15章）や、古い AMI を消す仕組みで片付けます。

よくある落とし穴

パイプラインは、本番を変えられる強い権限を持っています。つまり、パイプラインを乗っ取られることは、本番を乗っ取られることと同じです。

図のいちばん下の、緑の印の項目がこの章の守りのまとめです。鍵は OIDC、権限は最小、成果物は1つ、戻しは練習済み。

片付け：練習で作ったパイプラインを消す

この章で練習のために作ったものを、次の順で消します。

古い AMI は、登録を解除（deregister）した後に、その AMI が使っていた EBS のスナップショット（第10章）も消す必要があります。解除だけでは、スナップショットの保存料がかかり続けます。

構成そのものの片付けは、第18章の cdk destroy です。