【SRE活動】GitHub ActionsでCI/CDしてみた!
今回はCI/CDパイプラインをAWS CodePipelineからGitHub Actionsへ移行してみた試みについて、ご紹介したいと思います。
はじめに
こんにちは!
パイオニア株式会社のSaaS Technology Center(STC) の高橋です。
現在所属しているSRE/インフラチームでは、Piomatixクラウドのインフラの保守運用を行いつつ、開発自動化を支援するSRE活動も行っています。
特に、プロダクト開発者がGitHubにソースコードをpushすると自動でビルドやデプロイが行われるしくみ(CI/CDパイプラインと呼んでいます)を準備してきました。
今回は、得られた知見の一つとして、CI/CDパイプラインをAWS CodePipelineからGitHub Actionsへ移行してみた試みについて、ご紹介したいと思います。
背景
パイオニアでは、従来AWS CodePipelineとAWS CodeBuildを主軸としたCI/CDパイプラインを構築しており、主に3つのパターンを用意していました。
この3つのCI/CDパイプラインについて、簡単な構成図を下記に示します。
こちらについては、パイオニアの活動を発表した記事がありますので、ぜひご覧ください。
ここで次の2つを課題視していました。
AWS CodePipeline、AWS CodeBuild自体のリソースのIaC管理が煩雑化してきた。
AWSとGitHubを連携させる際は、GitHub OrganizationのOwnerによる手続きが必要でスピード感に乏しかった。
そこでGitHub Actionsに着目しました。
GitHub Actionsなら、workflowファイルのテンプレートを用意し、これをGitリポジトリに配置するだけでOKです。
つまりIaC管理が必要ありません。
また、GitHub OrganizationのOwnerによる手続きが省け、スピード感が向上します。
しかし移行する上で議論となったのが"GitHub ActionsからどのようにAWS環境にアクセスするのか?"という点です。
AWS CodePipeline、AWS CodeBuildはこれらがAWSアカウント内にあるため権限設定が安全で簡単に設定できますが、GitHub Actionsではそうはいきません。
この課題については、昨年朗報があり、OpenID ConnectによるGitHub ActionsとAWSの連携が可能になりました。
上記が可能になったことにより、AWSアカウントからクレデンシャル情報を払い出すことなくGitHub Actionsに権限設定が可能になりました。
その結果、GitHub Actionsを利用したCI/CDパイプラインを構築してみようということになりました。
やってみた
さっそくやってみようということで、3つのCI/CDパイプラインをGitHub Actionsを利用した形に置き換えてみました。
できあがったGitHub Actionsを主軸としたCI/CDパイプラインについて、構成図を示します。
従来に比べ、AWS CodePipeline、AWS CodeBuildがGitHub Actionsに置き換わり、かつ、GitHub OpenID Connect用のIAM Roleが増える形で、CI/CDパイプラインが構築されています。
フィードバック
新しいCI/CDパイプライン(GitHub Actions)を使ってみて、良かったポイントがいくつかあります。
開発者観点で良かったこと
これは個人的な感覚ですが、ユーザビリティが上がったと感じています。
ビルドなどのログを閲覧するまでの手順を従来と今回とで比べると、下記のようになります。(2022年7月時点のフローです。)
こちらは地味な変化かもしれませんが、個人的には大変気に入っています。
インフラ管理者観点で良かったこと
GitHub Actionsの無料枠の有効利用できた
パイオニアではGitHub Actionsの無料枠が余っていました。
そのためAWS CodePipelineとAWS CodeBuildにかかっていたコストを削減しつつ、無料枠も有効利用できました。
workflowでできることが増えた
GitHub Actionsのworkflowを使うことで、できることが増えたと考えています。
たとえば、連携させるブランチは、AWS CodePipeline、AWS CodeBuildのCI/CDパイプラインでは1つのパイプラインに1つのブランチだけでしたが、GitHub ActionsのCI/CDパイプラインでは1つのパイプラインに複数のブランチを割り当てることも可能です。
また、GitHub ActionsだとCI/CDパイプラインを動作させるトリガーよりもバリエーションを持たせることができるため、より柔軟性が上がりました。
これからのアクション
GitHub Actionsはどんどん機能が増えています。
CI/CDパイプラインのworkflowをもっと拡張して、脆弱性の診断やLintツールの静的解析も同時に実行できるよう、いろんな機能を導入していきたいと考えています。
さいごに
SRE/インフラチームでは今後もGitHub Actionsを積極的に利用して改善活動を行います。
SRE活動にご興味のある方、GitHub Actionsでいろんなしくみを構築したい!という方は、採用ページをご覧ください。