HarnessのIaCを調査する(Harness Git Experience)
はじめに
Harnessで複数のパイプライン構築しようとするときに、いちいちGUIでパイプラインを1から構築していくのはSRE的な観点からみるとトイルと言わざるを得ない
Harnessのネイティブ機能でパイプラインのclone(複製)はできるが、パラメータやクラスタの設定変更など全てプロビジョニングはできない
そこで、Harnessで構築するパイプライン自体をIaCで管理すべく、Harness Git Experienceを中心に技術検証を行う
Harness Git Experienceの概要はこちらを参照
調査
公式quickstartを元にHarness Git Experienceで実現出来ること・出来ないことの調査を行う
Github
まずは、github上にリポジトリの作成を行い、Harnessパイプラインを構成するyamlファイルを管理
その後、PAT(Personal Access Token)を取得します。
PATに必要なアクセスは以下
- repo
- user
Harness
PAT(Personal Access Token)を取得
取得したPATを元に、対象リポジトリへのアクセス権を持つGithub Connector を作成します(パイプライン作成の途中でも作成可能)
Remote Pipelinesを作成
※パイプラインを作成する前に、以下の設定をEnableにしないと、gitへyamlファイルが連携されないので、注意が必要
Allow different repo for Pipeline and InputSets
Enforce git experience for pipelines and templates
パイプラインを作成
今回は技術検証のため、以下のようなシンプルなCDパイプラインを構築
- 手動でApproval → GKEクラスタにデプロイ
- GKEクラスタへデプロイする設定などはこちらを参照
githubのorgの権限によっては、作成したPipelineを保存しようとすると以下になった。
(orgではOAuthのアクセスが許可されていなかったので、個人のリポジトリを指定したら解決)
Saveすると、どのブランチへコミットするか聞かれるので、任意のブランチを選択
gitリポジトリ上に以下のような.harness
ディレクトリが作成される(ファイル名はPipeline作成時に指定可能)
このyamlファイルに構築したパイプラインが記述される
├── .harness
│ └── harnessgitexperience.yaml
└── README.md
パイプラインの変更をcommitし、PipelinesのGitOpsが実現するか確認
例:pipelineのnameを変更し、commit
pipeline:
name: harness-git-experience
Harness上でReload from Git
をし、パイプラインの更新を行う
ref: https://developer.harness.io/docs/platform/Git-Experience/harness-git-cache
パイプラインのnameが変更されたことを確認できればOK
Harness Git Experience で出来ること
HarnessリソースのGit管理
Harness Git Experience を使用して、次の Harness リソースを Git管理できる
- Pipelines
- Input sets
- Templates(EnterPrise版のみ)
また、Input setsとトリガーを指定したパイプラインの構築(Git管理)もできる
インラインエンティティをGit管理に移管
Git管理されていない既存のパイプラインと入力セットをGit管理下に移管することができる
https://developer.harness.io/docs/platform/Git-Experience/move-inline-entities-to-git
OAuthとの統合
https://developer.harness.io/docs/platform/Git-Experience/oauth-integration
Harness Git Experience で出来ないこと
対象外HarnessリソースのGit管理
PipelinesやTemplatesはgit管理可能だが、Organizationやプロバイダーとの疎通に必要やConnectorsなどの主要なリソースはGit管理することができない
パイプラインリソースのGitOpsとは異なる文脈だが、Terraformを使用すると、以下のリソースのプロビジョニングが可能である
- Organizations
- Projects
- Delegates
- Connectors
- Secrets
- Variables
- Services
- Environments
- Infrastructure Definitions
- Pipelines
- Templates
- Permissions
Harness Terraform Provider overview | Harness Developer Hub
つまり、Harnessリソース全体のIaCを実現したい場合には、Harness Git Experienceだけでは不十分。しかし、Terraformを使用する必要がある。
注意点
Harness Git Ops ≠ Harness Git Experience
名前とパッと見の説明が似ているので注意
- Harnessでパイプラインを構築するクラスタ(アプリケーション)のGitOpsを実現
- ArgoCDのようなイメージ
- Harnessで構築するパイプライン自体をGitOpsで実現する
まとめ
Harness Git Experienceでは、HarnessリソースのすべてをIaCにすることは出来ない
また、Harnessリソースの構成管理やプロビジョニングをするという観点においては、Terraformを使用する必要がある。
あと、HarnessのYAMLを直接編集するのは、個人的にはすごくわかりづらいし、書きづらい。。。
Discussion