CI/CD＠技術的要素

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。

• https://hiroki-it.github.io/tech-notebook/

01. CI/CD とは

CI/CD は、DevOps を構成する『技術的要素』『組織文化的要素』のうち、技術的要素に相当する概念である。

02. CI/CD の必要性

自動化による高品質なシステムの維持

CI/CD の一連の流れ (パイプライン) のなかでテストを自動化できる。

そのため、一定水準以上の品質を維持しやすくする。

システム (ソフトウェアとハードウェアがあるがここでは特にソフトウェア) には、例えば以下の品質の特性がある (ISO の規格の場合) 。

• 機能性
• 性能効率性
• 互換性
• 利便性 (使いやすさ)
• 信頼性
• 安全性
• 保守性
• 移植性 (汎用性)

テストステップで特に機能性を検証し、一定水準以上の品質を維持するように設計する。

自動化による工数削減

開発からリリースには、以下のステップがある。

CI/CD の一連の流れ (パイプライン) のなかでこれらのステップを自動化できるため、工数を削減できる。

1. アプリケーションのビルド
2. テスト
3. 承認
4. DB マイグレーション（アプリケーションを起動する前に実行する必要がある）
5. アプリケーションのデプロイ

03. CI/CD パイプラインのステップについて

CI/CD パイプラインとは

CI パイプラインと CD パイプラインを組み合わせた手法のこと。

• https://www.redhat.com/ja/topics/devops/what-cicd-pipeline

CI パイプライン

▼ CI パイプラインとは

アプリケーションの機能追加/変更/削除からテストまでを『自動的』かつ『継続的に』実行する。

ステップ	詳細	自動化の可否	説明
ビルド	アプリケーションのビルド	⭕️	CI ツールと IaC ツールで自動化できる。
テスト	ホワイトボックステスト (ユニットテスト、機能テスト、回帰テストなど) の実施	⭕️	CI ツールとテストフレームワークで自動化できる。
	結合テスト	△	基本的にはブラックボックステストで、動作を確認する必要がある。ただし、自動的な E2E テストを簡易的な結合テストの代わりにしてもよい。
	コーディング規約に関するレビュー	⭕️	CI ツールと静的解析ツールで自動化できる。
	仕様に関するレビュー	×	GitHub 上でレビューする必要がある。

• https://tracpath.com/works/devops/11_topics_for_devops/

CD パイプライン

▼ CD パイプラインとは

変更内容を『自動的』かつ『継続的に』ステージング環境と本番環境にデプロイする。

▼ ステージング環境の場合

ステップ (ステージング環境の場合)	詳細	自動化の可否	説明
DB マイグレーション	ステージング環境の DB に対するデプロイ。アプリケーションを起動する前に実行する必要がある。	⭕️	CD ツールで自動化できる。
初期データ（Seed）の挿入	ステージング環境で動作確認するために、大量のダミーデータを挿入する	⭕️	CD ツールで自動化できる。
アプリケーションのデプロイ	ステージング環境に対するデプロイ	⭕️	CD ツールで自動化できる。

▼ 本番環境の場合

本番環境へのデプロイ前に、承認ステップを設ける。

承認ステップがある場合を、デプロイではなく特に『デリバリー』と呼ぶことがある。

ステップ (本番環境の場合)	詳細	自動化の可否	説明
承認	本番環境に対するデプロイの承認	⭕️	CD ツールで自動化できる。
DB マイグレーション	本番環境の DB に対するデプロイ。アプリケーションを起動する前に実行する必要がある。	⭕️	CD ツールで自動化できる。
アプリケーションのデプロイ	本番環境に対するデプロイ	⭕️	CD ツールで自動化できる。

• https://blog.kyanny.me/entry/2014/12/24/145001
• https://aws.amazon.com/jp/devops/continuous-delivery/

PD：Progressive Delivery

特にカナリアリリースやブルー/グリーンデプロイメントでデプロイされたアプリでは、ユーザーのアクセスから収集したテレメトリーを分析し、問題が起これば自動的にロールバックする。

問題の判定基準には、障害の有無や SLO 閾値未満がある。

