Flux を使用して AWS に GitOps を実装する

  • 399 ビュー
  • 18分の読み物
ハディ・バハドリ
  • 2024年4月8日
0 株式
0
0
0
0
0
株式
0
0
0
0

導入

多くの企業がKubernetesを本番環境に導入していますが、継続的デプロイメント、高度なセキュリティ、権限分離、監査をどのように実現するか、そして同時に複数のKubernetesクラスターを異なるステージで稼働させながらビジネスの俊敏性を確保する方法について、戸惑うことがよくあります。GitOpsを活用することで、Kubernetesクラスターをベースとしたこのような継続的デプロイメントを実現しながら、セキュリティや権限分離といったエンタープライズレベルの要件を満たすことができます。.

このブログでは、AWS CodeCommit、AWS CodePipeline、Flux を用いて Amazon EKS 環境に GitOps を実装します。この Amazon EKS 環境で本番環境の要件を満たす GitOps ワークフローを設定する方法を詳しく説明し、マイクロサービスアプリケーションが GitOps スタイルの CI/CD パイプラインで継続的インテグレーションと継続的デリバリーを実現する仕組みを実証します。.

前提条件
  • AWS エクスペリエンス
  • AWSアカウント

GitOps とは何ですか?

GitOpsは、クラウドアプリケーションの継続的デプロイメントを実現する方法です。開発者が既に使い慣れているツール（Gitや継続的デプロイメントツールなど）を活用しながら、インフラストラクチャを活用しながら開発者中心のエクスペリエンスを重視します。.

GitOpsの基本的な考え方は、本番環境のインフラストラクチャに関する詳細な記述を常に含むGitリポジトリと、リポジトリに記述された状態に合わせて本番環境を自動更新するプロセスを備えることです。新しいアプリケーションをデプロイしたり、既存のアプリケーションを更新したりする場合は、リポジトリを更新するだけで済みます。自動プロセスがすべてを処理します。まるでクルーズコントロールを使って本番環境のアプリケーションを管理しているようなものです。.

GitOps を使用する理由は何ですか?

Gitはシステムの状態を真に把握できる唯一の情報源です。Gitは、繰り返し実行可能な自動デプロイ、クラスター管理、そしてモニタリングをサポートします。開発者は、組織内で既に確立されているGitワークフローを、ビルド、テスト、スキャン、そしてその他の継続的インテグレーションのステップに再利用できます。最新のシステム状態がマスターGitリポジトリブランチにコミットされると、GitOpsツールチェーンを使用してデプロイの検証、アラートの確認、そしてオペレーションの修正が行われます。GitOpsのコア原則に基づき、私たちはGitOpsがKubernetesクラスターを継続的にデプロイするための最良の方法だと考えています。そのプロセスは以下のとおりです。


Amazon EKS ベースの GitOps のベストプラクティス

ベスト プラクティスに従った全体的な CI/CD パイプラインを下の図に示します。.


AWS CodeCommitリポジトリには3つのコードリポジトリがあります。1つは フラックスレポ は、 フラックスCDは、関連するリソースを定義するために使用されます。 フラックス もう1つはmicroservices-repoで、マイクロサービスアプリケーションの設定とデプロイメントファイルを保存します。3つ目は、ビジネスサービスのソースリポジトリアプリケーションです。この記事では、フロントエンドプロジェクトを例として使用します。パイプラインの継続的インテグレーションにはAWS CodePipelineを使用します。 CI/CD Dockerイメージは アマゾンECR 保存して保存し、Flux CD エンジンをポッドとして Amazon EKS 環境にデプロイしました。.

基本的なワークフローは次のとおりです。
  • コーディング エンジニアはコードを記述し、最終的なコードをアプリ リポジトリにプッシュします。.
  • app-repo のコード変更により、AWS CodePipeline がトリガーされます。.
  • AWS CodePipeline はコードを編集してパッケージ化し、コンテナイメージを生成して、コンテナイメージリポジトリ/Amazon ECR にプッシュします。.
  • EKS 環境で実行される Flux CD エンジンは、ECR コンテナ イメージ リポジトリを定期的にスキャンし、アプリケーションのコンテナ イメージ メタデータを取得します。.
  • 新しいバージョンのコンテナ イメージが検出されると、新しいコンテナ イメージの URL は、git commit/push を介して microservices-repo に保存されているアプリケーション デプロイメント ファイルと自動的に同期されます。.
  • Flux は、Flux-repo からアプリケーション構成とデプロイメントファイルを定期的に取得します。Flux-repo リポジトリは microservices-repo を参照するため、Flux はクラスターワークロードの実行状態が microservices-repo ファイルに記述された期待値と一致しているかどうかを確認します。差異がある場合、Flux は EKS クラスターが自動的に差異を同期できるようにし、ワークロードが期待どおりの状態で実行されるようにします。.

