Ops Manager のカスタム リソースの構成

管理者の認証情報と初期設定

MongoDB Ops Manager アプリケーションを起動する前に、初期の管理者アカウントが必要です。spec.adminCredentials で参照される Kubernetes Secret を使用して、これらの認証情報を提供します。Secret には、Username (メール アドレス)、Password、FirstName、LastName の 4 つのキーを含める必要があります。Kubernetes 演算子は、MongoDB Ops Manager ポッドが初めて初期化されるときに、この情報を使用して最初のグローバルオーナーアカウントをブートストラップします。

kubectl create secret generic ops-manager-admin-secret \  --from-literal=Username="admin@example.com" \  --from-literal=Password="<secure-password>" \  --from-literal=FirstName="Admin" \  --from-literal=LastName="User"

MongoDB Ops Managerが起動したら、MongoDB Ops ManagerのUIまたはAPIを使用して、追加のユーザーおよびAPIキーを作成できます。初期管理者のシークレットは初回設定時のみ使用されますが、Kubernetes Operatorが調整（reconciliation）のためにこれを参照するため、クラスター内に保持しておく必要があります。

spec.version フィールドは、Kubernetes Operator がどの MongoDB Ops Manager リリースを配置するかを決定します。フロートさせるのではなく、特定の X.Y.Z バージョンに固定します。アップグレードの準備ができたら、このフィールドを更新し、Kubernetes 演算子にローリング アップグレードを実行させます。次の例に示します。

apiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata:  name: ops-managerspec:  replicas: 1  version: "8.0.0"  adminCredentials: ops-manager-admin-secret

必要なすべてのフィールドの詳細については、仕様リファレンスの「必要な設定」を参照してください。

MongoDB Ops Manager リソースのサイズ設定とトポロジー

spec.replicasフィールドは、共有サービスの背後で並行して実行される Ops Managerアプリケーションインスタンスの数を制御します。開発と評価には単一のレプリカで十分です。実稼働環境では、ロードバランサーの背後で少なくとも 2 つのレプリカを実行して、Ped の再起動やノードの障害をダウンタイムなしで耐えられます。レプリカ間に機能的な違いはありません。これらはすべて、同じアプリケーション データベースを基盤としたステートレスアプリケーションサーバーです。

地理的な多重化やクロスリージョン間の高可用性が必要な組織の場合、Kubernetes Operator は MongoDB Ops Manager 自体の MultiCluster トポロジーをサポートします。このモードでは、次の例に示すように、spec.topology: MultiCluster を設定し、名前付き Kubernetes クラスターに MongoDB Ops Manager インスタンスを分配する clusterSpecList を定義します。

spec:  topology: MultiCluster  clusterSpecList:    - clusterName: "cluster-us-east"      members: 1    - clusterName: "cluster-eu-west"      members: 1

MultiCluster トポロジーを使用する場合、spec.replicas フィールドは無視されます。ノード数は、代わりに clusterSpecList から取得されます。複数のクラスターにわたる MongoDB Ops Manager 配置では、クラスター間のネットワーク要件が発生するため、このモデルを采用する前に「Kubernetes クラスター複数に MongoDB Ops Manager リソースを配置する」を検討してください。

アプリケーション構成プロパティ

MongoDB Ops Manager には、メール設定から機能フラグ、バイナリダウンロードソースまで、広範なサーバー側の構成プロパティがあります。これらをそれぞれファースト クラス CRD フィールドに翻訳するのではなく、Kubernetes 演算子は、spec.configuration ブロックをパススルーとして提供します。これにより、MongoDB Ops Manager システム プロパティに直接マップするキーと値のペアを設定できます。

配置時に設定する最も一般的なプロパティは、MongoDB Ops Manager がアラートや招待を送信できるようにするメール構成とセキュリティのデフォルトです。以下の例を参照してください。

spec:  configuration:    mms.fromEmailAddr: "ops-manager@example.com"    mms.replyToEmailAddr: "ops-manager@example.com"    mms.adminEmailAddr: "admin@example.com"    mms.mail.hostname: "smtp.example.com"    mms.mail.port: "587"    mms.mail.ssl: "true"    mms.mail.transport: "smtp"    mms.ignoreInitialUiSetup: "true"

mms.ignoreInitialUiSetup を "true" に設定すると、初回起動時の対話型の設定ウィザーがスキップされます。これは、完全に自動化された配置には不可欠です。

その他の有用なプロパティは次のとおりです。

• mms.security.allowCORS — UIがクロスオリジンリクエストを受け入れるかどうかを制御します。

• automation.versions.source — MongoDB バイナリのダウンロード方法を制御するため、"remote" (デフォルト)、"local"、または "hybrid" に設定します。詳細は、以下の ローカルモードとリモートモード を参照してください。

