문서 메뉴
문서 홈
/
MongoDB Enterprise Kubernetes 연산자
/
Ops Manager 배포 리소스

로컬 모드를 사용하도록 Ops Manager 리소스 구성

이 페이지의 내용

  • 전제 조건
  • 절차
  • 네임스페이스로 기본 설정하도록 kubectl 을 구성합니다.
  • StatefulSet 삭제 MongoDB Ops Manager 파드를 관리합니다.
  • 이 Ops Manager 리소스의 필드를 복사합니다.
  • 복사한 예시 섹션을 기존 Ops Manager 리소스에 붙여넣습니다.
  • Ops Manager 구성 파일을 저장합니다.
  • Ops Manager 배포에 변경 사항을 적용합니다.
  • 순차적으로 이전 Ops Manager Pod를 삭제합니다.
  • Ops Manager 인스턴스의 상태를 추적합니다.
  • MongoDB 설치 아카이브를 로컬 시스템에 다운로드합니다.
  • MongoDB 아카이브를 Ops Manager 영구 볼륨에 복사합니다.
  • MongoDB database 리소스를 배포합니다.

중요

Kubernetes에서 로컬 모드를 사용하도록 Ops Manager를 구성하는 것은 권장되지 않습니다. 대신원격 모드를 사용하도록 Ops Manager를 구성하는 것이 좋습니다.

기본 구성에서 MongoDB Agent와 백업 데몬은 인터넷을 통해 MongoDB, Inc.에서 MongoDB 설치 아카이브에 액세스합니다.

클러스터의 노드가 인터넷에 액세스할 수 없는 경우 Operator를 사용하여 로컬 모드 에서 실행되도록 MongoDB Ops Manager를 구성할 수 있습니다.Kubernetes Kubernetes 백업 데몬 및 관리되는 리소스는 MongoDB 영구 볼륨 에서만 설치 아카이브를 다운로드합니다. MongoDB Ops Manager StatefulSet에 대해 생성합니다.

이 절차에서는 Ops Manager에 설치 아카이브 업로드에 대해 설명합니다.

Ops Manager에서 인터넷에 액세스할 수 없는 경우 Configure Deployment to Have Limited Internet Access(인터넷 액세스가 제한되도록 배포서버 구성하기)를 참조하세요.

호환성에 대해서는 MongoDB Enterprise Kubernetes Operator 호환성 을 참조하십시오. 각 이미지에 사용 가능한 모든 버전을 보려면 container 이미지를 참조하세요.

전제 조건

  • MongoDB Ops Manager 리소스를 배포합니다. 다음 절차는 MongoDB Ops Manager Kubernetes 객체 를 업데이트하는 방법을 보여줍니다. 로컬 모드를 활성화합니다.

  • 로컬 모드를 활성화할 때 다운타임을 방지하려면 Ops Manager 리소스 정의에서 spec.replicas 를 1 보다 큰 값으로 설정해야 합니다.

    Ops Manager의 가용성을 높이기 위해 Ops Manager 리소스 정의를 업데이트한 경우 이 튜토리얼을 시작하기 전에 변경 사항을 적용하세요.

    kubectl apply -f <opsmgr-resource>.yaml -n <metadata.namespace>

절차

1

를 네임스페이스를 기본값으로 kubectl 구성합니다.

아직 실행하지 않았다면 다음 명령을 실행하여 생성한 네임스페이스에서 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

StatefulSet 삭제 Ops Manager Pods를 관리합니다.

이 튜토리얼에서는 Kubernetes cluster에서 Ops Manager 파드를 managed하는 StatefulSet를 업데이트합니다.

Kubernetes가 로컬 모드에 필요한 업데이트를 적용할 수 있도록 먼저 Ops Manager StatefulSet를 삭제해야 합니다.

  1. Ops Manager StatefulSet의 이름을 찾습니다.

    kubectl get statefulsets

    다음 항목의 metadata.name 와(과) 일치하는 응답의 항목입니다.

    Ops Manager StatefulSet는 Ops Manager 리소스 정의의 metadata.name 와 일치하는 응답의 항목입니다.

    kubectl get statefulsets -n mongodb
    NAME                       READY   AGE
    ops-manager-localmode      2/2     2m31s
    ops-manager-localmode-db   3/3     4m46s

  2. Ops Manager StatefulSet를 삭제합니다.

    경고

    Ops Manager StatefulSet를 삭제할 때 --cascade=false 플래그를 포함해야 합니다. 이 플래그를 포함하지 않으면 Kubernetes는 Ops Manager Pod도 삭제합니다.

    kubectl delete statefulset --cascade=false <ops-manager-statefulset>
