DockerComposeワークフローをKubernetesに移行する方法

投稿日: 2019-11-08 2022-10-16
タグ: Docker, Kubernetes, Microservices, MongoDB, Node.js

序章

最新のステートレスアプリケーションを構築する場合、アプリケーションのコンポーネントをコンテナ化するは、分散プラットフォームでのデプロイとスケーリングの最初のステップです。開発でDockerCompose を使用したことがある場合は、次の方法でアプリケーションを最新化およびコンテナー化できます。

コードから必要な構成情報を抽出します。
アプリケーションの状態をオフロードします。
繰り返し使用するためにアプリケーションをパッケージ化します。

また、コンテナイメージの実行方法を指定するサービス定義も作成します。

Kubernetes などの分散プラットフォームでサービスを実行するには、Composeサービス定義をKubernetesオブジェクトに変換する必要があります。これにより、アプリケーションを復元力でスケーリングできます。 Kubernetesへの変換プロセスを高速化できるツールの1つは、 kompose です。これは、開発者がComposeワークフローをKubernetesやOpenShiftなどのコンテナーオーケストレーターに移動するのに役立つ変換ツールです。

このチュートリアルでは、komposeを使用してComposeサービスをKubernetesオブジェクトに変換します。 komposeが提供するオブジェクト定義を開始点として使用し、セットアップで Secrets 、 Services 、およびPersistentVolumeClaimsが使用されるように調整します。 Kubernetesが期待していること。チュートリアルが終了すると、Kubernetesクラスターで実行されているMongoDBデータベースを備えたシングルインスタンスNode.jsアプリケーションが作成されます。このセットアップは、 Docker Compose を使用したNode.jsアプリケーションのコンテナー化で説明されているコードの機能を反映し、ニーズに合わせて拡張できる本番環境に対応したソリューションを構築するための良い出発点になります。

前提条件

ロールベースのアクセス制御（RBAC）が有効になっているKubernetes1.10+クラスター。このセットアップではDigitalOceanKubernetesクラスターを使用しますが、別の方法を使用してクラスターを自由に作成できます。
The kubectl ローカルマシンまたは開発サーバーにインストールされ、クラスターに接続するように構成されたコマンドラインツール。インストールについてもっと読むことができます kubectl 公式ドキュメントにあります。
Dockerがローカルマシンまたは開発サーバーにインストールされています。 Ubuntu 18.04を使用している場合は、 Ubuntu18.04にDockerをインストールして使用する方法の手順1と2に従ってください。それ以外の場合は、他のオペレーティングシステムへのインストールについて、公式ドキュメントに従ってください。必ず非rootユーザーをに追加してください docker リンクされたチュートリアルのステップ2で説明されているように、グループ。
DockerHubアカウント。これを設定する方法の概要については、DockerHubのこの紹介を参照してください。

ステップ1—komposeをインストールする

komposeの使用を開始するには、プロジェクトのGitHubリリースページに移動し、現在のリリース（この記事の執筆時点ではバージョン 1.18.0 ）へのリンクをコピーします。このリンクを次の場所に貼り付けます curl 最新バージョンのkomposeをダウンロードするコマンド：

curl -L https://github.com/kubernetes/kompose/releases/download/v1.18.0/kompose-linux-amd64 -o kompose

Linux以外のシステムへのインストールの詳細については、インストール手順を参照してください。

バイナリを実行可能にします。

chmod +x kompose

あなたにそれを移動します PATH:

sudo mv ./kompose /usr/local/bin/kompose

正しくインストールされていることを確認するには、バージョンチェックを実行します。

kompose version

インストールが成功すると、次のような出力が表示されます。

Output
1.18.0 (06a2e56)

と kompose インストールして使用する準備ができたら、Kubernetesに変換するNode.jsプロジェクトコードのクローンを作成できます。

ステップ2—アプリケーションのクローン作成とパッケージ化

アプリケーションをKubernetesで使用するには、プロジェクトコードのクローンを作成し、アプリケーションをパッケージ化して、 kubelet サービスはイメージをプルできます。