GitOps と CI/CD パイプライン アーキテクチャの概念について説明したので、次の 4 つのモジュールを確認してケースを使用してこの演習を完了します。

  • Infrastructure as Code (IaC) を使用してクラウド インフラストラクチャをデプロイする
  • AWS EKS クラスターに Flux CD をデプロイする
  • Flux CD を使用して GitOps ワークフローを実装する
  • GitOps ワークフローを使用したイメージに基づく自動デプロイメント

1- IaCを使用したクラウドインフラストラクチャの導入

DevOpsの基本理念は、インフラストラクチャはコードと同等であるということです。Infrastructure as Code（IaC）は、コードを使用してクラウドインフラストラクチャの展開と環境管理を可能にします。コーディングエンジニアは、構成ファイルまたはコードを使用してインフラストラクチャを定義し、コードで構築することで、一貫性と再現性を確保します。IaCでは、コーディングエンジニアはリソースのライフサイクルも管理します。具体的には、インフラストラクチャ定義をバージョン管理リポジトリにホストしたり、プログラミングと一貫性のある継続的インテグレーション/デプロイメント（CI/CD）を使用してIaC定義を変更したり、開発環境、テスト環境、本番環境などの環境とIaCコードの変更を同期させたりします。さらに、障害発生時には自動ロールバックが可能で、ドリフト検出機能は想定状態からの逸脱を特定するのに役立ちます。.

クラウドでは、ソフトウェアエンジニアはAWSクラウド開発キット（CDK）を使用して、Python、Java、TypeScriptでインフラストラクチャモデルを構築できます。CDKは、クラウドリソースを有効なデフォルト値で事前設定する「コンストラクト」と呼ばれる高度なコンポーネントを提供します。また、エンジニアは組織のニーズに合わせて独自のカスタムコンストラクトを作成し、共有することもできます。これらすべてがプロジェクトのスピードアップにつながります。.

1.1 CDK CLIでプロジェクトを作成する

TypeScript CDKプロジェクト cdk 初期化 「作成」はフォルダー構造を作成し、TypeScript CDK プロジェクトに必要なモジュールをインストールします。.

cdk init --language typescript

1.2 EKSブループリントを使用してEKSクラスターを作成する

EKS ブループリントは、ワークロードのデプロイと実行に必要な運用ソフトウェアが完全にブートストラップされた、完全な EKS クラスターの構築を支援します。EKS ブループリントでは、コントロールパネル、ワーカーノード、Kubernetes アドオンなど、EKS 環境の望ましい状態の設定を IaC ブループリントとして記述します。ブループリントを設定したら、継続的自動化によって複数の AWS アカウントとリージョンにまたがる一貫性のある環境をデプロイできます。.

EKS Blueprints を使用すると、Amazon EKS プラグインに加え、Prometheus、Karpenter、Nginx、Traefik、AWS Load Balancer Controller、Fluent Bit、Keda、ArgoCD など、幅広い人気のオープンソースプラグインを使用して、EKS クラスターを簡単にセットアップできます。EKS Blueprints は、複数のチームのワークロードをクラスター上で実行するために必要なセキュリティ制御の実装にも役立ちます。.

ディレクトリ クイックスタート 次のコードを作成して実行し、プロジェクトの依存関係をインストールします。.

mkdir quickstart
cd quickstart
npm install @aws-quickstart/eks-blueprints

lib/クイックスタートスタック.ts 開いてコードを入力します。 EKSブループリント 以下を追加します。.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as blueprints from '@aws-quickstart/eks-blueprints';
import { KubernetesVersion } from 'aws-cdk-lib/aws-eks';
export class QuickstartStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const account = props?.env?.account!;
const region = props?.env?.region!;
const clusterProvider = new blueprints.GenericClusterProvider({
version: KubernetesVersion.V1_23,
managedNodeGroups: [
{
id: "default-ng",
desiredSize: 2,
minSize: 1,
maxSize: 2,
}
]
});
const cluster = blueprints.EksBlueprint.builder()
.clusterProvider(clusterProvider)
.account(account)
.region(region)
.addOns(
new blueprints.AwsLoadBalancerControllerAddOn,
)
.teams();
}
}