ステップ	詳細	自動化の可否	説明
分析	ステージング環境のテレメトリーを分析	⭕️	CD ツールと監視ツールを組み合わせて自動化できる。
	本番環境のテレメトリーを分析	⭕️	CD ツールと監視ツールを組み合わせて自動化できる。

• https://r-kaga.com/blog/what-is-progressive-delivery
• https://codezine.jp/article/detail/14476
• https://speakerdeck.com/tozastation/3-shake-inc-niokeru-progressive-dellivery-dao-ru-madefalsenao-mitoqu-rizu-mi-cndt2021?slide=25

04. 要件定義事項

CI/CD パイプラインのステップをどこまで採用する必要があるかの質問

CI/CD パイプラインには種々のステップがあり、どこまで採用するべきかを判断するために、以下をヒアリングする。

質問	質問の意図
アプリケーションをリリースするまでに実施している手順は？	現状、どのような方法でアプリケーションをリリースしているのかを知りたい。
本番環境にて、バグが混入のインシデントが “頻繁に起こることがある？	品質を維持できているかどうかを聞きたい。CI/CD のビルドステップやテストステップを採用する必要があるか。もしテストコード自体も採用していない場合はこちらも採用してもらう必要があるが、テストコード設計は CI/CD と話が逸れるため言及しない。

アプリケーションが稼働しているインフラの技術スタックについての質問

CI/CD の設計はアプリケーションが稼働している既存のインフラの技術スタックで決まるため、以下をヒアリングする。

1. まずはこちらをどうぞ。

質問	質問の意図
アプリはコンテナ化しているか	アプリケーションをコンテナ化しているかどうかで適切な CIOps が異なるため、聞いておきたい。
アプリケーションをコンテナ化している場合は、コンテナオーケストレーションツールを使用しているか	コンテナオーケストレーションツールを使用しているかどうかで適切な CIOps が異なるため、聞いておきたい。

1. アプリケーションをコンテナ化していない場合は、こちらをどうぞ。

質問	質問の意図
オンプレでアプリケーションが稼働しているか。	オンプレ上で非コンテナ化のアプリケーションを動かしている場合、適切な CIOps が異なるため、聞いておきたい。クラウドプロバイダー (例：AWS) によっては、オンプレ上に専用エージェント (CodeDeploy エージェント) を稼働させることにより、クラウドからオンプレサーバー上にアプリケーションを安全にデプロイできる場合がある。
IaaS (Amazon EC2、GCE など) でアプリケーションが稼働しているか。	IaaS 上で非コンテナ化のアプリケーションを動かしている場合、適切な CIOps が異なるため、聞いておきたい。クラウドプロバイダー (例：AWS) によっては、CI/CD ツール (例：Code 三兄弟) やクラウドロードバランサーを使用することで、IaaS 上にアプリケーションを安全にデプロイできる可能性がある。
非コンテナ FaaS (Lambda、CloudFunction など) でアプリケーションが稼働しているか。	FaaS 上で非コンテナ化のアプリケーションを動かしている場合、適切な CIOps が異なるため、聞いておきたい。クラウドプロバイダーによっては、CI/CD ツールを使用することで、非コンテナ FaaS 上にアプリケーションを安全にデプロイできる可能性がある。

1. アプリケーションをコンテナ化しつつ、オーケストレーションツールを使用していない場合は、こちらをどうぞ。

質問	質問の意図
オンプレ上で docker コマンドを使用しているか。	オンプレ上で docker コマンドを使用してアプリケーションを動かしている場合、適切な CIOps が異なるため、聞いておきたい。クラウドプロバイダーによっては、オンプレ上に専用エージェントを稼働させることにより、クラウドからオンプレサーバー上にアプリケーションを安全にデプロイできる場合がある。もしクラウドプロバイダーを使用できないのであれば、オンプレのみで完結できる CI/CD ツール (例：Capistrano) の検討が必要になる。
コンテナ化 Faas (Lamba、CloudFunction) を使用しているか。	コンテナ化 FaaS のアプリケーションを動かしている場合、適切な CIOps があるため、聞いておきたい。CI/CD ツールを使用することで、コンテナ化 FaaS 上にアプリケーションを安全にデプロイできる可能性がある。

