翻訳

このドキュメントは The Kubectl Book の翻訳です。翻訳の GitHub リポジトリはこちら。

Experimental

Content in this chapter is experimental and will evolve based on user feedback.

Leave feedback on the conventions by creating an issue in the kubectl GitHub repository.

Also provide feedback on new kubectl docs at the survey

TL;DR

分離された環境にデプロイするために構成の変更を切り離す

ブランチ構造をベースとしたレイアウト

動機

ブランチを使う理由。リリース時にロールアウトされる変更 (たとえば新しいフラグ) を、本番環境のイベントに対するレスポンスでロールアウトされる変更から分離するためです。

ブランチ構造

ここで説明する方法は必要に応じて変更また応用してください。

ブランチのタイプ クラスタにデプロイするか 目的 構成の変更例 ブランチ名の例
ベース No - 他のブランチからマージされるだけ リリースの一部としてロールアウトされるべき変更 pubsub topic フラグを加える master, release-1.14, i1026
デプロイ Yes - 手動でまたは継続的にデプロイ ベースと、"production" (または dev、staging など) のイベントに対する反応として要求される変更 メモリリソースの増量 - たとえばコンテナのクラッシュにより deploy-test, deploy-staging, deploy-prod

ディレクトリとブランチで説明されているテクニックを使用します。

ワークフロー例

図

シナリオ

  1. Live Prod App のバージョンは v1
  2. v2 の変更がベースブランチの構成にコミットされる
  3. v2 が Staging にロールアウトされる
    • 継続的デプロイメントによりデプロイされる
  4. Live Prod App が v1 への変更を (v2 とは無関係に) 要求する
    • Prod のメモリリソースを変更
  5. Prod ブランチの構成を v1 のまま更新
    • 継続的デプロイメントによりただちにデプロイされる
  6. v2 の変更が別でロールアウトされる
    • ベースブランチのタグが Prod ブランチにマージされる
    • Prod ブランチが継続的デプロイされる

Created with Raphaël 2.1.4

詳細

注意: アプリケーションのバージョンは v1 から始まります

  1. 開発者のボブは v2 リリースで使用する新しいアプリのフラグを導入する
    • 例: PubSub のトピック名
  2. ボブはベース構成を更新して新しいフラグを取り入れる
    • Staging 環境用のトピック (staging-topic) を追加する
    • Prod 環境用のトピック (prod-topic) を追加する
    • フラグは v2 リリースでロールアウトする
  3. v2 が切られる
    • ベースブランチが v2 タグでタグ付けされる
  4. v2 が Staging にロールアウトされる
    • v2 タグ -> Staring ブランチにマージ
    • Staging ブランチを Staging クラスタにデプロイ
  5. 運用担当のアリスが (v1 の) Prod 環境で問題を発見する
    • コンテナのメモリを増量することで修正する
  6. アリスは Prod ブランチの構成を更新し、メモリリリースを増量する
    • 変更は直接 Prod ブランチに行い、ベースブランチを経由しない
  7. v1 の変更が Prod にロールアウトされる (v1++)
    • アリスの変更を含むが、ボブの変更は含まない
  8. v2 が Prod にロールアウトされる
    • v2 タグ -> Prod ブランチにマージ
    • Prod ブランチを Prod クラスタにデプロイ

テクニック:

  • 新しく要求されたフラグと環境変数をコードに追加するとき、ベースブランチのリリース構成に追加する
    • コードがロールアウトされると構成もロールアウトされるため
  • フラグと設定は、デプロイブランチのデプロイディレクトリにあるリソース構成に合わせて調整する
    • 独立したバージョンがただちにロールアウトされる
  • ベースブランチからデプロイブランチにマージし、ロールアウトを実行する

ディレクトリとブランチのレイアウト

構造:

  • 構成の変更を受けるベースブランチ (master、app-version など) はリリースに結びつく
  • 環境ごとにデプロイブランチを分離する (deploy-<env> など)
    • 各ブランチに伴う新しいディレクトリは overlay カスタマイズを含む - deploy-<env> など

ベースブランチ: master

tree
.
├── bases
│   ├── ...
├── prod
│   ├── bases
│   │   ├── ...
│   ├── us-central
│   │   ├── kustomization.yaml
│   │   └── backend
│   │       └── deployment-patch.yaml
│   ├── us-east
│   │   └── kustomization.yaml
│   └── us-west
│       └── kustomization.yaml
├── staging
│   ├── bases
│   │   ├── ...
│   └── us-west
│       └── kustomization.yaml
└── test
    ├── bases
    │   ├── ...
    └── us-west
        └── kustomization.yaml

デプロイブランチ:

Prod ブランチ: deploy-prod

tree
.
├── bases # From Base Branch
│   └── ...
└── deploy-prod # Prod deploy folder
│   ├── us-central
│   │   ├── kustomization.yaml # Uses bases: ["../../prod/us-central"]
│   ├── us-east
│   │   └── kustomization.yaml # Uses bases: ["../../prod/us-east"]
│   └── us-west
│       └── kustomization.yaml # Uses bases: ["../../prod/us-west"]
├── prod # From Base Branch
│   └── ...
├── staging # From Base Branch
│   └── ...
└── test # From Base Branch
    └── ...

Staging ブランチ: deploy-staging

tree
.
├── bases # From Base Branch
│   ├── ...
├── deploy-staging # Staging deploy folder
│   └── us-west
│       └── kustomization.yaml # Uses bases: ["../../staging/us-west"]
├── prod # From Base Branch
│   └── ...
├── staging # From Base Branch
│   └── ...
└── test # From Base Branch
    └── ...

Test ブランチ: deploy-test

tree
.
├── bases # From Base Branch
│   ├── ...
├──deploy-test # Test deploy folder
│   └── us-west
│       └── kustomization.yaml # Uses bases: ["../../test/us-west"]
├── prod # From Base Branch
│   └── ...
├── staging # From Base Branch
│   └── ...
└── test # From Base Branch
    └── ...

ロールバックのワークフロー例

ブランチで運用するときのロールバックのワークフロー例の概要:

  1. 動作中の Prod アプリは v1
  2. 変更がベースブランチの構成に取り入れられる
    • バージョン v2 としてリリースするため
  3. リリース v2 が切られ、ロールアウトされる
    • ベースのタグ v2 が切られると、アーティファクト (イメージなど) がビルドされる
  4. 変更がベースブランチの構成に取り入れられる
    • バージョン v3 としてリリースするため
  5. v2 が (ついに) Prod にプッシュされる
    • v2 タグを Prod ブランチにマージ
  6. Prod で v2 に問題が見つかり、ロールバックしなければならなくなる
    • v2 の変更が新しいコミットとして Prod ブランチに行われ、ロールバックされる
  7. ベースブランチは影響を受けない
    • 修正が v3 に取り入れられる

注意: "v3" でベースに新しい変更がコミットされた場合、"v2" から "v1" へのロールバックがより難しくなるということはありません。"v3" の変更は Prod ブランチにマージされていないからです。

図

Created with Raphaël 2.1.4

results matching ""

    No results matching ""