前の手順では、EKS クラスターを作成し、その NodeGroup を定義し、AwsLoadBalancerController プラグインを追加しました。.


CDK コマンドラインツールを使ってスタックをデプロイするのは便利ですが、EKS インフラストラクチャのデプロイとアップデートには自動化されたパイプラインを設定することをお勧めします。これにより、リージョンをまたいで開発、テスト、本番環境のデプロイが容易になります。.

CodePipelineStack は、AWS CDK アプリケーションの継続的デリバリーのためのフレームワークです。AWS CDK アプリケーションのソースコードが Git にアップロードされると、スタックが自動的に新しいバージョンをビルド、テスト、実行します。アプリケーションのステージまたはスタックが追加されるたびに、スタックは自動的に再構成され、新しいステージまたはスタックをデプロイします。.

次に、cdk deploy コマンドを実行してスタックをデプロイします。.

最後に、コマンドを使用して、アプリケーション ロード バランサーが正常にインストールされたことを確認しました。.

$ kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Running 0 5m31s
aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Running 0 5m31s
aws-node-9hsvz 1/1 Running 0 99m
coredns-66cb55d4f4-gdcqg 1/1 Running 0 106m
coredns-66cb55d4f4-gmzjt 1/1 Running 0 106m
kube-proxy-wr5jn 1/1 Running 0 99m

1.3 要約

このセクションでは、IaCの概念を紹介し、CDKを使用してカスタムEKSクラスターを作成し、AWS Application Load Balancerプラグインをインストールしました。これは、将来マイクロサービスのウェブページにアクセスするための前提条件となります。以下は、このセクションの要約です。

  • cdk init を使用して CDK プロジェクトを起動しました。.
  • AWS Application Load Balancer プラグインを追加することで、EKS Blueprint で EKS クラスターをすばやく定義しました。.

2. Amazon EKS クラスターに Fluxcd をデプロイする

Flux CD は、Weaveworks が開発し、CNCF 向けにオープンソース化された継続的デリバリーツールです。セットアップが簡単で、Kubernetes の変更を迅速に把握できるため、現在広く利用されています。重要な機能の一つは、チームが Kubernetes デプロイメントを宣言的に管理できることです。Flux CD は、リポジトリを定期的にポーリングすることで、ソースリポジトリに保存されている Kubernetes マニフェストファイルを Kubernetes クラスターと同期させます。Flux CD は、kube ctl の運用状態を気にしたり、追加のツールやサービスでワークロードを監視したりすることなく、Kubernetes クラスターがソースリポジトリで定義された構成と常に同期していることを保証します。それでは、Flux をインストールしてみましょう。.

2.1 Flux CLIのインストール

Flux CLI は、GitHub リリース ページからダウンロードできる、すべてのプラットフォーム用のバイナリ実行可能ファイルです。.

curl -s https://fluxcd.io/install.sh | sudo bash

2.2 AWS CodeCommitの認証情報を準備する

ユーザーを作成し、CodeCommit を Git ソースとして使用し、HTTPS Git 認証情報を介して AWS CodeCommit に必要なアクセスを行う必要があります。.

2.3 クラスターに Flux をインストールする

準備したGitOpsコードをクローンします。プロジェクト構造は次のとおりです。

.
├── apps // Define Application
│ ├── base // Application Infrastructure Layer
│ └── overlays // Application Overlays Layer
├── clusters // Cluster configuration portal
│ └── dev-cluster
├── infrastructure // Infrastructure Shared Components
│ ├── base // Infrastructure Infrastructure layer
│ └── overlays // Infrastructure Overlays layer
└── README.md

Kubernetes クラスターに Flux をインストールし、Flux ブートストラップを使用して Git リポジトリから管理するように設定します。クラスター内に Flux コンポーネントが存在する場合、ブートストラップコマンドは必要に応じてアップグレードを実行します。ブートストラップは無力であり、コマンドは複数回安全に実行できます。以下のコマンドのユーザー名とパスワードは、AWS CodeCommit の HTTPS Git 認証情報に置き換えてください。.

