$30 off During Our Annual Pro Sale. View Details »

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

コンテナイメージを複数のチームで扱うための、 ビルドフローの構築・運用 / Building and Managing a Container Image Workflow for Multiple Teams

コドモン開発チーム

December 02, 2024
Tweet

More Decks by コドモン開発チーム

Transcript

  1. 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
  2. 8 CONFIDENTIAL - © 2022 CoDMON Inc. 8 システム構成 ・メインのサーバーはEC2

    ・機能単位でマイクロサービ ス(ECS Fargate)に切り出し ている
  3. 9 CONFIDENTIAL - © 2022 CoDMON Inc. 9 システム構成と組織 ・マイクロサービス(ECS

    Fargate)ごとに担当チームが 存在し、コード・インフラ両 方を見ている ・メインサーバーのコードは 複数チームが触る ・メインサーバーのミドル ウェア、インフラ設定はSRE チームが管理している
  4. 10 CONFIDENTIAL - © 2022 CoDMON Inc. 10 直近取り組んだシステム構成変更 ・メインサーバーを、EC2

    → ECS(Fargate)に移行した ・アプリケーションをコンテ ナ化した
  5. 11 CONFIDENTIAL - © 2022 CoDMON Inc. 11 直近取り組んだシステム構成変更 ・各チームがメインアプリ

    ケーションのコンテナイメー ジを扱う ・SREチームに閉じていたミ ドルウェア構成管理の責務 が、開発チームに広がる
  6. 12 CONFIDENTIAL - © 2022 CoDMON Inc. 12 直近取り組んだシステム構成変更 複数チームがコンテナイ

    メージを安全に扱うための ビルドフローを検討 ・各チームがメインアプリ ケーションのコンテナイメー ジを扱う ・SREチームに閉じていたミ ドルウェア構成管理の責務 が、開発チームに広がる
  7. 13 CONFIDENTIAL - © 2022 CoDMON Inc. 13 ビルドフローの構築で重要視したこと •

    安全性が担保されたイメージのみ、本番環境にデリバリーされる仕組み ◦ 多くの人・チームがコンテナイメージに手を加えるため、安全性を担保する仕組 みを作ることが重要
  8. 14 CONFIDENTIAL - © 2022 CoDMON Inc. 14 ビルドフローの構築・運用に取り入れたプラクティス 1.

    脆弱性スキャンをCICDに組み込む 2. チェック済のイメージのみ本番環境にデリバリーする
  9. 16 CONFIDENTIAL - © 2022 CoDMON Inc. 16 脆弱性スキャンの重要性 •

    複数チームにまたがる大規模システムの場合、「多くのサードパーティライ ブラリ・パッケージが導入されている」「それらをいつ誰が導入したかの管 理が難しい」ため、脆弱性スキャンが重要
  10. 17 CONFIDENTIAL - © 2022 CoDMON Inc. 17 脆弱性スキャンを有効活用するためのポイント •

    パイプラインの中で、なるべく早期に脆弱性を検出し、問題を取り除くこと が大切 ◦ 本番環境のリポジトリにPush後や、デプロイ後の検知だと、問題の修復に時間が かかったり、対応が後回しになったりする ◦ 脆弱性スキャンをCICDに組み込み、ビルドしたコンテナイメージに対してスキャ ンを実行することで、問題の早期発見が可能になる
  11. 18 CONFIDENTIAL - © 2022 CoDMON Inc. 18 脆弱性スキャンツールの選定 •

    脆弱性スキャン製品は数多く存在するが、Amazon Inspector を利用 ◦ マイクロサービスチームで利用実績があり、開発チームに馴染みが深い ◦ メインサービス側も、レポジトリPush後の継続的スキャンはAmazon Inspector を使うので、それに合わせたい
  12. 19 CONFIDENTIAL - © 2022 CoDMON Inc. 19 脆弱性スキャンツールの選定 •

    脆弱性スキャン製品は数多く存在するが、Amazon Inspector を利用する ◦ マイクロサービスチームで利用実績あり ◦ メインサービス側も、レポジトリPush後の継続的スキャンはAmazon Inspector を使うので、それに合わせたい ただし、ECR拡張スキャンによってInspectorと統合した場合は、レポジトリにコンテナイ メージをPushして以降でないとスキャンを実施できない・・・
  13. 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に送信し、脆弱 性レポートが生成される ビルドしたコンテナイメージに対して、脆 弱性スキャンを実施可能に
  14. 21 CONFIDENTIAL - © 2022 CoDMON Inc. 21 脆弱性スキャンツールの選定 •

    公式からGithubActionsが提供されているので、利用する ◦ https://github.com/aws-actions/vulnerability-scan-github-action-for-amazon-ins pector
  15. 23 CONFIDENTIAL - © 2022 CoDMON Inc. 23 脆弱性レポートの見え方 •

    GitHub Actionsの実行サマリページに結果が表示される
  16. 24 CONFIDENTIAL - © 2022 CoDMON Inc. 24 運用時のポイント:抑制ルールの実装 •

    CICDに脆弱性スキャンを組み込む場合、抑制手段の提供が必要 ◦ 脆弱性が検知されると、デプロイを失敗させている場合 ◦ 抑制手段がないと「対応不要と判断された場合」「対応必要だがすぐに対応で きない場合」といった例外的なケースで、リリースできない
  17. 25 CONFIDENTIAL - © 2022 CoDMON Inc. 25 運用時のポイント:抑制ルールの実装 •

    ただし、Amazon Inspector CICD統合機能では、今のところ抑制機能は用 意されていない・・・ ◦ https://github.com/aws-actions/vulnerability-scan-github-action-for-a mazon-inspector/issues/90
  18. 26 CONFIDENTIAL - © 2022 CoDMON Inc. 26 運用時のポイント:抑制ルールの実装 •

    「抑制対象として指定された脆弱性IDについては、検出されてもスルーす る(デプロイを失敗させない)」という部分を自前で実装
  19. 27 CONFIDENTIAL - © 2022 CoDMON Inc. 27 運用時のポイント:抑制ルールの実装 •

    ただ抑制機能を提供するだけだと、脆弱性スキャンが形骸化したり、対応 されていない脆弱性を見逃してしまう ◦ SREチームで以下を取りまとめている ▪ 「何を」「どんな理由で」抑制しているのか ▪ (対応必要な場合)「いつ」「どのチームが」対応するのか
  20. 29 CONFIDENTIAL - © 2022 CoDMON Inc. 29 元々の本番デプロイフロー ※

    現在は1日に複数回リリースしているの で、あくまでイメージです 10:00~10:30:リリース予定の変更をstg 環境にデプロイ 10:30~13:00:リリース予定の変更がある チームは動作確認実施 13:00~:リリース予定の変更を本番環境に リリース
  21. 30 CONFIDENTIAL - © 2022 CoDMON Inc. 30 Stg環境へのデプロイについて •

    デプロイ実施前に、各種チェックを実施 ◦ 【既存から存在】各種自動テスト(Unit Test・E2E Test) ◦ 【コンテナ化に伴い新設】コンテナイメージに対する脆弱性スキャン • チェックを通過したコンテナイメージのみ、Stg環境のリポジトリにPush される ◦ 本番環境でもこのイメージをそのまま使うことで、信頼されたイメー ジのみ本番環境にデリバリー可能
  22. 31 CONFIDENTIAL - © 2022 CoDMON Inc. 31 ECRイメージレプリケーション機能を利用 •

    複製元リポジトリへのPushをトリガーに、異なるリージョンやアカウン トにイメージを複製可能 • リポジトリ単位で、複製する/しない を指定可能
  23. 32 CONFIDENTIAL - © 2022 CoDMON Inc. 32 ECRイメージレプリケーションの設定 【複製元アカウント】

    レプリケーション設定で、複製したいア カウントID・リージョンを指定 【複製先アカウント】 レジストリのアクセス許可設定で、複製 を許可するリポジトリを指定
  24. 34 CONFIDENTIAL - © 2022 CoDMON Inc. 34 レプリケーション利用時のポイント1 •

    コンテナイメージの環境依存をなくす ◦ 例えば、コードのビルド時に環境変数を埋め込んでいたり、環境ごとに設定 ファイルが違っていたりすると、stg環境用にビルドしたイメージを本番環境 に適用できない ◦ どの部分に環境依存が含まれるか は、システムによって異なるため、事前に 確認し、取り除いておくことが必要
  25. 35 CONFIDENTIAL - © 2022 CoDMON Inc. 35 レプリケーション利用時のポイント1 •

    ソースコードの環境依存 ◦ ビルド時に環境依存値を埋め込まない形に修正 • サーバー用の設定ファイル ◦ stg・本番環境では同様の設定ファイルを利用する • 環境変数ファイル ◦ コンテナ起動時に作成 ◦ 環境変数値はコンテナ(ECSタスク)起動時にSecrets Managerから取得可能
  26. 36 CONFIDENTIAL - © 2022 CoDMON Inc. 36 レプリケーション利用時のポイント2 •

    どのイメージがデプロイ済か(運用環境で動作しているか)を明確にする ◦ 例えばstg環境動作確認時に問題点が発覚し、修正バージョンを含めて再度stg にデプロイすると、本番環境のリポジトリに、実際にはリリースされなかった イメージが含まれてしまう ◦ 誤ったイメージが本番環境にデプロイされてしまう可能性
  27. 37 CONFIDENTIAL - © 2022 CoDMON Inc. 37 レプリケーション利用時のポイント2 •

    本番デプロイフローの中で、本番リリース対象のコンテナイメージには別 名のイメージタグを付与する ◦ https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/image-retag.html • どのイメージが本番デプロイ済か、一 目でわかるようにする • 元々付与されていたイメージタグ or 別名のイメージタグ どちらでイメー ジpullしても同じ結果となる
  28. 39 CONFIDENTIAL - © 2022 CoDMON Inc. 39 まとめ •

    複数チームでコンテナイメージを扱う際は、ビルドフローの中で信頼できる イメージのみ本番環境にデリバリーされるように工夫する • AWSマネージドサービスを活用することで、構成・運用をシンプルに保つこ とが可能