最初のステップは、 DigitalOceanCommunityGitHubアカウントからnode-mongo-docker-devリポジトリのクローンを作成することです。このリポジトリには、DockerComposeを使用した開発用のNode.jsアプリケーションのコンテナ化で説明されているセットアップのコードが含まれています。このコードはデモのNode.jsアプリケーションを使用してDockerComposeを使用して開発環境をセットアップする方法を示します。アプリケーション自体の詳細については、Node.jsを使用したコンテナーからKubernetesへのシリーズを参照してください。

リポジトリをと呼ばれるディレクトリに複製します node_project:

git clone https://github.com/do-community/node-mongo-docker-dev.git node_project

に移動します node_project ディレクトリ：

cd node_project

The node_project ディレクトリには、ユーザー入力で動作するサメ情報アプリケーションのファイルとディレクトリが含まれています。コンテナーで動作するように最新化されました。機密性の高い特定の構成情報がアプリケーションコードから削除され、実行時に注入されるようにリファクタリングされ、アプリケーションの状態がMongoDBデータベースにオフロードされました。

最新のステートレスアプリケーションの設計の詳細については、Kubernetes用アプリケーションのアーキテクチャおよびKubernetes用アプリケーションの最新化を参照してください。

プロジェクトディレクトリには、 Dockerfile アプリケーションイメージを構築するための手順が記載されています。今すぐイメージをビルドして、Docker Hubアカウントにプッシュし、Kubernetesセットアップで使用できるようにします。

docker build コマンドを使用して、 -t フラグ。覚えやすい名前でタグ付けできます。この場合、イメージにDocker Hubユーザー名のタグを付け、名前を付けます node-kubernetes またはあなた自身が選んだ名前：

docker build -t your_dockerhub_username/node-kubernetes .

The . コマンドで、ビルドコンテキストが現在のディレクトリであることを指定します。

イメージの作成には1〜2分かかります。完了したら、画像を確認します。

docker images

次の出力が表示されます。

OutputREPOSITORY                                TAG                 IMAGE ID            CREATED             SIZE
your_dockerhub_username/node-kubernetes   latest              9c6f897e1fbc        3 seconds ago       90MB
node                                      10-alpine           94f3c8956482        12 days ago         71MB

次に、前提条件で作成したDockerHubアカウントにログインします。

docker login -u your_dockerhub_username

プロンプトが表示されたら、DockerHubアカウントのパスワードを入力します。この方法でログインすると、 ~/.docker/config.json DockerHubのクレデンシャルを使用してユーザーのホームディレクトリにファイルします。

dockerpushコマンドを使用してアプリケーションイメージをDockerHubにプッシュします。交換することを忘れないでください your_dockerhub_username 独自のDockerHubユーザー名を使用：

docker push your_dockerhub_username/node-kubernetes

これで、Kubernetesでアプリケーションを実行するためにプルできるアプリケーションイメージができました。次のステップは、アプリケーションサービス定義をKubernetesオブジェクトに変換することです。

ステップ3—komposeを使用してComposeサービスをKubernetesオブジェクトに変換する

DockerComposeファイル。ここでは docker-compose.yaml、Composeでサービスを実行する定義を示します。 Composeのserviceは実行中のコンテナーであり、サービス定義には、各コンテナーイメージの実行方法に関する情報が含まれています。このステップでは、komposeを使用してこれらの定義をKubernetesオブジェクトに変換します。 yaml ファイル。これらのファイルには、目的の状態を記述するKubernetesオブジェクトのspecsが含まれます。

これらのファイルを使用して、さまざまなタイプのオブジェクトを作成します。 Services 。これにより、コンテナを実行しているPodsに引き続きアクセスできるようになります。展開。ポッドの望ましい状態に関する情報が含まれます。 PersistentVolumeClaim を使用して、データベースデータのストレージをプロビジョニングします。実行時に注入される環境変数のConfigMap。アプリケーションのデータベースユーザーとパスワード用のSecret。これらの定義の一部は、komposeが作成するファイルに含まれ、その他の定義は、自分で作成する必要があります。