flux bootstrap git \ 
--url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ 
--username=__replace_with_your_Git_credential_username__ \ 
--password=__replace_with_your_Git_credential_password__ \ 
--token-auth=true \ 
--path="./clusters/dev-cluster" \ 
--components-extra=image-reflector-controller,image-automation-controller

git pull を使用して、ブートストラッパーによる更新を確認します。Git リポジトリの clusters/dev-cluster/flux-system ディレクトリに、次の 3 つの新しいファイルが作成されます。

  • gotk-components.yaml: 6 つの Flux コントローラー (helm、Kustomize、source、notification、image automation、image reflector) を定義します。.
  • gotk-sync.yaml: Git Flux ソース、ソース コントローラーは GitOps リポジトリ内のクラスター監視コードを変更し、対応する変更をコミットします。.
  • kustomization.yaml: マルチクラスター構成。.

Flux が正常にインストールされたかどうかは、flux get kustomizations --watch で確認できます。出力は次のようになります。

$ flux get kustomizations --watch
NAME REVISION SUSPENDED READY MESSAGE 
flux-system master/83b7e66 False True Applied revision: master/83b7e66
infrastructure master/83b7e66 False True Applied revision: master/83b7e66

kubectl -n flux-system get pod,services を実行して、flux-systemによってデプロイされたコンポーネントを確認します。出力は以下のようになります。

$ kubectl -n flux-system get pod,services
NAME READY STATUS RESTARTS AGE
pod/helm-controller-88f6889c6-sblvd 1/1 Running 0 11m
pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Running 0 11m
pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Running 0 11m
pod/kustomize-controller-784bd54978-s82dq 1/1 Running 0 11m
pod/notification-controller-648bbb9db7-627zs 1/1 Running 0 11m
pod/source-controller-79f7866bc7-gdt95 1/1 Running 0 11m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/notification-controller ClusterIP 172.20.60.72 <none> 80/TCP 11m
service/source-controller ClusterIP 172.20.133.44 <none> 80/TCP 11m
service/webhook-receiver ClusterIP 172.20.196.178 <none> 80/TCP 11m

2.4 要約

このセクションでは、flux ブートストラップコマンドを使用して Kubernetes クラスターに Flux をインストールし、3 つの重要な設定ファイル（gotk-components.yaml、gotk-sync.yaml、kustomization.yaml）を導入しました。以下は、このセクションの要約です。

  • Fluxクライアントのインストール
  • IAM ユーザーと CodeCommit 認証情報の作成
  • Amazon EKS クラスターに Flux をインストールし、自動イメージ更新機能を有効にする

3. Flux CD で GitOps ワークフローを実装する

GitOps CI/CD パイプラインでは、EKS クラスターとその上で実行されるワークロードの構成変更と状態変更は、Git のコード変更（git プッシュまたはプルリクエストによって生成されます。GitOps ではプルリクエストを推奨します）によって実行されます。従来の CI/CD パイプラインは CI エンジンと連携し、kubectl コマンドの create/apply または install/upgrade をトリガーしてクラスターをデプロイします。このように、GitOps はより効率的で簡潔な CI/CD パイプラインを作成します。.

特定のアプリケーション「Sock Shop」と実践的な演習をデモンストレーションし、GitOps CI/CD パイプラインで継続的な統合と配信を実現する方法を説明します。.

3.1 ソックスショップについて

オンライン靴下ストアのユーザー対応部分を例として挙げます。これはSpring Boot、Go Kit、Node.jsで構築され、Dockerコンテナにパッケージ化されています。「Microservice Standard Demo」で示されているように、以下のようになります。

  • マイクロサービスの導入に関するベストプラクティス（間違いの例を含む）
  • クロスプラットフォーム展開機能
  • 継続的インテグレーション/デプロイメントの利点
  • DevOpsとマイクロサービスの相補性
  • さまざまなオーケストレーションプラットフォーム向けのテスト可能な「実際の」アプリケーション

Socks Storeプロジェクトは、8つのフロントエンドおよびバックエンドのマイクロサービスで構成されており、Node.jsで作成されたWebページのフロントエンドです。プロジェクト名はfront-endです。このプロジェクトは、注文、支払い、ユーザー管理、商品管理、ショッピングカートなど、HTTPリクエストを介して複数のバックエンドサービスにアクセスします。バックエンドサービスのデータはMongoDBとMySQLに保存されます。.