3

이 Ops Manager 리소스의 필드를 복사합니다.

이 예제의 9~31줄을 다음 위치에 복사합니다.

  • spec.configuration 에서 MongoDB Ops Manager 구성 설정 automation.versions.source: local 을(를) 사용하여 로컬 모드를 활성화합니다.

  • 영구 볼륨 정의 Ops Manager StatefulSet가 MongoDB 설치 아카이브를 저장합니다. Kubernetes Operator로 생성한 MongoDB 데이터베이스 리소스 컨테이너에서 실행 중인 MongoDB Agent는 인터넷이 아닌 Ops Manager에서 설치 아카이브를 다운로드합니다.

1apiVersion: mongodb.com/v1
2kind: MongoDBOpsManager
3metadata:
4 name: ops-manager-localmode
5spec:
6 replicas: 2
7 version: "6.0.0"
8 adminCredentials: ops-manager-admin-secret
9 configuration:
10   # this enables local mode in Ops Manager
11   automation.versions.source: local
12 statefulSet:
13   spec:
14     # the Persistent Volume Claim will be created for each Ops Manager Pod
15     volumeClaimTemplates:
16      - metadata:
17          name: mongodb-versions
18        spec:
19          accessModes: [ "ReadWriteOnce" ]
20          resources:
21            requests:
22              storage: "20Gi"
23     template:
24       spec:
25         containers:
26           - name: mongodb-ops-manager
27             volumeMounts:
28             - name: mongodb-versions
29               # this is the directory in each Pod where all MongoDB
30               # archives must be put
31               mountPath: /mongodb-ops-manager/mongodb-releases
32 backup:
33  enabled: false
34 applicationDatabase:
35  members: 3
4

복사한 예시 섹션을 기존 Ops Manager 리소스에 붙여넣습니다.

원하는 텍스트 편집기를 열고 객체 를 붙여넣습니다. 사양을 리소스 파일의 적절한 위치에 추가합니다.

5

Ops Manager 구성 파일을 저장합니다.

6

Ops Manager 배포에 변경 사항을 적용합니다.

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

    kubectl apply -f <opsmgr-resource>.yaml

  2. Kubernetes는 Ops Manager 리소스 정의에 변경 사항을 적용할 때 새 Ops Manager StatefulSet를 생성합니다. 다음 단계로 진행하기 전에 다음 명령을 실행하여 Ops Manager StatefulSet가 존재하는지 확인하세요.

    kubectl get statefulsets

    새로운 Ops Manager StatefulSet에는 0 멤버가 준비 상태로 표시되어야 합니다.

    kubectl get statefulsets -n mongodb
    NAME                       READY   AGE         ops-manager-localmode      0/2     2m31s
    ops-manager-localmode-db   3/3     4m46s
7

순차적으로 이전 Ops Manager Pod를 삭제합니다.

  1. Kubernetes cluster의 Ops Manager Pod를 나열합니다.

    kubectl get pods

  2. Ops Manager Pod 한 개를 삭제합니다.

    kubectl delete pod <om-pod-0>

  3. Kubernetes는 삭제한 Ops Manager Pod를 다시 생성합니다. 준비가 될 때까지 새 Pod의 상태를 계속 가져옵니다.

    kubectl get pods

    새 Pod가 초기화 중일 때 출력은 다음 예시와 유사합니다.

    NAME                                          READY   STATUS    RESTARTS   AGE
    mongodb-enterprise-operator-5648d4c86-k5brh   1/1     Running   0          5m24s
    ops-manager-localmode-0                       0/1     Running   0          0m55s
    ops-manager-localmode-1                       1/1     Running   0          5m45s
    ops-manager-localmode-db-0                    1/1     Running   0          5m19s
    ops-manager-localmode-db-1                    1/1     Running   0          4m54s
    ops-manager-localmode-db-2                    1/1     Running   0          4m12s

    새 Pod가 준비되면 출력은 다음 예시와 유사합니다.

    NAME                                          READY   STATUS    RESTARTS   AGE
    mongodb-enterprise-operator-5648d4c86-k5brh   1/1     Running   0          5m24s
    ops-manager-localmode-0                       1/1     Running   0          3m55s
    ops-manager-localmode-1                       1/1     Running   0          5m45s
    ops-manager-localmode-db-0                    1/1     Running   0          5m19s
    ops-manager-localmode-db-1                    1/1     Running   0          4m54s
    ops-manager-localmode-db-2                    1/1     Running   0          4m12s

  4. 모든 Ops Manager Pod를 삭제하고 모든 새 Pod가 준비되었는지 확인할 때까지 b , c 단계를 반복합니다.