1. アプリケーションをコンテナ化しつつ、Kubernetes 系ではないオーケストレーションツールを使用している場合は、こちらをどうぞ。

質問	質問の意図
オンプレ上で Docker Compose を使用しているか。	Docker Compose でオーケストレーションを実施している場合、適切な CIOps があるため、聞いておきたい。
CaaS (Amazon ECS、Google Cloud Run) を使用しているか。	CaaS でオーケストレーションを実施している場合、適切な CIOps があるため、聞いておきたい。

1. アプリケーションをコンテナ化しつつ、Kubernetes 系のオーケストレーションツールを使用している場合は、こちらをどうぞ。

質問	質問の意図
オンプレ上でセルフマネージドな Kubernetes オーケストレーションツール (Kubeadm、Rancher) を使用しているか。	セルフマネージドな Kubernetes オーケストレーションツールを使用している場合、適切な CIOps があるため、聞いておきたい。
ベアメタル型 IaaS 上でクラウドプロバイダーの Kubernetes オーケストレーションツール (例：Amazon EKS Anywhere、Google Cloud Anthos on Baremetal) を使用しているか。	ベアメタル型 IaaS 上でクラウドプロバイダーの Kubernetes オーケストレーションツールを使用している場合、適切な CIOps があるため、聞いておきたい。
CaaS (EKS、GKE) を使用しているか。	CaaS を使用している場合、適切な CIOps があるため、聞いておきたい。

ドメインに応じた規定についての質問

準拠しなければならない国の規定についてヒアリングする。

質問	質問の意図
システムを作るにあたって、準拠しなければならない規定はあるか	システム化するドメイン (例：クレジットカード) によっては、国が用意した規定の要件 (例：PCI DSS) に準拠したシステムを設計しないといけない場合がある。
過去に準拠したシステムは構築したことがあるか	過去の設計を参考にすれば、要件をいずれの技術をして実装できるかがわかる。
監査が入るタイミングはいつか。	構築時点では完全に準拠できていなくても

05. 要件回答に基づく技術選定フローチャート

要件定義でヒアリングした回答に基づいて、要件にあった CI/CD を選択していく。

graph TD;
  A[はじめに] --> B[Opsの種類]

  B ---> | アプリケーションを<br>コンテナ化していない | C[そのまま進む]
  B --> | アプリケーションを<br>コンテナ化している | D[コンテナオーケストレーションツールの種類]

  C ---> | オンプレ | E[オンプレのための<br>CIOps]
  C ---> | Amazon EC2, Google GCE | F["IaaSのための<br>CIOps"]
  C ---> | AWS Lambda, Google Cloud Run Functions | G[非コンテナFaaSのための<br>CIOps]

  D ----> | Docker compose on オンプレ | H[Docker composeのための<br>CIOps]
  D ----> | Amazon ECS, Google Cloud Run  | I[CaaSのための<br>CIOps]
  D --> | いずれも使っていない | J[そのまま進む]
  D ----> | Kubeadm, Rancher, on オンプレ | K[オンプレのための<br>GitOps]
  D ----> | Amazon EKS Anywhere Baremetal Deployment, Google Anthos on Baremetal| L[IaaSのための<br>GitOps]
  D ----> | Amazon EKS, Google Cloud GKE | M[CaaSのための<br>GitOps]

  J --> | AWS Lambda, Google Cloud Run Functions | N[コンテナ化FaaSのための<br>CIOps]
  J --> | dockerコマンド on オンプレ| O[dockerコマンドのための<br>CIOps]

  E ---> P[CIOpsのための<br>ブランチ戦略]

  F ---> P

  G ---> P

  H ---> P

  I ---> P

  K ---> Q[GitOpsのための<br>ブランチ戦略]

  L ---> Q

  M ---> Q

  N ---> P

  O ---> P

06. CIOps

CIOps とは

DevOps を実現する技術的要素の 1 つ。

CI ツール (例：GitHub Actions、CircleCI、GitLab CI、Argo Workflows、Tekton など) を使用して、CI パイプラインと CD パイプラインの両方を実行する手法のこと。