リファレンスアーキテクチャは次のとおりです。


3.2 Kustomizeについて

GitOpsワークフローの設定に加えて、Kubernetesの設定方法も知っておく必要があります。システムと環境の複雑さが増すにつれて、従来のリソースインベントリ（YAML）ベースの管理を維持することはますます困難になります。複雑なビジネスユースケース、複数の環境（開発、テスト、プレリリース、本番）、そして大量のYAMLリソースインベントリを維持・管理する必要があります。Helmは、散在するリソースファイルの統合管理、アプリケーションの配布、アップグレード、ロールバックなど、いくつかの問題を解決できますが、環境間の小さな差異への対応はより困難です。また、複雑なDSL（テンプレート構文）構文の習得も必要であり、導入障壁が高くなっています。そこで、宣言型構成管理ツールKustomizeが誕生しました。Kustomizeは、異なる環境やチームにまたがる大量のYAML Kubernetesリソースの管理を支援します。これにより、チームは環境間の小さな差異を軽量に管理し、リソース構成の再利用性を高め、コピーや変更の労力を削減し、構成エラーも大幅に削減できます。アプリケーション構成プロセス全体で、テンプレート構文の追加学習は必要ありません。.

Kustomize は上記の問題を次のように解決します。
  • Kustomize は、Base と Overlays を通じてさまざまな環境にわたってアプリケーション構成を維持します。.
  • Kustomize は Patch を使用して基本構成と実装を再利用し、オーバーレイ記述と基本アプリケーション構成の差分セクションを通じてソースの再利用を実現します。.
  • Kustomize は、DSL 構文を学習する必要なく、ネイティブの Kubernetes YAML ファイルを管理します。.

公式サイトによると、KustomizeはKubernetesのネイティブ構成管理ツールとなり、テンプレートなしでアプリケーション設定をカスタマイズできるようになりました。KustomizeはネイティブK8sのコンセプトを用いてソース構成（YAML）の作成と再利用を支援し、ユーザーはアプリケーション記述ファイル（YAML）をベース（Base YAML）として使用し、Overlaysを介して最終的にデプロイされるアプリケーションに必要な記述ファイルを生成することができます。.


3.3 マルチクラスタ構成

Kustomize 構成管理ツールを理解し、Kustomization (ベース、オーバーレイ) を使用してマルチクラスター展開変換を可能にします。.

マイクロサービス プロジェクトに、完全なソース構成ファイル (YAML) を保存するベース ディレクトリと、さまざまな環境または差分クラスター構成を保存するオーバーレイ ディレクトリの 2 つのディレクトリを作成しました。.

たとえば、この場合、マイクロサービスの完全な構成ファイルは full-demo.yaml であり、これをメイン フォルダーにコピーします。.

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

次に、kustomization.yaml を介してファイルを参照します。

# deploy/kubernetes/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./complete-demo.yaml

開発環境では、サービス ポートやコピーの数を変更するなどの差分要件がある場合は、既存の full-demo.yaml をコピーして変更せずに、overlays/development/kustomization.yaml ファイルで差分設定を構成するだけです。.

3.4 GitOpsワークフローによるマイクロサービスのデプロイ

マイクロサービスのマルチクラスターサポートが完了したら、マイクロサービスの構成が変更されたことを Flux が認識する必要があるため、マイクロサービスリポジトリ (microservices-repo) の CodeCommit URL を Flux リポジトリ (flux-repo) に登録します。.

3.4.1 マイクロサービスリポジトリアドレスの追加

アプリケーション層/アプリケーション フォルダーの下の Flux リポジトリに戻ります。

.
├── base
│ ├── kustomization.yaml
│ └── sock-shop
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ ├── rbac.yaml
│ └── tenant.yaml
└── overlays
└── development
├── kustomization.yaml
└── sock-shop
└── kustomization.yaml

apps/base/sock-shop/ の tenant.yaml ファイルを開き、MICRO_SERVICES_REPO をマイクロサービス URL: https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo に置き換えます。.

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
name: sock-shop-tenant
namespace: sock-shop
spec:
interval: 1m
url: __MICRO_SERVICES_REPO__
ref:
branch: main
secretRef:
name: microservices-basic-access-auth
......

