前書き
最新のステートレスアプリケーションを構築する場合、containerizing your application’s componentsは分散プラットフォームでの展開とスケーリングの最初のステップです。 開発でDocker Composeを使用した場合は、次の方法でアプリケーションを最新化およびコンテナ化できます。
-
コードから必要な構成情報を抽出します。
-
アプリケーションの状態をオフロードします。
-
繰り返し使用するためにアプリケーションをパッケージ化します。
また、コンテナイメージの実行方法を指定するサービス定義を作成します。
Kubernetesなどの分散プラットフォームでサービスを実行するには、Composeサービス定義をKubernetesオブジェクトに変換する必要があります。 これにより、scale your application with resiliencyが可能になります。 Kubernetesへの変換プロセスを高速化できるツールの1つは、komposeです。これは、開発者がComposeワークフローをKubernetesやOpenShiftなどのコンテナーオーケストレーターに移動するのに役立つ変換ツールです。
このチュートリアルでは、komposeを使用してComposeサービスをKubernetesobjectsに変換します。 komposeが提供するオブジェクト定義を開始点として使用し、Kubernetesが期待する方法でセットアップがSecrets、Services、およびPersistentVolumeClaimsを使用するように調整します。 チュートリアルが終了すると、Kubernetesクラスターで実行されているMongoDBデータベースを備えた単一インスタンスのNode.jsアプリケーションが作成されます。 このセットアップは、Containerizing a Node.js Application with Docker Composeで説明されているコードの機能を反映し、ニーズに合わせて拡張できる本番環境に対応したソリューションを構築するための良い出発点になります。
前提条件
-
役割ベースのアクセス制御(RBAC)が有効になっているKubernetes 1.10+クラスター。 この設定ではDigitalOcean Kubernetes clusterを使用しますが、create a cluster using another methodは自由に使用できます。
-
ローカルマシンまたは開発サーバーにインストールされ、クラスターに接続するように構成された
kubectl
コマンドラインツール。 official documentationにkubectl
をインストールする方法の詳細を読むことができます。 -
Dockerがローカルマシンまたは開発サーバーにインストールされています。 Ubuntu 18.04を使用している場合は、How To Install and Use Docker on Ubuntu 18.04の手順1と2に従います。それ以外の場合は、他のオペレーティングシステムへのインストールについて、official documentationに従ってください。 リンクされたチュートリアルのステップ2で説明されているように、root以外のユーザーを必ず
docker
グループに追加してください。 -
Docker Hubアカウント。 これを設定する方法の概要については、Docker Hubへのthis introductionを参照してください。
[[step-1 -—- installing-kompose]] ==ステップ1—komposeのインストール
komposeの使用を開始するには、project’s GitHub Releases pageに移動し、現在のリリース(この記事の執筆時点ではバージョン1.18.0)へのリンクをコピーします。 このリンクを次のcurl
コマンドに貼り付けて、最新バージョンのkomposeをダウンロードします。
curl -L https://github.com/kubernetes/kompose/releases/download/v1.18.0/kompose-linux-amd64 -o kompose
Linux以外のシステムへのインストールの詳細については、installation instructionsを参照してください。
バイナリを実行可能にします:
chmod +x kompose
PATH
に移動します。
sudo mv ./kompose /usr/local/bin/kompose
正しくインストールされたことを確認するには、バージョンチェックを実行できます。
kompose version
インストールが成功した場合、次のような出力が表示されます。
Output1.18.0 (06a2e56)
kompose
がインストールされ、使用できる状態になったら、Kubernetesに変換するNode.jsプロジェクトコードのクローンを作成できます。
[[step-2 -—-アプリケーションのクローン作成とパッケージ化]] ==ステップ2—アプリケーションのクローン作成とパッケージ化
アプリケーションをKubernetesで使用するには、プロジェクトコードのクローンを作成し、アプリケーションをパッケージ化して、kubelet
サービスがイメージをプルできるようにする必要があります。
最初のステップは、DigitalOcean Community GitHub accountからnode-mongo-docker-dev repositoryを複製することです。 このリポジトリには、Containerizing a Node.js Application for Development With Docker Composeで説明されているセットアップのコードが含まれています。このコードは、デモNode.jsアプリケーションを使用して、DockerComposeを使用して開発環境をセットアップする方法を示しています。 アプリケーション自体の詳細については、シリーズFrom Containers to Kubernetes with Node.jsを参照してください。
リポジトリをnode_project
というディレクトリに複製します。
git clone https://github.com/do-community/node-mongo-docker-dev.git node_project
node_project
ディレクトリに移動します。
cd node_project
node_project
ディレクトリには、ユーザー入力で動作するサメ情報アプリケーションのファイルとディレクトリが含まれています。 コンテナを操作するために近代化されました。機密性の高い特定の構成情報がアプリケーションコードから削除され、実行時にリファクタリングされ、アプリケーションの状態がMongoDBデータベースにオフロードされました。
最新のステートレスアプリケーションの設計の詳細については、Architecting Applications for KubernetesおよびModernizing Applications for Kubernetesを参照してください。
プロジェクトディレクトリには、アプリケーションイメージを構築するための手順を含むDockerfile
が含まれています。 ここでイメージを作成して、Docker HubアカウントにプッシュしてKubernetesセットアップで使用できるようにします。
docker build
コマンドを使用して、-t
フラグを使用してイメージを作成します。これにより、覚えやすい名前でイメージにタグを付けることができます。 この場合、イメージにDocker Hubユーザー名のタグを付け、node-kubernetes
または独自に選択した名前を付けます。
docker build -t your_dockerhub_username/node-kubernetes .
コマンドの.
は、ビルドコンテキストが現在のディレクトリであることを指定します。
イメージの構築には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
次に、前提条件で作成したDocker Hubアカウントにログインします。
docker login -u your_dockerhub_username
プロンプトが表示されたら、Docker Hubアカウントのパスワードを入力します。 この方法でログインすると、Docker Hubの認証情報を使用してユーザーのホームディレクトリに~/.docker/config.json
ファイルが作成されます。
docker push
commandを使用してアプリケーションイメージをDockerHubにプッシュします。 your_dockerhub_username
を独自のDockerHubユーザー名に置き換えることを忘れないでください。
docker push your_dockerhub_username/node-kubernetes
これで、Kubernetesでアプリケーションを実行するためにプルできるアプリケーションイメージが作成されました。 次のステップは、アプリケーションサービス定義をKubernetesオブジェクトに変換することです。
[[step-3 -—- translating-compose-services-to-kubernetes-objects-with-kompose]] ==ステップ3—composeを使用してComposeサービスをKubernetesオブジェクトに変換する
ここではdocker-compose.yaml
と呼ばれるDocker Composeファイルは、Composeでサービスを実行する定義をレイアウトします。 Composeのserviceは実行中のコンテナーであり、service definitionsには各コンテナーイメージの実行方法に関する情報が含まれています。 このステップでは、komposeを使用してyaml
ファイルを作成することにより、これらの定義をKubernetesオブジェクトに変換します。 これらのファイルには、desired stateを記述するKubernetesオブジェクトのspecsが含まれます。
これらのファイルを使用して、さまざまなタイプのオブジェクトを作成します。Services。これにより、コンテナーを実行しているPodsが引き続きアクセス可能になります。 Deployments。ポッドの望ましい状態に関する情報が含まれます。データベースデータ用のストレージをプロビジョニングするためのPersistentVolumeClaim。実行時に注入される環境変数のConfigMap。アプリケーションのデータベースユーザーとパスワードのSecret。 これらの定義の一部は、komposeが作成するファイルに含まれますが、他の定義は自分で作成する必要があります。
まず、Kubernetesで機能するように、docker-compose.yaml
ファイルの定義の一部を変更する必要があります。 新しく作成したアプリケーションイメージへの参照をnodejs
サービス定義に含め、アプリケーションの実行に使用したbind mounts、volumes、および追加のcommandsを削除します。 Composeで開発中のコンテナ。 さらに、両方のコンテナの再起動ポリシーをthe behavior Kubernetes expectsに一致するように再定義します。
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
...
サービス定義を次のように編集します。
-
ローカルの
Dockerfile
の代わりにnode-kubernetes
イメージを使用します。 -
コンテナの
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
ファイルの値を使用する代わりに、Step 4で作成するシークレットを使用して、MONGO_INITDB_ROOT_USERNAME
とMONGO_INITDB_ROOT_PASSWORD
の値をデータベースコンテナーに渡します。
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
...
最後に、ファイルの下部で、最上位のvolumes
キーからnode_modules
ボリュームを削除します。 キーは次のようになります。
~/node_project/docker-compose.yaml
...
volumes:
dbdata:
編集が終了したら、ファイルを保存して閉じます。
サービス定義を変換する前に、komposeが機密情報を使用してConfigMapを作成するために使用する.env
ファイルを作成する必要があります。 このファイルの詳細については、Containerizing a Node.js Application for Development With Docker ComposeのStep 2を参照してください。
そのチュートリアルでは、.gitignore
ファイルに.env
を追加して、バージョン管理にコピーされないようにしました。 これは、node-mongo-docker-dev repositoryをStep 2 of this tutorialに複製したときに、コピーオーバーしなかったことを意味します。 したがって、今すぐ再作成する必要があります。
ファイルを作成します。
nano .env
komposeはこのファイルを使用して、アプリケーションのConfigMapを作成します。 ただし、作成ファイルのnodejs
サービス定義からすべての変数を割り当てる代わりに、MONGO_DB
データベース名とMONGO_PORT
のみを追加します。 Step 4にSecretオブジェクトを手動で作成するときに、データベースのユーザー名とパスワードを個別に割り当てます。
次のポートとデータベース名の情報を.env
ファイルに追加します。 必要に応じて、データベースの名前を自由に変更してください。
~/node_project/.env
MONGO_PORT=27017
MONGO_DB=sharkinfo
編集が終了したら、ファイルを保存して閉じます。
これで、オブジェクト仕様でファイルを作成する準備ができました。 komposeは、リソースを翻訳するためのmultiple optionsを提供します。 あなたはできる:
-
kompose convert
を使用してdocker-compose.yaml
ファイルのサービス定義に基づいてyaml
ファイルを作成します。 -
kompose up
を使用してKubernetesオブジェクトを直接作成します。 -
kompose convert -c
を使用してHelmチャートを作成します。
今のところ、サービス定義を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
これには、ノードアプリケーションのService、Deployment、ConfigMap、およびdbdata
のPersistentVolumeClaimとMongoDBデータベースのDeploymentの仕様を含むyaml
ファイルが含まれます。
これらのファイルは良い出発点ですが、アプリケーションの機能をContainerizing a Node.js Application for Development With Docker Composeで説明されている設定と一致させるには、komposeが生成したファイルにいくつかの追加と変更を加える必要があります。
[[step-4 -—- creating-kubernetes-secrets]] ==ステップ4—Kubernetesシークレットの作成
アプリケーションが期待どおりに機能するためには、komposeが作成したファイルにいくつかの変更を加える必要があります。 これらの変更の最初は、データベースユーザーとパスワードのシークレットを生成し、それをアプリケーションとデータベースのデプロイメントに追加することです。 Kubernetesは、環境変数を操作する2つの方法、ConfigMapsとSecretsを提供します。 komposeは、.env
ファイルに含めた非機密情報を使用してConfigMapを既に作成しているため、データベースのユーザー名とパスワードという機密情報を使用してシークレットを作成します。
シークレットを手動で作成する最初のステップは、ユーザー名とパスワードをbase64に変換することです。これは、バイナリデータを含むデータを均一に送信できるようにするエンコードスキームです。
データベースのユーザー名を変換します。
echo -n 'your_database_username' | base64
出力に表示される値を書き留めます。
次に、パスワードを変換します。
echo -n 'your_database_password' | base64
ここの出力の値にも注意してください。
シークレットのファイルを開きます。
nano secret.yaml
[。注意]##
Note: KubernetesオブジェクトはYAMLを使用するtypically definedであり、タブを厳密に禁止し、インデントのために2つのスペースを必要とします。 yaml
ファイルのフォーマットを確認したい場合は、linterを使用するか、kubectl create
と--dry-run
および%を使用して構文の有効性をテストできます。 (t7)sフラグ:
kubectl create -f your_yaml_file.yaml --dry-run --validate=true
一般に、kubectl
。
でリソースを作成する前に、構文を検証することをお勧めします。
次のコードをファイルに追加して、作成したばかりのエンコードされた値を使用してMONGO_USERNAME
とMONGO_PASSWORD
を定義するシークレットを作成します。 ここのダミー値は、必ずencodedのユーザー名とパスワードに置き換えてください。
~/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
変数へのシークレットへの参照を追加して、アプリケーションがこれらの値にアクセスできるようにする必要があります。 MONGO_DB
およびMONGO_PORT
の値の場合のように、nodejs-env
ConfigMapを指すconfigMapKeyRef
キーを含める代わりに、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
。 mongo
イメージは、これらの変数を使用可能にして、データベースインスタンスの初期化を変更できるようにします。 MONGO_INITDB_ROOT_USERNAME
とMONGO_INITDB_ROOT_PASSWORD
が一緒になって、admin
認証データベースにroot
ユーザーを作成し、データベースコンテナの起動時に認証が有効になっていることを確認します。
シークレットに設定した値を使用すると、データベースインスタンスにroot
privilegesを持つアプリケーションユーザーが存在し、その役割のすべての管理特権と操作特権にアクセスできるようになります。 本番環境で作業する場合は、適切なスコープの特権を持つ専用のアプリケーションユーザーを作成する必要があります。
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
...
編集が終了したら、ファイルを保存して閉じます。
シークレットを設定したら、データベースサービスの作成に進み、アプリケーションコンテナが完全にセットアップされて初期化された後にのみデータベースへの接続を試行するようにします。
[[step-5 --- creating-the-database-service-and-an-application-init-container]] ==ステップ5—データベースサービスとアプリケーション初期化コンテナの作成
シークレットができたので、データベースサービスとInit Containerの作成に進み、このサービスをポーリングして、%の作成を含むデータベースの起動タスクが実行されたときにのみアプリケーションがデータベースへの接続を試行するようにします。 (t1)のユーザーとパスワードが完了しました。
Composeでこの機能を実装する方法については、Containerizing a Node.js Application for Development with Docker ComposeのStep 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: {}
ここに含めたselector
は、このサービスオブジェクトをデータベースポッドと照合します。データベースポッドは、db-deployment.yaml
ファイルのkomposeによってラベルio.kompose.service: db
で定義されています。 このサービスにもdb
という名前を付けました。
編集が終了したら、ファイルを保存して閉じます。
次に、nodejs-deployment.yaml
のcontainers
配列にInitContainerフィールドを追加しましょう。 これにより、到達可能なポッドでdb
サービスが作成されるまで、アプリケーションコンテナの開始を遅らせるために使用できるInitコンテナが作成されます。 これは、Initコンテナの可能な用途の1つです。他のユースケースの詳細については、official documentationを参照してください。
nodejs-deployment.yaml
ファイルを開きます。
nano nodejs-deployment.yaml
ポッド仕様内で、containers
配列と一緒に、db
サービスをポーリングするコンテナーを含むinitContainers
フィールドを追加します。
次のコードをports
フィールドとresources
フィールドの下、およびnodejs
containers
配列のrestartPolicy
の上に追加します。
~/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コンテナは、多くのUNIXユーティリティを含む軽量イメージであるBusyBox imageを使用します。 この場合、netcat
ユーティリティを使用して、db
サービスに関連付けられたポッドがポート27017
でTCP接続を受け入れているかどうかをポーリングします。
このコンテナcommand
は、Step 3のdocker-compose.yaml
ファイルから削除したwait-for
スクリプトの機能を複製します。 Composeを使用するときにアプリケーションがwait-for
スクリプトを使用する方法と理由の詳細については、Containerizing a Node.js Application for Development with Docker ComposeのStep 4を参照してください。
Initコンテナは完了するまで実行されます。この場合、これは、データベースコンテナが実行され、ポート27017
で接続を受け入れるまで、ノードアプリケーションコンテナが起動しないことを意味します。 db
サービス定義により、可変であるデータベースコンテナーの正確な場所に関係なく、この機能を保証できます。
編集が終了したら、ファイルを保存して閉じます。
データベースサービスが作成され、コンテナーの起動順序を制御するためのInitコンテナーが配置されたら、PersistentVolumeClaimのストレージ要件を確認し、LoadBalancerを使用してアプリケーションサービスを公開できます。
[[step-6 -—- persistentvolumeclaim-and-exposed-the-application-frontend]] ==ステップ6—PersistentVolumeClaimの変更とアプリケーションフロントエンドの公開
アプリケーションを実行する前に、データベースストレージが適切にプロビジョニングされ、LoadBalancerを使用してアプリケーションフロントエンドを公開できるようにするために、2つの最終変更を行います。
まず、komposeが作成したPersistentVolumeClaimで定義されているstorage
resource
を変更しましょう。 このクレームにより、dynamically provisionのストレージでアプリケーションの状態を管理できます。
PersistentVolumeClaimsを使用するには、ストレージリソースをプロビジョニングするようにStorageClassを作成および構成する必要があります。 この場合、DigitalOcean Kubernetesを使用しているため、デフォルトのStorageClassprovisioner
はdobs.csi.digitalocean.com
—DigitalOcean Block Storageに設定されます。
これを確認するには、次のように入力します。
kubectl get storageclass
DigitalOceanクラスターを使用している場合、次の出力が表示されます。
OutputNAME PROVISIONER AGE
do-block-storage (default) dobs.csi.digitalocean.com 76m
DigitalOceanクラスターを使用していない場合は、StorageClassを作成し、選択したprovisioner
を構成する必要があります。 これを行う方法の詳細については、official documentationを参照してください。
komposeがdbdata-persistentvolumeclaim.yaml
を作成すると、storage
resource
がprovisioner
の最小サイズ要件を満たさないサイズに設定されます。 したがって、minimum viable DigitalOcean Block Storage unit: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
は、このクレームの結果としてプロビジョニングされたボリュームが単一ノードによってのみ読み取り/書き込みされることを意味します。 さまざまなアクセスモードの詳細については、documentationを参照してください。
完了したら、ファイルを保存して閉じます。
次に、nodejs-service.yaml
を開きます。
nano nodejs-service.yaml
DigitalOcean Load Balancerを使用して、このサービスを外部に公開します。 DigitalOceanクラスターを使用していない場合、クラウドプロバイダーの関連ドキュメントを参照して、ロードバランサーに関する情報を確認してください。 または、公式のKubernetes documentationに従って、kubeadm
を使用して高可用性クラスターをセットアップすることもできますが、この場合、PersistentVolumeClaimsを使用してストレージをプロビジョニングすることはできません。
サービス仕様内で、LoadBalancer
をサービスtype
として指定します。
~/node_project/nodejs-service.yaml
apiVersion: v1
kind: Service
...
spec:
type: LoadBalancer
ports:
...
nodejs
サービスを作成すると、ロードバランサーが自動的に作成され、アプリケーションにアクセスできる外部IPが提供されます。
編集が終了したら、ファイルを保存して閉じます。
すべてのファイルを配置したら、アプリケーションを開始してテストする準備ができました。
[[step-7 -—-アプリケーションの起動とアクセス]] ==ステップ7—アプリケーションの起動とアクセス
Kubernetesオブジェクトを作成し、アプリケーションが期待どおりに動作することをテストします。
定義したオブジェクトを作成するには、kubectl create
と-f
フラグを使用します。これにより、komposeが作成したファイルと、作成したファイルを指定できます。 次のコマンドを実行して、Secret、ConfigMap、およびPersistentVolumeClaimとともにNodeアプリケーションとMongoDBデータベースサービスおよびデプロイメントを作成します。
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
名前空間でオブジェクトを作成したため、ここでNamespaceを指定する必要はありません。 複数のネームスペースを使用している場合は、このコマンドを実行するときに、ネームスペースの名前とともに-n
フラグを必ず含めてください。
db
コンテナが起動し、アプリケーションのInit Containerが実行されている間、次の出力が表示されます。
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
Running
STATUS
は、ポッドがノードにバインドされており、それらのポッドに関連付けられているコンテナーが実行されていることを示します。 READY
は、ポッド内で実行されているコンテナーの数を示します。 詳細については、documentation on Pod lifecyclesを参照してください。
[。注意]##
Note: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 27017/TCP 93s
kubernetes ClusterIP 10.245.0.1 443/TCP 25m12s
nodejs LoadBalancer 10.245.15.56 your_lb_ip 80:30729/TCP 93s
nodejs
サービスに関連付けられているEXTERNAL_IP
は、アプリケーションにアクセスできるIPアドレスです。 EXTERNAL_IP
列に<pending>
ステータスが表示されている場合、これはロードバランサーがまだ作成中であることを意味します。
その列にIPが表示されたら、ブラウザでそのIPに移動します:http://your_lb_ip
。
次のランディングページが表示されます。
Get Shark Infoボタンをクリックします。 サメの名前とそのサメの一般的なキャラクターの説明を入力できるエントリフォームのページが表示されます。
フォームに、選択したサメを追加します。 実例を示すために、Megalodon Shark
をShark Nameフィールドに追加し、Ancient
をShark Characterフィールドに追加します。
Submitボタンをクリックします。 このサメの情報が表示されたページが表示されます:
これで、Kubernetesクラスターで実行されているMongoDBデータベースを使用したNode.jsアプリケーションの単一インスタンスのセットアップができました。
結論
このチュートリアルで作成したファイルは、本番環境に移行する際のビルドの出発点として適しています。 アプリケーションを開発するときに、次の実装に取り組むことができます。
-
Centralized logging and monitoring。 一般的な概要については、Modernizing Applications for Kubernetesのrelevant discussionを参照してください。 また、How To Set Up an Elasticsearch, Fluentd and Kibana (EFK) Logging Stack on Kubernetesを調べて、Elasticsearch、Fluentd、およびKibanaでログスタックを設定する方法を学ぶこともできます。 また、Istioのようなサービスメッシュがこの機能を実装する方法については、An Introduction to Service Meshesを確認してください。
-
Ingress Resources to route traffic to your cluster。 これは、それぞれ独自のLoadBalancerを必要とする複数のサービスを実行している場合、またはアプリケーションレベルのルーティング戦略(A / Bおよびカナリアテストなど)を実装する場合に、LoadBalancerの代替として適しています。 詳細については、An Introduction to Service MeshesのサービスメッシュコンテキストでのルーティングのHow to Set Up an Nginx Ingress with Cert-Manager on DigitalOcean Kubernetesとrelated discussionを確認してください。
-
Backup strategies for your Kubernetes objects。 DigitalOceanのKubernetes製品でVelero(以前のHeptio Ark)を使用してバックアップを実装するためのガイダンスについては、How To Back Up and Restore a Kubernetes Cluster on DigitalOcean Using Heptio Arkを参照してください。