Helmを使用してKubernetesでMongoDBを使用してNode.jsアプリケーションをスケーリングする方法

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

序章

Kubernetes は、最新のコンテナ化されたアプリケーションを大規模に実行するためのシステムです。これにより、開発者はマシンのクラスター全体にアプリケーションを展開および管理できます。また、単一インスタンスのアプリケーションセットアップで効率と信頼性を向上させるために使用できますが、Kubernetesは、マシンのグループ間でアプリケーションの複数のインスタンスを実行するように設計されています。

Kubernetesを使用してマルチサービスデプロイメントを作成する場合、多くの開発者はHelmパッケージマネージャーを使用することを選択します。 Helmは、これらのオブジェクトの相互作用を調整するチャートとテンプレートを提供することにより、複数のKubernetesリソースを作成するプロセスを合理化します。また、人気のあるオープンソースプロジェクト用にパッケージ化されたチャートも提供しています。

このチュートリアルでは、Helmチャートを使用して、MongoDBデータベースを備えたNode.jsアプリケーションをKubernetesクラスターにデプロイします。公式HelmMongoDBレプリカセットチャートを使用して、3つのポッド、ヘッドレスサービス、および3つのStatefulSetオブジェクトを作成します。 PersistentVolumeClaims。また、カスタムアプリケーションイメージを使用してマルチレプリカNode.jsアプリケーションをデプロイするためのグラフを作成します。このチュートリアルで構築するセットアップは、 Docker Compose を使用したNode.jsアプリケーションのコンテナー化で説明されているコードの機能を反映し、MongoDBを使用して復元力のあるNode.jsアプリケーションを構築するための良い出発点になります。ニーズに合わせて拡張できるデータストア。

前提条件

このチュートリアルを完了するには、次のものが必要です。

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

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

アプリケーションをKubernetesで使用するには、kubeletエージェントがイメージをプルできるようにアプリケーションをパッケージ化する必要があります。ただし、アプリケーションをパッケージ化する前に、アプリケーションコードのMongoDB接続URIを変更して、Helmmongodb-replicasetチャート。

最初のステップは、 DigitalOceanCommunityGitHubアカウントからnode-mongo-docker-devリポジトリのクローンを作成することです。このリポジトリには、DockerComposeを使用した開発用の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

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

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

Helm mongodb-replicasetチャートを展開すると、次のものが作成されます。

3つのポッドを持つStatefulSetオブジェクト—MongoDBレプリカセットのメンバー。各ポッドには、関連付けられたPersistentVolumeClaimがあり、スケジュールが変更された場合でも固定IDを維持します。
StatefulSetのポッドで構成されるMongoDBレプリカセット。セットには、1つのプライマリと2つのセカンダリが含まれます。データはプライマリからセカンダリに複製され、アプリケーションデータの高可用性が維持されます。

アプリケーションがデータベースレプリカと対話するには、コード内のMongoDB接続URIに、レプリカセットメンバーのホスト名とレプリカセット自体の名前の両方を含める必要があります。したがって、これらの値をURIに含める必要があります。

データベース接続情報を指定するクローンリポジトリ内のファイルは、db.jsと呼ばれます。 nanoまたはお気に入りのエディターを使用して、そのファイルを今すぐ開きます。

nano db.js

現在、ファイルには、実行時にデータベース接続URIで参照される定数が含まれています。これらの定数の値は、ノードの process.env プロパティを使用して注入されます。このプロパティは、実行時にユーザー環境に関する情報を含むオブジェクトを返します。アプリケーションコードで動的に値を設定すると、動的なステートレス環境で必要な、基盤となるインフラストラクチャからコードを切り離すことができます。この方法でのアプリケーションコードのリファクタリングの詳細については、DockerComposeを使用した開発用のNode.jsアプリケーションのコンテナ化のステップ2および12ファクターの関連する説明を参照してください。 App。

接続URIとURI文字列自体の定数は、現在次のようになっています。

〜/ node_project / db.js

...
const {
  MONGO_USERNAME,
  MONGO_PASSWORD,
  MONGO_HOSTNAME,
  MONGO_PORT,
  MONGO_DB
} = process.env;