3.4.2 CodeCommit 認証情報の追加

「AWS CodeCommit 認証情報を準備する」のアカウントとパスワードを確認します。コマンドを実行する前に、データ値を base64 エンコードに変換してください。.

次に、base/sock-shop/basic-access-auth.yaml ファイルを開き、BASE64_USERNAME と BASE64_PASSWORD を生成された base64 エンコーディングに置き換えます。

---
apiVersion: v1
kind: Secret
metadata:
name: microservices-basic-access-auth
namespace: sock-shop
type: Opaque
data:
username: __BASE64_USERNAME__
password: __BASE64_PASSWORD__

3.4.3 デプロイメント

Flux 構成リポジトリにマイクロサービスの Git URL を追加すると、Flux は構成の変更を自動的にスキャンします。コードがコミットされると、Flux はクラスターにデプロイされたマイクロサービスがあるかどうか、またそれらが Git リポジトリの定義に一致するかどうかを確認します。一致しない場合は、Flux が自動的にマイクロサービスをクラスターにデプロイします。.

コードを実行した後、コマンド flux get kustomizations -watch を実行し、Flux が更新されるのを待ちます。すべてのカスタマイズの READY ステータスが True になったら、デプロイは完了です。.

以下に示すように、ソック ストア名前空間内のポッドとサービスを検索します。

$ kubectl get pod,service -n sock-shop
NAME READY STATUS RESTARTS AGE
pod/carts-b4d4ffb5c-z4jrj 1/1 Running 0 5m28s
pod/carts-db-6c6c68b747-jl5pd 1/1 Running 0 5m28s
pod/catalogue-759cc6b86-qdmvc 1/1 Running 0 5m28s
pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Running 0 5m28s
pod/front-end-5c89db9f57-cvbdl 1/1 Running 0 5m28s
pod/orders-7664c64d75-lqwbm 1/1 Running 0 5m28s
pod/orders-db-659949975f-qv7pl 1/1 Running 0 5m28s
pod/payment-7bcdbf45c9-szrfq 1/1 Running 0 5m28s
pod/queue-master-5f6d6d4796-nkktx 1/1 Running 0 5m28s
pod/rabbitmq-5bcbb547d7-gzhn4 2/2 Running 0 5m28s
pod/session-db-7cf97f8d4f-9mz6v 1/1 Running 0 5m28s
pod/shipping-7f7999ffb7-95rlc 1/1 Running 0 5m27s
pod/user-68df64db9c-kh247 1/1 Running 0 5m27s
pod/user-db-6df7444fc-jlkp9 1/1 Running 0 5m27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/carts ClusterIP 172.20.33.124 <none> 80/TCP 5m29s
service/carts-db ClusterIP 172.20.75.163 <none> 27017/TCP 5m29s
service/catalogue ClusterIP 172.20.92.254 <none> 80/TCP 5m29s
service/catalogue-db ClusterIP 172.20.242.255 <none> 3306/TCP 5m29s
service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5m29s
service/orders ClusterIP 172.20.8.252 <none> 80/TCP 5m29s
service/orders-db ClusterIP 172.20.40.212 <none> 27017/TCP 5m29s
service/payment ClusterIP 172.20.6.218 <none> 80/TCP 5m29s
service/queue-master ClusterIP 172.20.153.80 <none> 80/TCP 5m29s
service/rabbitmq ClusterIP 172.20.99.37 <none> 5672/TCP,9090/TCP 5m29s
service/session-db ClusterIP 172.20.37.111 <none> 6379/TCP 5m29s
service/shipping ClusterIP 172.20.43.252 <none> 80/TCP 5m29s
service/user ClusterIP 172.20.220.174 <none> 80/TCP 5m29s
service/user-db ClusterIP 172.20.70.57 <none> 27017/TCP 5m29s

AWS ロードバランサーの DNS 名にアクセスします。.


3.5 まとめ

このセクションでは、マイクロサービスビジネスアプリケーション「Sock Shop」オンラインストアを紹介し、マルチクラスター構成を完了しました。また、Fluxベースの標準GitOpsワークフローを作成し、構成ファイルの変更をターゲットクラスターに自動的に同期することで、EKSクラスターへのマイクロサービスのデプロイを完了しました。さらに、実用的な構成管理ツールK8s-Kustomizeと、アプリケーションリソースファイルの管理方法についても紹介しました。このセクションのまとめは次のとおりです。

  • 靴下屋のご紹介
  • 構成管理ツールである Kustomize (ベース、オーバーレイ) と、マルチクラスター マイクロサービス デプロイメントを変更する方法について学習します。.
  • GitOpsワークフローを構築し、マイクロサービスをデプロイする

