コンテナイメージを複数のチームで扱うための、ビルドフローの構築・運用

ゆるSRE勉強会 #8 の発表資料です。
https://yuru-sre.connpass.com/event/332731/

Transcript

1. コンテナイメージを複数のチームで扱うための、 ビルドフローの構築・運用 2024年11月29日 株式会社コドモン 小西達大 ゆるSRE勉強会 #8
2. 2 経歴 1996年生まれ、大阪育ち。前職でアプリケーションエンジニアとし て従事後、株式会社コドモンのSREチームにジョイン。 関心のある分野はコンテナとセキュリティ。 自己紹介 小西 達大 こにし たつひろ
3. 3 Mission
4. 4 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。
5. 5 全国のこども施設へのICT普及実績 • 2014年のサービスリリース以降、全国的に導入が拡大し、現在は保育業務支援システムとして 国内で最も普及が進んでいます。（※） 2022年4月 14,800 2021年4月 11,400 2020年4月 8,000 2019年4月 5,200 2018年4月 3,000 1,500 全国導入数 20,000 施設 2024年11月現在 20,000 園児数 　　: 約176万人 職員数 　　: 約40万人 保護者数 　: 約315万人 99 継続利用率 .8％ 2023年4月 ※東京商工リサーチ「SaaS型業務支援システムの導入園調査2022」 5
6. 6 今日話すこと 複数チームが関わるシステムにおいて、ビルドフローで重要なこと ビルドフローの構築・運用について
7. 7 弊社のシステム・組織構成について
8. 8 CONFIDENTIAL - © 2022 CoDMON Inc. 8 システム構成 ・メインのサーバーはEC2 ・機能単位でマイクロサービ ス（ECS Fargate）に切り出し ている
9. 9 CONFIDENTIAL - © 2022 CoDMON Inc. 9 システム構成と組織 ・マイクロサービス（ECS Fargate）ごとに担当チームが 存在し、コード・インフラ両 方を見ている ・メインサーバーのコードは 複数チームが触る ・メインサーバーのミドル ウェア、インフラ設定はSRE チームが管理している
10. 10 CONFIDENTIAL - © 2022 CoDMON Inc. 10 直近取り組んだシステム構成変更 ・メインサーバーを、EC2 → ECS(Fargate)に移行した ・アプリケーションをコンテ ナ化した
11. 11 CONFIDENTIAL - © 2022 CoDMON Inc. 11 直近取り組んだシステム構成変更 ・各チームがメインアプリ ケーションのコンテナイメー ジを扱う ・SREチームに閉じていたミ ドルウェア構成管理の責務 が、開発チームに広がる
12. 12 CONFIDENTIAL - © 2022 CoDMON Inc. 12 直近取り組んだシステム構成変更 複数チームがコンテナイ メージを安全に扱うための ビルドフローを検討 ・各チームがメインアプリ ケーションのコンテナイメー ジを扱う ・SREチームに閉じていたミ ドルウェア構成管理の責務 が、開発チームに広がる
13. 13 CONFIDENTIAL - © 2022 CoDMON Inc. 13 ビルドフローの構築で重要視したこと • 安全性が担保されたイメージのみ、本番環境にデリバリーされる仕組み ◦ 多くの人・チームがコンテナイメージに手を加えるため、安全性を担保する仕組 みを作ることが重要
14. 14 CONFIDENTIAL - © 2022 CoDMON Inc. 14 ビルドフローの構築・運用に取り入れたプラクティス 1. 脆弱性スキャンをCICDに組み込む 2. チェック済のイメージのみ本番環境にデリバリーする
15. 15 1：脆弱性スキャンをCICDに組み込む
16. 16 CONFIDENTIAL - © 2022 CoDMON Inc. 16 脆弱性スキャンの重要性 • 複数チームにまたがる大規模システムの場合、「多くのサードパーティライ ブラリ・パッケージが導入されている」「それらをいつ誰が導入したかの管 理が難しい」ため、脆弱性スキャンが重要
17. 17 CONFIDENTIAL - © 2022 CoDMON Inc. 17 脆弱性スキャンを有効活用するためのポイント • パイプラインの中で、なるべく早期に脆弱性を検出し、問題を取り除くこと が大切 ◦ 本番環境のリポジトリにPush後や、デプロイ後の検知だと、問題の修復に時間が かかったり、対応が後回しになったりする ◦ 脆弱性スキャンをCICDに組み込み、ビルドしたコンテナイメージに対してスキャ ンを実行することで、問題の早期発見が可能になる
18. 18 CONFIDENTIAL - © 2022 CoDMON Inc. 18 脆弱性スキャンツールの選定 • 脆弱性スキャン製品は数多く存在するが、Amazon Inspector を利用 ◦ マイクロサービスチームで利用実績があり、開発チームに馴染みが深い ◦ メインサービス側も、レポジトリPush後の継続的スキャンはAmazon Inspector を使うので、それに合わせたい
19. 19 CONFIDENTIAL - © 2022 CoDMON Inc. 19 脆弱性スキャンツールの選定 • 脆弱性スキャン製品は数多く存在するが、Amazon Inspector を利用する ◦ マイクロサービスチームで利用実績あり ◦ メインサービス側も、レポジトリPush後の継続的スキャンはAmazon Inspector を使うので、それに合わせたい ただし、ECR拡張スキャンによってInspectorと統合した場合は、レポジトリにコンテナイ メージをPushして以降でないとスキャンを実施できない・・・
20. 20 CONFIDENTIAL - © 2022 CoDMON Inc. 20 脆弱性スキャンツールの選定 • Amazon Inspector CI/CD統合 ◦ re:Invent 2023 で発表された機能 ◦ https://docs.aws.amazon.com/ja_jp/inspector/latest/user/scanning-cicd.html 1. 提供されたアーティファクトからSBOM(ソ フトウェア部品表)を生成 2. SBOMをAmazon Inspectorに送信し、脆弱 性レポートが生成される ビルドしたコンテナイメージに対して、脆 弱性スキャンを実施可能に
21. 21 CONFIDENTIAL - © 2022 CoDMON Inc. 21 脆弱性スキャンツールの選定 • 公式からGithubActionsが提供されているので、利用する ◦ https://github.com/aws-actions/vulnerability-scan-github-action-for-amazon-ins pector
22. 22 CONFIDENTIAL - © 2022 CoDMON Inc. 22 脆弱性スキャンをCICDに組み込んだビルドフロー
23. 23 CONFIDENTIAL - © 2022 CoDMON Inc. 23 脆弱性レポートの見え方 • GitHub Actionsの実行サマリページに結果が表示される
24. 24 CONFIDENTIAL - © 2022 CoDMON Inc. 24 運用時のポイント：抑制ルールの実装 • CICDに脆弱性スキャンを組み込む場合、抑制手段の提供が必要 ◦ 脆弱性が検知されると、デプロイを失敗させている場合 ◦ 抑制手段がないと「対応不要と判断された場合」「対応必要だがすぐに対応で きない場合」といった例外的なケースで、リリースできない
25. 25 CONFIDENTIAL - © 2022 CoDMON Inc. 25 運用時のポイント：抑制ルールの実装 • ただし、Amazon Inspector CICD統合機能では、今のところ抑制機能は用 意されていない・・・ ◦ https://github.com/aws-actions/vulnerability-scan-github-action-for-a mazon-inspector/issues/90
26. 26 CONFIDENTIAL - © 2022 CoDMON Inc. 26 運用時のポイント：抑制ルールの実装 • 「抑制対象として指定された脆弱性IDについては、検出されてもスルーす る(デプロイを失敗させない)」という部分を自前で実装
27. 27 CONFIDENTIAL - © 2022 CoDMON Inc. 27 運用時のポイント：抑制ルールの実装 • ただ抑制機能を提供するだけだと、脆弱性スキャンが形骸化したり、対応 されていない脆弱性を見逃してしまう ◦ SREチームで以下を取りまとめている ▪ 「何を」「どんな理由で」抑制しているのか ▪ （対応必要な場合）「いつ」「どのチームが」対応するのか
28. 28 2：チェック済のイメージのみ本番環境にデリバ リーする
29. 29 CONFIDENTIAL - © 2022 CoDMON Inc. 29 元々の本番デプロイフロー ※ 現在は1日に複数回リリースしているの で、あくまでイメージです 10:00~10:30：リリース予定の変更をstg 環境にデプロイ 10:30~13:00：リリース予定の変更がある チームは動作確認実施 13:00~：リリース予定の変更を本番環境に リリース
30. 30 CONFIDENTIAL - © 2022 CoDMON Inc. 30 Stg環境へのデプロイについて • デプロイ実施前に、各種チェックを実施 ◦ 【既存から存在】各種自動テスト（Unit Test・E2E Test） ◦ 【コンテナ化に伴い新設】コンテナイメージに対する脆弱性スキャン • チェックを通過したコンテナイメージのみ、Stg環境のリポジトリにPush される ◦ 本番環境でもこのイメージをそのまま使うことで、信頼されたイメー ジのみ本番環境にデリバリー可能
31. 31 CONFIDENTIAL - © 2022 CoDMON Inc. 31 ECRイメージレプリケーション機能を利用 • 複製元リポジトリへのPushをトリガーに、異なるリージョンやアカウン トにイメージを複製可能 • リポジトリ単位で、複製する/しない を指定可能
32. 32 CONFIDENTIAL - © 2022 CoDMON Inc. 32 ECRイメージレプリケーションの設定 【複製元アカウント】 レプリケーション設定で、複製したいア カウントID・リージョンを指定 【複製先アカウント】 レジストリのアクセス許可設定で、複製 を許可するリポジトリを指定
33. 33 CONFIDENTIAL - © 2022 CoDMON Inc. 33 ECRイメージレプリケーションを用いたフロー 安全性が担保されたイメージのみ、本 番環境にデプロイされるようになる
34. 34 CONFIDENTIAL - © 2022 CoDMON Inc. 34 レプリケーション利用時のポイント1 • コンテナイメージの環境依存をなくす ◦ 例えば、コードのビルド時に環境変数を埋め込んでいたり、環境ごとに設定 ファイルが違っていたりすると、stg環境用にビルドしたイメージを本番環境 に適用できない ◦ どの部分に環境依存が含まれるか は、システムによって異なるため、事前に 確認し、取り除いておくことが必要
35. 35 CONFIDENTIAL - © 2022 CoDMON Inc. 35 レプリケーション利用時のポイント1 • ソースコードの環境依存 ◦ ビルド時に環境依存値を埋め込まない形に修正 • サーバー用の設定ファイル ◦ stg・本番環境では同様の設定ファイルを利用する • 環境変数ファイル ◦ コンテナ起動時に作成 ◦ 環境変数値はコンテナ(ECSタスク)起動時にSecrets Managerから取得可能
36. 36 CONFIDENTIAL - © 2022 CoDMON Inc. 36 レプリケーション利用時のポイント2 • どのイメージがデプロイ済か(運用環境で動作しているか)を明確にする ◦ 例えばstg環境動作確認時に問題点が発覚し、修正バージョンを含めて再度stg にデプロイすると、本番環境のリポジトリに、実際にはリリースされなかった イメージが含まれてしまう ◦ 誤ったイメージが本番環境にデプロイされてしまう可能性
37. 37 CONFIDENTIAL - © 2022 CoDMON Inc. 37 レプリケーション利用時のポイント2 • 本番デプロイフローの中で、本番リリース対象のコンテナイメージには別 名のイメージタグを付与する ◦ https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/image-retag.html • どのイメージが本番デプロイ済か、一 目でわかるようにする • 元々付与されていたイメージタグ or 別名のイメージタグ どちらでイメー ジpullしても同じ結果となる
38. 38 まとめ
39. 39 CONFIDENTIAL - © 2022 CoDMON Inc. 39 まとめ • 複数チームでコンテナイメージを扱う際は、ビルドフローの中で信頼できる イメージのみ本番環境にデリバリーされるように工夫する • AWSマネージドサービスを活用することで、構成・運用をシンプルに保つこ とが可能
40. 40 最後に
41. 41 コドモン採用ページ 開発ブログ コドモンでは一緒に働きたい仲間を募集しています！
42. 42 CONFIDENTIAL - © 2022 CoDMON Inc. 42 宣伝