まず、私たちの定義のいくつかを変更する必要があります docker-compose.yaml Kubernetesで動作するファイル。新しく作成したアプリケーションイメージへの参照を nodejs サービス定義を行い、Composeを使用して開発中のアプリケーションコンテナを実行するために使用したバインドマウント、ボリューム、および追加のコマンドを削除します。さらに、両方のコンテナの再起動ポリシーをKubernetesが期待する動作に一致するように再定義します。

でファイルを開く nano またはお気に入りの編集者：

nano docker-compose.yaml

の現在の定義 nodejs アプリケーションサービスは次のようになります。

〜/ node_project / docker-compose.yaml

...
services:
  nodejs:
    build:
      context: .
      dockerfile: Dockerfile
    image: nodejs
    container_name: nodejs
    restart: unless-stopped
    env_file: .env
    environment:
      - MONGO_USERNAME=$MONGO_USERNAME
      - MONGO_PASSWORD=$MONGO_PASSWORD
      - MONGO_HOSTNAME=db
      - MONGO_PORT=$MONGO_PORT
      - MONGO_DB=$MONGO_DB 
    ports:
      - "80:8080"
    volumes:
      - .:/home/node/app
      - node_modules:/home/node/app/node_modules
    networks:
      - app-network
    command: ./wait-for.sh db:27017 -- /home/node/app/node_modules/.bin/nodemon app.js
...

サービス定義を次のように編集します。

あなたの node-kubernetes ローカルの代わりに画像 Dockerfile.
コンテナを変更します restart からのポリシー unless-stopped に always.
を削除します volumes リストと command 命令。

完成したサービス定義は次のようになります。

〜/ node_project / docker-compose.yaml

...
services:
  nodejs:
    image: your_dockerhub_username/node-kubernetes
    container_name: nodejs
    restart: always
    env_file: .env
    environment:
      - MONGO_USERNAME=$MONGO_USERNAME
      - MONGO_PASSWORD=$MONGO_PASSWORD
      - MONGO_HOSTNAME=db
      - MONGO_PORT=$MONGO_PORT
      - MONGO_DB=$MONGO_DB 
    ports:
      - "80:8080"
    networks:
      - app-network
...

次に、下にスクロールして db サービス定義。ここで、次の編集を行います。

変更 restart サービスのポリシー always.
を削除します .env ファイル。からの値を使用する代わりに .env ファイル、私たちは私たちの値を渡します MONGO_INITDB_ROOT_USERNAME と MONGO_INITDB_ROOT_PASSWORD ステップ4で作成するシークレットを使用してデータベースコンテナに移動します。

The db サービス定義は次のようになります。

〜/ node_project / docker-compose.yaml

...
  db:
    image: mongo:4.1.8-xenial
    container_name: db
    restart: always
    environment:
      - MONGO_INITDB_ROOT_USERNAME=$MONGO_USERNAME
      - MONGO_INITDB_ROOT_PASSWORD=$MONGO_PASSWORD
    volumes:  
      - dbdata:/data/db   
    networks:
      - app-network
...

最後に、ファイルの下部で、 node_modules トップレベルからのボリューム volumes 鍵。キーは次のようになります。

〜/ node_project / docker-compose.yaml

...
volumes:
  dbdata:

編集が終了したら、ファイルを保存して閉じます。

サービス定義を翻訳する前に、 .env komposeが機密情報を使用してConfigMapを作成するために使用するファイル。このファイルの詳細については、DockerComposeを使用した開発用のNode.jsアプリケーションのコンテナ化のステップ2を参照してください。

そのチュートリアルでは、 .env 私たちに .gitignore バージョン管理にコピーされないようにするためのファイル。これは、このチュートリアルのステップ2でnode-mongo-docker-devリポジトリのクローンを作成したときにコピーされなかったことを意味します。したがって、今すぐ再作成する必要があります。

ファイルを作成します。

nano .env

