さてさて。今年も残るところあとわずかですね~⛄🎅
OpenShift Advent Calendar 2023 の6日目は、OpenShiftの技術営業のフリをしている北山からお届けしますー。
今年も日々の提案ナレッジをお届けっ!!と思ったのですが、今回はちょうど cdCon Japan に参加する機会を頂いたので、現地レポートをお送りします。
ところで皆様は、 Open Source Summit Japan 2023 に参加されたことはありますでしょうか?? クラウドネイティブ界隈だとCNCFのKubeConが有名どころですが、Open Source SummitもLinux Foundationによって開催されているオープンソースの国際イベントの一つです。毎年欧州や北米と合わせ、日本でも開催されている貴重なイベントで、2023年はお台場(Ariake Central Tower Hall & Conference)で行われました。実は毎年、名だたる国産SI企業様と並んでRed Hatもスポンサーしてるんですよっ!?

その併設イベントとして、今年もcdCon Japanを始めとするいくつかのイベントが同じ場所で開催されました。　

Hyperledger Member Summit Tokyo : エンタープライズグレードのブロックチェーン技術に関するイベント
cdCon Japan : 継続的デリバリーに関するイベント
OpenSSF Day Japan : オープンソースセキュリティに関するイベント
Open Compliance Summit : コンプライアンスに関するイベント

今回紹介するcdConは、Linux Foundaionの傘下にあるContinuous Delivery Foundation(CDF)によって運営されているカンファレンスです。

Continuous Delivery Foundation(CDF)のプロジェクト

CDFは、継続的インテグレーションや継続的デリバリー(CI/CD)の発展に伴い、プロジェクト開発者やエンドユーザー、またベンダー間の中立的なコラボレーションを促進して、CI/CDの業界仕様を推進した団体です。
2023/12時点でCDFがホストしているオープンソースプロジェクトには、以下のものがあります。
詳細: Continuous Delivery Landscape

いつの間にか増えてきましたねぇ~。これらのプロジェクトの選定は、CDFの技術概要委員会(TOC)によって採択されています。
このプロジェクトを見ると「OpenShift GitOpsでも利用されているArgoCDはないの？」と思う方もいらっしゃるかもしれませんが、ArgoCDはCNCFに寄贈され、2022/12にGraduated Projectとして認定されています。
このようにオープンソースプロジェクトひとつとっても、CNCFやCDFなど、どこの団体に所属するのかといった議論だけでなく、cdConとは別にArgoConやFluxConというようにプロジェクト独自のカンファレンスを行う道もあります。それぞれプロジェクトのイロがありつつも、GitOpsはContinuous Deliveryには欠かせない技術要素としてcdConのセッションにもよくでてきます。
たとえば、Red HatのKevinのセッションでは、Quarkus製のレーシングゲームが紹介され、会場みんなでArgoCDを使用したリリースを体験しました。

cdCon Japan 2023の気になったセッション

さて。参加したセッションの中から気になった以下のセッションについて、簡単にメモ。

注1. 資料の利用規約を配慮し、今回は下記よりpdfを直接DLください。
注2. 本編のPipelineは「Tekton Pipelines」= CRD: Pipelinesを示します。

"Pipeline as Code" Journey

Date: Monday, December 4 • 16:10 - 16:40
Presenter: Jun Makishi & Kasuki Aizawa, NTT Communication
Agenda Link: https://sched.co/1TzRl
Presentaion: "Pipeline as Code" Journey

セッション概要

NTT Communicationさんの中で使われているTekonパイプラインを管理するために Pipeline as Code を実装されたお話です。
ここでは docomo business RINK というサービスを安定的にデプロイするための「パイプライン」を動的に提供するSREとしての取り組みを発表いただきました。

Journey 1 : Pipeline as Code the moderate way

ここまでは、SREチームが標準的なPipelineを提供することを前提とした運用。

