構成の継承

1）なぜ私は構成継承を必要としますか？

• 共通の値（ロギング、リトレイ、タイムアウト）を再利用します。
• 共有責任：プラットフォームは基本的なポリシー、サービスコマンドを設定します。
• 重複を避け、ずれの危険を減らして下さい。
• スピードアップリリース：変更はデフォルトでツリーにブロードキャストされます。
• 単一のアプローチで複数の環境と複数のテナントをサポートします。

2）継承パターン

2.1階層（親→子）

Base（グローバル）→environment （prod/stage/dev）→region/cluster→service→instance。
シンプルで透明ですが、ディープチェーンや複雑なデバッグにつながる可能性があります。

2.2レイヤード（ベース/オーバーレイ）

ベースレイヤー+オーバーレイセット（feature-x、 region-eu、 security-hardening）。
GitOpsとKustomizeでうまく動作します。オーバーレイは独立した構成です。

2.3コンポジット（モジュール/パッケージ）

構成はモジュール'logging@v2'、 'metrics@v1'、 'http@v3'から組み立てられます。
モジュールのバージョン管理、意味互換性、明示的な依存関係。

2.4ポリシー・アズ・コード

基本的な「リミッター」と不変量（OPA/Rego、 Kyverno、 Conftest）。
価値自体は継承されていませんが、その許容性のためのルール。

3）合併アルゴリズムと優先順位

1.ソースの順序：左から右へ（base_env_region_service_instance）。

• スカラー："last-write-wins'。
• オブジェクト：キーの再帰的なマージ。

• 'append'/'prepend'
• 'uniqueBy （key）'（キーで設定）
• 'patch' （'name'と部分マージでアイテムを検索）。
• 3.予約されたキー（例えば、'_merge： replace'/'_merge： deep'）。

• スタートアップフラグ/ENV変数>ランタイムシークレット>ディスク上のファイル>コードのデフォルト値。

YAMLマージの例

yaml base. yaml http:
port: 8080 timeouts:
read: 2s write: 2s features:
- name: audit enabled: false

prod. yaml http:
timeouts:
read: 1s features:
- name: audit enabled: true
- name: billing enabled: true

Result (under policy: object = deep merge, array = uniqueBy (name) + patch)
http:
port: 8080 timeouts:
read: 1s write: 2s features:
- name: audit enabled: true
- name: billing enabled: true

4）スキームと検証

スキーマの存在は、安全な継承のための前提条件です。

JSON スキーマ/OpenAPI：型、必須フィールド、列挙型、パターン、制約（'minimum'、 'format'、 'patternProperties'）。
スキーマバージョニング（semver）：メジャー-ブレイク、マイナー-新しいフィールド、パッチ-修正。
マージ前とマージ後のチェック：フラグメントと結果の両方を検証します。
デフォルト：スキーマレベルで設定します（draft-07+は'default'をサポートしています）。

5）環境と展開マトリックス

• env： dev、 test、 stage、 prod region： eu-central-1、 us-east-1層：バッチ、リアルタイム、内部テナント：A/B/C（ホワイトラベル、B2B）
• 組み合わせはオーバーレイツリーを形成します。過度の深さを避けます（3-4レベルで十分です）。

6）複数のテナント

• ハードスプリット：テナントごとにファイル/フォルダを分離します。
• パラメータ化：テナントごとに1つのテンプレート+値。
• 継承されたポリシー：リソース/クォータ制限、SLO、ログ保持。
• 重要：セキュリティ境界（秘密/鍵）はテナント間を流れるべきではありません。

7）秘密とセキュリティ

秘密を明示的に継承しないでください。継承された参照：'secretRef'、 'vaultPath'。
KMS/Vault/SOPS：暗号化された値をGit、 keys-outに格納します。
責任を共有する：プラットフォームはパスとポリシー、サービスチームを管理します。
ポリシー：CIチェックで'プレーンテキスト'シークレットを禁止します。
ローテーション：「上書きしない」-エイリアス/抽象（'db/primary/password@2025-Q4'）を使用します。

Vault Linkの例

yaml db:
host: postgres. service user: app passwordFrom:
vaultPath: "kv/prod/app-db"
key: "password" # secret is taken at the deploy stage, not stored in files

8）バージョン管理と移行

コンフィギュレーションモジュールバージョン： 'logging@2。3.1`.

スキーマの変更履歴：jsonnet/ytt/customスクリプトを使用したマイグレーション。
安全なロールバックのためのアップダウン移行。
長い枝：漂流を避けて下さい；定期的にベースオーバーレイを曲げます。

9）ツールとプラクティス

9.1 Kubernetes

Kustomize（オーバーレイ）：'bases'/'resources'、 'patchesStrategicMerge'/'patchesJSON6902'による自然継承モデル。
Helm （values）： hierarchy 'values。yaml'+'--set'（ただし、CIのオーバーライドには注意してください）。
Kyverno/OPA：「セーフティネット」としての政治家。

