DockerComposeワークフローをKubernetesに移行する方法
序章
最新のステートレスアプリケーションを構築する場合、アプリケーションのコンポーネントをコンテナ化するは、分散プラットフォームでのデプロイとスケーリングの最初のステップです。 開発で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
インストールが成功すると、次のような出力が表示されます。
Output1.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
アプリケーションサービスは次のようになります。
...
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
命令。
完成したサービス定義は次のようになります。
...
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
サービス定義は次のようになります。
...
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
鍵。 キーは次のようになります。
...
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
ファイル。 必要に応じて、データベースの名前を自由に変更してください。
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
作成したエンコードされた値を使用します。 ここのダミー値は、必ずエンコードされたユーザー名とパスワードに置き換えてください。
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
鍵:
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
変数:
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
変数、シークレット値への参照を追加します。
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
次のコードをファイルに追加して、サービスを定義します。
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
配列:
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
:
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
:
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クラスターをバックアップおよび復元する方法を参照してください。