komposeはこのファイルを使用して、アプリケーションのConfigMapを作成します。ただし、からすべての変数を割り当てる代わりに nodejs 作成ファイルのサービス定義では、 MONGO_DB データベース名と MONGO_PORT. ステップ4でシークレットオブジェクトを手動で作成するときに、データベースのユーザー名とパスワードを別々に割り当てます。

次のポートとデータベース名の情報をに追加します .env ファイル。必要に応じて、データベースの名前を自由に変更してください。

〜/ node_project / .env

MONGO_PORT=27017
MONGO_DB=sharkinfo

編集が終了したら、ファイルを保存して閉じます。

これで、オブジェクトの仕様を使用してファイルを作成する準備が整いました。 komposeは、リソースを翻訳するための複数のオプションを提供しています。あなたはできる：

作成 yaml のサービス定義に基づくファイル docker-compose.yaml とファイル kompose convert.
を使用してKubernetesオブジェクトを直接作成する kompose up.
ヘルムチャートを作成する kompose convert -c.

今のところ、サービス定義を次のように変換します yaml ファイルを追加してから、komposeが作成するファイルを追加および修正します。

サービス定義をに変換します yaml 次のコマンドでファイルを作成します。

kompose convert

を使用して、特定または複数の作成ファイルに名前を付けることもできます。 -f 国旗。

このコマンドを実行すると、komposeは作成したファイルに関する情報を出力します。

OutputINFO Kubernetes file "nodejs-service.yaml" created 
INFO Kubernetes file "db-deployment.yaml" created 
INFO Kubernetes file "dbdata-persistentvolumeclaim.yaml" created 
INFO Kubernetes file "nodejs-deployment.yaml" created 
INFO Kubernetes file "nodejs-env-configmap.yaml" created

これらには以下が含まれます yaml NodeアプリケーションService、Deployment、ConfigMap、および dbdata PersistentVolumeClaimおよびMongoDBデータベースのデプロイ。

これらのファイルは良い出発点ですが、アプリケーションの機能を Docker Composeを使用した開発用のNode.jsアプリケーションのコンテナー化で説明されているセットアップと一致させるには、いくつかの追加と変更を行う必要があります。 komposeが生成したファイル。

ステップ4—Kubernetesシークレットを作成する

アプリケーションが期待どおりに機能するためには、komposeが作成したファイルにいくつかの変更を加える必要があります。これらの変更の最初は、データベースユーザーとパスワードのシークレットを生成し、それをアプリケーションとデータベースの展開に追加することです。 Kubernetesは、環境変数を操作する2つの方法を提供します。ConfigMapsとSecretsです。 komposeは、私たちが含めた非機密情報を使用してConfigMapをすでに作成しています .env ファイルなので、データベースのユーザー名とパスワードという機密情報を使用してシークレットを作成します。

シークレットを手動で作成する最初のステップは、ユーザー名とパスワードを base64 に変換することです。これは、バイナリデータを含むデータを均一に送信できるエンコードスキームです。

データベースのユーザー名を変換します。

echo -n 'your_database_username' | base64

出力に表示される値を書き留めます。

次に、パスワードを変換します。

echo -n 'your_database_password' | base64

ここでも出力の値に注意してください。

シークレットのファイルを開きます。

nano secret.yaml

注：Kubernetesオブジェクトは通常でYAML を使用して定義されます。これはタブを厳密に禁止し、インデントに2つのスペースを必要とします。いずれかのフォーマットを確認したい場合 yaml ファイルの場合は、 linter を使用するか、次を使用して構文の有効性をテストできます。 kubectl create とともに --dry-run と --validate フラグ：

kubectl create -f your_yaml_file.yaml --dry-run --validate=true

一般に、リソースを作成する前に構文を検証することをお勧めします。 kubectl.

次のコードをファイルに追加して、 MONGO_USERNAME と MONGO_PASSWORD 作成したエンコードされた値を使用します。ここのダミー値は、必ずエンコードされたユーザー名とパスワードに置き換えてください。

〜/ node_project / secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mongo-secret
data:
  MONGO_USERNAME: your_encoded_username
  MONGO_PASSWORD: your_encoded_password