yaml overlays/prod/kustomization. yaml resources:
-../../base patchesStrategicMerge:
- patch-resources. yaml commonLabels:
env: prod

9.2テラフォーム

+'変数モジュール。TFは契約として。
計算された値の'locals'、' override 'no files-ディレクトリレイヤとワークスペース（'workspaces'）を使用します。
ソースオーダー：デフォルトは<tfvars-files <'-var'/'-var-file'です。

hcl module "svc" {
source = "./modules/svc"
replicas = var. env == "prod"? 4: 2 logging = local. logging_base
}

9.3アンシブル

変数の明確な階層（昇順優先度）：ロールのデフォルトは<inventory group_vars <host_vars <extra varsです。
継承の場合-構造'group_vars/{ env}/{region} 。yml'。

9.4 Jsonnet/ytt

豊富な構成、関数と「キーの意図」（'オーバーレイ。'、'overlayを置き換えます。merge'）。

10）契約とバッテリーの制限

プラットフォームチーム-スキーマ、ポリシー、基本値、およびマージロジックを定義します。
製品チーム：契約内のオーバーレイのみ。
SRE/セキュリティ：監査、検証、署名、執行。

11） CI・CD・GitOps

1.Lint（フォーマット、未知のキーの禁止）。

2.検証（JSON スキーマ/OpenAPI）。

3.Dry-run/Render （ヘルムテンプレート/kustomizeビルド）

4.ポリシーチェック（OPA/Kyverno/Conftest）。

5.Diffとターゲットクラスタ（kubectl diff/ArgoCD diff）。

6.プログレッシブデリバリー：トラフィックが限られたカナリアオーバーレイ。

7.アーティファクトの署名（Cosign、 SLSA証明）。

12） Observabilityおよびデバッグ

出所トレース：誰がフィールドに貢献し、いつ、そこから最終的な値が来ました。
Merge visualization：「勝利」キーのレポート。
アクティブな構成の実行時エクスポート（秘密マスキング付きのエンドポイント'/config'）。
ドリフトアラート：宣言と実際の間の不一致。

13）アンチパターン

明示的な優先ルールなしの「魔法」。
深い鎖（>4-5層）：認知負荷を増加させる。
継承されたファイルの秘密。
CIの'--set'を介して隠されたオーバーライド。
スキーマとレンダリングテストの欠如。

14）実装チェックリスト

• モデル（階層/レイヤー/コンポジション）を定義します。
• タイプ別のマージ順序と戦略を修正しました。
• スキーマとバージョン管理を公開します。
• 秘密を共有する（リンク/参照のみ）。
• ポリシーチェックとアーティファクト署名を追加します。
• ドライラン、拡散、原点の可視化を有効にします。
• アクティブな構成を実行時にエクスポートします。
• 設定変更のためにプログレッシブリリースを構成します。

15） FAQ

Q：層が深すぎることを理解する方法か？
A：パラメータを変更するために>3ファイルを開き「、スクロール」>2レベルの抽象化を行う必要がある場合は、構造を修正してください。

Q：相反する配列をどうしたらいいですか？
A：明示的な戦略を入力します：'replace'、 'append'、 'uniqueBy （key）'、 'patchBy （name）'-ドキュメントでそれらを修正します。

Q：秘密は継承できますか？
A：いいえ。秘密ストアやアクセスポリシーへのリンク（URI/refs）のみが継承されます。

Q：継承をテストする方法か？
A：キーのオーバーレイの組み合わせのための「スライス」を撮影し、ゴールデンファイルで確認します。PRごとのCIでレースレンダリング。

付録A： ミニスペックマージ

'scalars'： last-write-wins ［scalars： las

'objects'： deep-merge by key

• デフォルト'replace'

• 'append'
• 'uniqueBy （key）'
• 'patchBy （key）'と再帰要素のマージ

• '_merge：' deep'を置き換えます'
• '_strategy。array： replace 'append' uniqueBy （name） |patchBy （name）'

付録B： 例

B.1ヘルム値（ベース上のprod）

yaml values. base. yaml replicas: 2 resources:
requests:
cpu: "100m"
memory: "128Mi"
logging:
level: info

values. prod. yaml replicas: 4 logging:
level: warn

helm template svc chart/ -f values. base. yaml -f values. prod. yaml

最後のファイルの優先度は'valuesです。PROD。ヤムル・・・

B.2 Kustomizeオーバーレイ

yaml base/deployment. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 2

overlays/prod/patch. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 4

B.3 Ansible vars

group_vars/prod. yml # values of prod host_vars/prod-eu-1. yml # clarifications for extra vars host in CLI have highest priority

概要

1.明確なモデルおよび優先順位、

2.検証スキームと独立したオーバーレイ、

3.秘密を継承することを拒否し、

4.ドライラン、ポリシーチェック、拡散を備えたGitOpsパイプライン、

5.最終的な値の起源の観測可能性。

これらの原則に従うことで、すべての環境およびトポロジーに対して予測可能でスケーラブルで安全な構成が可能になります。