• mms.featureFlag.automation.verifyDownloads — "enabled" に設定すると、エージェントはすべての MongoDB バイナリに対して暗号化された署名を必要とします。

プロパティの全カタログについては、仕様リファレンスの「MongoDB Ops Manager 構成設定」と「spec.configuration」を参照してください。

TLS での接続の保護

ローカル開発以外のすべての環境では、HTTPS を介して Ops Manager を実行することを強くお勧めします。これがないと、管理者の認証情報、API キー、モニタリングデータがネットワーク上をクリアテキストで通過します。

HTTPS を有効にするには、次の条件が必要です。

• MongoDB Ops Manager アプリケーション自体の TLS 証明書。

• アプリケーションデータベース用の TLS 証明書。

各証明書は、名前がパターン <certsSecretPrefix>-<metadata.name>-cert (アプリケーションの場合) または <certsSecretPrefix>-<metadata.name>-db-cert (アプリケーションデータベースの場合) に従う シークレット に保存されます。

The certsSecretPrefix is how the Kubernetes 演算子がこれらの命名規則を結び付ける方法です。spec.security.certsSecretPrefix を "om-prod" に設定し、リソースの名前が ops-manager の場合、Kubernetes 演算子は、次の例に示すように、om-prod-ops-manager-cert とアプリケーションデータベース用の appdb-prod-ops-manager-db-cert という名前のシークレットを予想します。

# Create the Ops Manager TLS certificate secretkubectl create secret tls om-prod-ops-manager-cert \  --cert=om-tls.crt \  --key=om-tls.key
# Create the Application Database TLS certificate secretkubectl create secret tls appdb-prod-ops-manager-db-cert \  --cert=appdb-tls.crt \  --key=appdb-tls.key

認証書がカスタム認証機関によって署名されている場合は、CA 認証書を含む ConfigMap も作成する必要があります。Ops Manager CA 認証書は mms-ca.crtConfigMap 内で という名前にする必要があります。さらに、バックアップデーモンが MongoDB バイナリをダウンロードできるように、この CA ファイルには downloads.mongodb.com の認証書チェーンを含める必要があります。

spec:  security:    certsSecretPrefix: "om-prod"    tls:      ca: "om-ca-configmap"  applicationDatabase:    security:      certsSecretPrefix: "appdb-prod"      tls:        ca: "appdb-ca-configmap"

CA チェーンを組み立てるための openssl コマンドを含むステップバイステップの HTTPS 配置手順については、MongoDB Ops Manager リソースの配置を参照してください。証明書更新の自動化については、cert-manager 統合のセットアップを参照してください。

外部接続

そのままでは、MongoDB Ops ManagerはKubernetes クラスターの内部ネットワーク内でのみアクセス可能です。クラスター外で実行されている管理者とモニタリングエージェントがMongoDB Ops Manager UI とAPIにアクセスできるようにするには、外部接続を構成する必要があります。

spec.externalConnectivity ブロックは、Kubernetes 演算子に指定された種類の Kubernetes サービスを作成するよう指示します。クラウドプロバイダーがサポートしている場合は、安定した外部エンドポイントが自動的にプロビジョニングされるため、LoadBalancer の使用を強くお勧めします。NodePort は、次の例に示すように、オンプレミスまたはベアメタル クラスターのフォールバックです。

spec:  externalConnectivity:    type: LoadBalancer

クラウド固有のアノテーションを追加して、ロード バランサーの動作に影響を与えることができます。例えば、内部サブネットで AWS Network Load Balancer を使用するには、次のようにします。

spec:  externalConnectivity:    type: LoadBalancer    annotations:      service.beta.kubernetes.io/aws-load-balancer-type: "nlb"      service.beta.kubernetes.io/aws-load-balancer-internal: "true"

