PipeCD Terraform Providerの開発とサイバーエージェントのインナーソース事例

WRITER: 前田 拓
このエントリーをはてなブックマークに追加

はじめに

こんにちは、FANTECH本部の前田(@arabian9ts)です。

サイバーエージェントでは、アプリケーションのデプロイにPipeCDを利用するサービスが増えています。
PipeCDはサイバーエージェント発のOSSであり、先日、PipeCDがCNCF Sandboxに参加することが決まりました。

この記事では、FANTECH本部とAI事業本部にて、PipeCDを実務で活用する上で感じた課題と、その解決策として開発したTerraform Providerとインナーソース事例について紹介します。
こちらの取り組みは、FANTECH本部に所属する前田、AI事業本部の黒崎(@kuro_m88)、渋谷(@sivchari)からスタートした取り組みになります。

 

FANTECH本部での課題とPipeCDの活用

FANTECH本部では、ファンとアーティストをテクノロジーでつなぐための様々な取り組みをしています。
以前、「FanTechで日本の閉塞感を打破する」サーバーサイドエンジニアの開発思想にも記載しましたが、私のチームでは1コードベースで、事業を横断した複数のサービスを同時開発・同時運用する体制を採っています。

そして、改めてになりますが、PipeCDの特徴として大きな点を挙げてみます。
1. GitOpsスタイルで、デプロイはマニフェストコードの変更で反映される
2. PipeCDの設計上セキュアにデプロイが可能
3. 統一されたインターフェースでマルチプラットフォーム対応が可能

どれも魅力的な要素ですが、今回肝となったのはアプリケーション数が今後も増え続けることです。

アプリケーションが増え続けることによる課題

私のチームでは、2023年7月現在、120以上のアプリケーションを管理しており、各アプリケーションに対してPipeCD上のアプリケーションが紐づいています。
これらのアプリケーションはマルチテナント型ではなく、モジュラーモノリスで構成された複数のアプリケーションのセットを、運用しているサービス分管理しています(例えば、管理画面用、toCユーザー用、toBユーザー用、etc、を各サービス分といった具合です)。
同時開発するサービス数は今後も増え続けるため、それらのアプリケーションのデプロイを効率的に、そして安全に実現するため、GitOpsは私のチームの課題にマッチしています。

しかし、これまでのPipeCDでは、新規に展開するサービスが増えた場合に、コンソール上で手動で複数のリソースを作成する必要がありました。
私のチームではマルチリージョン展開しているサービスもあり、toCユーザー用アプリケーションに限ってもリージョンの数分のリソースを手動で作成する必要がありました(そして何度か誤った設定をしてしまった過去があります)。

これは、アプリケーション数が多い私のチームやAI事業本部では共通の課題でした。

 

アプローチとインナーソースの実践

プロジェクト化の流れと成果物

PipeCDはサイバーエージェント発のOSSということもあり、メンテナーと社内で抱えている課題について気軽に相談することができました。
実は、Terraform Providerを自作する方針である程度固まっていたのですが、PipeCDとしてのロードマップなども含め、どう実現していくかを議論しました。

結論、PipeCDとしてのロードマップには、Terraformを始めとするコード管理に関する内容は含まれていなかったこともあり、メンテナーに開発してもらうにはやや時間がかかりそうでした。
そのため、後にPipeCDに寄贈するまでを含め、PipeCDプロジェクトとは別で開発を進めてしまう方針で話は着地し、同じ課題を持っていた/興味を持ってくれた黒崎、渋谷とTerraform Providerの開発をスタートしました。
そして、つい先日PipeCD Terraform Providerとして公開するに至りました。
これにより、TerraformでのPipeCDリソース管理が可能になりました。

共同開発は結構軽いノリで決まりました(記念撮影)。
共同開発が決まったやり取りの記念撮影

 

Terraform Providerの概要

私の拙い英語ではありますが、Providerの簡単なデモをCommunity Meetingで紹介しています。
デモで使用したコードはGitHub上に公開してあります。

以下に、TerraformでPipeCD Applicationを管理する例を記載しておきます。

variable regions {
  type = list(string)
}

variable piped_id {
  type = string
}

resource "pipecd_application" "user" {
  for_each          = toset(var.regions)
  name              = "admin-${each.key}"
  piped_id          = var.piped_id
  kind              = "CLOUDRUN"
  platform_provider = each.key

  git {
    repository_id = "example"
    remote        = "git@github.com:/.git"
    branch        = "main"
    path          = "path/to/config"
    filename      = "${each.key}-pipe.yaml"
  }
}

 

振り返りと今後

昨今注目を集めているインナーソースの取り組みについて、サイバーエージェントでの事例を紹介しました。
サイバーエージェントでは、管轄をまたいだコミュニケーションの場があることで、お互いの課題やアプローチの事例について知る機会が豊富にあります。
今回取り組んだプロジェクトは、お互いが利用しているOSSに対するエコシステムの拡充ということで、CNCFプロジェクトのメンテナーを巻き込んだ形で実現することができ、社内に限らず世界的に影響のあるOSS活動になったのではないかと思います。
この取り組みの中で、PipeCD自体へのコントリビュートも含め、自分自身も貴重な体験ができたと思いますし、事業部をまたいだOSS活動は多くの観点が得られて非常に楽しいです。

さて、これからのTerraform Providerの開発についてですが、私と黒崎、渋谷の3名はメンテナーとして継続的に開発に関わっていきます。
具体的に、今後Terraform Providerで何を管理するのかは、PipeCDの機能に応じて議論しつつ進めていきたいと考えています。

また、今回のプロジェクトをはじめ、OSSコントリビュートやサイバーエージェントのインナーソースなど、これからも積極的に活動していきたいと思っています。

新卒Webフロントエンドエンジニアが配属1ヶ月半で生成AIを活用した新機能をリリースするまで
次の記事
新卒バックエンドエンジニアとして入社し、配属されて1ヶ月を振り返る
前の記事