Oracle Cloud Hangout Cafe Season4 #3「CI/CD 最新事情」(2021年6月9日開催)

1.GitHub ActionsのCI構成
下図は、デモ構成で確認したGitHub Actionsが処理するCIの構成です。

GitHub Actions CI構成

GitHub Actionsでは、main.ymlを利用して、CIにおけるワークフローを定義します。その処理内容を確認します。Codeリポジトリ側から見ていきます。

【「GitHub Actions main.yaml 1」図の処理内容】

• mainブランチへのプッシュをトリガーとする処理
• BuildKitによるコンテナイメージビルド処理
• GitHub Actionsの実行ナンバリングをタグにする処理

GitHub Actions main.yaml 1

【「GitHub Actions main.yaml 2」図の処理内容

• dockleによるイメージ診断処理
• Trivyによるイメージスキャン処理

GitHub Actions main.yaml 2

【「GitHub Actions main.yaml 3」図の処理内容】

• OCIRへのログイン処理
• OCIRへのコンテナイメージプッシュ処理

GitHub Actions main.yaml 3

【「GitHub Actions main.yaml 4」図の処理内容】

• GitHubへのログイン処理
• Configリポジトリからvalues.yamlファイルのクローン処理
• 新規ブランチの作成処理
• values.yamlファイルのコンテナイメージタグの更新処理
• Configリポジトリに作成した新規ブランチへのプッシュ処理
• Configリポジトリへのプルリクエスト処理

GitHub Actions main.yaml 4

ここからは、Configリポジトリ側の処理内容です。

【GitHub Actions main.yaml 5」図の処理内容】
Conftestでは、values.yamlファイル内のコンテナイメージタグにlatest タグがある場合、faildとする定義に従ってポリシーチェックを実行します。

• プルリクエストをトリガーとする処理
• Conftestによるポリシーチェック処理

GitHub Actions main.yaml 5

以上が、GitHub Actions CIにおけるワークフローの定義です。

2.Gatekeeper設定
デプロイ対象となるOKEのKubernetesクラスタにGatekeeperの設定をしています。Conftestと同様にlatestタグがある場合、faildとする定義に従ってポリシーチェックを実行します。

Gatekeeper設定

実際のデモについては、こちらの動画リンクから見られます。

CI/CD これからを見る

Progressive Deliveryについて

1. Progressive Deliveryとは?
Progressive Deliveryは、分析しながらデプロイを実行して、その分析結果が失敗と判断された場合は自動的にロールバック、成功と判断された場合はデプロイを継続して行うデプロイ手法です。

Progressive Delivery

Continuous Deliveryの次のステップとして、メトリクスを取得して分析を行います。その分析を基に評価して、デプロイするかロールバックするかを判定する仕組みです。

2. 主なツール
Progressive Deliveryを実現する主なツールは以下です。

• Argo Rollouts
• Flagger
• PipeCD

3. Flaggerから見るProgressive Delivery
Flaggerは、KubernetesをプラットフォームにProgressive Delivery を実現するツールです。

Kubernetes CNIやサービスメッシュプロダクト(Istio、Linkerdなど)と組み合わせたトラフィックシフトによるBlue/Greenデプロイ形式にも対応しています。サービスメッシュプロダクト、Ingress Controller(Nginx、Countorなど)と組み合わせたCanaryリリース、A/Bテストといったデプロイ形式にも対応しています。また、GitOpsツールと組み合わせてProgressive Deliveryを実現できます。

ここでは、Flaggerと親和性のあるFluxと組み合わせたFlaggerドキュメント情報を基に見ていきます。

FluxからKubernetesクラスタにデプロイが実行される際に、Prometheusからメトリクスを取得して分析しながら、異なるバージョンのアプリケーションへのトラフィック量を変更(Canaryリリース)していきます。

Flagger Progressive Delivery
【出典】「Flagger Official Documents - Introduction」

Flaggerには、Webhookを利用した分析の拡張機能があります。以下8種類のHookがあり、そのレスポンスコードによって切り替えます(【参考】「Flagger Official Documents - Webhooks」)。

• confirm-rollout
• pre-rollout
• rollout
• confirm-traffic-increase
• confirm-promotion
• post-rollout
• rollback
• event

このことを踏まえて、IstioとFlaggerを組み合わせたチュートリアルが公式サイトにあります。

カナリア分析が開始されると、FlaggerはトラフィックをCanaryにルーティングする前にpre-rollout webhookを呼び出します。カナリア分析は、HTTPメトリクスとロールアウト フックを毎分検証しながら5分間実行されます。

Istio Canary Deployments 1
【出典】「Flagger Official Documents - Istio Canary Deployments」

下図は、Flaggerが分析しながらトラフィック量を変更して、最終的に最新バージョンにシフトして行く流れです。

Istio Canary Deployments 2
【出典】「Flagger Official Documents - Istio Canary Deployments」

おわりに

CIOps、GitOps、Progressive Deliveryの流れで、コンテナアプリケーション開発をベースにCI/CDのこれまで、今、これからを見てきました。あくまでも、これらは技術手段の一部です。こうした技術手段を活かした実現する目的を忘れてはいけません。CI/CD環境を整備することで、スピード(Agility)、信頼性(Reliability)を高めて、品質及び生産性の高いアプリケーション開発の実現を目指します。

これまで時間やコストを要していた箇所を改善し、より良いビジネスロジックに時間やコストを傾けて、リリースサイクルを速め、エンドユーザに最高品質のサービスの提供につなげていきます。そして、最終的にエンドユーザの満足度、企業価値や収益の向上を見込むことができるのではないでしょうか。

最後に