Ops Manager 사용자 지정 리소스 구성

관리자 자격 증명 및 초기 설정

MongoDB Ops Manager 애플리케이션이 시작되기 전에 초기 관리자 계정이 필요합니다. spec.adminCredentials에서 참조하는 Kubernetes Secret을 통해 이러한 자격 증명을 제공합니다. 시크릿에는 Username (이메일 주소), Password, FirstName, LastName 등 4개의 키가 포함되어 있어야 합니다. Kubernetes 연산자는 이 정보를 사용하여 MongoDB Ops Manager 팟이 처음 초기화될 때 첫 번째 Global Owner 계정을 부트스트랩합니다.

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"

Ops Manager가 실행되면 Ops Manager UI 또는 API를 통해 추가 사용자와 API 키를 만들 수 있습니다. 초기 관리자 시크릿은 초기 설정 시에만 사용되지만 Kubernetes 연산자는 제거를 위해 참조하므로 클러스터에 계속 있어야 합니다.

spec.version 필드는 Kubernetes Operator가 배포할 MongoDB Ops Manager 릴리스를 결정합니다. X.Y.Z 버전을 유동적으로 두지 말고 특정 버전으로 고정하세요. 업그레이드할 준비가 되면 이 필드를 업데이트하고 다음 예시와 같이 Kubernetes 연산자가 롤링 업그레이드를 수행하도록 하십시오:

apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager
spec:
  replicas: 1
  version: "8.0.0"
  adminCredentials: ops-manager-admin-secret

필수 필드에 대한 자세한 내용은 사양 참조의 필수 설정 을 참조하십시오.

MongoDB Ops Manager 리소스의 크기 조정 및 토폴로지

spec.replicas 필드는 공유 서비스 뒤에서 동시에 실행되는 MongoDB Ops Manager 애플리케이션 인스턴스 수를 제어합니다. 개발 및 평가에는 단일 복제본으로 충분하지만, 생산 환경에서는 가동 중단 없이 Pod 재시작 및 노드 장애에 대처하기 위해 부하 밸런서 뒤에서 최소 두 개의 복제본을 실행해야 합니다. 복제본 간에는 기능적 차이가 없습니다. 모든 복제본은 동일한 애플리케이션 데이터베이스로 지원되는 무상태 애플리케이션 서버입니다.

지역 이중화 또는 리전 간 고가용성이 필요한 조직의 경우 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 Operator는 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 유저 인터페이스가 출처 간 요청을 허용하는지 여부를 제어합니다.

• automation.versions.source — MongoDB 바이너리가 다운로드되는 방식을 제어하려면 "remote" (기본값), "local" 또는 "hybrid" 로 설정합니다. 아래의 로컬 및 원격 모드 를 참조하세요.

• mms.featureFlag.automation.verifyDownloads — "enabled"으로 설정되면 에이전트는 모든 MongoDB 바이너리에 대한 암호화 서명을 요구합니다.

속성의 전체 카탈로그는 사양 참조에서 MongoDB Ops Manager 구성 설정 및 spec.configuration 를 참조하세요.

TLS를 사용하여 연결 보안

로컬 개발 이외의 모든 환경에서는 HTTPS를 통해 MongoDB Ops Manager를 실행하는 것이 강력히 권장됩니다. 이것이 없으면 관리자 자격 증명, API 키 및 모니터링 데이터가 클리어 텍스트로 네트워크를 통해 이동합니다.

HTTPS를 활성화하려면 다음이 필요합니다.

• MongoDB Ops Manager 애플리케이션 자체에 대한 TLS 인증서입니다.

• 애플리케이션 데이터베이스용 TLS 인증서.

각 인증서는 패턴 <certsSecretPrefix>-<metadata.name>-cert (애플리케이션용) 또는 <certsSecretPrefix>-<metadata.name>-db-cert (애플리케이션 데이터베이스용)을 따르는 이름의 시크릿 에 저장됩니다.