外部エンドポイントにカスタムドメイン名 (例: https://opsmanager.example.com) がある場合は、Kubernetes 演算子とそのエージェントが Ops Manager と通信する際に正しいアドレスを使用するように spec.opsManagerURL を設定します。

spec:  opsManagerURL: "https://opsmanager.example.com:8443"  externalConnectivity:    type: LoadBalancer

外部接続フィールドの全体については、仕様リファレンスの「spec.externalConnectivity」を参照してください。

アプリケーション データベース

アプリケーションデータベースは、プロジェクト構成、ユーザーアカウント、アラート定義など、MongoDB Ops Manager の内部状態をすべて保存する MongoDB レプリカセットです。MongoDB Ops Manager アプリケーションサーバーと密接に結合しており、MongoDB Ops Manager が機能するにはヘルシーである必要があります。演算子はアプリケーションデータベースを同じカスタムリソースの一部として管理します。つまり、1 つの YAML マニフェストでアプリケーションとそのバッキング データベースの両方を制御できます。

spec:  applicationDatabase:    members: 3    version: "8.0.0-ubi8"

spec:  applicationDatabase:    version: "8.0.0-ubi8"    featureCompatibilityVersion: "7.0"

spec:  applicationDatabase:    passwordSecretKeyRef:      name: appdb-user-secret      key: password

spec:  applicationDatabase:    members: 3    version: "8.0.0-ubi8"    podSpec:      podTemplate:        spec:          containers:            - name: mongod              resources:                limits:                  cpu: 4                  memory: 8Gi                requests:                  cpu: 2                  memory: 4Gi      persistence:        multiple:          data:            storage: "100Gi"            storageClass: "fast-ssd"          journal:            storage: "30Gi"            storageClass: "fast-ssd"          logs:            storage: "10Gi"            storageClass: "standard"

spec:  applicationDatabase:    topology: MultiCluster    version: "8.0.0-ubi8"    clusterSpecList:      - clusterName: "cluster-1"        members: 2      - clusterName: "cluster-2"        members: 2      - clusterName: "cluster-3"        members: 1

バックアップインフラストラクチャ

Ops Manager は、管理する MongoDB 配置の継続的なバックアップを提供します。MongoDB CR の配置ごとの spec.backup.mode フラグとは異なり、Ops Manager リソースのバックアップ設定では、バックアップデータを保存する インフラストラクチャ (ヘッドデータベース、oplog ストア、スナップショット ストア)が定義されます。このインフラストラクチャが準備されていない場合、個別の MongoDB リソースでバックアップを有効にするとエラーが発生します。

spec:  backup:    enabled: true

spec:  backup:    enabled: true    headDB:      storage: "50Gi"      storageClass: "fast-ssd"

spec:  backup:    enabled: true    opLogStores:      - name: oplog1        mongodbResourceRef:          name: oplog-db        mongodbUserRef:          name: oplog-user        assignmentLabels:          - "production"

spec:  backup:    s3OpLogStores:      - name: s3-oplog-store        s3SecretRef:          name: s3-credentials        pathStyleAccessEnabled: true        s3BucketEndpoint: "s3.us-east-1.amazonaws.com"        s3BucketName: "oplog-bucket"

spec:  backup:    enabled: true    s3Stores:      - name: s3-snapshot-store        mongodbResourceRef:          name: s3-metadata-db        mongodbUserRef:          name: s3-store-user        s3SecretRef:          name: s3-credentials        pathStyleAccessEnabled: true        s3BucketEndpoint: "s3.us-east-1.amazonaws.com"        s3BucketName: "snapshot-bucket"        assignmentLabels:          - "production"

spec:  backup:    blockStores:      - name: blockstore1        mongodbResourceRef:          name: blockstore-db        mongodbUserRef:          name: blockstore-user

spec:  backup:    enabled: true    encryption:      kmip:        server:          url: "kmip.example.com:5696"          ca: "kmip-ca-configmap"        client:          clientCertificatePrefix: "kmip-client"

リソースの割り当てと JVM チューニング

MongoDB Ops Manager は Java アプリケーションであり、そのリソース消費量は、モニター対象の配置の数、メトリクス データの量、バックアップが有効になっているかどうかによって異なります。演算子は MongoDB Ops Manager を StatefulSet として配置し、spec.statefulSet を介して Pod 仕様を制御します。

最低でも、CPU とメモリのリクエストと制限を設定します。MongoDB は、小規模の配置について、最低 4 CPU と 8 GiB のメモリを推奨しています。大規模の環境では拡大します。

spec:  statefulSet:    spec:      template:        spec:          containers:            - name: mongodb-ops-manager              resources:                requests:                  cpu: "4"                  memory: "8Gi"                limits:                  cpu: "8"                  memory: "16Gi"

演算子は、コンテナのメモリ制限に基づいてJVMヒープ設定を計算します。JavaヒープまたはGCパラメータを上書きする必要がある場合は、spec.jvmParametersを使用しますが、注意して行ってください。ヒープ値が不正だと、MongoDB Ops Managerが不安定になる可能性があります。

spec:  jvmParameters:    - "-Xmx12g"    - "-Xms8g"    - "-XX:+UseG1GC"

StatefulSet の完全な仕様フィールドについては、仕様リファレンスのspec.statefulSet.specを参照してください。

ローカル モードとリモート モード

デフォルトで、MongoDB Ops Manager はインターネットから MongoDB インストール バイナリをダウンロードする (リモート モード)。エアギャップ環境または制限されたネットワーク環境では、バイナリが MongoDB Ops Manager ポッドにマウントされた PersistentVolume から勤めるローカルモード、またはカスタムエンドポイントとなる接続されたデバイスを使用するリモートモードを構成できます。

リモート モード (デフォルト):

spec:  configuration:    automation.versions.source: "remote"

ローカルモード（エアギャップ環境向け）：

spec:  configuration:    automation.versions.source: "local"    automation.versions.directory: "/mongodb-ops-manager/mongodb-releases"

詳細な手順については、「ローカル モードを使用するようにMongoDB Ops Managerリソースを構成する」と「リモート モードを使用するようにMongoDB Ops Managerリソースを構成するを参照してください。

Ops Manager 構成の反復

Ops Manager カスタム リソースは、組織とともに進化します。一般的な反復シナリオには、Ops Manager バージョンのアップグレード、高可用性のためのレプリカの拡大、新しく配置されたデータベースのバックアップ インフラの追加、TLS 証明書のローテーションがあります。

安全な変更のガイドライン:

• |onprem| をインプレースでアップグレードします。spec.version を変更して適用します。演算子は、アプリケーションポッドのローリングアップグレードを実行します。アップグレードする前に、アプリケーションデータベースのバージョンが新しい MongoDB Ops Manager バージョンと互換性があることを確認してください。

• レプリカを独立して増やします。ダウンタイムなしで spec.replicas を増やすことができます。新しいポッドは既存のサービスに自動的に参加します。

• バックアップ ストレージを増分的に追加します。CR で新しい oplog またはスナップショット ストレージを定義して適用します。既存のバックアップ割り当ては影響を受けません。

• 証明書を積極的にローテーションする。 TLS 証明書シークレットと、CA が変更された場合は CA ConfigMap を更新します。演算子は変更されたシークレットを検出し、影響を受けたポッドを再起動します。

• リソースの状態を監視します。変更後は、kubectl get om を実行し、status フィールドで調整の進行状況とエラー状況を確認します。

バージョンのアップグレード手順については、「MongoDB Ops Managerおよびバッキングデータベースのバージョンをアップグレードする」を参照してください。障害復旧のガイダンスについては、「MongoDB Ops Managerと AppDB リソースの障害復旧」を参照してください。

まとめ: 完全な MongoDB Ops Manager リソースの例

次の例では、このページで説明されている概念を組み合わせて、本番環境で使用できるMongoDB Ops Manager配置を示します。HTTPS、メール構成、ストレージが分割された3ノードのアプリケーションデータベース、S3 スナップショットとoplogストレージを使用したバックアップ、KMIP暗号化、およびリソース制限が含まれています。

apiVersion: mongodb.com/v1kind: MongoDBOpsManagermetadata:  name: ops-manager-prod  namespace: ops-managerspec:  replicas: 2  version: "8.0.0"  adminCredentials: ops-manager-admin-secret  opsManagerURL: "https://opsmanager.example.com:8443"  configuration:    mms.fromEmailAddr: "ops-manager@example.com"    mms.replyToEmailAddr: "ops-manager@example.com"    mms.adminEmailAddr: "admin@example.com"    mms.mail.hostname: "smtp.example.com"    mms.mail.port: "587"    mms.mail.ssl: "true"    mms.mail.transport: "smtp"    mms.ignoreInitialUiSetup: "true"  security:    certsSecretPrefix: "om-prod"    tls:      ca: "om-ca-configmap"  externalConnectivity:    type: LoadBalancer    annotations:      service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  statefulSet:    spec:      template:        spec:          containers:            - name: mongodb-ops-manager              resources:                requests:                  cpu: "4"                  memory: "8Gi"                limits:                  cpu: "8"                  memory: "16Gi"  jvmParameters:    - "-Xmx12g"    - "-Xms8g"  applicationDatabase:    members: 3    version: "8.0.0-ubi8"    featureCompatibilityVersion: "8.0"    security:      certsSecretPrefix: "appdb-prod"      tls:        ca: "appdb-ca-configmap"    podSpec:      podTemplate:        spec:          containers:            - name: mongod              resources:                limits:                  cpu: 8                  memory: 16Gi                requests:                  cpu: 4                  memory: 8Gi      persistence:        multiple:          data:            storage: "200Gi"            storageClass: "fast-ssd"          journal:            storage: "50Gi"            storageClass: "fast-ssd"          logs:            storage: "20Gi"            storageClass: "standard"  backup:    enabled: true    encryption:      kmip:        server:          url: "kmip.example.com:5696"          ca: "kmip-ca-configmap"        client:          clientCertificatePrefix: "kmip-client"    headDB:      storage: "100Gi"      storageClass: "fast-ssd"    opLogStores:      - name: oplog1        mongodbResourceRef:          name: oplog-db        mongodbUserRef:          name: oplog-user        assignmentLabels:          - "production"    s3Stores:      - name: s3-snapshots        mongodbResourceRef:          name: s3-metadata-db        mongodbUserRef:          name: s3-store-user        s3SecretRef:          name: s3-credentials        pathStyleAccessEnabled: true        s3BucketEndpoint: "s3.us-east-1.amazonaws.com"        s3BucketName: "backup-snapshots-prod"        assignmentLabels:          - "production"