8

Ops Manager 인스턴스의 상태를 추적합니다.

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

kubectl get om -o yaml -w

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

Ops Manager 리소스가 Pending 단계를 완료한 후 이 명령은 다음과 유사한 출력을 반환합니다.

1status:
2  applicationDatabase:
3    lastTransition: "2020-05-15T16:20:22Z"
4    members: 3
5    phase: Running
6    type: ReplicaSet
7    version: "4.4.5-ubi8"
8  backup:
9    phase: ""
10  opsManager:
11    lastTransition: "2020-05-15T16:20:26Z"
12    phase: Running
13    replicas: 1
14    url: http://ops-manager-localmode-svc.mongodb.svc.cluster.local:8080
15    version: "6.0.0"

리소스의 연결 URL 을 나타내는 status.opsManager.url 필드의 값을 복사합니다. ConfigMap 을 만들 때 이 값을 사용합니다. 단계의 뒷부분에 있습니다.

9

MongoDB 설치 아카이브를 로컬 시스템에 다운로드합니다.

다운로드하는 설치 프로그램은 연산자를 배포한 환경에 따라 다릅니다.

참고

다음 예제에는 지정된 버전의 MongoDB Community Edition을 다운로드할 수 있는 링크가 포함되어 있습니다. 다른 버전의 MongoDB Community Edition을 다운로드하려면 MongoDB Community Edition 다운로드 센터 를 방문하세요. MongoDB Enterprise 를 다운로드하려면 MongoDB Enterprise 다운로드 센터를 방문하세요.

Kubernetes 연산자가 배포하려는 MongoDB Server 버전에 대한 RHEL 설치 tarball을 다운로드합니다. 예를 들어 6.0.1 릴리스를 다운로드하려면 다음을 수행합니다.

curl -OL https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel80-6.0.1.tgz
10

MongoDB 아카이브를 Ops Manager 영구 볼륨에 복사합니다.

배포하려는 각 MongoDB 버전에 대한 MongoDB 아카이브를 Ops Manager 영구 볼륨에 복사합니다.

사용하는 명령은 Kubernetes 연산자를 배포한 환경에 따라 다릅니다.

참고

Ops Manager replica 를 두 개 이상 배포한 경우 MongoDB 설치 tarball 패키지만 Replica 1 이상에 복사합니다.

MongoDB 설치 아카이브를 Ops Manager PersistentVolume에 복사하려면 다음을 수행합니다.

MongoDB Server 설치 tarball을 Ops Manager PersistentVolume에 복사합니다. 예를 들어 6.0.1 릴리스를 복사하려면 다음을 수행합니다.

Replica 0:
kubectl cp mongodb-linux-x86_64-rhel80-6.0.1.tgz \
"ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz"
Replica 1:
kubectl cp mongodb-linux-x86_64-rhel80-6.0.1.tgz \
"ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz"

MongoDB 설치 아카이브를 Ops Manager PersistentVolume에 복사하려면 MongoDB Server 설치 tarball 를 Ops Manager PersistentVolume에 복사합니다. 예를 들어 6.0.1 릴리스를 복사하려면 다음을 수행합니다.

Replica 0:
oc rsync  "ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz" \
mongodb-linux-x86_64-rhel80-6.0.1.tgz
Replica 1:
oc rsync  "ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz" \
mongodb-linux-x86_64-rhel80-6.0.1.tgz
11

MongoDB database 리소스를 배포합니다.

  1. 아직 완료하지 않았다면 다음 전제 조건을 완료하세요.

  2. Ops Manager를 배포한 것과 동일한 네임스페이스에 MongoDB database resource 를 배포합니다. 다음을 확인합니다.

    1. 리소스의 spec.opsManager.configMapRef.name 를 ConfigMap의 metadata.name 와 일치시킵니다.

    2. 리소스의 spec.credentials 을(를) Ops Manager 프로그래밍 방식 API 키 쌍을 포함하여 생성한 시크릿의 이름과 일치시킵니다.

MongoDB Agent는 Kubernetes Operator로 생성한 MongoDB 데이터베이스 리소스 컨테이너에서 실행됩니다. 설치 아카이브를 인터넷에서 다운로드하는 대신 Ops Manager에서 다운로드하세요.