はじめに
今回は前回に引き続きKubernetesのためのパッケージマネージャーであるHelmを使ってAzure Kubernetes Service上にWebアプリケーションをデプロイする方法について説明していきます。前回はHelmの概要の説明とHelmチャートの新規作成方法について説明しましたので、今回はHelmを使ったAKSへのアプリケーションのデプロイ方法を中心に説明していきます。
Webアプリケーション用のHelmチャートを完成させよう
前回新規作成したHelmチャートに含まれるファイル群を編集してWebアプリケーションをデプロイ可能な状態にします。
values.yamlの編集
まずはHelmチャートのディレクトリ直下にある「values.yaml」を編集していきます。
values.yamlの編集(zerokara-aks-helm-front/values.yaml)
replicaCount: 1
・・・中略
# imageブロックの内容を差し替え・・・①
image:
repository: zerokara.azurecr.io/zerokara-aks-helm
pullPolicy: IfNotPresent
tag: "v1"
・・・中略
# Serviceに関連する設定情報の変更・・・②
service:
type: LoadBalancer
port: 80
targetPort: 5000
# Redisに関する設定情報を追加・・・③
backendName: zerokara-aks-helm-backend-master
redis:
image:
registry: docker.io
repository: bitnami/redis
tag: 7.0.5
fullnameOverride: zerokara-aks-helm-backend
auth:
enabled: false
「values.yaml」は、次に説明する各テンプレートファイルから参照されるファイルです。テンプレートファイルはその名の通りKubernetesのマニフェストファイルのテンプレートとなっており、具体的な設定値を「values.yaml」等から参照してKubernetesへデプロイ可能なマニュフェストファイルを作り上げていきます。
まずは「image」ブロックの内容を差し替えます(①)。「image」ブロックにはデプロイしたいアプリケーションのDockerイメージの情報を記述します。初期状態ではnginxのイメージを参照するようになっているので、今回作成しACRへプッシュしたWebアプリケーションのDockerイメージが参照できるように内容を修正します。
次にKubernetesのServiceリソースに関連する情報を修正します(②)。Serviceリソースはアプリケーションを外部公開する方法について定義するリソースのため、ポート番号などの情報をアプリケーションに合わせて修正します。
先程依存アプリケーションとしてダウンロードしたRedisのHelmチャートも同様にテンプレートファイルを持っているため、Redisのテンプレートファイル向けの設定値も「values.yaml」に記述していきます(③)。
テンプレートファイルの編集
次にHelmチャート内のテンプレートファイル群を、デプロイしたいアプリケーションの内容に沿って編集していきます。
テンプレートファイルはKubernetesのマニフェストファイルをテンプレート化したもので、Helmチャート作成時に「templates」ディレクトリ配下に作成されています。
deployment.yamlの編集
まずは「deployment.yaml」を編集します。
deployment.yamlの編集(zerokara-aks-helm-front/templates/deployment.yaml)
apiVersion: apps/v1
kind: Deployment
・・・中略
containers:
- name: {{ .Chart.Name }}
securityContext:
{{- toYaml .Values.securityContext | nindent 12 }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
# 環境変数の追加・・・①
env:
- name: REDIS_SERVER
value: {{ .Values.backendName }}
# コンテナ起動ポートの参照先を変更・・・②
ports:
- name: http
containerPort: {{ .Values.service.targetPort }}
protocol: TCP
# コンテナのヘルスチェック用のエンドポイントを変更・・・③
livenessProbe:
httpGet:
path: /health
port: http
readinessProbe:
httpGet:
path: /health
port: http
・・・以下略
テンプレートファイルでは、Kubernetesのマニュフェストファイルの値に相当する部分が「{{ }}」の形式でテンプレート化されています。例えば「{{ .Values.xxx.yyy }}」と記述すると、values.yamlファイル内のxxx.yyyの値が代入されるようになります。テンプレートと値を分離することで、アプリケーションに更新があった場合でも各マニュフェストファイルを修正するのではなく、values.yamlのみを修正するだけで対応できるためメンテナンスが容易になることが期待できます。
「deployment.yaml」はDeploymentのマニュフェストのテンプレートファイルです。そのためここではデプロイするWebアプリケーションの構成に従ってテンプレートを修正しています。
まずは「app.py」の実装内で参照している環境変数の定義を追加します(①)。app.pyでは「REDIS_SERVER」という環境変数名でRedisの接続先を参照しているので、その値をここで設定します。値は先程values.yamlに追加した「backendName」というフィールドに設定した値が代入されるようにします。
次にコンテナが起動するポート番号の参照先を変更します(②)。アプリは5000番ポートで起動するように実装しているため、「.Values.service.targetPort」の値を参照するようにします。
最後にコンテナのヘルスチェック用のエンドポイントを変更します(③)。Deploymentのマニュフェストファイルでは「livenessProbe」と「readinessProbe」という項目があり、これを定義することでコンテナに対してヘルスチェックが実施されるようになります。それぞれの「path」フィールドの値を「/」から「/health」に変更します。これによってapp.pyで実装したヘルスチェック用のAPIに対してヘルスチェックのリクエストが定期的に送られ、コンテナの死活監視が行われるようになります。
service.yamlの編集
次に「service.yaml」を編集します。
service.yamlの編集(zerokara-aks-helm-front/templates/service.yaml)
apiVersion: v1
kind: Service
metadata:
name: {{ include "zerokara-aks-helm-front.fullname" . }}
labels:
{{- include "zerokara-aks-helm-front.labels" . | nindent 4 }}
spec:
type: {{ .Values.service.type }}
ports:
- port: {{ .Values.service.port }}
targetPort: {{ .Values.service.targetPort }} # values.yamlから参照するように変更・・・①
protocol: TCP
name: http
selector:
{{- include "zerokara-aks-helm-front.selectorLabels" . | nindent 4 }}
「service.yaml」はServiceマニュフェストのテンプレートファイルです。アプリケーションを公開する際のポートをここで定義することができます。元々のテンプレートファイルでは、「targetPort」の値が「http」となっているため、コンテナの80番ポートに対してアクセスされるようになってしまっているので、ここを「.Values.service.targetPort」から参照するように変更し、5000番ポートに対してアクセスするように変更します(①)。
テンプレートファイルの確認を行う
HelmチャートをAKSにデプロイする前に、編集したテンプレートファイルがKubernetesの認識できる形式、つまりマニュフェストファイルとして正しく生成されるかを事前に確認してみましょう。
テンプレートファイルからマニュフェストファイルを出力する
$ helm template zerokara-aks-helm-front
「helm template」コマンドを実行すると、Helmチャート内に存在するテンプレートファイルにChart.yamlやvalues.yamlなどから値が代入され、Kubernetesにデプロイするマニュフェストと同等の内容が出力されます。 以下は、出力内容から先程編集した「service.yaml」の代入結果を抜粋したものです。
出力されたマニュフェストの抜粋
apiVersion: v1
kind: Service
metadata:
name: release-name-zerokara-aks-helm-front
labels:
helm.sh/chart: zerokara-aks-helm-front-0.1.1
app.kubernetes.io/name: zerokara-aks-helm-front
app.kubernetes.io/instance: release-name
app.kubernetes.io/version: "v1"
app.kubernetes.io/managed-by: Helm
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 5000
protocol: TCP
name: http
selector:
app.kubernetes.io/name: zerokara-aks-helm-front
app.kubernetes.io/instance: release-name
テンプレートファイルでは「{{ }}」で記述していたテンプレート部分に、値が代入されていることが分かります。「helm template」コマンドを使うことでデプロイ時の事前チェックができるほか、テンプレートファイルの作成中にテンプレートが正しく変換できるかのデバッグに活用することもできます。
Helmを使ってWebアプリケーションをAKS上にデプロイしよう
作成したHelmチャートの各テンプレートファイルをアプリケーションの構成に合わせて修正できたら、Helmチャートを使ってAKSにアプリケーションをデプロイしてみましょう。
作成したHelmチャートをAKSクラスターにデプロイする
Helmを使ったKubernetesクラスターへのアプリケーションのデプロイには、前回インストールしたHelm CLIを使用します。
HelmチャートのAKSクラスターへのデプロイ
# AKSクラスターに接続する
$ az aks get-credentials --resource-group zerokara --name zerokara-aks
$ helm install zerokara-aks-helm-front zerokara-aks-helm-front/
NAME: zerokara-aks-helm-front
NAMESPACE: default
STATUS: deployed
REVISION: 1
・・・以下略
まずはターミナルをAKSクラスターに接続します。Azure CLIの「az aks get-credentials」コマンドを使って、ご自身のAzure環境上にあるAKSクラスターと接続します。
次に「helm install」コマンドを使い、HelmチャートをKubernetesクラスターへデプロイします。コマンドの第1引数にはAKSクラスタ上でのHelmチャートの名称を指定します。第2引数にはデプロイするHelmチャートのパスを指定します。
コマンド実行後、「STATUS」という行が出力され「deployed」となっていればデプロイは成功です。
AKSクラスター上のリソースの確認とアプリケーションの動作確認
Helmチャートのデプロイ後少し待つとAKSクラスター内で各リソースの作成が完了します。正しくアプリケーションがデプロイされ、サービスとして公開されているかを確認していきます。
アプリケーションの公開先URLの取得
$ export SERVICE_IP=$(kubectl get svc --namespace default zerokara-aks-helm-front --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
$ echo http://$SERVICE_IP
上記コマンドでkubectlコマンドを使ってサービスのパブリックIPアドレスを取得し、URL形式で出力をします。出力されたURLにWebブラウザからアクセスし、アクセスカウンターのアプリケーションが表示されれば成功です。