...

const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}?authSource=admin`;
...

12FAのアプローチに従い、レプリカインスタンスのホスト名またはレプリカセット名をこのURI文字列にハードコーディングする必要はありません。既存のMONGO_HOSTNAME定数を拡張して、複数のホスト名（レプリカセットのメンバー）を含めることができるため、そのままにしておきます。ただし、URI文字列のオプションセクションにレプリカセット定数を追加する必要があります。

MONGO_REPLICASETをURI定数オブジェクトと接続文字列の両方に追加します。

〜/ node_project / db.js

...
const {
  MONGO_USERNAME,
  MONGO_PASSWORD,
  MONGO_HOSTNAME,
  MONGO_PORT,
  MONGO_DB,
  MONGO_REPLICASET
} = process.env;

...
const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}?replicaSet=${MONGO_REPLICASET}&authSource=admin`;
...

URIのオプションセクションでreplicaSetオプションを使用すると、レプリカセットの名前を渡すことができます。これにより、MONGO_HOSTNAME定数で定義されたホスト名とともに、次のことが可能になります。セットメンバーに接続します。

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

レプリカセットで機能するようにデータベース接続情報を変更すると、アプリケーションをパッケージ化し、 docker build コマンドを使用してイメージをビルドし、DockerHubにプッシュできるようになります。

docker buildと-tフラグを使用してイメージを作成します。これにより、イメージに覚えやすい名前を付けることができます。この場合、イメージにDocker Hubユーザー名のタグを付け、node-replicasまたは自分で選択した名前を付けます。

docker build -t your_dockerhub_username/node-replicas .

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

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

docker images

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

OutputREPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
your_dockerhub_username/node-replicas   latest              56a69b4bc882        7 seconds ago       90.1MB
node                                    10-alpine           aa57b0242b33        6 days ago          71MB

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

docker login -u your_dockerhub_username

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

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

docker push your_dockerhub_username/node-replicas

これで、Kubernetesでレプリケートされたアプリケーションを実行するためにプルできるアプリケーションイメージができました。次のステップは、MongoDBHelmチャートで使用する特定のパラメーターを構成することです。

ステップ2—MongoDBレプリカセットのシークレットを作成する

stable/mongodb-replicasetチャートは、シークレットの使用に関してさまざまなオプションを提供します。チャートの展開で使用する2つを作成します。

レプリカセットキーファイルのシークレット。レプリカセットメンバー間で共有パスワードとして機能し、他のメンバーを認証できるようにします。
adminデータベースにrootユーザーとして作成されるMongoDB管理者ユーザーの秘密。この役割により、アプリケーションを本番環境にデプロイするときに、権限が制限された後続のユーザーを作成できます。

これらのシークレットを設定すると、専用の値ファイルに優先パラメーター値を設定し、Helmチャートを使用してStatefulSetオブジェクトとMongoDBレプリカセットを作成できるようになります。

まず、キーファイルを作成しましょう。 opensslコマンドとrandオプションを使用して、キーファイルの756バイトのランダムな文字列を生成します。

openssl rand -base64 756 > key.txt

コマンドによって生成される出力は、 base64 でエンコードされ、均一なデータ送信が保証され、 mongodb-replicasetチャート認証ドキュメントに記載されているガイドラインに従って、key.txtというファイルにリダイレクトされます。。キー自体は、6〜1024文字の長さで、base64セットの文字のみで構成されている必要があります。

これで、 kubectl create でこのファイルを使用して、keyfilesecretというシークレットを作成できます。

kubectl create secret generic keyfilesecret --from-file=key.txt

これにより、default namespace にシークレットオブジェクトが作成されます。これは、セットアップ用の特定の名前空間を作成していないためです。

シークレットが作成されたことを示す次の出力が表示されます。

Outputsecret/keyfilesecret created

key.txtを削除します：

rm key.txt

または、ファイルを保存する場合は、必ずアクセス許可を制限し、.gitignoreファイルに追加してバージョン管理されないようにしてください。

次に、MongoDB管理者ユーザーのシークレットを作成します。最初のステップは、希望するユーザー名とパスワードを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および[ X174X]

getdocs

8783