Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インフラのCI/CDはGitHub Actionsに任せた

F5c597c41d9bc6a80cce50adbd6c7bd9?s=47 mihyon
June 21, 2022

インフラのCI/CDはGitHub Actionsに任せた

サービスのインフラ構築のCI/CDのツールとして色々試しましたが、GitHub Actionsで落ち着いたこの頃です。開発環境と本番環境で異なるパラメータの管理もGitHubで管理出来て楽々です。本発表資料では、GitHub Actionsを使ってインフラのCI/CDを実現する方法を初心者向けに紹介します。

F5c597c41d9bc6a80cce50adbd6c7bd9?s=128

mihyon

June 21, 2022
Tweet

Other Decks in Technology

Transcript

  1. インフラの は に任せた 株式会社クオリティア 平野美賢 GitHub Actionsを使ったインフラの自動構築とパラメータ管理

  2. 自己紹介 • Name: 平野美賢 (Mihyon Lee Hirano) • Company: 株式会社クオリティア

    • Role: SRE/Ops • Title: IT Specialist Leader • Likes: 宝塚歌劇、高校野球 • Language: Shell, Python 最近は Yaml 職人 • Twitter: @mihyon
  3. 目次 • GitHub Actions をCI/CDに導入するまで • GitHub Actions の採用 •

    CI/CDへの道のり • 完成したCI/CD • 今後の課題 • 公開資料
  4. を に 導入するまで

  5. 当初のTEAM構成 • 2017年に新サービスの企画や研究開発を目的に発足 • Product Owner かつ Tech Lead 1名

    • Full Stack Engineer 1名 • 自然言語処理専門 Data Scientist 1名 • Frontend Engineer 1名 • SRE/Ops, Scrum Master/Management 1名(私) • 5名の少人数チームでやや開発より
  6. 開発体制 • 開発方式 - Agile, Scrum - DevOps, CI/CD ・インフラ

    - AWS - Microsoft Azure - Vultr, さくら etc • 12 factor app 準拠 https://12factor.net/ja/
  7. 問題点・要件① • インフラを手動で触りたくない。Infra as a Code したい。 • プログラマはインフラを一度作ったら忘れてしまう。 •

    パラメータをExcelで管理したくない(重要) • これらを解決するために、AWS CodePipeline、CodeDeployなど使ってみたが、限界を感じ る(Multi Cloudに使えない等)
  8. 問題点・要件② • 開発環境と本番が別々だが、同じものをDeployしたい(Build Once) • 開発環境でテストされたものを本番にDeployしたい • パラメータはソースコードと別のところに、環境毎に保存・管理したい

  9. GitHub Actionsの登場と採用 • その時、GitHub Actionsがリリース (2019年) • GitHub Actions :

    “開発ワークフローをリポジトリの中で自動化し、カスタマイズし、実行” するもの • https://docs.github.com/ja/actions • すでにGitHubを使っているので、導入しやい • 説明聞いたら使いやすそう • 無料
  10. への道のり

  11. 問題点・要件①はすぐ解決 • インフラを手動で触りたくない。Infra as a Code したい。 ✅ • プログラマはインフラを一度作ったら忘れてしまう。

    ✅ • パラメータをExcelで管理したくない(重要) ✅ • これらを解決するために、AWS CodePipeline、CodeDeployなど使ってみたが、限界を感じ る(Multi Cloudに使えない等) ✅
  12. 問題点・要件② • 開発環境と本番が別々だが、同じものをDeployしたい(Build Once) • 開発環境でテストされたものを本番にDeployしたい • パラメータはソースコードと別のところに、環境毎に保存・管理したい これだけではない。さらに

  13. 問題点・要件③ • 開発環境と本番環境ではパラメータが異なる • 開発環境でパラメータを変えたら開発環境だけDeployしたい • パラメータは各環境毎に管理し、それぞれ履歴に残したい

  14. 解決策 • Build と Deploy の2段階に分ける • そのために、Repository を ソースコードとパラメータの2つに分ける

  15. REPOSITORY の中身 hoge というサービス  hoge-infra  hoge-infra-params インフラのソースコード インフラをDeployするコードと

    環境毎のパラメータ
  16. hoge-infra Repoの構造 インフラのソースコード インフラのBuild(CI)

  17. hoge-infra-params Repoの構造 インフラソースコードのバージョン インフラのDeploy (CD) 環境毎のパラメータ

  18. hoge-infra CI/CD 1 merge to main Unit Test Build Etc...

    S3 Store Package Version Parameters Change Package Version Development Environment (Staging) hoge-infra/ vpc.cf.yaml vpc.cf. yaml hoge-infra-params/ vpc/packages/develop.yaml 続く
  19. hoge-infra CI/CD 2 S3 Store Package Version Parameters Version Development

    Environment (Staging) Package Version Parameters Change Package Version Production Environment hoge-infra-params/ vpc/packages/prod.yaml hoge-infra-params/ vpc/packages/develop.yaml 前のページ から続く
  20. hoge-infra workflow 1

  21. hoge-infra workflow 2

  22. 問題点・要件②が解決 • 開発環境と本番が別々だが、同じものをDeployしたい(Build Once) ✅ • 開発環境でテストされたものを本番にDeployしたい ✅ • パラメータはソースコードと別のところに、環境毎に保存・管理したい✅

  23. 問題点・要件③ • 開発環境と本番環境ではパラメータが異なる • 開発環境でパラメータを変えたら開発環境だけDeployしたい • パラメータは各環境毎に管理し、それぞれ履歴に残したい

  24. 解決策 hoge というサービス  hoge-infra  hoge-infra-params 環境毎のパラメーターファイルをそ れぞれ格納してDeployさせる インフラのソースコード

    インフラのソースコード 環境毎のパラメータファイルを それぞれ格納してDeployさせる
  25. hoge-infra-params Repoの構造 インフラソースコードのバージョン インフラのDeploy (CD) 環境毎のパラメータ

  26. パラメータの例 • Develop/prodで比較する EC2 develop.yaml (開発環境) EC2 prod.yaml (本番環境)

  27. Deploy parameters to develop merge to main Unit Test Build

    Etc... S3 Change Parameters Store Package Version Parameters Change Package Version Development Environment (Staging) hoge-infra-params/ ec2/parameters/develop.yaml
  28. Deploy parameters to prod merge to main Unit Test Build

    Etc... S3 Change Parameters Store Package Version Parameters Change Package Version Production Environment hoge-infra-params/ ec2/parameters/prod.yaml
  29. hoge-infra-params workflow 1

  30. hoge-infra-params workflow 2

  31. 問題点・要件③の解決 • 開発環境と本番環境ではパラメータが異なる ✅ • 開発環境でパラメータを変えたら開発環境だけDeployしたい ✅ • パラメータは各環境毎に管理し、それぞれ履歴に残したい ✅

  32. 完成した

  33. CI and Deploy to Develop merge to main Unit Test

    Build Etc... S3 Change Parameters Store Package Version Parameters Docker-Compose etc... Change Package Version Development Environment (Staging) インフラの ソースコード インフラの パラメータ (開発環境)
  34. Deploy to Prod S3 ECR Registry rs Store Store Package

    Version Parameters Docker-Compose etc... Version Development Environment (Staging) Change Parameters Package Version Parameters Docker-Compose etc... Change Package Version Production Environment インフラの パラメータ (本番環境)
  35. AZ #A AZ #C AZ #A AZ #C AZ #B

    AZ #C Azure Tokyo Canary Release Develop Prod #2 (Servers) Servers Servers Tokyo Servers Servers Singapore Servers Servers San Francisco Prod #1 (Servers) Servers Servers Tokyo AZ #A AZ #C Servers Servers Singapore AZ #A AZ #C Servers Servers Frankfurt AZ #A AZ #C Release 1 Release 2 Release 3 Release 4 Approve Approve Approve Approve GitHub Actions Push
  36. 今後の課題 • Repositoryが2つなのでActionsが2回実行され、時間がかかると感じる • 従来のOpsとしては、パラメータをまとめて一元管理したくなる • これがベストプラクティスかは断言できない • モノレポに戻りたい時もある

  37. 公開資料 • 本スライド: https://speakerdeck.com/mihyon • Blog : https://qiita.com/qualitia_cdev

  38. ご静聴ありがとうございました。