--- title: "Gitless GitOpsとは：OCIレジストリから配信する仕組みとFlux・Argo CDの設定" url: "https://www.issoh.co.jp/tech/details/9508/" published: 2025-10-27 updated: 2026-10-31 categories: ["CI/CD"] publisher: "株式会社一創" --- # Gitless GitOpsとは：OCIレジストリから配信する仕組みとFlux・Argo CDの設定 Gitless GitOpsは、Kubernetesのマニフェストを**OCIアーティファクトとしてコンテナレジストリに置き、Flux CDやArgo CDがGitではなくレジストリから取得して適用する**GitOpsの構成です。開発者はこれまでどおりGitで設定を書いてレビューし、クラスターへ届ける経路だけをレジストリに替えます。本記事では2026年10月時点のFlux 2.10・Argo CD 3.5での設定、両ツールで挙動が違う点（メディアタイプと署名検証）、既存のGitRepository構成からの移行手順を扱います。なお、Gitを置き換えるバージョン管理ツール「Gitless」（gitless-vcs）とは別物です。 ## まとめ：Gitless GitOpsの要点 - **変わるのは配信経路だけ**：Gitは人が書いてレビューする場所として残り、CIがマニフェストをレジストリへpushし、クラスター側のコントローラーはレジストリだけを読む。本番クラスターにGitの認証情報が要らなくなる。 - **Fluxが本命**：Fluxは2022年にOCIRepositoryで始め、2026-10-26のv2.10.0まで機能を積んできた。取得時にCosignまたはNotationで署名を検証できる。 - **Argo CDはv3.1（2025-08-13）からBetaで対応**：`repoURL: oci://...`で読めるが、受け付けるレイヤーのメディアタイプが限られ、Fluxが作ったアーティファクトは既定では読めない。ソースの署名検証もGitのGPGにしか対応していない。 - **失うものもある**：レジストリにはGitの差分・blame・プルリクエストのレビューが無い。アーティファクトにGitのコミットSHAを刻み、ダイジェストで固定して追跡できるようにする。 - **見送ってよい条件**：クラスターが1〜2個で、署名やSBOMを求める規制も無いなら、CIを作り込む手間に見合わない。 ## Gitless GitOpsの仕組み：Gitとレジストリの役割分担 Fluxの公式ドキュメント（[Flux Core Concepts](https://fluxcd.io/flux/concepts/)）は、Gitless GitOpsを「Fluxのコントローラーを完全にGitから切り離し、コンテナレジストリだけをクラスターの望ましい状態の情報源にするモデル」と説明しています。同じ箇所で、利用者から見ればGitは引き続き主要な入口であるとも書いています。起点は2022年7月8日にマージされた[RFC-0003（Flux OCI support for Kubernetes manifests）](https://github.com/fluxcd/flux2/pull/2601)です。 流れは3段です。 1. 開発者がGitにマニフェストの変更をpushし、プルリクエストでレビューする。 2. CIがKustomizeやHelmの出力を1つのOCIアーティファクトにまとめ、レジストリへpushして署名する。 3. クラスター内のFluxまたはArgo CDがレジストリを定期的に確認し、新しいダイジェストを見つけたら取得して適用する。 GitOpsそのものの4原則とPush型との違いは[GitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML【2026年10月】](/tech/details/18553/)で扱っています。 ### Push型CI/CD・従来GitOpsとの運用比較 3つの方式を、クラスターが何に接続し、誰が鍵を持つかで並べると違いがはっきりします。 | 比較項目 | Push型CI/CD | 従来GitOps | Gitless GitOps | | --------- | ------------ | --------- | -------------- | | 適用する主体 | CIが外からapply | クラスター内が取得 | クラスター内が取得 | | クラスターの接続先 | なし（CIが接続） | Gitサーバー | コンテナレジストリ | | CIが持つ権限 | 対象リソースへの適用権限 | Gitへのpush | レジストリへのpush | | クラスターが持つ鍵 | 不要 | Gitの読み取り鍵 | レジストリの読み取り | | 設定の署名検証 | CI次第 | コミット署名 | Fluxのみ取得時に検証 | | 変更履歴の確認 | CIのログ | Gitの履歴 | Gitの履歴＋ダイジェスト | Gitless GitOpsはプル型のまま、クラスターから見た依存先をGitサーバーからレジストリへ移す方式です。アプリのイメージと同じレジストリに設定も置き、Gitへの参照を残さなければ、本番の依存先が1つ減ります。レジストリの選び方は[コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](/tech/details/13259/)を参照してください。 ## Fluxで構成する：flux push artifactとOCIRepository Fluxでは、CIで`flux push artifact`を実行し、クラスター側で`OCIRepository`と`Kustomization`を組み合わせます。Flux自体の構成要素は[Flux CDとは？GitOps Toolkitの仕組みとArgo CDとの違いを実装者目線で解説](/tech/details/15586/)で扱っています。 ### CIによるマニフェストのOCI化とキーレス署名 GitHub Actionsで、mainへのpushごとにアーティファクトを作り、キーレス署名してから`production`タグを付け替える例です。`--revision`にブランチ名とコミットSHAを入れておくと、クラスター側の`OCIRepository`のステータスからGitの変更へ戻れます。ghcr.ioのリポジトリ名は小文字にする必要があります。GHCRに初めてpushしたパッケージは既定で非公開なので、クラスター側には読み取り用の認証（Fluxは`OCIRepository`の`spec.secretRef`、Argo CDはリポジトリの認証情報）を別に用意します。CI側の`docker/login-action`の認証はクラスターへは引き継がれません。 ``` name: publish-config on: push: branches: [main] permissions: contents: read packages: write id-token: write jobs: publish: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: fluxcd/flux2/action@v2.10.0 with: version: 2.10.0 - uses: sigstore/cosign-installer@v4 - uses: docker/login-action@v4 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Push, sign and promote run: | repo=oci://ghcr.io/your-org/config/app digest_url=$(flux push artifact ${repo}:${GITHUB_SHA::7} \ --path=./deploy/production \ --source="${{ github.server_url }}/${{ github.repository }}" \ --revision="${GITHUB_REF_NAME}@sha1:${GITHUB_SHA}" \ --output json | jq -r '.repository + "@" + .digest') cosign sign --yes "${digest_url}" flux tag artifact ${repo}:${GITHUB_SHA::7} --tag production ``` `id-token: write`はキーレス署名でGitHubのOIDCトークンを使うための権限です。署名はタグでなくダイジェストに対して行います。`flux push artifact`と`cosign sign`を組み合わせる形は、Flux CLI v2.10.0のヘルプに載っている例と同じです。鍵ペアで署名する手順は[Flux OCI Artifactsのチートシート](https://fluxcd.io/flux/cheatsheets/oci-artifacts/)にあります。 ### OCIRepositoryによる取得・署名検証とKustomizationによる適用 クラスター側では、上のワークフローが署名したものだけを受け入れるよう、OIDCの発行者とサブジェクトを正規表現で縛ります。 ``` apiVersion: source.toolkit.fluxcd.io/v1 kind: OCIRepository metadata: name: app namespace: flux-system spec: interval: 5m url: oci://ghcr.io/your-org/config/app ref: tag: production verify: provider: cosign matchOIDCIdentity: - issuer: "^https://token[.]actions[.]githubusercontent[.]com$" subject: "^https://github[.]com/your-org/your-repo/[.]github/workflows/publish-config[.]yaml@refs/heads/main$" --- apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: app namespace: flux-system spec: interval: 10m sourceRef: kind: OCIRepository name: app path: ./ prune: true ``` [OCIRepositoryの仕様](https://fluxcd.io/flux/components/source/ocirepositories/)では、`spec.verify.provider`は`cosign`と`notation`の2択です。Cosignの公開鍵で検証するときは`matchOIDCIdentity`の代わりに`secretRef`で拡張子`.pub`の鍵を入れたSecretを指します。`matchOIDCIdentity`は複数書くとどれか1つに一致すれば通ります。検証に通ると`SourceVerified`条件が`True`になり、通らなければ適用されません。 注意点が1つあります。仕様書には、公開Sigstoreの信頼ルート（Fulcio・Rekorの鍵）がローテーションしても検知しないと書かれています。信頼ルートを明示的に管理したい場合や、自前のSigstoreを使う場合は`spec.verify.trustedRootSecretRef`で`trusted_root.json`を固定します（v2.9.0で追加）。 ### FluxInstanceによるクラスター設定のOCI同期 Flux Operatorを使う構成なら、ブートストラップの同期元そのものもOCIにできます。[FluxInstanceの仕様](https://fluxoperator.dev/docs/crd/fluxinstance/)で、`spec.sync.kind`は`GitRepository`・`OCIRepository`・`Bucket`から選べます。 ``` apiVersion: fluxcd.controlplane.io/v1 kind: FluxInstance metadata: name: flux namespace: flux-system spec: distribution: version: "2.10.x" registry: "ghcr.io/fluxcd" sync: kind: OCIRepository url: "oci://ghcr.io/your-org/fleet" ref: "latest" path: "clusters/production" pullSecret: "oci-token-auth" ``` この設定で変わるのはFluxの同期元です。配下の`GitRepository`やHelmの参照も合わせてOCIへ移せば、クラスターからGitへの接続は残りません。`pullSecret`は`kubernetes.io/dockerconfigjson`型のSecretです。AWS・Azure・GCPのレジストリなら`provider`を指定してWorkload Identityで認証でき、Secret自体が不要になります。 ## Flux 2.7〜2.10で増えたGitless向けの機能 1年余りで、OCIまわりの機能は次のように増えました。日付はGitHubのリリース公開日です。 | 版 | 公開日 | Gitless GitOpsに関わる追加 | | ------- | ---------- | -------------------------------------------- | | v2.7.0 | 2025-09-30 | ArtifactGenerator・ExternalArtifact | | v2.8.0 | 2026-02-24 | Cosign v3の署名を検証 | | v2.9.0 | 2026-06-30 | CLIプラグイン（mirror・schema）、信頼ルートの指定 | | v2.10.0 | 2026-10-26 | ArtifactGeneratorの名前空間またぎ、object identityのGA | 実務で効くのはv2.9.0のプラグインです。`flux plugin install mirror`で入る`flux mirror sync`は、公開Helmリポジトリのチャートを自社レジストリへ複製します。複製したうえで`HelmRelease`の参照先を自社レジストリへ替えれば、そのチャートの取得は外部の配布元の障害に左右されなくなります。`flux schema validate`はpush前にマニフェストのスキーマ違反を見つけます。CIで検証が失敗したらpushまで進まないようにしておけば、スキーマ違反のマニフェストはレジストリに入りません。アプリの設定値の誤りまでは検出しない点は従来と同じです。 [v2.10.0のリリースノート](https://github.com/fluxcd/flux2/releases/tag/v2.10.0)には破壊的変更があります。object identityが常時有効になり、既定のRBACから`serviceaccounts/token`の`create`権限が外れました。Workload Identityでレジストリへ認証している環境は、更新前に必要なClusterRoleを付与しておきます。対応するKubernetesは1.35.2以上・1.36.1以上・1.37.0以上の3系列です。 ## Argo CDで構成する：oci://のrepoURLとメディアタイプ Argo CDは[v3.1.0（2025-08-13）](https://github.com/argoproj/argo-cd/releases/tag/v3.1.0)でOCIをアプリケーションのソースとして扱えるようになりました。リリースノートの表記はBetaです。Helmチャートを使う構成は[ArgoCDでHelm chartを使う方法：valueFiles・マルチソースの設定とargo-cd chartでのインストール【3.5系】](/tech/details/18562/)を参照してください。 ### Application定義とoras pushでの作り方 [Argo CDのOCIガイド](https://argo-cd.readthedocs.io/en/stable/user-guide/oci/)は、アーティファクトの作成に[ORAS](https://oras.land/)を例示しています。マニフェストのあるディレクトリで次のように実行すると、1レイヤーにまとめてpushされます。 ``` oras push ghcr.io/your-org/config/app:1.4.0 . ``` ``` apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: app namespace: argocd spec: project: default source: repoURL: oci://ghcr.io/your-org/config/app targetRevision: 1.4.0 path: . destination: server: https://kubernetes.default.svc namespace: app syncPolicy: automated: {} ``` ガイドでは、イメージが単一レイヤーであることを前提にしています。tarball をpushするときは、メディアタイプを手で指定する必要があります。 ### Fluxで作ったアーティファクトを既定で読めない理由 FluxとArgo CDを併用している組織が最初につまずく点です。`flux push artifact`が作るレイヤーのメディアタイプは`application/vnd.cncf.flux.content.v1.tar+gzip`です（fluxcd/pkgの`oci/constants.go`）。一方、Argo CD v3.5.6のrepo-serverが既定で受け付けるのは次の3種類だけです。 - `application/vnd.oci.image.layer.v1.tar` - `application/vnd.oci.image.layer.v1.tar+gzip` - `application/vnd.cncf.helm.chart.content.v1.tar+gzip` 同じアーティファクトをArgo CDでも読ませるなら、repo-serverの環境変数`ARGOCD_REPO_SERVER_OCI_LAYER_MEDIA_TYPES`にFluxのメディアタイプを足します。値はカンマ区切りで、指定すると既定値を置き換えるため、既定の3種類も一緒に書いておきます。Argo CDだけで運用するなら、最初から`oras push`で作るほうが設定を増やさずに済みます。 ### Argo CDのOCIソースで署名を検証できない制約 Argo CD v3.5.6の[source integrity](https://argo-cd.readthedocs.io/en/stable/user-guide/source-integrity/)が対応する方式は、GitコミットのGnuPG署名検証だけです。FluxのようにOCIアーティファクトの署名を取得時に検証する仕組みはありません。Gitless GitOpsを選ぶ理由が「設定に署名を付けて改ざんを防ぎたい」なら、現時点ではFluxを選びます。Argo CDを使い続ける場合は、CIの昇格ジョブで`cosign verify`を通したダイジェストだけにタグを付けるなど、検証をクラスターの外に置くことになります。Podのイメージ署名をアドミッションで強制する方法は[Kyvernoとは？Kubernetesのポリシー適用の仕組みとCEL移行を解説](/tech/details/17271/)で扱っていますが、これはマニフェストのアーティファクトではなくコンテナイメージが対象です。 Argo CDの周辺では、GitリポジトリからOCIへの格納とArgo CDのApplication展開をつなぐ[Kokumi](https://github.com/kokumi-dev/kokumi)も出てきました。最新は0.17.0（2026-10-11）ですが、READMEには本番での利用は注意するよう書かれた実験段階のプロジェクトです。 ## Flux・Argo CD・Kubernetesの対応状況 2026年10月31日時点の現行版と、Gitless GitOpsでの立ち位置です。 | ツール | 現行版（公開日） | OCIの扱い | | ------------- | ------------------- | -------------------- | | Flux | v2.10.0（2026-10-26） | 2022年から対応・取得時に署名検証 | | Flux Operator | v0.62.1（2026-10-27） | 同期元にOCIを指定可 | | Argo CD | v3.5.6（2026-10-20） | v3.1からBeta・署名検証なし | | Kubernetes | v1.37.2（2026-10-28） | ImageVolumeはv1.36でGA | | Cosign | v3.1.4（2026-10-20） | アーティファクトの署名 | | ORAS CLI | v1.3.6（2026-10-24） | 任意ファイルのpush・pull | KubernetesのImageVolumeは、OCIのイメージやアーティファクトを読み取り専用ボリュームとしてPodに直接マウントする機能です。[フィーチャーゲートの一覧](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)では、v1.31でalpha、v1.33でbeta（既定は無効）、v1.35で既定有効、v1.36でstableになりました。設定ファイルやモデルをPodに配る用途で、GitOpsの配信経路とは別物です。Gitless GitOps自体はImageVolumeが無くても動きます。 ## サプライチェーン対策として効く範囲 アプリのイメージに使っている署名・スキャン・SBOMの仕組みを、マニフェストにもそのまま使えるのがこの構成の実利です。署名やSBOMは、OCI 1.1のsubjectで元のアーティファクトに関連付けて同じレジストリに置けます（referrers API）。 - **改ざんの防止**：クラスターは、特定のCIワークフローが署名したダイジェストしか適用しない。Gitの書き込み権限を奪われても、CIを通らない変更は配信されない。 - **鍵の削減**：クラスターからGitのデプロイキーやトークンが消える。クラウドのレジストリならWorkload Identityで読み取り鍵も消せる。 - **SBOMは別ツール**：Cosignは署名のツールで、SBOMを作らない。SyftやTrivyで作ったSBOMを`cosign attest`で添付する。Trivyの使い方は[Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで【v0.76対応】](/tech/details/10398/)にあります。 効かない範囲もはっきりしています。署名はCIの出力であることしか保証しません。Gitに悪意ある変更がマージされれば、CIはそれをそのまま署名します。レビューの必須化やブランチ保護は、引き続きGit側で必要です。開発工程全体の対策は[ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断](/tech/details/16232/)で整理しています。 ## 採用を判断する条件：向くケースと見送るケース 向くのは次のような環境です。 - 規制や顧客要件で、デプロイした設定の真正性を証明する必要がある。 - 本番ネットワークからGitサーバーへ出られない（閉域・エアギャップ）が、レジストリのミラーは置ける。 - クラスターが多く、1つのモノリポジトリを全クラスターがcloneする負荷が問題になっている。 反対に、次に当てはまるなら見送ります。 - クラスターが1〜2個で、Gitへの接続に困っていない。CIを1段増やす保守のほうが重い。 - Argo CDで運用しており、署名検証が目的。前述のとおりArgo CD単体では取得時に検証できない。 - 「今どのコミットが本番か」をGitの画面だけで追う運用に慣れている。 最後の点は見落とされがちです。KokumiのREADMEも、GitOpsで得ていた履歴・blame・差分・プルリクエストのレビューはOCIへ移すと失われると問題提起しています。`--revision`でコミットSHAを刻む、本番の`OCIRepository`はタグでなくダイジェスト（`spec.ref.digest`）で固定する、昇格と切り戻しはそのダイジェストをGit上で書き換えるプルリクエストで行う、という3点を最初に決めておきます。こうすると、本番に何がいつ出たかがGitの履歴に残ります。`spec.ref.digest`はタグ指定より優先されるため、ダイジェスト固定とタグの付け替えは併用できません。 移行するかの判断や、CIとGitOpsの設計を外部と一緒に詰めたい場合は、一創の[DevOps・CI/CD導入支援](/service/system/devops/)で相談を受けています。 ## 既存のGitRepository構成からの移行手順 Fluxで、配信を止めずにGitからOCIへ切り替える順序です。 1. **CIで並行pushを始める**：既存のGitの運用は変えず、上のワークフローでアーティファクトを作る。`flux diff artifact`で、アーティファクトの中身がGitのディレクトリと同じファイルであることを確認する。 2. **OCIRepositoryを追加する**：同じ名前空間に`OCIRepository`を作り、`SourceVerified`と`Ready`が`True`になるのを見る。 3. **Kustomizationの参照先を替える**：`sourceRef.kind`を`GitRepository`から`OCIRepository`へ変える。`path`はアーティファクトの中の相対パスになるため、`--path`で詰めたディレクトリに合わせて直す。 4. **Gitの接続を外す**：`GitRepository`とデプロイキーのSecretを消し、Gitホスティング側のデプロイキーも失効させる。 5. **切り戻しを確認する**：タグ追従なら`flux tag artifact`で前の版へ`production`を付け直し、ダイジェスト固定なら`spec.ref.digest`を前の値に戻す。`flux reconcile kustomization app --with-source`を実行し、`flux get kustomizations`でKustomizationが`Ready`になり適用まで済んだことを確かめておく。 移行でよく起きる失敗は3つです。`matchOIDCIdentity`のサブジェクトをワークフローのファイル名やブランチと一致させておらず検証で止まる。`path`を直し忘れて何も適用されない。`prune: true`のまま参照先を替え、差分のあるリソースが消える。`flux diff artifact`が比べるのはローカルのファイルとアーティファクトの中身だけで、クラスター上で何が消えるかまでは分かりません。3つめを避けるには、切り替えの間だけ`prune: false`にし、`flux get kustomizations`で`Ready`を確認してから`true`に戻します。KustomizeのbaseとoverlaysをどうOCIに詰めるかは[Kustomizeとは？base・overlaysの仕組みとHelmとの違い・導入判断を実装者目線で解説](/tech/details/15572/)が参考になります。 ## よくある質問 ### Gitless GitOpsはGitを完全に使わないのですか？ 使います。設定を書いてレビューするのはGitのままで、Gitを使わなくなるのはクラスター側のコントローラーだけです。Fluxの公式ドキュメントも、利用者から見ればGitが主要な入口だと説明しています。 ### バージョン管理ツールのGitlessとは関係がありますか？ 関係ありません。gitless-vcsはGitの操作を簡単にする別のツールで、GitHub上の最終リリースはv0.8.8（2019年5月）です。Gitless GitOpsはKubernetesへの配信方式の名前です。 ### FluxとArgo CDのどちらで始めるべきですか？ 署名検証まで含めて組むならFluxです。Fluxは`OCIRepository`の`spec.verify`で取得時にCosignかNotationの署名を検証できますが、Argo CD v3.5.6のsource integrityはGitのGPG署名にしか対応していません。すでにArgo CDで運用しており、Gitへの接続を減らすことだけが目的なら、Argo CDのOCIソースで足ります。 ### Kubernetesのどのバージョンが必要ですか？ Gitless GitOpsに特定のKubernetes機能は要りません。条件になるのはFluxやArgo CDの対応範囲で、Flux v2.10.0は1.35.2以上・1.36.1以上・1.37.0以上をサポートします。ImageVolumeを併用する場合はv1.36以降ならstableです。 ### 小規模なチームでも導入するメリットはありますか？ 署名やエアギャップの要件が無ければ、小さいと言えます。クラスターが1〜2個なら、Gitへの接続を残した従来のGitOpsのほうが保守は軽く済みます。要件が出てから、上の移行手順で切り替えても遅くありません。 ## 関連記事 - [GitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML【2026年10月】](/tech/details/18553/) - [Flux CDとは？GitOps Toolkitの仕組みとArgo CDとの違いを実装者目線で解説](/tech/details/15586/) - [コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](/tech/details/13259/) - [ソフトウェアサプライチェーンセキュリティとは？開発工程に組み込む防御と2026年規制対応の実装判断](/tech/details/16232/) --- 出典: [Gitless GitOpsとは：OCIレジストリから配信する仕組みとFlux・Argo CDの設定]()（株式会社一創）