コンテナのイメージ

アーキテクチャ

静的コンテナと非静的コンテナのアーキテクチャは大きく異なるため、一方からもう一方の要素に移行するにはいくつかの手順が必要です。 詳細については、「静的コンテナへの移行 」および「非静的コンテナへの移行 」を参照してください。

非静的コンテナのアーキテクチャ

デフォルトの非静的コンテナMongoDB Agent アーキテクチャでは、空の shellmongod コンテナをブートストラップすること、mongosh をダウンロードして起動すること、によりCloud Manager または から とMongoDB Ops Manager のバイナリをダウンロードすることを前提としています。

クリックして拡大します

静的コンテナ アーキテクチャ

静的コンテナ アーキテクチャは、Kubernetes の 共有名前空間機能 を使用します MongoDB Agent を別のプロセスとして実行することで、完全なmongod ライフサイクルを制御し、ネットワーク経由でのファイルのダウンロードを回避できます。

クリックして拡大します

ローカル モードまたはリモート モードとの互換性

静的コンテナを使用する場合は、クエリ可能なバックアップを使用しない限り、 MongoDB Ops Managerをローカル モードまたはリモート モードで実行するように構成する必要はありません。 静的コンテナ アーキテクチャでは、エージェントと mongod のバイナリに独自のコンテナ イメージがあり、これらはMongoDB Ops Managerからダウンロードされません。

クエリ可能なバックアップは例外です。非静的コンテナ アーキテクチャでは、デフォルトでは、バックアップデーモンがバックアップされているすべてのバージョンの MongoDB Server バイナリをダウンロードして実行します。 このデフォルトの MongoDB 動作は、バックアップデーモンの実行に使用されるコンテナの完全に静的な性質を低下させます。 クエリ可能なバックアップを使用する場合は、ローカル モードまたはリモート モードを使用して、関連する MongoDB Server バイナリをホストする必要があります。 詳細については、「ローカル モードを使用するようにMongoDB Ops ManagerリソースをMongoDB Ops Managerする 」または「 リモート モードを使用するように MongoDB Ops Manager リソースを構成する 」を参照してください。

以前にリモート モードまたはローカル モードを使用していて、クエリ可能なバックアップを使用しない場合は、次の操作を行って、mongodb-enterprise-server がイメージ は ノード でダウンロードできます ポッドによって使用される場合があります。

1. Kubernetes ノードの内部コンテナ レジストリを構成します。

   ノード は Qui.io からイメージをダウンロードします ローカル コンテナ レジストリを使用する場合を除きます。

2. mongodb-enterprise-serverイメージをダウンロードして追加します。

制限

静的コンテナを有効にする場合:

• バックアップデーモン サービスMongoDB がMongoDB Ops Manager から バイナリをダウンロードしようとしないように、 クエリ可能なバックアップ を 無効 にする 必要があります。これにより、静的コンテナの不変の性質が損なわれます。

• MongoDB Ops Managerでは、バージョン 6.0.24 のみ、 7.0.5 、またはそれ以降と互換性があります。 KubernetesOperatorMongoDB Agent は、特定の配置を管理するために、選択した バージョンに基づいて、正しいバージョンのMongoDB Ops Manager コンテナを自動的に使用します。

• MongoDB Cloud Manager では、Kubernetes Operator が MongoDB Cloud Manager のagentVersionエンドポイントを呼び出されないため、MongoDB Agent バージョンが MongoDB Cloud Manager の最新バージョンとの互換性を失う可能性があります。 MongoDB Agent が MongoDB Cloud Manager で最新の状態になるようにするには、次のいずれかのアクションを実行します。

  • ステートフルセット をオーバーライドして、 MongoDB リソース仕様 で 互換性 のある MongoDB Agent のバージョンを指定する MongoDB Agent のコンテナ イメージ。例:

    podSpec:
      podTemplate:
        spec:
          containers:
            - name: mongodb-agent-ubi
              Image: 12.0.29.7785-1_1.24.0

  • Kubernetes Operator を最新バージョンにアップグレードすると、MongoDB Agent が自動的に更新されます。

• MongoDB のバージョンをアップグレードすると、最後から最初の順に、すべての ポッドのローリング再起動がトリガーされ、最大でポッドの数まで増加する選挙が発生する可能性があります。 これは、ローリング再起動をtriggerするすべての更新に当てはまります。

• MongoDB Agent の ステータスから、MongoDB database のアップグレードが行われたかどうかを判断することはできません。 アップグレード後に Kubernetes がポッドをローテーションすると、MongoDB Agent はヘルス ステータス ファイルを置き換えるため、バージョンの変更が発生したことはヘルス ステータスからは判断できず、現在のヘルス ステータスのみが置き換えられます。

FAQ

静的コンテナへの移行

非静的コンテナから静的コンテナに移行するには、MongoDB Agent 環境変数を設定し、以下の手順に従って静的コンテナを有効にします。 インストールまたはアップグレード時に静的コンテナを有効にすることもできます。

kubectl apply -f mongodb-enterprise.yaml

oc apply -f mongodb-enterprise-openshift.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
  --set registry.pullPolicy='IfNotPresent'

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

非静的コンテナへの移行

静的コンテナから非静的コンテナに移行するには、以下の手順に従って静的コンテナを無効にします。 インストールまたはアップグレード中に静的コンテナを無効にすることもできます。

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"