4. GitOpsワークフローによるイメージベースの自動デプロイメント

コード変更、イメージビルド、および GitOps ワークフローを使用したカスタムリリースの詳細なプロセスを示す例として、Sock Shop フロントエンド マイクロサービスを選択しました。.

4.1 CodePipeline CIの定義

フロントエンドは、Dockerイメージのパッケージングをサポートする純粋なNode.jsフロントエンドサービスです（詳細は第3.1章のSock Shop Architectを参照してください）。CodePipelineで実行されるCIプロセスを定義するには、フロントエンドプロジェクトのソースコードにbuildspec.ymlファイルを追加します。

version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws --version
- AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1`
- AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4`
- echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST
- COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
- IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER
- echo $IMAGE_TAG
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker images...
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG

このCIプロセスは、フロントエンドコードが変更されると、自動的にイメージをビルドし、ECR weaveworksdemos/front-endリポジトリにアップロードします。イメージタグの形式は[ブランチ]-[コミット]-[ビルド番号]です。.

4.2 自動画像更新

開発のテストなど、継続的インテグレーションを伴うアジャイル環境で作業する場合、GitOpsリポジトリの更新やスクリプトを使った新しいサービスイメージの管理は非常に面倒です。幸いなことに、Fluxにはこうした作業を自動化する優れた自動イメージ更新機能があります。この機能を使うには、設定でイメージ更新コンポーネントを有効にするだけです。まだ有効化していない場合でもご安心ください。Fluxブートストラップを反復処理する際に、パラメータ –components-extra=image-reflector-controller,image-automation-controller を追加するだけで有効化できます。.

イメージベースの自動更新を実現するには、次の手順を実行する必要があります。

  • フロントエンド マイクロサービス イメージ リポジトリを登録して、Flux がフロントエンド プロジェクト内の ECR イメージ リポジトリ レポーターを定期的にスキャンできるようにします。.
  • イメージリポジトリにアクセスするための資格情報を設定します。Flux では、ECR イメージリポジトリにアクセスしてイメージ情報を読み取るための資格情報が必要です。.
  • イメージ更新ポリシーを設定します。多くの場合、イメージバージョンへのすべての変更が毎回CDをトリガーするわけではありません。代わりに、指定されたブランチ（ルート）コードのみがCDをトリガーするようにします。この要件を満たすには、特別な更新ポリシーが必要です。.

次に、上記の操作を1つずつ完了させます。.

4.2.1 Gitリポジトリのフロントエンドにイメージポリシーを追加する

microservices-repo プロジェクトでは、DEV 環境で Kustomization オーバーレイを使用して、マイクロサービスのフロントエンドをカスタマイズおよび更新されたバージョンに置き換えます。deploy/kubernetes/overlays/development/kustomization.yaml ファイルを変更します。(注: ACCOUNT_ID は実際の ACCOUNT_ID に置き換えてください)。.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
images:
- name: weaveworksdemos/front-end
newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"}
newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

4.2.2 Fluxリポジトリへのマイクロサービスのフロントエンドの登録

flux-repo プロジェクトで、新しい apps/overlays/development/sock-shop/registry.yaml ファイルを作成し、ACCOUNT_ID を自分の ACCOUNT_ID に置き換えます。.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
name: sock-shop-front-end
namespace: sock-shop
spec:
image: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end
interval: 1m0s

4.2.3 Amazon ECR のアクセス認証情報の設定

Flux には、Amazon ECR 認証情報を使用する方法が 2 つあります。.

  • 自動認証メカニズム (Image Reflector Controller は、Amazon ECR、GCP GCR、Azure ACR の場合のみ、独自に認証情報を取得します)
  • CronJob を使用して、定期的に認証情報（Secret 経由でクラスターに保存されている）を取得します。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
patches:
- patch: |-
- op: add
path: /spec/template/spec/containers/0/args/-
value: --aws-autologin-for-ecr
target:
version: v1
group: apps
kind: Deployment
name: image-reflector-controller
namespace: flux-system

