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

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

　本連載では、オープンソースのオーケストレーションシステムである「Kubernetes」を用いて、スケーラブルで運用しやすいWebアプリケーションを構築する方法を紹介します。前回はWebアプリケーションを外部に公開するために、クラスタにServiceとIngressを追加しました。今回は、Serviceのselectorを使ったBlue-Green Deployment相当の機能の実現方法と、アプリケーションのバージョンごとにURLを自動で割り当てる機能を実現するため、必要な手順を解説します。

はじめに

　本記事の構成図です。

本記事の構成図

　以下の項目について解説していきます。

• アプリケーションのデプロイ
• Production用とDevelop用のServiceをデプロイ
• Nginx（Deplyment）のデプロイ
• Ingressの設定
• 動作確認

　第1回や第2回に比べると構築しなけらばならないことが多く大変ですが、アプリケーションを運用していく上でこのような機能があるとないとでは開発や運用の効率が変わってくるので頑張りましょう！

対象読者

• Linuxの基本的なコマンドが使える方
• Dockerの使用経験がある方
• Kubernetesを使ったことがない技術者

検証環境

Kubernetes側の環境

• Google Container Engine 1.7.6
• Kubernetes 1.7.6

クライアントの環境

• macOS Sierra 10.12.6
• kubectl 1.7.6

アプリケーションのデプロイ

　最初にアプリケーションをデプロイしていきます。アプリケーションはDeploymentとService（Cluster IP）を組み合わせたものです。Deploymentでは事前に作成したmy-apiというイメージを使います。DeploymentとServiceの名前はversionを含んだ名前を指定します。今回は、アプリケーションのバージョンごとにURLを自動で割り当てる機能の動作確認をしたいので、2つのバージョンをデプロイします。

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

リスト1　my-api-v2.yaml（my-api-v3.yamlは「v2」の部分を「v3」に置き替えて別途作成してください）

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-api-v2
spec:
  replicas: 2
  template:
    metadata:
      labels: # labelに下記の値を設定
        app: my-api
        version: v2
    spec:
      containers:
      - name: my-api
        image: tinjyuu/my-api:v2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-api-v2
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    name: http
  selector:
    app: my-api
    version: v2

　このDeploymentとServiceでは以下の設定をしています。

Deployment

• versionを含んだnameを指定。
• labelsでversionを指定。
• imageではそれぞれv2、v3のイメージを指定。
  • イメージの詳細はこちらのGitHubレポジトリのmy-api-v2、my-api-v3で確認ができます。このイメージはhttpでアクセスした時に「my-api-v2」などのアプリケーション名を返すだけのシンプルな作りになっています。

Service

• kindにCluster IPを指定、nameでCluster内部からアクセスできるように。
• DeploymentとServiceを同じ名前を指定。
• ServiceのselectorでDeploymentのappとversionを指定。

　それでは、createコマンドでそれぞれデプロイしましょう。

$ kubectl create -f my-api-v2.yaml
$ kubectl create -f my-api-v3.yaml

Production用とDevelop用のServiceをデプロイ

　構成図に合わせて、Production用とDevelop用のサービスをデプロイします。Production用とDevelop用のServiceにはそれぞれ以下の役割があります。

Productionの用のService

　安定版のWebアプリケーションを外部に公開するためのServiceです。

　Serviceのselectorの機能でステーブルなWebアプリケーションのバージョンを指定します。ここのselectorを切り替えることで、外部に公開するバージョンを変更することができます。切り替えたバージョンに問題があれば、selectorを変更することで前の安定したバージョンに戻すなどの運用が可能です。Blue-Greenではありませんが、selectorとversionというメタデータを使うことで、Blue-Green相当の機能が実現ができます。

Develop用のService

　開発バージョンのWebアプリケーションを外部に公開するためのServiceです。こちらのServiceはNginxを経由してWebアプリケーションを公開するようになっています。Nginxを経由することで、バージョンを含むURLで各バージョンのWebアプリケーションにアクセスできるようになります。一度設定をしてしまえば、あとは、アプリケーションをデプロイするだけで、そのバージョンにアクセスできるエンドポイントが自動的に追加されるようなものなので、効率よく開発ができるようになるはずです。

　それでは、実際にデプロイしてきましょう。

　エディタを開き、次の内容をコピーして「service-production-develop.yaml」というファイル名で保存してください。

リスト2　service-production-develop.yaml

apiVersion: v1
kind: Service
metadata:
  name: service-production
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    name: http
  selector:
    app: my-api
    version: v2
---
apiVersion: v1
kind: Service
metadata:
  name: service-develop
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx-develop

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

• productionのServiceに、my-apiのバージョンv2を指定。
• developのServiceにはNginxを指定して、直接my-apiとは通信しない設定にする。

　それでは、kubectl createコマンドを使ってServiceを作成しましょう

$ kubectl create -f service-production-develop.yaml