• https://atmarkit.itmedia.co.jp/ait/articles/2105/26/news005.html
• https://medium.com/orangesys/kubernetes-anti-patterns-lets-do-gitops-not-ciops-62cfecd1c1a9

CIOps を採用する場合の CI ツールの一覧

CIOps では、すべての手順を CI ツールで実施する。

そのため、多機能かつユーザーフレンドリーなツールがよい。

• CircleCI
• GitHub Actions
• GitLab CI
• Jenkins
• CodePipeline

アンチパターンとなる場合

▼ セキュリティ

Kubernetes の CI/CD パイプラインに CIOps を採用する場合、セキュリティ上の理由で CIOps はアンチパターンとされている。

リポジトリ側に kubeconfig ファイルを配置する必要がある。

kubeconfig ファイルは機密性が高く、漏洩させたくない。

ただし、どうしても CIOps を採用したいのであれば、暗号化キー (例：AWS KMS、Google Cloud CKM、GPG、PGP など) で kubeconfig ファイルを暗号化しておき、これを CI パイプライン内に出力する。

• https://devops-blog.virtualtech.jp/entry/20220418/1650250499

▼ 責務境界の分離

Kubernetes の CI/CD パイプラインに CIOps を採用する場合、責務協会の分離上の理由で CIOps はアンチパターンとされている。

CIOps の場合、CI と CD が強く結合しており、切り分けにくい。

そのため、結果的に CI の構築/運用を担当するアプリエンジニアが、CD も構築/運用することになる。

特に、CD はインフラに影響するため、アプリエンジニアチームが責任を持つべきではない。

一方で GitOps であれば、CI と CD を切り分けやすいため、CI と CD の構築/運用をアプリチームと SRE チームで分担できるようになる。

• https://news.mynavi.jp/techplus/article/techp5025/

07. GitOps

GitOps とは

DevOps を実現する技術的要素の 1 つ。

CI ツール (例：GitHub Actions、CircleCI、GitLab CI、Argo Workflows、Tekton など) を使用して CI パイプラインを、または CD ツール (例：ArgoCD、Flux など) を使用して CD パイプラインを、実装する手法のこと。

• https://atmarkit.itmedia.co.jp/ait/articles/2105/26/news005.html
• https://github.com/argoproj/gitops-engine/blob/v0.6.2/specs/design.md

技術ツール例

GitOps では、CD ツールで実施する手順が多いため、多機能かつユーザーフレンドリーなツールがよい。

執筆時点 (2022/11/09) では、どのようなユースケースでも ArgoCD がよいかもしれない。

特に OSS の開発が活発である。

• ArgoCD
• Flux
• Jenkins X
• PipeCD
• Harness

相性のよい CI ツール

CIOps でなく GitOps を採用する場合、アプリはマイクロサービスアーキテクチャを採用しているはずである。

GitOps では、CI ツールで実施する手順が少ないため、基本的にいずれのツールを使用しても問題ない。

ただし、リポジトリの分割戦略としてポリレポ (マイクロサービスごとにリポジトリを用意する) を採用している場合がある。

この場合、リポジトリで同じ設定ファイルを横展開するよりも、CI ツールの設定ファイルの共有部分は特定のリポジトリで中央集中的に管理するとよい。

他のリポジトリでこれを読み込むようにすると、管理が楽になる。

外部リポジトリに置いた設定ファイルをリモート参照できるような機能を持つ CI ツール (例：GitLab CI) であれば、ポリレポ戦略と相性がよい。

CI/CD パイプラインのステップ

▼ CI パイプラインのステップ

1. アプリケーションのビルド
2. テスト

▼ CD パイプラインのステップ

1. 承認
2. DB マイグレーション（アプリケーションを起動する前に実行する必要がある）
3. アプリケーションのデプロイ

DB マイグレーションを実行するタイミングには、次がある。

• CD ツール（例：ArgoCD）でアプリケーションのデプロイ直前に実行する
• Dockerfile で、アプリケーションの起動コマンドの直前にマイグレーションコマンドを実行する
• CI ツールとも CD ツールとも違う別のツールで実行する