翻訳
このドキュメントは The Kubectl Book の翻訳です。翻訳の GitHub リポジトリはこちら。
Experimental
TL;DR
別々のチームが所有しているリソース構成への変更を切り離す
リポジトリ構造をベースとしたレイアウト
動機
- 別々の環境を管理するチーム間で分離する
- 権限
- きめ細かい制御
- PR
- Issue
- Project
- Automation
ディレクトリ構造
リソース構成
| リポジトリのタイプ | クラスタへのデプロイ | 内容 | 名前の例 |
|---|---|---|---|
| ベース | No - ベースとして使用 | 他チームと共有する構成 | platform |
| App | Yes - 手動でまたは継続的にデプロイ | デプロイ可能な構成 | guest-book |
ディレクトリとブランチで説明されているテクニックを使用します。
ワークフロー例
- Java プラットフォームチームに所属するアリスが他チームが使用する Java ベースを更新する
- アリスが新規リリースのために Git タグを作成する
- GuestBook App チームに所属するボブが新しい Java ベースに切り替えるため、参照を更新する
図
シナリオ
- アリスが Java ベースリポジトリを修正し、v2 タグを作成する
- 変更はこの段階ではどこにもプッシュされない
- ボブが GuestBook App リポジトリを修正し、Java ベースの v2 を使うようにする
- 変更が継続的デプロイメントによりプッシュされる
構造:
- プラットフォームチームが共有の構成のためにベースリポジトリを作成する
- App チームが App を開発するために App リポジトリを作成する
- ベースリポジトリをリモートに参照
ベースリポジトリ: プラットフォームチーム
tree
.
├── bases # Used as a Base only
│ ├── kustomization.yaml
│ └── ...
├── java # Java Bases
│ ├── kustomization.yaml # Uses bases: ["../bases"]
│ └── ...
└── python # Python Bases
App リポジトリ: GuestBook チーム
tree
.
├── bases # References Base Repositories
│ └── ...
├── prod
│ └── ...
├── staging
│ └── ...
└── test
└── ...
リモート URL vs Vendoring
- 同じ組織が所有・管理しているリポジトリは URL によって参照できます
- 別の組織が所有・管理しているリポジトリは vendor として管理し、vendor ディレクトリへのパスによって参照すべきです