このシリーズでは、コードとしてのインスフラストラクチャ (IaC) を導入する方法について説明していきます。開発者の皆さんに IaC のコンセプトをしっかりご理解いただけるよう、チュートリアルやコード サンプルを交えて作成しました。各記事では以下のトピックについて取り上げます。
- パート 1: Kubernetes クラスタを作成する
- パート 2: Docker イメージを作成して Kubernetes にデプロイする
- パート 3: CI/CD によってデプロイを自動化する
今回の記事では、アプリケーション用に Docker イメージを作成して、Docker Hub にプッシュする方法を説明します。 HashiCorp の Terraform を使用して、作成した Docker イメージを Google Kubernetes Engine (GKE) クラスタにデプロイする方法にも触れていきます。この記事で行う手順は以下のとおりです。
- Docker イメージを新規作成する
- 作成した Docker イメージを Docker Hub レジストリにプッシュする
- Terraform を使用して GKE クラスタを新規作成する
- Terraform Kubernetes プロバイダーを使用して Terraform Kubernetes Deploymentを新規作成する
- Terraform を使用して作成したすべてのリソースを破棄する
事前にパート 1 の前提条件セクションに記載されている手順をすべて完了する必要があります。前提条件の手順が完了したら、こちらのコード リポジトリに含まれるサンプル Node.js アプリケーションに基づいて Docker イメージを作成する方法から始めていきましょう。
Docker イメージの作成
前回の記事では、Terraform を使用して GKE クラスタを作成しました。しかし、アプリケーションやサービスがデプロイされていない状態では、クラスタは何の役にも立ちません。Kubernetes (K8s) はコンテナ オーケストレーターなので、アプリやサービスは Docker イメージにパッケージ化する必要があります。そうすることで、アプリケーションやサービスを実行する Docker コンテナが生成されます。
Docker イメージは docker build コマンドで作成します。Docker イメージを作成するには、作成方法を指定するための Dockerfile が必要です。Dockerfile について解説する前に、.dockerignore ファイルについて少し説明しておきましょう。
.dockerignore ファイル
.dockerignore ファイルを使用すると、ファイル内に宣言したパターンと一致するファイルおよびディレクトリを除外できます。このファイルは、サイズが大きいまたは機密情報の含まれるファイルやディレクトリを必要がないのにデーモンに送信した結果、これらをパブリックイメージに追加してしまうのを防止する役目を果たします。今回のプロジェクトでは、.dockerignore ファイルを使用して Terraform 関連の不要なファイルと Node.js のローカル依存関係を除外します。
Dockerfile
Dockerfile は、Docker イメージの作成に欠かせないファイルです。イメージの作成方法と設定方法に加え、イメージにインポートするファイルの情報も指定します。Dockerfile は非常にダイナミックなので、さまざまな方法でさまざまな目的を達成することができます。正常に機能するイメージを作成するためには、Dockerfile の機能をよく理解しておく必要があります。では、今回のプロジェクトのコード リポジトリに含まれる Dockerfile について詳しく見ていきましょう。
FROM node:12
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
COPY package*.json ./
RUN npm install --only=production
# Bundle app source
COPY . .
EXPOSE 5000
CMD [ "npm", "start" ]
FROM node:12 の行では、継承元のイメージを定義しています。イメージを作成するとき、Docker は親イメージを継承します。今回の親イメージは node:12 です。ローカルに存在しない場合は Docker Hub からプルされます。
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
COPY package*.json ./
RUN npm install --only=production
上記のコード ブロックでは、Docker イメージ内の作業ディレクトリを指定する WORKDIR パラメーターを定義しています。COPY package*.json ./ の行でパッケージ関連ファイルを Docker イメージにコピーします。RUN npm install の行で、package.json ファイルに列記されているアプリケーション依存関係をインストールします。
COPY . .
EXPOSE 5000
CMD [ "npm", "start" ]
上記のコード ブロックは、.dockerignore ファイルに列記されているファイルとディレクトリを除くすべてのファイルを Docker イメージにコピーします。EXPOSE 5000 の行で、この Docker イメージに公開するポートを指定します。最後に、CMD [ "npm", "start" ] の行で、このイメージの起動方法を定義します。今回は、このプロジェクトの package.json ファイルに指定されている start セクションを実行します。この CMD パラメーターは既定の実行コマンドです。Dockerfile についてひととおりご説明できたので、ここからは Dockerfile を使用してローカルでイメージを作成してみましょう。
docker build コマンド
Dockerfile と docker build コマンドを使用して、Dockerfile 内のディレクティブから新しいイメージを作成できます。Docker イメージを作成するにあたって、理解しておくべき命名規則がいくつかあります。これらは、イメージを共有する場合に非常に重要です。
イメージの作成に入る前に、イメージの命名規則について確認しておきましょう。Docker イメージは、タグのコンセプトを採用しています。タグとは、スラッシュで区切られた名前コンポーネントのことです。このチュートリアルでは、イメージを Docker Hub にプッシュします。したがって、イメージ名のプレフィックスとして Docker Hub ユーザー名を指定する必要があります。この例では ariv3ra/ です。私はいつもこの後ろに、プロジェクト名か、イメージのわかりやすい説明を続けます。この Docker イメージのフルネームは ariv3ra/learniac:0.0.1 になります。:0.0.1 はアプリケーションのバージョン タグですが、イメージの詳細説明に使用することもできます。
イメージ名について理解できたでしょうか。では、いよいよイメージの作成です。プロジェクト リポジトリのルートから以下のコマンドを実行します (ariv3ra の部分は実際の Docker Hub 名で置き換えてください)。
docker build -t ariv3ra/learniac -t ariv3ra/learniac:0.0.1 .
次に、以下のコマンドを実行して、マシン上の Docker イメージの一覧を表示します。
docker images
今回の例では以下の内容が出力されます。
REPOSITORY TAG IMAGE ID CREATED SIZE
ariv3ra/learniac 0.0.1 ba7a22c461ee 24 seconds ago 994MB
ariv3ra/learniac latest ba7a22c461ee 24 seconds ago 994MB
docker push コマンド
これで Docker Hub にイメージをプッシュする準備が整ったので、イメージを公開しましょう。Docker Hub のサービスにアクセスするには認証が必要なので、login コマンドを実行して認証します。以下のコマンドでログインします。
docker login
プロンプトが表示されたら、Docker Hub 認証情報を入力してアカウントを認証します。このログイン操作が必要になるのはマシン 1 台につき 1 回のみです。さあ、準備は万端なので、イメージをプッシュしましょう。
以下のコマンドを実行して新しいメージを Docker Hub にプッシュします。ここでは必ず docker images コマンドを実行して表示されたイメージ名を使用してください。
docker push ariv3ra/learniac
今回の例では以下の内容が出力されます。
The push refers to repository [docker.io/ariv3ra/learniac]
2109cf96cc5e: Pushed
94ce89a4d236: Pushed
e16b71ca42ab: Pushed
8271ac5bc1ac: Pushed
a0dec5cb284e: Mounted from library/node
03d91b28d371: Mounted from library/node
4d8e964e233a: Mounted from library/node
これで Docker Hub に Docker イメージが保管され、GKE クラスタにデプロイできる状態になりました。アプリケーションを新しい Kubernetes クラスタにデプロイするためのすべてのピースが揃ったところで、次は Terraform を使用して Kubernetes Deployment を構築します。
本シリーズのパート 1 では、Terraform を使用して新しい Google Kubernetes Engine (GKE) クラスタを作成する方法を取り上げました。既に触れたように、このクラスタはアプリケーションやサービスを一切提供しません。なぜなら、このクラスタにはアプリケーションもサービスもデプロイしていないからです。ここからは、Terraform を使用して Kubernetes Deployment をデプロイするのに必要な要素について見ていきます。
Terraform Kubernetes Deployment
Terraform には Kubernetes Deployment のリソースがあります。このリソースによって、GKE クラスタに配置する Kubernetes Deployment を定義し、実行するわけです。本シリーズのパート 1 では、part01/iac_gke_cluster/ ディレクトリ内の Terraform コードを使用して GKE クラスタを新規作成しました。今回は、part02/iac_gke_cluster/ ディレクトリと part02/iac_kubernetes_app/ ディレクトリを使用します。iac_gke_cluster/ は、パート 1 で使用したのと同じコードです。ここでは、このコードと iac_kubernetes_app/ ディレクトリを組み合わせて使用します。
Terraform Kubernetes プロバイダー
パート 1 では、Terraform の Google Cloud Platform プロバイダーを使用して GKE クラスタを新規作成しました。これは Google Cloud Platform に固有のクラスタですが、まだ Kubernetes の配下にあります。GKE は基本的に Kubernetes クラスタなので、GKE クラスタに配置するアプリケーションを構成してデプロイするには、Terraform Kubernetes プロバイダーとKubernetes Deployment リソースを使用する必要があります。
Terraform コード
part02/iac_kubernetes_app/ ディレクトリには以下のファイルが含まれています。
- providers.tf
- variables.tf
- main.tf
- deployments.tf
- services.tf
- output.tf
これらのファイルには、Kubernetes クラスタにデプロイするアプリケーションを定義、作成、構成するために使用するコードがすべて含まれています。それでは、各ファイルの役割について詳しく見ていきましょう。
解説: providers.tf
provider.tf ファイルでは、これから使用する Terraform プロバイダー (Terraform Kubernetes プロバイダー) を定義します。provider.tf は以下のようになります。
provider "kubernetes" {
}
上記のコード ブロックは、この Terraform プロジェクトで使用するプロバイダーを定義しています。{ } ブロックが空なのは、別のプロセスによって認証要求を処理するからです。
解説: variables.tf
このファイルは一見、パート 1 の variables.tf とよく似ていますが、今回の Terraform Kubernetes プロジェクトで使用する入力変数のみが指定されています。
variable "cluster" {
default = "cicd-workshops"
}
variable "app" {
type = string
description = "Name of application"
default = "cicd-101"
}
variable "zone" {
default = "us-east1-d"
}
variable "docker-image" {
type = string
description = "name of the docker image to deploy"
default = "ariv3ra/learniac:latest"
}
ここで定義されている変数は、この Terraform プロジェクト全体を通じてさまざまなファイルのコードブロック内で使用されます。これらすべての変数には default 値がありますが、コードの実行時に CLI を使って定義することで変更可能です。これらの変数を使用することで Terraform コードに求められる柔軟性が確保され、変数コードを再利用できるようになります。上記では variable "docker-image" の既定のパラメーターに私の Docker イメージが指定されていますが、この値は実際の Docker イメージのファイルで置き換えてください。
解説: main.tf
main.tf ファイルの要素を 1 つずつ解説していきたいと思います。terraform ブロックから始めましょう。このブロックでは Terraform Backendのタイプを指定します。Terraform の「バックエンド」によって、ステートを読み込む方法や、apply などのオペレーションの実行方法が決定されます。この抽象化により、非ローカルのファイル ステート ストレージやリモート実行が使用可能になります。今回のコードブロックでは、remote バックエンドを使用します。このバックエンドは Terraform Cloud を使用し、パート 1 の前提条件セクションに沿って作成した iac_kubernetes_app ワークスペースに接続しています。
terraform {
required_version = "~>0.12"
backend "remote" {
organization = "datapunks"
workspaces {
name = "iac_kubernetes_app"
}
}
}
解説: deployments.tf
続いて、deployments.tf ファイルの構文を見ていきます。このファイルは、Terraform Kubernetes Deployment リソースを使用して、アプリケーションを GKE クラスタにリリースするために必要なすべての Kubernetes リソースを定義、構成、作成します。
resource "kubernetes_deployment" "app" {
metadata {
name = var.app
labels = {
app = var.app
}
}
spec {
replicas = 3
selector {
match_labels = {
app = var.app
}
}
template {
metadata {
labels = {
app = var.app
}
}
spec {
container {
image = var.docker-image
name = var.app
port {
name = "port-5000"
container_port = 5000
}
}
}
}
}
}
具体的に何が起こっているのかを理解するために、コードの要素をそれぞれ確認しておきましょう。
resource "kubernetes_deployment" "app" {
metadata {
name = var.app
labels = {
app = var.app
}
}
上記のコードブロックでは、Kubernetes のデプロイ オブジェクトを定義する Terraform Kubernetes Deployment リソースを使用するよう指定しています。Kubernetes サービスで使用するパラメーターの値は、metadata ブロックで指定します。
spec {
replicas = 3
selector {
match_labels = {
app = var.app
}
}
template {
metadata {
labels = {
app = var.app
}
}
spec {
container {
image = var.docker-image
name = var.app
port {
name = "port-5000"
container_port = 5000
}
}
}
}
}
リソースの spec{...} ブロックでは、クラスタ内のアプリケーションのために実行する 3 つの Kubernetes pods を指定しています。selector{...} ブロックはラベル セレクターであり、Kubernetes のコア グループのプリミティブです。ユーザーはこれらを使って、オブジェクトのセットを選択します。
リソースの template{...} ブロック内には spec{...} ブロックが入れ子になっており、その内部にはさらに container{...} プロパティ ブロックが入れ子になっています。このブロック内には、デプロイで使用するコンテナを定義、構成するパラメーターが含まれています。コードからおわかりのように、ここに pod の Docker image (使用するイメージ) を定義します。コンテナの name は Kubernetes 内の名前になります。port は、Ingress に実行中のアプリケーションへのアクセスを許可するコンテナ上で公開されます。値は同じディレクトリ内の variables.tf ファイルから取得されたものです。Terraform Kubernetes Deployment リソースは非常に堅牢な構成が実行できます。ツールについて理解を深めるために、他のプロパティを指定して実験してみることをお勧めします。
解説: services.tf
Terraform Kubernetes Deployment リソース ファイルを作成し、このアプリケーションで使用する Kubernetes Deployment を定義しました。アプリのデプロイを完了する前に、もう 1 つ詳細を確認しておくべきものがあります。これからデプロイするアプリケーションは標準的な Web サイトです。すべての Web サイトと同様に、利用するにはアクセス許可が必要になります。ここまでで deployments.tf ファイルには、Docker イメージを使用して Kubernetes pod をデプロイするディレクティブと必要な pod の数が指定されていますが、デプロイにおける重要な要素がまだ欠けています。それは Kubernetes サービスです。このサービスは、複数の pod で実行中のアプリケーションをネットワーク サービスとして公開するための抽象化を提供します。Kubernetes では、馴染みのないサービス ディスカバリ メカニズムを使用する場合にも、アプリケーションを変更する必要はありません。Kubernetes が pod に IP アドレスを割り当て、一連の pod に単一の DNS 名を割り当てて、負荷分散処理を行います。
Terraform Kubernetes サービスを定義するのが、services.tf ファイルです。このサービスは Kubernetes 要素をつなぎ合わせ、Ingress にクラスタ内の pod で実行中のアプリケーションへのアクセスを許可します。services.tf ファイルの中身を見ていきましょう。
resource "kubernetes_service" "app" {
metadata {
name = var.app
}
spec {
selector = {
app = kubernetes_deployment.app.metadata.0.labels.app
}
port {
port = 80
target_port = 5000
}
type = "LoadBalancer"
}
}
spec{...} ブロックと、このブロック内にある要素に注目してください。selector{ app...} ブロックでは、deployments.tf ファイルに定義されている名前を指定します。このブロックは、deployments リソース内にある metadata ブロックの label プロパティの app 値を表します。これは、関連リソースに既に割り当てられている値を再利用する一例です。重要な値を合理化して、ここに示したような重要なデータの参照整合性を確立するメカニズムも提供します。
port{...} ブロックには port と target_port の 2 つのプロパティが含まれ、これらのパラメーターでサービスがアプリケーションへのリクエストを待機する外部ポートを定義します。今回の例では、ポート 80 を使用します。target_port は pod が待機する内部ポートであり、ポート 5000 です。このサービスは、すべてのトラフィックをポート 80 からポート 5000 にルーティングします。
ここで取り上げる最後の要素は type パラメーターです。これから作成するサービスのタイプを指定します。Kubernetes のサービスには 3 つのタイプがあります。今回の例で使用するのは、LoadBalancer タイプです。クラウド プロバイダーのロードバランサーを使用してサービスを外部に公開します。外部ロードバランサーのルーティング先である NodePort と ClusterIP Service は自動的に作成されます。今回は GCP により、トラフィックの制御と GKE クラスタへのルーティングを行う LoadBalancer が作成、構成されます。
解説: output.tf
Terraform ではTerraform では出力値と呼ばれるコンセプトが採用されています。Terraform モジュールが返した値は、子モジュールに出力され、そのリソース属性のサブセットが親モジュールに公開されるか、terraform apply の実行後に CLI 出力に特定の値が出力されます。以下の output.tf ブロックでは、出力値を使用して、クラスタ名や新規作成した LoadBlancer サービスの Ingress IP アドレスなどの値を読み出します。このアドレスを使用すると、GKE クラスタ上の pod でホスティングされているアプリケーションにアクセスできます。
output "gke_cluster" {
value = var.cluster
}
output "endpoint" {
value = kubernetes_service.app.load_balancer_ingress.0.ip
}
part02/iac_gke_cluster での Terraform の初期化
Terraform のプロジェクトと構文についての理解が深まったところで、今度は Terraform を使用して GKE クラスタのプロビジョニングを行います。まずは part02/iac_gke_cluster ディレクトリに移動しましょう。
cd part02/iac_gke_cluster
part02/iac_gke_cluster ディレクトリで以下のコマンドを実行します。
terrform init
今回の例では以下の内容が出力されます。
Initializing the backend...
Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "google" (hashicorp/google) 3.31.0...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.google: version = "~> 3.31"
Terraform has been successfully initialized!
うまくいきました。次は、いよいよ GKE クラスタの作成です。
part02/iac_gke_cluster での Terraform の適用
Terraform には、Terraform コードをドライ実行して、実際には何も実行することなくバリデーションできる terraform plan というコマンドがあります。このコマンドでは、Terraform が既存のインフラストラクチャに対して実行するすべてのアクションと変更をグラフ化することも可能です。ターミナルで以下を実行します。
terraform plan
今回の例では以下の内容が出力されます。
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# google_container_cluster.primary will be created
+ resource "google_container_cluster" "primary" {
+ additional_zones = (known after apply)
+ cluster_ipv4_cidr = (known after apply)
+ default_max_pods_per_node = (known after apply)
+ enable_binary_authorization = false
...
Terraform は main.tf ファイル内のコードに基づいて GCP リソースを新規作成します。インフラストラクチャを新規作成してアプリケーションをデプロイする準備が整ったので、ターミナルで以下のコマンドを実行します。
terraform apply
コマンドを確認するメッセージが表示されたら、yes と入力して Enter キーを押します。
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
Terraform により、GCP 上に新しい Google Kubernetes Engine クラスタが作成されます。
注: クラスタの完成には 3 ～ 5 分かかります。バックエンド システムがプロビジョニングを行ってからクラスタをオンラインにするため、瞬時には処理されません。
クラスタが完成すると、以下のような内容が出力されます。
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Outputs:
cluster = cicd-workshops
cluster_ca_certificate = <sensitive>
host = <sensitive>
password = <sensitive>
username = <sensitive>
GKE クラスタが新規作成され、Outputs の結果が表示されます。機密情報としてマークされていると、出力値が <sensitive> タグによってマスキングされ、結果に表示されません。このように、機密データは必要に応じて保護することができます。
次に、part02/iac_kubernetes_app/ ディレクトリ内のコードを使用して、Kubernetes Deployment と付随する LoadBalancer サービスを作成します。
part02/iac_kubernetes_app/ での Terraform の初期化
part02/iac_kubernetes_app/ ディレクトリ内のコードを使用して GKE クラスタにアプリケーションをデプロイします。まず、以下のコマンドでディレクトリを移動します。
cd part02/iac_kubernetes_app/
part02/iac_kubernetes_app/ で以下のコマンドを実行して Terraform プロジェクトを初期化します。
terrform init
今回の例では以下の内容が出力されます。
Initializing the backend...
Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "kubernetes" (hashicorp/kubernetes) 1.11.3...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.kubernetes: version = "~> 1.11"
Terraform has been successfully initialized!
GKE クラスタの認証情報
Terraform で google_container_cluster を作成できたら、クラスタの認証を行う必要があります。Google Cloud CLI を使用してクラスタ アクセスを構成し、kubeconfig ファイルを生成します。以下のコマンドを実行して、Kubernetes クラスタにアクセスします。
gcloud container clusters get-credentials cicd-workshops --zone="us-east1-d"
このコマンドを実行すると、認証メカニズムとして gcloud を使用する kubeconfig エントリが、gcloud によって生成されます。上記のコマンドでは、cicd-workshops 値をクラスタ名として使用します。この値は variables.tf にも指定されています。続いて、アプリを GKE にデプロイします。
part02/iac_kubernetes_app/ での Terraform の適用
いよいよ Terraform を使用してアプリケーションを GKE クラスタにデプロイする準備が整いました。以下のコマンドを実行します。
terraform plan
今回の例では以下の内容が出力されます。
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# kubernetes_deployment.app will be created
+ resource "kubernetes_deployment" "app" {
+ id = (known after apply)
+ metadata {
+ generation = (known after apply)
+ labels = {
+ "app" = "cicd-101"
}
+ name = "cicd-101"
+ namespace = "default"
+ resource_version = (known after apply)
+ self_link = (known after apply)
+ uid = (known after apply)
}
...
Terraform は deployment.tf ファイルと services.tf ファイル内のコードに基づいて GCP リソースを新規作成します。インフラストラクチャを新規作成してアプリケーションをデプロイする準備が整ったので、ターミナルで以下のコマンドを実行します。
terraform apply
コマンドを確認するメッセージが表示されたら、yes と入力して Enter キーを押します。
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
Terraform により、新しい Kubernetes アプリケーション デプロイと、関連する LoadBalancer が作成されます。
注: クラスタの完成には 3 ～ 5 分かかります。バックエンド システムがプロビジョニングを行ってからクラスタをオンラインにするため、瞬時には処理されません。
クラスタが完成すると、以下のような内容が出力されます。
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Outputs:
endpoint = 104.196.222.238
gke_cluster = cicd-workshops
これでアプリケーションがデプロイされました。endpoint 値として、クラスタ LoadBalancer のパブリック Ingress の IP アドレスが出力されます。アプリケーションにはこのアドレスからアクセスできます。Web ブラウザーを開き、output 値を使用してアプリケーションにアクセスすると、Web ページに「Welcome to CI/CD 101 using CircleCI!」というメッセージが表示されます。
Terraform のリソースの破棄
Kubernetes デプロイが動作すること、GKE クラスタにアプリケーションが正常にデプロイされたことを確認できたところで、今度は terraform destroy コマンドを実行して、このチュートリアルで作成したアセットを破棄してみましょう。アセットはそのまま稼働させても構いません。しかし、Google Cloud Platform 上でアセットを実行するにはコストが発生し、そのコストに対する責任も負わなくてはなりません。Google から無料トライアルの登録ユーザーに提供されている 300 ドル分のクレジットは、アセットを実行し続ければあっという間に尽きてしまいます。もちろん、ご事情に合わせて判断していただければと思いますが、terraform destroy を実行すれば実行中のすべてのアセットを破棄できます。
以下のコマンドを実行して GKE クラスタを破棄しましょう。
terraform destroy
なお、上記のコマンドで破棄できるのは part02/iac_kubeernetes_app/ デプロイのみです。このチュートリアルで作成したすべてのリソースを破棄するには、以下のコマンドを実行する必要があります。
cd ../iac_gke-cluster/
terraform destroy
上記のコマンドを実行すると、先に作成した GKE クラスタが破棄されます。
まとめ
お疲れさまでした。本シリーズのパート 2 はこれで以上です。今回は新しい Docker イメージを作成して公開する手順と、アプリケーションをプロビジョニングし、コードとしてのインフラストラクチャおよび Terraform を使用して Kubernetes クラスタにデプロイする方法をご説明しました。
次回のパート 3 では、ここまでに学習した内容を CI/CD パイプラインに取り入れ、CircleCI を使用して自動化する方法について取り上げます。
さらに詳しく知りたい方は以下の資料を参照してください。
