문서 메뉴
문서 홈
/
MongoDB Enterprise Kubernetes 연산자
/

Ops Manager 리소스 배포

이 페이지의 내용

  • 고려 사항
  • 절차

Kubernetes Operator를 사용하여 Ops Manager를 Kubernetes 컨테이너의 리소스로 배포할 수 있습니다.

다음 고려 사항이 적용됩니다.

Ops Manager 배포를 구성할 때 HTTPS 또는 HTTP 를 통해 연결을 실행할지 여부를 선택해야 합니다.

다음 HTTPS 절차:

  • Ops Manager 애플리케이션과의 TLS암호화 연결을 설정합니다.

  • 애플리케이션 데이터베이스의 복제본 세트 멤버 간에 TLS암호화 연결을 설정합니다.

  • TLS 암호화를 위해 유효한 인증서가 필요합니다.

다음 HTTP 절차는 다음과 같습니다.

  • Ops Manager 애플리케이션과의 연결을 암호화하지 않습니다.

  • 애플리케이션 데이터베이스의 복제본 세트 멤버 간의 연결을 암호화하지 않습니다.

  • 설정 요구 사항이 적습니다.

HTTPS 를 통해 실행하는 경우 Ops Manager는 기본적으로 포트 8443 에서 실행됩니다.

Ops Manager 및 애플리케이션 데이터베이스 연결을 TLS 로 암호화할지 여부에 따라 적절한 탭을 선택합니다.

  • 전제 조건을 완료합니다.

  • 고려 사항을 참조하세요.

  • 애플리케이션 데이터베이스의 복제본 세트 에 대한 TLS 인증서 한 개를 생성합니다.

    TLS 인증서에는 다음 속성이 필요합니다.

    DNS 이름

    Pod 에 SAN또는 주체 이름을 추가해야 합니다. 애플리케이션 데이터베이스 복제본 세트의 멤버를 호스팅합니다. 각 포드의 SAN 은 다음 형식을 사용해야 합니다.

    <opsmgr-metadata.name>-db-<index>.<opsmgr-metadata.name>-db-svc.<namespace>.svc.cluster.local
    키 용도

    TLS 인증서에 다음 키 용도(5280):

    • "서버 인증"

    • "클라이언트 인증"

중요

Kubernetes Operator는 다음을 사용합니다 .kubernetes.io/tls Ops Manager 및 MongoDB 리소스에 대한 TLS 인증서 및 비공개 키를 저장하기 위한 비밀입니다. Kubernetes Operator 버전 부터 1 시작됩니다.17.0, Kubernetes Operator는 Opaque 시크릿 으로 저장된 연결된 PEM 파일을 지원하지 않습니다.

Ops Manager 리소스를 배포하기 전에 Ops Manager 리소스에 대한 계획을 세워야 합니다.

이 절차는 단일 Kubernetes 클러스터에 MongoDB Ops Manager 인스턴스를 배포하는 것과 멀티 클러스터 배포의 연산자 클러스터에 MongoDB Ops Manager를 배포하는 데 적용됩니다. 여러 Kubernetes 클러스터에 MongoDB Ops Manager의 여러 인스턴스를 배포하려면 여러 Kubernetes 클러스터에 Kubernetes Ops Manager 리소스 배포를 참조하세요.

다음 단계에 따라 HTTPS 를 통해 실행되도록 Ops Manager 리소스를 배포하고 TLS 를 사용하여 애플리케이션 데이터베이스를 보호합니다.

1

아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 kubectl 명령을 모두 실행합니다.

참고