certsSecretPrefix 는 Kubernetes Operator가 이러한 명명 규칙을 연결하는 방법입니다. spec.security.certsSecretPrefix 을 "om-prod" 로 설정하고 리소스 이름을 ops-manager으로 설정하면 Kubernetes Operator는 다음 예시에 나와 있는 것처럼 om-prod-ops-manager-cert 와 (애플리케이션 데이터베이스의 경우) appdb-prod-ops-manager-db-cert라는 이름의 시크릿를 예상합니다.

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

인증서가 사용자 지정 인증 기관에 의해 서명된 경우 CA 인증서가 포함된 ConfigMaps를 만들어야 합니다. MongoDB Ops Manager CA 인증서의 이름은 ConfigMap 내에서 mms-ca.crt (으)로 지정되어야 합니다. 이 CA 파일에는 백업 디먼이 MongoDB 바이너리를 다운로드할 수 있도록 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 네트워크 로드 밸런서를 사용하려면 다음과 같은 조치를 취합니다.

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 연산자와 에이전트가 MongoDB 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 애플리케이션 서버와 강력하게 연결되어 있으며 정상적이어야 합니다. 연산자는 동일한 사용자 지정 리소스의 일부로 애플리케이션 데이터베이스를 관리합니다. 이는 단일 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:
      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을 통해 팝 사양을 제어합니다.

최소한 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을 사용하지만 주의해야 합니다. 힙 값이 정확하지 않으면 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 리소스 구성을 참조하세요.

MongoDB Ops Manager 구성 반복

MongoDB Ops Manager 사용자 지정 리소스는 조직과 함께 발전합니다. 일반적인 반복 시나리오에는 MongoDB Ops Manager 버전 업그레이드, 고가용성을 위한 복제본 확장, 새로 배포된 데이터베이스를 위한 백업 인프라스트럭처 추가 및 TLS 인증서 로테이션이 포함됩니다.

안전한 변경을 위한 지침:

• 업그레이드 |onprem| 제자리에서. spec.version 을 변경하고 적용합니다. 연산자는 애플리케이션 팝의 롤링 업그레이드를 수행합니다. 업그레이드하기 전에 애플리케이션 데이터베이스 버전이 새 Ops Manager 버전과 호환되는지 확인합니다.

• 복제본을 독립적으로 확장합니다. 다운타임 없이 spec.replicas 을 증가시킬 수 있습니다. 새 팟은 기존 서비스에 자동으로 가입됩니다.

• 백업 저장소를 점증적으로 추가합니다. CR에 새 oplog 또는 스냅샷 저장소를 정의하고 적용합니다. 기존 백업 할당에는 영향이 없습니다.

• 인증서를 사전에 회전합니다. TLS 인증서 시크릿과 필요한 경우 CA ConfigMap을 업데이트합니다. 연산자는 변경된 시크릿를 감지하고 영향을 받은 팝을 다시 시작합니다.

• 리소스 상태를 주시합시오. 변경 후 kubectl get om 를 실행하고 status 필드에서 조정 진행 상태 및 오류 상태를 확인합니다.

버전 업그레이드 절차에 대한 자세한 내용은 MongoDB Ops Manager 및 백업 데이터베이스 버전 업그레이드를 참조하세요. 재해 복구 지침에 대한 자세한 내용은 MongoDB Ops Manager 및 AppDB 리소스에 대한 재해 복구를 참조하세요.

모든 것 하나로 모으기: 완전한 Ops Manager 리소스 예시

다음 예시에서는 이 페이지에서 다루는 개념을 하나의 생산 준비 Ops Manager 배포에 결합합니다. HTTPS, 이메일 구성, 분할 저장소가 있는 3노드 애플리케이션 데이터베이스, S3 스냅샷 및 oplog 저장소를 사용한 백업, KMIP 암호화 및 리소스 제한이 포함됩니다.

apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager-prod
  namespace: ops-manager
spec:
  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:
      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"