Kubernetesで構築したWebアプリケーションに、Blue-Green Deployment相当の機能と、バージョンごとにURLを生成する機能を追加

KubernetesによるスケーラブルなWebアプリ環境の構築 第3回

Nginx（Deployment）のデプロイ

　次に、Develop用のServiceと通信するNginxのDeploymentをデプロイしていきましょう。このNginxを経由することで、バージョンを含むURLで各バージョンのWebアプリケーションにアクセスできるようになります。これはNginxのlocation機能を使って実現します。

　それでは、NginxのPodをデプロイしていきましょう。今回は、Nginxの設定ファイルを編集する必要があるので、Dockerイメージのビルドから行います。手順は以下の通りです。

1. NginxのDockerイメージのビルド
2. DockerイメージをGoogle cloud platformのContainer Registryにpush
3. NginxのPodのデプロイ

　Container RegistryはGoogle Cloud Platformが提供している、プライベートなDockerコンテナイメージのレポジトリです。GKEから自前のDockerイメージを使う場合などによく使います。

　では早速、NginxのDockerイメージのビルドをしていきましょう。

　Dockerfileやnginxの設定ファイルは私が事前に編集したものがあるので、それをgit cloneして使ってください。

$ git clone https://github.com/tinjyuu/k8s-codezine.git
$ cd k8s-codezine/step3/nginx

　pullが完了したら、次はdocker buildとpushを行いましょう。tag名はGKEのプロジェクトIDを含んだものを指定します。これは、GKEと同じプロジェクトのContainer Registryにpushするためで、GKEから見ると同じプロジェクトのContainer Registryなのでそのイメージを特別な設定なしにpullして使えます。

$ docker build -t gcr.io/{プロジェクト名}/nginx:v1 .
$ gcloud docker -- push gcr.io/{プロジェクト名}/nginx:v1

　pushが完了したらNginxのDeploymentをデプロイします。イメージには先ほどpushしたイメージを指定します。このDeploymentは先ほどのNginxのイメージとDnsmasq（DNSサーバー）の構成になっています。

　それでは、Deploymentの設定ファイルを作成していきましょう。エディタを開き、次の内容をコピーして「nginx-develop.yaml」というファイル名で保存してください。

リスト3　nginx-develop.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-develop

spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: gcr.io/{project-id}/nginx:v1
        ports:
        - containerPort: 80
      - name: dnsmasq
        image: "janeczku/go-dnsmasq:release-1.0.5"
        args:
          - --listen
          - "127.0.0.1:53"
          - --default-resolver
          - --append-search-domains
          - --hostsfile=/etc/hosts
          - --verbose

　nginx-develop.yamlをデプロイします。

$kubectl create -f nginx-develop.yaml

Ingressの設定

　次に、Ingressをデプロイします。エディタを開き、次の内容をコピーして「ingress-my-api.yaml」というファイル名で保存してください。

リスト4　ingress-my-api.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "test-ip" # 第2回の記事で、予約したstatic-ipを指定
spec:
  rules:
  - host: pro.app.io
    http:
      paths:
      - backend:
          serviceName: service-production
          servicePort: 80
  - host: dev.app.io
    http:
      paths:
      - backend:
          serviceName: service-develop
          servicePort: 80

　このIngressでは以下の設定をしています。

• pro.app.ioのドメインからのアクセスであれば、service-productionにリクエストを流す設定
• dev.app.ioのドメインからのアクセスであれば、service-developにリクエストを流す設定

　今回は、前回の記事で作成したIngressの設定を上書きする形でデプロイしましょう。そのため、createコマンドではなくてapplyコマンドを使います。

$kubectl apply -f ingress-my-api.yaml

動作確認

　最後に動作確認をしましょう。確認したい点は以下の通りです。

• pro.app.ioにアクセスするとProductionのServiceで指定したアプリケーションのバージョンにつながるか。
• dev.app.io/versions/{my-apiのversion}にアクセスすると{my-apiのversion}で指定したmy-apiのバージョンにつながるか。

　それでは、curlコマンドを使って、pro.app.ioにアクセスしましょう。ただ、実際にはIngressのIPにpro.app.ioのドメインが振られていないはずなのでcurlの--resolveオプションを使ってアクセスします。

$curl --resolve pro.app.io:80:{ingress-ip} http://pro.app.io
my-api-v2%

　my-apiのv2にアクセスできたことが確認できると思います。

　次に、dev.app.ioのversionsというURLパスで各versionのmy-apiにアクセスしてみます。

$curl --resolve dev.app.io:80:{ingress-ip} http://dev.app.io/versions/v2/index
my-api-v2%

$curl --resolve dev.app.io:80:{ingress-ip} http://dev.app.io/versions/v3/index
my-api-v3%

　URLのパスに合わせてアクセスできるバージョンが変わったことが確認できると思います。

最後に

　以上でServiceのselectorを使ったBlue-Green Deployment相当の機能の実現、アプリケーションのバージョンごとにURLを自動で割り当てる機能を実現できました。

参考Webページ

• Kubernetes Documentation（公式）
• Google Container Engine ドキュメント（公式）