4.2.4 イメージ更新ポリシーの設定

gitops/apps/overlays/development/sock-shop/policy.yaml ファイルを追加します。以下のルールは、master-d480788-1、master-d480788-2、master-d480788-3 などのイメージバージョンに対応しています。.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: sock-shop-front-end
spec:
imageRepositoryRef:
name: sock-shop-front-end
filterTags:
pattern: '^main-[a-fA-F0-9]+-(?P<buidnumber>.*)'
extract: '$buidnumber'
policy:
numerical:
order: asc

gitops/apps/overlays/development/sock-shop/image-automation.yaml ファイルを追加します。Flux イメージ自動化は、ブランチ、パス、その他の情報を含むアプリケーション構成用の Git リポジトリを指定します。.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
name: sock-shop-front-end
spec:
git:
checkout:
ref:
branch: main
commit:
author:
email: [email protected]
name: fluxcdbot
messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
push:
branch: main
interval: 5m0s
sourceRef:
kind: GitRepository
name: sock-shop-tenant
namespace: sock-shop
update:
path: ./deploy/kubernetes/overlays/development
strategy: Setters

4.3 公表と承認

フロントエンドのソースコードを変更して、自動イメージ更新プロセス全体を検証します。.

4.3.1 フロントエンドコードの更新

フロントエンドのフッターを変更し、ファイル front-end/public/footer.html を変更します。.


4.3.2 コードパイプラインの確認

フロントエンドでのコード変更により、CodePipeline の実行が自動的にトリガーされます。.


4.3.3 ECRイメージバージョンの変更を確認する

CodePipeline が完了したら、Amazon ECR コンソールにログインして、weaveworksdemos/front-end イメージのバージョンを確認します。


4.3.4 フラックス画像情報の確認

Flux CLI を使用して、ImageRepository と ImagePolicy が最新バージョンを正常に取得したかどうかを確認します。.

$ flux get images all --all-namespaces
NAMESPACE NAME LAST SCAN SUSPENDED READY MESSAGE 
sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z False True successful scan, found 20 tags
NAMESPACE NAME LATEST IMAGE READYMESSAGE 
sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 True Latest image tag for '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' resolved to: master-1f49071-24
NAMESPACE NAME LAST RUN SUSPENDED READY MESSAGE 
sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z False True no updates made; last commit 1ff6d91 at 2022-09-18T14:34:40Z

4.3.5 マイクロサービスのソースコードは自動的に更新される

Flux はフロントエンドイメージのバージョンを自動的に更新しました。最後のコミットは fluxcdbot によって行われ、イメージタグは最新バージョンの master-1f49071-24 に正常に変更されました。.


4.3.6 ポッドイメージバージョンの確認

kubectl get pod -n sock-shop | grep front-end でポッド名を確認します。kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image でポッドの詳細を確認します。イメージバージョンの更新を確認するには、以下のように表示されます。

$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Image:
Image: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24

4.3.7 静的ページが最新であることを確認する


4.4 まとめ

このセクションでは、イメージに基づく自動デプロイプロセス全体を詳細に説明しました。簡単に言うと、イメージリポジトリに対してFluxの継続的な監視機能を使用します。イメージバージョンの変更が検出されると、Gitリポジトリ内のイメージ構成が自動的に変更され、前のセクションの標準GitOpsワークフローに接続することで自動デプロイが完了します。このセクションをまとめると、次のようになります。

  • CodePipeline を通じて CI プロセスを実行し、フロントエンド コードの継続的な統合を実現します。.
  • Flux アノテーションを使用してビジネス構成ファイルを見つけて変更します。.
  • Flux イメージ更新ポリシーを構成して、Flux が特定のバージョンのイメージを監視し、デプロイメントを完全に自動化できるようにします。.

結果

この記事では、FluxCD を使用してクラウド上の Amazon EKS クラスターへのマイクロサービスのデプロイを自動化する方法と、GitOps パイプラインのベストプラクティスに焦点を当てます。GitOps は、一連のベストプラクティスを網羅した継続的デリバリー手法です。GitOps の基本原則に準拠している限り、CI/CD ツールの構築に厳格な制限はありません。.

この記事の内容:
,
投稿者:
フォローする
コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事
次の記事
あなたも気に入るかもしれない