シークレットオブジェクトに名前を付けました mongo-secret、ただし、好きな名前を付けることができます。

編集が終了したら、このファイルを保存して閉じます。あなたがしたように .env ファイル、必ず追加してください secret.yaml あなたに .gitignore バージョン管理の対象外にするためのファイル。

と secret.yaml 次のステップは、アプリケーションとデータベースポッドの両方がファイルに追加した値を使用することを確認することです。シークレットへの参照をアプリケーションのデプロイに追加することから始めましょう。

というファイルを開きます nodejs-deployment.yaml:

nano nodejs-deployment.yaml

ファイルのコンテナ仕様には、以下で定義されている次の環境変数が含まれています。 env 鍵：

〜/ node_project / nodejs-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
...
    spec:
      containers:
      - env:
        - name: MONGO_DB
          valueFrom:
            configMapKeyRef:
              key: MONGO_DB
              name: nodejs-env
        - name: MONGO_HOSTNAME
          value: db
        - name: MONGO_PASSWORD
        - name: MONGO_PORT
          valueFrom:
            configMapKeyRef:
              key: MONGO_PORT
              name: nodejs-env
        - name: MONGO_USERNAME

シークレットへの参照を追加する必要があります MONGO_USERNAME と MONGO_PASSWORD ここにリストされている変数。これにより、アプリケーションはこれらの値にアクセスできるようになります。含める代わりに configMapKeyRef 私たちを指すための鍵 nodejs-env ConfigMap、の値の場合と同様 MONGO_DB と MONGO_PORT、を含めます secretKeyRef 私たちの値を指すための鍵 mongo-secret 秘密。

次の秘密の参照をに追加します MONGO_USERNAME と MONGO_PASSWORD 変数：

〜/ node_project / nodejs-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
...
    spec:
      containers:
      - env:
        - name: MONGO_DB
          valueFrom:
            configMapKeyRef:
              key: MONGO_DB
              name: nodejs-env
        - name: MONGO_HOSTNAME
          value: db
        - name: MONGO_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: MONGO_PASSWORD
        - name: MONGO_PORT
          valueFrom:
            configMapKeyRef:
              key: MONGO_PORT
              name: nodejs-env
        - name: MONGO_USERNAME
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: MONGO_USERNAME

編集が終了したら、ファイルを保存して閉じます。

次に、同じ値をに追加します db-deployment.yaml ファイル。

編集用にファイルを開きます。

nano db-deployment.yaml

このファイルでは、次の可変キーのシークレットへの参照を追加します。 MONGO_INITDB_ROOT_USERNAME と MONGO_INITDB_ROOT_PASSWORD. The mongo imageはこれらの変数を使用可能にして、データベースインスタンスの初期化を変更できるようにします。 MONGO_INITDB_ROOT_USERNAME と MONGO_INITDB_ROOT_PASSWORD 一緒に作成します root のユーザー admin データベースを認証し、データベースコンテナの起動時に認証が有効になっていることを確認します。

シークレットに設定した値を使用すると、データベースインスタンスでルート権限を持つアプリケーションユーザーが、その役割のすべての管理権限と運用権限にアクセスできるようになります。本番環境で作業する場合は、適切なスコープの特権を持つ専用のアプリケーションユーザーを作成する必要があります。

下 MONGO_INITDB_ROOT_USERNAME と MONGO_INITDB_ROOT_PASSWORD 変数、シークレット値への参照を追加します。

〜/ node_project / db-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
...
    spec:
      containers:
      - env:
        - name: MONGO_INITDB_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: MONGO_PASSWORD        
        - name: MONGO_INITDB_ROOT_USERNAME
          valueFrom:
            secretKeyRef:
              name: mongo-secret
              key: MONGO_USERNAME
        image: mongo:4.1.8-xenial
...

編集が終了したら、ファイルを保存して閉じます。

シークレットを設定したら、データベースサービスの作成に進み、アプリケーションコンテナが完全にセットアップされて初期化された後でのみ、データベースへの接続を試行するようにすることができます。

ステップ5—データベースサービスとアプリケーション初期化コンテナの作成