Step#0: First development flow of Pipeline as Code
SRE側で標準的なPipelineを作成し、プルリクエストでの変更によってパイプラインを管理。アプリケーション側でPipelineRunを実行。
Problem: Disturbing application team’s activity
ただし、Pipelineの作成が失敗するとアプリケーション側でPipelineRunが実行できずスタックしてしまう。
Step#1: Pipeline end-to-end testing
そのため、パイプライン実行確認専用のパイプラインテスト環境を作成。
Problem: Firefighting pipeline troubles
異なるアプリケーションでは異なるパイプライン構築が必要であり、個別カスタマイズを要求されるとPipeline開発者に依存してしまう。
Step#2: Scaled pipeline with standardization
パイプライン作成のスタンダード化やオンボーディングを各チームで実施。チームビルディングによって対応。

Journey 2: Pipeline as Code the hard way

ここからは、SREチームがPipeline Template生成ツール管理し、各アプリケーションチーム側でPipelineを生成する運用。

Problem: One-size-fill-all Pipeline
すべてのアプリケーションチームが標準Pipelineに異なるパラメーターを入れると、パラメーターが多すぎる
Step#3: Composable pipeline
テンプレートとして CUE Lang を使い、Pipelineそのものを生成できる「Composable pipeline」の仕組みを構築
Pipeline generation at glance
「Composable pipeline」の仕組みによって、Pipeline生成の役割はアプリケーションチーム側に移譲。
アプリケーションチームは必要なタスクを選ぶだけで、それに応じたPipelineを生成できる。
Implementing packages with tests
SREチームは「Composable pipeline」の仕組みをテストするために、期待するマニフェストと、CUEによって生成されたマニフェストを比較してテスト。
Problem: unstable packages
一つの環境でテストしていたため、異なるKubernetesバージョンやクラウドAPIによるテストカバレッジが少なかった。
Step#4: Pipeline package testing Golangによるテストツールを作成し、異なるKubernetes APIのテストができる用にテストカバレッジを増強。
Demo
最後にDEMOの実施。近日Demoコードを公開予定!!

Conclusion

CUE Langだとメンテナンスできる人も限られるため、今後はCUEではなくYAMLで対応できるように検討。TektonもカスタムOperatorで拡張していくことを検討。

My impressions

"Pipeline as Code"という概念は知っていたものの、実際にTekton Pipelinesを使ってプロジェクトを回している話は初めてだったので、個人的に色々学ぶことができました。またマニフェスト生成方法に関しても、普段はKustomizeやHelm Chartに慣れてしまっていましたが、CUE Langを使っていたのが興味深かったです。
すでに「Composable pipeline」の仕組みである、Adaptersが以下に公開されていたので、ソースコードをいくつかのぞいて見てました。(あくまで見たただけで、すいませんwww)
いくつかのAdapters(Task生成用かな？)からPipelineの中でやりたいTaskを選んで、CUEでコンパイルをすればPipelineが生成されるのかな？と妄想。
https://github.com/qmonus/official-cloud-native-adapters/tree/main/docs/cicd

例: official-cloud-native-adapters/pipeline/scan/trivyGcp.cue

package trivyGcp

import (
    "strings"
    "qmonus.net/adapter/official/pipeline:utils"
    "qmonus.net/adapter/official/pipeline/tasks:trivyImageScanGcp"
)

DesignPattern: {
    name: "imageScan:trivyGcp"

    pipelineParameters: {
        image:        string | *""
        shouldNotify: bool | *false
    }

    let _imageName = strings.ToLower(pipelineParameters.image)

    _scanTask: string

    if pipelineParameters.image != "" {
        _scanTask: {
            utils.#concatkebab
            input: [_imageName, "image-scan-gcp"]
        }.out
    }
    if pipelineParameters.image == "" {
        _scanTask: "image-scan-gcp"
    }
…

社内ツールだけではもったいないと思ってしまうほどちゃんとドキュメント化もされていたので、SREのオンボーディングの取り組みが素晴らしいなぁと思った次第です。
Tektonの中にも Pipeline as Code の仕組みがありTektonHubからPipelines生成ができるので、今後はこうしたツールに置き換わるのかなー。とも期待。
cdCon含め、それぞれの業界標準や規則、ガバナンスを確認するCI/CDパイプラインが整ってくると、日本のExcel $ 目grep 文化も減るのにな~。と改めて感じたところでした。
おしまい。