다중 Kubernetes 클러스터 MongoDB deployment에서 MongoDB Ops Manager 리소스를 배포하는 경우:

  • context을 중앙 클러스터의 이름(예: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME")으로 설정합니다.

  • --namespace 를 다중 Kubernetes 클러스터 MongoDB 배포에 사용한 것과 동일한 범위 (예: kubectl config --namespace "mongodb" 로 설정합니다.

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

HashiCorp Vault 를 사용하는 경우 대신 볼트 시크릿을 생성 할 수 있습니다.

시크릿 스토리지 옵션에 대한 자세한 내용은 시크릿 스토리지 구성을 참조하세요.

  1. TLS 인증서와 비공개 키가 있으면 다음 명령을 실행하여 시크릿 을 생성하세요. Ops Manager의 TLS 인증서를 저장합니다.

    kubectl create secret tls <prefix>-<metadata.name>-cert \
    --cert=<om-tls-cert> \
    --key=<om-tls-key>
  2. 다음 명령을 실행하여 새 시크릿 을 생성합니다. 애플리케이션 데이터베이스의 TLS 인증서를 저장합니다.

    kubectl create secret tls <prefix>-<metadata.name>-db-cert \
    --cert=<appdb-tls-cert> \
    --key=<appdb-tls-key>
3

MongoDB Ops Manager TLS 인증서가 사용자 지정 CA 에서 서명한 경우, CA 인증서에는 MongoDB Ops Manager 백업 데몬이 인터넷에서 MongoDB 바이너리를 다운로드할 수 있도록 허용하는 추가 인증서도 포함되어 있어야 합니다. TLS 인증서를 만들려면 ConfigMap 을 만듭니다.CA 인증서를 보유합니다:

중요

Kubernetes 연산자는 ConfigMap에서 Ops Manager 인증서의 이름이 mms-ca.crt 이어야 합니다.

  1. downloads.mongodb.com 에서 Ops Manager에 대한 전체 TLS 인증서 체인을 얻습니다. 다음 openssl 명령은 체인의 인증서를 현재 작업 디렉토리에 .crt 형식으로 출력합니다.

    openssl s_client -showcerts -verify 2 \
    -connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \
    | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}'
  2. Ops Manager용 CA 의 인증서 파일을 이전 단계에서 얻은 downloads.mongodb.com 의 전체 TLS 인증서 체인과 연결합니다.

    cat cert1.crt cert2.crt cert3.crt cert4.crt >> mms-ca.crt
  3. ConfigMap 만들기 MongoDB Ops Manager의 경우:

    kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
4

Ops Manager 및 애플리케이션 데이터베이스 구성과 일치하도록 설정을 변경합니다.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: SingleCluster
27 members: 3
28 version: "6.0.0-ubi8"
29 security:
30 certsSecretPrefix: <prefix> # Required. Text to prefix to the
31 # name of the secret that contains the Application
32 # Database's TLS certificate. Name the secret
33 # <prefix>-<metadata.name>-db-cert.
34 tls:
35 ca: "appdb-ca" # Optional. Name of the ConfigMap file
36 # containing the certicate authority that
37 # signs the certificates used by the
38 # application database.
39
40...
1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: MultiCluster
27 clusterSpecList:
28 - clusterName: cluster1.example.com
29 members: 4
30 - clusterName: cluster2.example.com
31 members: 3
32 - clusterName: cluster3.example.com
33 members: 2
34 version: "6.0.0-ubi8"
35 security:
36 certsSecretPrefix: <prefix> # Required. Text to prefix to the
37 # name of the secret that contains the Application
38 # Database's TLS certificate. Name the secret
39 # <prefix>-<metadata.name>-db-cert.
40 tls:
41 ca: "appdb-ca" # Optional. Name of the ConfigMap file
42 # containing the certicate authority that
43 # signs the certificates used by the
44 # application database.
45
46...
5
6
유형
설명
예제
문자열

이 Kubernetes Ops Manager 객체 의 이름 .

리소스 이름은 44자 이내여야 합니다.

metadata.name이름에 대한 Kubernetes 문서도 참조하세요.

om
숫자

병렬로 실행할 Ops Manager 인스턴스의 수입니다.

최소 유효한 값은 1 입니다. spec.topology 설정에서 MultiCluster 을 지정하면 이 필드는 무시됩니다.

1
문자열

설치할 Ops Manager의 버전입니다.

형식은 XYZ 여야 합니다. 사용 가능한 Ops Manager 버전을 보려면 컨테이너 레지스트리를 확인합니다.

6.0.0
문자열
시크릿 이름 Ops Manager 관리자 사용자를 위해 생성 했습니다.동일한 네임스페이스 를 사용하도록 시크릿 구성 Ops Manager 리소스로 지정됩니다.
om-admin-secret
spec
.security
문자열

필수 사항.

Ops Manager TLS 인증서가 포함된 시크릿의 이름 앞에 붙일 텍스트입니다.

om-prod
spec
.security
.tls
문자열
ConfigMap 의 이름 사용자 지정 CA 를 사용하여 서명된 Ops Manager TLS 인증서를 확인하기 위해 생성했습니다. 이 필드는 사용자 지정 CA 를 사용하여 Ops Manager TLS 인증서에 서명한 경우 필수입니다.
om-http-cert-ca
spec
.externalConnectivity
문자열
Kubernetes 서비스 ServiceType Kubernetes 외부에 Ops Manager를 노출합니다.spec.externalConnectivity Kubernetes Operator가 외부 트래픽을 Ops Manager 애플리케이션으로 라우팅하는 Kubernetes 서비스를 생성하지 않도록 하려면 설정과 해당 하위 설정을 제외하세요.
LoadBalancer
spec
.applicationDatabase
integer
Ops Manager 애플리케이션 데이터베이스 복제본 세트의 멤버 수입니다.
3
spec
.applicationDatabase
문자열

필수 사항.

가 실행해야 MongoDB Ops Manager Application Database 하는 의 버전입니다.

형식은 Enterprise 에디션 의 경우 X.Y.Z-ubi8 , Community 에디션의 경우 X.Y.Z 이어야 합니다. Kubernetes 연산자가 태그 접미사를 자동으로 추가하므로 커뮤니티 에디션 이미지에 -ubi8 태그 접미사를 추가하지 마세요.

중요

호환되는 MongoDB Server 버전을 선택하도록 합니다.

호환되는 버전은 MongoDB database 리소스가 사용하는 기본 이미지에 따라 다릅니다.

MongoDB 버전 관리에 대해 자세히 알아보려면 MongoDB 매뉴얼의 MongoDB 버전 관리를 참조하세요.

최상의 결과를 얻으려면 사용 가능한 최신 MongoDB 엔터프라이즈 버전 을 사용하세요. MongoDB Ops Manager 버전과 호환 됩니다.

spec
.applicationDatabase
문자열

선택 사항입니다.

애플리케이션 데이터베이스에 대한 Kubernetes 배포 유형입니다. 생략하면 기본값은 SingleCluster 입니다.

MultiCluster 을 지정하면 Kubernetes 연산자는 spec.applicationDatabase.members 필드에 설정한 값(지정된 경우)을 무시합니다. 대신 clusterSpecList 을 지정하고 애플리케이션 데이터베이스를 배포하려는 선택한 각 Kubernetes 멤버 cluster의 clusterName 와 각 Kubernetes cluster의 members (MongoDB 노드) 수를 포함해야 합니다.

참고

CRD에서 topologyclusterSpecList 설정을 수정하여 단일 클러스터 Ops Manager 인스턴스를 다중 Kubernetes 클러스터 MongoDB 배포 인스턴스로 변환할 수 없습니다.

리소스 사양의 예도 참조하세요.

MultiCluster
spec
.applicationDatabase
.security
문자열

필수 사항.

애플리케이션 데이터베이스의 TLS 인증서가 포함된 시크릿 이름 앞에 붙일 텍스트입니다.

appdb-prod
spec
.applicationDatabase
.security
.tls
문자열
ConfigMap 의 이름 사용자 지정 CA 를 사용하여 서명된 애플리케이션 데이터베이스 TLS 인증서를 확인하기 위해 생성했습니다. 이 필드는 사용자 지정 CA 를 사용하여 애플리케이션 데이터베이스 TLS 인증서에 서명한 경우 필수입니다.

ca

Kubernetes Operator는 설정을 사용하여 추가한 spec.applicationDatabase.security.tls.ca CA 를 Ops Manager와 애플리케이션 데이터베이스 파드 모두에 마운트합니다.

7

백업을 구성하려면 허용한 후 다음을 수행합니다.

  • S3 스냅샷 저장소 또는 블록 저장소를 구성하도록 선택합니다. S3 스냅샷 저장소블록 저장소를 모두 배포하는 경우 Ops Manager가 백업에 사용할 스냅샷 중 하나를 무작위로 선택합니다.

  • oplog 저장소 또는 S3 oplog 저장소를 구성하도록 선택합니다. oplog 저장소와 S3 oplog 저장소를 모두 배포하는 경우 Ops Manager는 그 중 하나를 무작위로 선택하여 oplog 백업에 사용할 수 있습니다.

유형
설명
예제
spec
.backup
부울
백업이 활성화되어 있음을 나타내는 플래그입니다. 헤드 데이터베이스, oplog 저장소 및 스냅샷 저장소에 대한 설정을 구성하려면 spec.backup.enabled: true 을(를) 지정해야 합니다.
true
spec
.backup
.headDB
컬렉션
헤드 데이터베이스 에 대한 구성 설정 컬렉션입니다. 컬렉션의 개별 설정에 대한 설명은 spec.backup.headDB 를 참조하세요.
spec
.backup
.opLogStores
문자열
oplog 스토어의 이름입니다.
oplog1
spec
.backup
.s3OpLogStores
문자열
S3 oplog 스토어의 이름입니다.
my-s3-oplog-store
spec
.backup
.opLogStores
.mongodbResourceRef
문자열
oplog 저장소의 MongoDB 리소스 또는 MongoDBMultiCluster 리소스의 이름입니다. 리소스의 metadata.name 이(가) 이 이름과 일치해야 합니다.
my-oplog-db
spec
.backup
.s3OpLogStores
.mongodbResourceRef
문자열
S3 oplog 저장소에 대한 MongoDB 리소스 또는 MongoDBMultiCluster 리소스의 이름입니다. 리소스의 metadata.name 이(가) 이 이름과 일치해야 합니다.
my-s3-oplog-db

또한 S3 스냅샷 저장소 또는 블록 저장소를 구성해야 합니다.

S3 스냅샷 저장소블록 저장소를 모두 배포하는 경우 Ops Manager가 백업에 사용할 스냅샷 중 하나를 무작위로 선택합니다.

스냅샷 저장소를 구성하려면 다음 설정을 구성합니다.

유형
설명
예제
spec
.backup
.s3Stores
문자열
S3 스냅샷 저장소의 이름입니다.
s3store1
spec
.backup
.s3Stores
.s3SecretRef
문자열
시크릿 이름 accessKeysecretKey 필드를 포함합니다.백업 데몬 서비스 는 이러한 필드의 값을 자격 증명으로 사용하여 S3 또는 S3호환 버킷에 액세스합니다.
my-s3-credentials
spec
.backup
.s3Stores
문자열
데이터베이스 백업 스냅샷을 저장 하는 S3 또는 S 호환3버킷의 URL 입니다.
s3.us-east-1.amazonaws.com
spec
.backup
.s3Stores
문자열
데이터베이스 백업 스냅샷을 저장하는 S3 또는 S3호환 버킷의 이름입니다.
my-bucket

블록 저장소를 구성하려면 다음 설정을 구성합니다.

유형
설명
예제
spec
.backup
.blockStores
문자열
블록 저장소의 이름입니다.
blockStore1
spec
.backup
.blockStores
.mongodbResourceRef
문자열
블록 저장소에 대해 생성하는 MongoDB 리소스의 이름입니다. 이 데이터베이스 리소스는 Ops Manager 리소스와 동일한 네임스페이스에 배포해야 합니다.
my-mongodb-blockstore
8

배포에 적용하려는 백업에 대한 선택적 설정 을 객체 에 추가합니다. 사양 파일. 예를 들어, 각 백업 저장소 유형 및 Ops Manager 백업 데몬 프로세스의 경우 레이블을 할당하여 특정 백업 저장소 또는 백업 데몬 프로세스를 특정 프로젝트와 연결할 spec.backup.[*].assignmentLabels 수 있습니다. OpsManager 리소스의 요소를 사용합니다.

9

배포에 적용할 선택적 설정 을 객체 에 추가합니다. 사양 파일.

10
11

Ops Manager 리소스 정의의 파일 이름에 대해 다음 kubectl 명령을 실행합니다.

kubectl apply -f <opsmgr-resource>.yaml

참고

다중 Kubernetes 클러스터 MongoDB 배포에 Ops Manager 리소스를 배포하는 경우 다음을 실행합니다.

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-enterprise-kubernetes/master/samples/ops-manager/ops-manager-external.yaml
12

Ops Manager 리소스의 상태를 확인하려면 다음 명령을 호출합니다.

kubectl get om -o yaml -w

이 명령은 리소스가 배포되는 동안 status 필드 아래에 다음과 유사한 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2022-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

Kubernetes Operator는 다음 순서로 리소스를 조정합니다.

  1. 애플리케이션 데이터베이스.

  2. Ops Manager.

  3. 백업.

Kubernetes 연산자는 이전 리소스가 Running 단계에 들어갈 때까지 리소스를 조정하지 않습니다.

Ops Manager 리소스가 Pending 단계를 완료한 후 백업을 활성화한 경우 명령은 status 필드 아래에 다음과 유사한 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2022-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2023-04-01T09:57:40Z"
phase: Running
replicas: 1
url: https://om-svc.cloudqa.svc.cluster.local:8443
version: "6.0.17"

백업은 데이터베이스 백업을 구성할 때까지 Pending 상태로 유지됩니다.

status.opsManager.url 필드에는 리소스의 연결 URL 이 명시되어 있습니다. 이 URL 을 사용하면 Kubernetes 클러스터 내에서 Ops Manager에 연결하거나 ConfigMap을 사용하여 프로젝트를 만들 수 있습니다.

리소스가 Pending 단계를 완료하면 명령은 status 필드 아래에 다음과 유사한 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2022-12-06T18:23:22Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
opsManager:
lastTransition: "2022-12-06T18:23:26Z"
message: The MongoDB object namespace/oplogdbname doesn't exist
phase: Pending
url: https://om-svc.dev.svc.cluster.local:8443
version: ""

백업은 데이터베이스 백업을 구성할 때까지 Pending 상태로 유지됩니다.

status.opsManager.url 필드에는 리소스의 연결 URL 이 명시되어 있습니다. 이 URL 을 사용하면 Kubernetes 클러스터 내에서 Ops Manager에 연결하거나 ConfigMap을 사용하여 프로젝트를 만들 수 있습니다.

13

취하는 단계는 Kubernetes의 Ops Manager 애플리케이션으로 트래픽을 라우팅하는 방법에 따라 다릅니다. Kubernetes 서비스를 생성하도록 Kubernetes 연산자를 구성했거나 Kubernetes 서비스를 수동으로 생성한 경우, 다음 방법 중 하나를 사용하여 Ops Manager 애플리케이션에 액세스합니다.

  1. 클라우드 제공자를 쿼리하여 로드 밸런서 서비스의 FQDN 을 가져옵니다. 자세한 내용은 클라우드 제공자의 설명서를 참조하세요.

  2. 브라우저 창을 열고 로드 밸런서 서비스의 FQDN 및 포트 번호를 사용하여 Ops Manager 애플리케이션으로 이동합니다.

    https://ops.example.com:8443
  3. 관리자 사용자 자격 증명을 사용하여 Ops Manager에 로그인합니다.

  1. 방화벽 규칙을 설정하여 인터넷에서 Kubernetes 클러스터가 실행 중인 호스트의 spec.externalConnectivity.port 에 액세스할 수 있도록 합니다.

  2. 브라우저 창을 열고 FQDNspec.externalConnectivity.port 를 사용하여 Ops Manager 애플리케이션으로 이동합니다.

    https://ops.example.com:30036
  3. 관리자 사용자 자격 증명을 사용하여 Ops Manager에 로그인합니다.

타사 서비스를 사용하여 Ops Manager 애플리케이션에 액세스하는 방법을 알아보려면 해당 솔루션의 설명서를 참조하세요.

14

자격 증명을 구성하려면 Ops Manager 조직을 생성하고, 프로그래밍 방식 API 키를 생성하고, 시크릿 을 생성해야 합니다. . 이러한 활동 은 Kubernetes Operator에 대한 자격 증명 생성 페이지의 전제 조건 및 절차를 따릅니다.

15

프로젝트를 만들려면 ConfigMap을 사용하여 프로젝트 1개 만들기 페이지의 전제 조건 및 절차를 따르세요.

프로젝트 ConfigMap에서 다음 필드를 설정합니다.

  • ConfigMap에서 data.baseUrl 를 Ops Manager 애플리케이션의 URL 로 설정합니다. 이 URL 을 찾으려면 다음 명령을 호출합니다.

    kubectl get om -o yaml -w

    이 명령은 다음 예와 유사하게 status.opsManager.url 필드에 Ops Manager 애플리케이션의 URL을 반환합니다.

    status:
    applicationDatabase:
    lastTransition: "2022-12-06T18:23:22Z"
    members: 3
    phase: Running
    type: ReplicaSet
    version: "6.0.5-ubi8"
    opsManager:
    lastTransition: "2022-12-06T18:23:26Z"
    message: The MongoDB object namespace/oplogdbname doesn't exist
    phase: Pending
    url: https://om-svc.dev.svc.cluster.local:8443
    version: ""

    중요

    Kubernetes Operator와 함께 운영 관리자를 배포하고 운영 관리자가 배포된 Kubernetes 클러스터 외부에 배포된 MongoDB 데이터베이스 리소스를 관리하는 경우, data.baseUrl 을 운영 관리자 리소스 사양의 spec.configuration.mms.centralUrl 설정과 동일한 값으로 설정해야 합니다.

    다음도 참조하세요.

  • data.sslMMSCAConfigMap ConfigMap mms-ca.crt 의 이름으로 설정합니다. Ops Manager 호스트의 인증서에 서명하는 데 사용되는 루트 CA 인증서가 포함되어 있습니다. Kubernetes Operator를 사용하려면 ConfigMap에서 이 Ops Manager 리소스의 인증서 이름을 으로 지정해야 합니다.

16

기본적으로 Ops Manager는 백업 을 활성화합니다. oplog 및 스냅샷 저장소에 대한 MongoDB 데이터베이스 리소스를 생성하여 구성을 완료합니다.

  1. Ops Manager 리소스와 동일한 네임스페이스에 oplog 저장소에 대한 MongoDB database 리소스 를 배포합니다.

    참고

    이 데이터베이스를 3명의 멤버로 구성된 복제본 세트로 생성합니다.

    리소스의 metadata.name 를 Ops Manager 리소스 정의에 지정한 spec.backup.opLogStores.mongodbResourceRef.name 과 일치시킵니다.

  2. Ops Manager 리소스와 동일한 네임스페이스에 S 스냅샷3 저장소에 대한 MongoDB 데이터베이스 리소스 를 배포합니다.

    참고

    S3 스냅샷 저장소를 복제본 세트로 생성합니다.

    리소스의 metadata.name 를 Ops Manager 리소스 정의에 지정한 spec.backup.s3Stores.mongodbResourceRef.name 과 일치시킵니다.

17

Ops Manager 리소스의 상태를 확인하려면 다음 명령을 호출합니다.

kubectl get om -o yaml -w

Ops Manager가 실행 중일 때 이 명령은 status 필드 아래에 다음과 유사한 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2022-12-06T17:46:15Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
opsManager:
lastTransition: "2022-12-06T17:46:32Z"
phase: Running
replicas: 1
url: https://om-backup-svc.dev.svc.cluster.local:8443
version: "6.0.17"

리소스 배포 상태에 대한 자세한 내용은 Kubernetes 연산자 문제 해결을 참조하세요.

다음 단계에 따라 HTTP 를 통해 실행할 Ops Manager 리소스를 배포합니다.

1

아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 kubectl 명령을 모두 실행합니다.

참고

다중 Kubernetes 클러스터 MongoDB deployment에서 MongoDB Ops Manager 리소스를 배포하는 경우:

  • context을 중앙 클러스터의 이름(예: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME")으로 설정합니다.

  • --namespace 를 다중 Kubernetes 클러스터 MongoDB 배포에 사용한 것과 동일한 범위 (예: kubectl config --namespace "mongodb" 로 설정합니다.

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Ops Manager 구성과 일치하도록 설정을 변경합니다.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the secret
11 # for the admin user
12 externalConnectivity:
13 type: LoadBalancer
14
15 applicationDatabase:
16 topology: SingleCluster
17 members: 3
18 version: <mongodbversion>
19...
1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15
16 applicationDatabase:
17 topology: MultiCluster
18 clusterSpecList:
19 - clusterName: cluster1.example.com
20 members: 4
21 - clusterName: cluster2.example.com
22 members: 3
23 - clusterName: cluster3.example.com
24 members: 2
25 version: "6.0.5-ubi8"
26
27...
3
4
유형
설명
예제
문자열

이 Kubernetes Ops Manager 객체 의 이름 .

리소스 이름은 44자 이내여야 합니다.

다음도 참조하세요.

om
숫자

병렬로 실행할 Ops Manager 인스턴스의 수입니다.

최소 유효한 값은 1 입니다. spec.topology 설정에서 MultiCluster 을 지정하면 이 필드는 무시됩니다.

1
문자열

설치할 Ops Manager의 버전입니다.

형식은 XYZ 여야 합니다. 사용 가능한 Ops Manager 버전 목록은 컨테이너 레지스트리를 참조하세요.

6.0.0
문자열

Ops Manager 관리자 사용자에 대해 생성 한 시크릿의 이름입니다.

참고

동일한 네임스페이스 를 사용하도록 시크릿 구성 Ops Manager 리소스로 지정됩니다.

om-admin-secret
spec
.externalConnectivity
문자열

선택 사항입니다.

Kubernetes 서비스 ServiceType 외부에 MongoDB Ops Manager를 Kubernetes 노출합니다.

참고

Kubernetes 연산자가 외부 트래픽을 Ops Manager 애플리케이션으로 라우팅하는 Kubernetes 서비스를 생성하지 않도록 하려면 spec.externalConnectivity 설정과 해당 하위를 제외하세요.

LoadBalancer
spec
.applicationDatabase
integer
Ops Manager 애플리케이션 데이터베이스 복제본 세트의 멤버 수입니다.
3
spec
.applicationDatabase
문자열

필수 사항.

가 실행해야 MongoDB Ops Manager Application Database 하는 의 버전입니다.

형식은 MongoDB Community Edition의 경우 X.Y.Z , Enterprise Edition의 경우 X.Y.Z-ubi8 이어야 합니다.

중요

호환되는 MongoDB Server 버전을 선택하도록 합니다.

호환되는 버전은 MongoDB database 리소스가 사용하는 기본 이미지에 따라 다릅니다.

MongoDB 버전 관리에 대해 자세히 알아보려면 MongoDB 매뉴얼의 MongoDB 버전 관리를 참조하세요.

최상의 결과를 얻으려면 사용 가능한 최신 MongoDB 엔터프라이즈 버전 을 사용하세요. MongoDB Ops Manager 버전과 호환 됩니다.

spec
.applicationDatabase
문자열

선택 사항입니다.

애플리케이션 데이터베이스에 대한 Kubernetes 배포 유형입니다. 생략하면 기본값은 SingleCluster 입니다.

MultiCluster 을 지정하면 Kubernetes 연산자는 spec.applicationDatabase.members 필드에 설정한 값(지정된 경우)을 무시합니다.

대신 clusterSpecList 를 지정하고 애플리케이션 데이터베이스를 배포하려는 선택한 각 Kubernetes 멤버 cluster의 clusterName 와 각 Kubernetes cluster의 members (MongoDB 노드) 수를 포함해야 합니다.

참고

CRD에서 topologyclusterSpecList 설정을 수정하여 단일 클러스터 Ops Manager 인스턴스를 다중 Kubernetes 클러스터 MongoDB 배포 인스턴스로 변환할 수 없습니다.

리소스 사양의 예도 참조하세요.

MultiCluster
5

백업을 구성하려면 허용한 후 다음을 수행합니다.

  • S3 스냅샷 저장소 또는 블록 저장소를 구성하도록 선택합니다. S3 스냅샷 저장소블록 저장소를 모두 배포하는 경우 Ops Manager가 백업에 사용할 스냅샷 중 하나를 무작위로 선택합니다.

  • oplog 저장소 또는 S3 oplog 저장소를 구성하도록 선택합니다. oplog 저장소와 S3 oplog 저장소를 모두 배포하는 경우 Ops Manager는 그 중 하나를 무작위로 선택하여 oplog 백업에 사용할 수 있습니다.

유형
설명
예제
spec
.backup
부울
백업이 활성화되었음을 나타내는 플래그입니다. 헤드 데이터베이스, oplog 저장소, S3 oplog 저장소 및 스냅샷 저장소에 대한 설정을 구성하려면 spec.backup.enabled: true 를 지정해야 합니다.
true
spec
.backup
.headDB
컬렉션
헤드 데이터베이스 에 대한 구성 설정 컬렉션입니다. 컬렉션의 개별 설정에 대한 설명은 spec.backup.headDB 를 참조하세요.
spec
.backup
.opLogStores
문자열
oplog 스토어의 이름입니다.
oplog1
spec
.backup
.s3OpLogStores
문자열
S3 oplog 스토어의 이름입니다.
my-s3-oplog-store
spec
.backup
.opLogStores
.mongodbResourceRef
문자열
oplog 저장소의 MongoDB 리소스 또는 MongoDBMultiCluster 리소스의 이름입니다. 리소스의 metadata.name 이(가) 이 이름과 일치해야 합니다.
my-oplog-db
spec
.backup
.s3OpLogStores
.mongodbResourceRef
문자열
S3 oplog 저장소에 대한 MongoDB 데이터베이스 리소스의 이름입니다.
my-s3-oplog-db

또한 S3 스냅샷 저장소 또는 블록 저장소를 구성해야 합니다. S3 스냅샷 저장소블록 저장소를 모두 배포하는 경우 Ops Manager가 백업에 사용할 스냅샷 중 하나를 무작위로 선택합니다.

S3 스냅샷 저장소를 구성하려면 다음 설정을 구성합니다.

유형
설명
예제
spec
.backup
.s3Stores
문자열
S3 스냅샷 저장소의 이름입니다.
s3store1
spec
.backup
.s3Stores
.s3SecretRef
문자열
accessKeysecretKey 필드가 포함된 시크릿의 이름입니다. 백업 데몬 서비스 는 이러한 필드의 값을 자격 증명으로 사용하여 S3 또는 S3호환 버킷에 액세스합니다.
my-s3-credentials
spec
.backup
.s3Stores
문자열
데이터베이스 백업 스냅샷을 저장 하는 S3 또는 S 호환3버킷의 URL입니다.
s3.us-east-1.amazonaws.com
spec
.backup
.s3Stores
문자열
데이터베이스 백업 스냅샷을 저장하는 S3 또는 S3호환 버킷의 이름입니다.
my-bucket
spec
.backup
.s3Stores
문자열
S3호환 버킷이 있는 리전입니다. 이 필드는 S3 매장의 s3BucketEndpoint URL 에 리전이 포함되지 않은 경우에만 사용합니다. 이 필드를 AWS S3 버킷과 함께 사용하지 마세요.
us-east-1

블록 저장소를 구성하려면 다음 설정을 구성합니다.

유형
설명
예제
spec
.backup
.blockStores
문자열
블록 저장소의 이름입니다.
blockStore1
spec
.backup
.blockStores
.mongodbResourceRef
문자열
블록 저장소에 대해 생성하는 MongoDB 리소스의 이름입니다. 이 데이터베이스 리소스는 Ops Manager 리소스와 동일한 네임스페이스에 배포해야 합니다. 리소스의 metadata.name 이(가) 이 이름과 일치해야 합니다.
my-mongodb-blockstore
6

배포에 적용하려는 백업에 대한 선택적 설정 을 객체 에 추가합니다. 사양 파일. 예를 들어, 각 백업 저장소 유형 및 Ops Manager 백업 데몬 프로세스의 경우 레이블을 할당하여 특정 백업 저장소 또는 백업 데몬 프로세스를 특정 프로젝트와 연결할 spec.backup.[*].assignmentLabels 수 있습니다. OpsManager 리소스의 요소를 사용합니다.

7

배포에 적용할 선택적 설정 을 객체 에 추가합니다. 사양 파일.

8
9

Ops Manager 리소스 정의의 파일 이름에 대해 다음 kubectl 명령을 실행합니다.

kubectl apply -f <opsmgr-resource>.yaml

참고

다중 Kubernetes 클러스터 MongoDB 배포에 Ops Manager 리소스를 배포하는 경우 다음을 실행합니다.

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-enterprise-kubernetes/master/samples/ops-manager/ops-manager-external.yaml
10

Ops Manager 리소스의 상태를 확인하려면 다음 명령을 호출합니다.

kubectl get om -o yaml -w

이 명령은 리소스가 배포되는 동안 status 필드 아래에 다음과 유사한 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2023-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

Kubernetes Operator는 다음 순서로 리소스를 조정합니다.

  1. 애플리케이션 데이터베이스.

  2. Ops Manager.

  3. 백업.

Kubernetes 연산자는 이전 리소스가 Running 단계에 들어갈 때까지 리소스를 조정하지 않습니다.

MongoDB Ops Manager 리소스가 Pending 단계를 완료한 후 백업을 활성화한 경우 명령은 status 필드 아래에 다음과 유사한 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2023-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "6.0.17"

백업은 데이터베이스 백업을 구성할 때까지 Pending 상태로 유지됩니다.

status.opsManager.url 필드에는 리소스의 연결 URL 이 명시되어 있습니다. 이 URL 을 사용하면 Kubernetes 클러스터 내에서 Ops Manager에 연결하거나 ConfigMap을 사용하여 프로젝트를 만들 수 있습니다.

11

취하는 단계는 Kubernetes의 Ops Manager 애플리케이션으로 트래픽을 라우팅하는 방법에 따라 다릅니다. Kubernetes 서비스를 생성하도록 Kubernetes 연산자를 구성했거나 Kubernetes 서비스를 수동으로 생성한 경우, 다음 방법 중 하나를 사용하여 Ops Manager 애플리케이션에 액세스합니다.

  1. 클라우드 제공자를 쿼리하여 로드 밸런서 서비스의 FQDN 을 가져옵니다. 자세한 내용은 클라우드 제공자의 설명서를 참조하세요.

  2. 브라우저 창을 열고 로드 밸런서 서비스의 FQDN 및 포트 번호를 사용하여 Ops Manager 애플리케이션으로 이동합니다.

    http://ops.example.com:8080
  3. 관리자 사용자 자격 증명을 사용하여 Ops Manager에 로그인합니다.

  1. 방화벽 규칙을 설정하여 인터넷에서 Kubernetes 클러스터가 실행 중인 호스트의 spec.externalConnectivity.port 에 액세스할 수 있도록 합니다.

  2. 브라우저 창을 열고 FQDNspec.externalConnectivity.port 를 사용하여 Ops Manager 애플리케이션으로 이동합니다.

    http://ops.example.com:30036
  3. 관리자 사용자 자격 증명을 사용하여 Ops Manager에 로그인합니다.

타사 서비스를 사용하여 Ops Manager 애플리케이션에 액세스하는 방법을 알아보려면 해당 솔루션의 설명서를 참조하세요.

12

백업을 활성화한 경우 Ops Manager 조직을 만들고, 프로그래밍 방식 API 키를 생성하고, secret-storage-tool 에 시크릿을 생성해야 합니다. 이러한 활동 은 Kubernetes 연산자에 대한 자격 증명 생성 페이지의 전제 조건 및 절차를 따릅니다.

13

백업을 활성화 한 경우 ConfigMap을 사용하여 프로젝트 하나 생성 페이지의 전제 조건 및 절차에 따라 프로젝트를 생성합니다.

ConfigMap에서 data.baseUrl 를 Ops Manager 애플리케이션의 URL 로 설정해야 합니다. 이 URL 을 찾으려면 다음 명령을 호출합니다.

kubectl get om -o yaml -w

이 명령은 다음 예와 유사하게 status.opsManager.url 필드에 Ops Manager 애플리케이션의 URL을 반환합니다.

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "6.0.17"

중요

Kubernetes Operator와 함께 운영 관리자를 배포하고 운영 관리자가 배포된 Kubernetes 클러스터 외부에 배포된 MongoDB 데이터베이스 리소스를 관리하는 경우, data.baseUrl 을 운영 관리자 리소스 사양의 spec.configuration.mms.centralUrl 설정과 동일한 값으로 설정해야 합니다.

다음도 참조하세요.

14

백업 MongoDB database oplog 을 활성화한 경우, 및 스냅샷 저장소에 대한 리소스를 생성하여 구성을 완료합니다.

  1. Ops Manager 리소스와 동일한 네임스페이스에 oplog 저장소에 대한 MongoDB database 리소스 를 배포합니다.

    참고

    이 데이터베이스를 복제본 세트로 생성합니다.

    리소스의 metadata.name 를 Ops Manager 리소스 정의에 지정한 spec.backup.opLogStores.mongodbResourceRef.name 과 일치시킵니다.

  2. 다음 중 하나를 선택 합니다.

    1. MongoDB Ops Manager 리소스와 동일한 네임스페이스에 블록 저장소에 대한 MongoDB database 리소스 를 배포합니다.

      리소스의 metadata.name 를 Ops Manager 리소스 정의에 지정한 spec.backup.blockStores.mongodbResourceRef.name 과 일치시킵니다.

    2. S3 스냅샷 3 저장소로 사용할 S 버킷을 구성합니다.

      Ops Manager 리소스 정의에 지정한 세부 정보를 사용하여 S3 버킷에 액세스할 수 있는지 확인합니다.

15

백업을 활성화한 경우 다음 명령을 호출하여 Ops Manager 리소스의 상태를 확인합니다.

kubectl get om -o yaml -w

Ops Manager가 실행 중일 때 이 명령은 status 필드 아래에 다음 출력을 반환합니다.

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "6.0.5-ubi8"
backup:
lastTransition: "2022-04-01T10:00:53Z"
phase: Running
version: "6.0.5-ubi8"
opsManager:
lastTransition: "2022-04-01T10:00:34Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "6.0.17"

리소스 배포 상태에 대한 자세한 내용은 Kubernetes 연산자 문제 해결을 참조하세요.

이 페이지의 내용