シークレットができたので、データベースサービスと Init Container の作成に進むことができます。このサービスは、このサービスをポーリングして、データベースの起動タスクが含まれる場合にのみ、アプリケーションがデータベースへの接続を試行するようにします。の作成 MONGO_INITDB ユーザーとパスワードが完成しました。

Composeでこの機能を実装する方法については、DockerComposeを使用した開発用のNode.jsアプリケーションのContainerizingのステップ4を参照してください。

ファイルを開いて、データベースサービスの仕様を定義します。

nano db-service.yaml

次のコードをファイルに追加して、サービスを定義します。

〜/ node_project / db-service.yaml

apiVersion: v1
kind: Service
metadata:
  annotations: 
    kompose.cmd: kompose convert
    kompose.version: 1.18.0 (06a2e56)
  creationTimestamp: null
  labels:
    io.kompose.service: db
  name: db
spec:
  ports:
  - port: 27017
    targetPort: 27017
  selector:
    io.kompose.service: db
status:
  loadBalancer: {}

The selector ここに含めたものは、このサービスオブジェクトを、ラベルで定義されたデータベースポッドと照合します io.kompose.service: db でkomposeによって db-deployment.yaml ファイル。このサービスにも名前を付けました db.

編集が終了したら、ファイルを保存して閉じます。

次に、InitContainerフィールドをに追加しましょう。 containers の配列 nodejs-deployment.yaml. これにより、アプリケーションコンテナの開始を遅らせるために使用できるInitコンテナが作成されます。 db サービスは、到達可能なポッドを使用して作成されています。これは、Initコンテナの可能な用途の1つです。他の使用例の詳細については、公式ドキュメントを参照してください。

を開きます nodejs-deployment.yaml ファイル：

nano nodejs-deployment.yaml

ポッド仕様内および containers 配列、追加します initContainers ポーリングするコンテナを持つフィールド db サービス。

以下のコードを追加します ports と resources フィールド以上 restartPolicy の中に nodejs containers 配列：

〜/ node_project / nodejs-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
...
    spec:
      containers:
      ...
        name: nodejs
        ports:
        - containerPort: 8080
        resources: {}
      initContainers:
      - name: init-db
        image: busybox
        command: ['sh', '-c', 'until nc -z db:27017; do echo waiting for db; sleep 2; done;']
      restartPolicy: Always
...

このInitコンテナは、 BusyBoxイメージを使用します。これは、多くのUNIXユーティリティを含む軽量のイメージです。この場合、 netcat ユーティリティを使用して、ポッドがに関連付けられているかどうかをポーリングします。 db サービスはポートでTCP接続を受け入れています 27017.

このコンテナ command 削除したwait-forスクリプトの機能を複製します docker-compose.yaml ステップ3のファイル。私たちのアプリケーションがどのようにそしてなぜ使用したかについてのより長い議論のために wait-for Composeを使用する場合のスクリプトについては、DockerComposeを使用した開発用のNode.jsアプリケーションのContainerizingのステップ4を参照してください。

InitContainersは完了するまで実行されます。この場合、これは、データベースコンテナが実行され、ポートで接続を受け入れるまで、Nodeアプリケーションコンテナが起動しないことを意味します。 27017. The db サービス定義により、変更可能なデータベースコンテナの正確な場所に関係なく、この機能を保証できます。

編集が終了したら、ファイルを保存して閉じます。

データベースサービスを作成し、Init Containerを配置してコンテナーの起動順序を制御したら、PersistentVolumeClaimのストレージ要件を確認し、LoadBalancerを使用してアプリケーションサービスを公開できます。

ステップ6—PersistentVolumeClaimを変更してアプリケーションフロントエンドを公開する

アプリケーションを実行する前に、データベースストレージが適切にプロビジョニングされ、LoadBalancerを使用してアプリケーションフロントエンドを公開できるようにするために、2つの最終的な変更を行います。

まず、変更しましょう storage komposeが作成したPersistentVolumeClaimで定義されたresource。このクレームにより、アプリケーションの状態を管理するために動的にストレージをプロビジョニングできます。

PersistentVolumeClaimsを使用するには、 StorageClass を作成し、ストレージリソースをプロビジョニングするように構成する必要があります。この例では、 DigitalOcean Kubernetes を使用しているため、デフォルトのStorageClass provisioner に設定されています dobs.csi.digitalocean.com —DigitalOceanブロックストレージ。

これを確認するには、次のように入力します。

kubectl get storageclass

DigitalOceanクラスターを使用している場合は、次の出力が表示されます。

OutputNAME                         PROVISIONER                 AGE
do-block-storage (default)   dobs.csi.digitalocean.com   76m

DigitalOceanクラスターを使用していない場合は、StorageClassを作成し、 provisioner お好みの。これを行う方法の詳細については、公式ドキュメントを参照してください。

komposeが作成されたとき dbdata-persistentvolumeclaim.yaml、それは設定します storage resource 私たちの最小サイズ要件を満たしていないサイズに provisioner. したがって、最小実行可能DigitalOceanブロックストレージユニット：1GBを使用するように、PersistentVolumeClaimを変更する必要があります。ストレージ要件に合わせて、これを自由に変更してください。

開ける dbdata-persistentvolumeclaim.yaml:

nano dbdata-persistentvolumeclaim.yaml

交換してください storage の値 1Gi:

〜/ node_project / dbdata-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: dbdata
  name: dbdata
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
status: {}

また、 accessMode: ReadWriteOnce このクレームの結果としてプロビジョニングされたボリュームは、単一のノードによってのみ読み取り/書き込みが行われることを意味します。さまざまなアクセスモードの詳細については、ドキュメントを参照してください。

終了したら、ファイルを保存して閉じます。

次に、開く nodejs-service.yaml:

nano nodejs-service.yaml

DigitalOcean Load Balancer を使用して、このサービスを外部に公開します。 DigitalOceanクラスターを使用していない場合、ロードバランサーについては、クラウドプロバイダーの関連ドキュメントを参照してください。または、公式の Kubernetesドキュメントに従って、 kubeadm を使用した高可用性クラスターのセットアップを行うこともできますが、この場合、PersistentVolumeClaimsを使用してストレージをプロビジョニングすることはできません。

サービス仕様内で、 LoadBalancer サービスとして type:

〜/ node_project / nodejs-service.yaml

apiVersion: v1
kind: Service
...
spec:
  type: LoadBalancer
  ports:
...

作成するとき nodejs サービス、ロードバランサーが自動的に作成され、アプリケーションにアクセスできる外部IPが提供されます。

編集が終了したら、ファイルを保存して閉じます。

すべてのファイルが揃ったら、アプリケーションを起動してテストする準備が整いました。

ステップ7—アプリケーションの起動とアクセス

Kubernetesオブジェクトを作成し、アプリケーションが期待どおりに機能していることをテストします。

定義したオブジェクトを作成するには、 kubectlcreateを使用します。 -f フラグ。これにより、komposeが作成したファイルと、作成したファイルを指定できます。次のコマンドを実行して、ノードアプリケーションとMongoDBデータベースのサービスとデプロイメントを、Secret、ConfigMap、およびPersistentVolumeClaimとともに作成します。

kubectl create -f nodejs-service.yaml,nodejs-deployment.yaml,nodejs-env-configmap.yaml,db-service.yaml,db-deployment.yaml,dbdata-persistentvolumeclaim.yaml,secret.yaml

オブジェクトが作成されたことを示す次の出力が表示されます。

Outputservice/nodejs created
deployment.extensions/nodejs created
configmap/nodejs-env created
service/db created
deployment.extensions/db created
persistentvolumeclaim/dbdata created
secret/mongo-secret created

ポッドが実行されていることを確認するには、次のように入力します。

kubectl get pods

ここで名前空間を指定する必要はありません。これは、でオブジェクトを作成したためです。 default 名前空間。複数の名前空間を使用している場合は、必ず -n このコマンドを実行するときに、名前空間の名前とともにフラグを立てます。

次の出力が表示されます。 db コンテナが起動し、アプリケーションのInitContainerが実行されています。

OutputNAME                      READY   STATUS              RESTARTS   AGE
db-679d658576-kfpsl       0/1     ContainerCreating   0          10s
nodejs-6b9585dc8b-pnsws   0/1     Init:0/1            0          10s

そのコンテナが実行され、アプリケーションとデータベースコンテナが開始されると、次の出力が表示されます。

OutputNAME                      READY   STATUS    RESTARTS   AGE
db-679d658576-kfpsl       1/1     Running   0          54s
nodejs-6b9585dc8b-pnsws   1/1     Running   0          54s

The Running STATUS ポッドがノードにバインドされており、それらのポッドに関連付けられているコンテナが実行されていることを示します。 READY ポッド内で実行されているコンテナの数を示します。詳細については、ポッドライフサイクルに関するドキュメントを参照してください。

注：予期しないフェーズが表示された場合 STATUS 列では、次のコマンドを使用してポッドのトラブルシューティングを行うことができることを忘れないでください。

kubectl describe pods your_pod
kubectl logs your_pod

コンテナが実行されていると、アプリケーションにアクセスできるようになります。 LoadBalancerのIPを取得するには、次のように入力します。

kubectl get svc

次の出力が表示されます。

OutputNAME         TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)        AGE
db           ClusterIP      10.245.189.250   <none>           27017/TCP      93s
kubernetes   ClusterIP      10.245.0.1       <none>           443/TCP        25m12s
nodejs       LoadBalancer   10.245.15.56     your_lb_ip       80:30729/TCP   93s

The EXTERNAL_IP に関連付けられている nodejs serviceは、アプリケーションにアクセスできるIPアドレスです。あなたが見たら <pending> のステータス EXTERNAL_IP 列の場合、これはロードバランサーがまだ作成中であることを意味します。

その列にIPが表示されたら、ブラウザでそのIPに移動します。 http://your_lb_ip.

次のランディングページが表示されます。

Get SharkInfoボタンをクリックします。サメの名前とそのサメの一般的な性格の説明を入力できる入力フォームのあるページが表示されます。

フォームに、選択したサメを追加します。実証するために、 Megalodon Shark Shark Name フィールドに移動し、 Ancient Shark Character フィールドへ：

送信ボタンをクリックします。このサメの情報が表示されたページが表示されます。

これで、Kubernetesクラスターで実行されているMongoDBデータベースを使用したNode.jsアプリケーションのシングルインスタンスセットアップができました。

結論

このチュートリアルで作成したファイルは、本番環境に移行する際の出発点として適しています。アプリケーションを開発するときに、次の実装に取り組むことができます。

一元化されたロギングとモニタリング。一般的な概要については、Kubernetes用アプリケーションの最新化の関連するディスカッションを参照してください。 KubernetesでElasticsearch、Fluentd、Kibana（EFK）のログスタックを設定する方法を参照して、 Elasticsearch 、Fluentdでログスタックを設定する方法を学ぶこともできます。、およびKibana。 Istio のようなサービスメッシュがこの機能を実装する方法については、サービスメッシュの概要も確認してください。
トラフィックをクラスターにルーティングするための入力リソース。これは、それぞれが独自のLoadBalancerを必要とする複数のサービスを実行している場合、またはアプリケーションレベルのルーティング戦略（A / Bおよびカナリアテストなど）を実装する場合に、LoadBalancerの優れた代替手段です。詳細については、 DigitalOcean KubernetesでCert-Managerを使用してNginxIngressを設定する方法と、はじめにのサービスメッシュコンテキストでのルーティングに関する関連のディスカッションをご覧ください。サービスメッシュ。
Kubernetesオブジェクトのバックアップ戦略。 DigitalOceanのKubernetes製品でVelero（以前のHeptio Ark）を使用してバックアップを実装するためのガイダンスについては、 HeptioArkを使用してDigitalOceanでKubernetesクラスターをバックアップおよび復元する方法を参照してください。

getdocs

13036