Auto DevOps를 위한 PostgreSQL 업그레이드

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

POSTGRES_ENABLED가 true일 때 Auto DevOps는 애플리케이션을 위해 in-cluster PostgreSQL 데이터베이스를 제공합니다.

프로비저닝된 차트의 버전:

  • GitLab 12.8 및 이전 버전에서 0.7.1입니다.
  • GitLab 12.9 이상에서는 0.7.1부터 8.2.1까지로 설정할 수 있습니다.

GitLab은 사용자들에게 데이터베이스를 더 최근의 PostgreSQL 차트로 마이그레이션할 것을 권장합니다.

이 가이드는 PostgreSQL 데이터베이스를 마이그레이션하는 방법에 대한 지침을 제공하며, 다음을 포함합니다:

  1. 데이터베이스 덤프를 가져오는 것.
  2. 차트의 최신 버전 8.2.1을 사용하여 새 PostgreSQL 데이터베이스를 설치하고 이전 PostgreSQL 설치를 제거하는 것.
  3. 새 PostgreSQL에 데이터베이스 덤프를 복원하는 것.

전제 조건

  1. kubectl을 설치합니다.
  2. kubectl을 사용하여 Kubernetes 클러스터에 액세스할 수 있는지 확인합니다. 이는 Kubernetes 제공업체에 따라 다릅니다.
  3. 다운타임을 준비하세요. 아래 단계에는 애플리케이션을 오프라인으로 전환하여 데이터베이스 덤프가 생성된 후에 클러스터 내 데이터베이스가 수정되지 않도록 하는 것이 포함됩니다.
  4. POSTGRES_ENABLED를 false로 설정하지 않았는지 확인합니다. 이 설정은 기존 채널 1 데이터베이스를 삭제합니다. 자세한 내용은 기존 PostgreSQL 데이터베이스 감지함을 확인하세요.
note
자동 DevOps를 스테이징으로 구성한 경우, 먼저 백업 및 복원 단계를 스테이징에서 시도해 보거나 리뷰 앱에서 시도해 보세요.

애플리케이션 오프라인으로 전환

필요한 경우, 데이터베이스 덤프를 생성한 후 데이터베이스의 수정을 방지하기 위해 애플리케이션을 오프라인으로 전환하세요.

  1. 환경에 대한 Kubernetes 네임스페이스를 가져옵니다. 일반적으로 <프로젝트명>-<프로젝트ID>-<환경>와 같은 형식입니다. 예를 들어, 네임스페이스는 minimal-ruby-app-4349298-production이라고 가정합니다. 

    $ kubectl get ns
   
NAME                                                  STATUS   AGE
minimal-ruby-app-4349298-production                   Active   7d14h

  2. 사용하기 쉽도록 네임스페이스 이름을 내보냅니다: 

    export APP_NAMESPACE=minimal-ruby-app-4349298-production

  3. 애플리케이션의 배포 이름을 다음 명령어로 가져옵니다. 이 예에서 배포 이름은 production입니다. 

    $ kubectl get deployment --namespace "$APP_NAMESPACE"
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
production            2/2     2            2           7d21h
production-postgres   1/1     1            1           7d21h

  4. 다음 명령어로 배포의 레플리카를 0으로 설정하여 데이터베이스 수정을 방지하세요. 이전 단계에서 배포 이름을 사용합니다 (deployments/<DEPLOYMENT_NAME>). 

    $ kubectl scale --replicas=0 deployments/production --namespace "$APP_NAMESPACE"
deployment.extensions/production scaled

  5. 워커에 대해서도 레플리카를 0으로 설정해야 합니다.

백업

  1. PostgreSQL의 서비스 이름을 가져옵니다. 서비스 이름은 일반적으로 -postgres로 끝납니다. 예를 들어, 서비스 이름은 production-postgres입니다. 

    $ kubectl get svc --namespace "$APP_NAMESPACE"
NAME                     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
production-auto-deploy   ClusterIP   10.30.13.90   <none>        5000/TCP   7d14h
production-postgres      ClusterIP   10.30.4.57    <none>        5432/TCP   7d14h

  2. 다음 명령어로 PostgreSQL의 파드 이름을 가져옵니다. 이 예에서 파드 이름은 production-postgres-5db86568d7-qxlxv입니다. 

    $ kubectl get pod --namespace "$APP_NAMESPACE" -l app=production-postgres
NAME                                   READY   STATUS    RESTARTS   AGE
production-postgres-5db86568d7-qxlxv   1/1     Running   0          7d14h

  3. 다음 명령어로 파드에 연결합니다: 

    kubectl exec -it production-postgres-5db86568d7-qxlxv --namespace "$APP_NAMESPACE" -- bash

  4. 연결되면 다음 몤령어로 덤프 파일을 생성합니다.

    • SERVICE_NAME은 이전 단계에서 얻은 서비스 이름입니다.
    • USERNAME은 PostgreSQL의 구성된 사용자 이름입니다. 기본값은 user입니다.

    • DATABASE_NAME은 보통 환경 이름입니다.

    • 데이터베이스 암호를 요청하면 기본값은 testing-password입니다. 

      ## 형식:
# pg_dump -h SERVICE_NAME -U USERNAME DATABASE_NAME > /tmp/backup.sql
     
pg_dump -h production-postgres -U user production > /tmp/backup.sql

  5. 백업 덤프가 완료되면 Kubernetes exec 프로세스를 Control-D 또는 exit로 종료합니다.

  6. 다음 명령어로 덤프 파일을 다운로드합니다: 

    kubectl cp --namespace "$APP_NAMESPACE" production-postgres-5db86568d7-qxlxv:/tmp/backup.sql backup.sql

지속적인 볼륨 유지

기본적으로 PostgreSQL의 (데이터의 기반이 되는) 지속적인 볼륨은 사용하는 파드 및 파드 클레임이 삭제될 때 Delete로 표시됩니다.

기존 0.7.1 PostgreSQL을 선택하는 경우에는 이전 PostgreSQL이 삭제되어 지속적인 볼륨도 삭제되므로, 8.2.1 PostgreSQL을 선택하는 경우에 중요합니다.

다음 명령어를 사용하여 확인할 수 있습니다: 

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                     STORAGECLASS   REASON   AGE
pvc-0da80c08-5239-11ea-9c8d-42010a8e0096   8Gi        RWO            Delete           Bound    minimal-ruby-app-4349298-staging/staging-postgres         standard                7d22h
pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096   8Gi        RWO            Delete           Bound    minimal-ruby-app-4349298-production/production-postgres   standard                7d22h

이전 0.7.1 PostgreSQL이 삭제되어도 지속적인 볼륨을 유지하려면 Retain으로 보관 정책을 변경할 수 있습니다. 이 예에서는 클레임 이름을 확인하여 볼륨 이름을 찾습니다. minimal-ruby-app-4349298 애플리케이션의 스테이징과 프로덕션에 대한 볼륨을 유지하려면 여기서 볼륨 이름은 pvc-0da80c08-5239-11ea-9c8d-42010a8e0096와 pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096입니다: 

$ kubectl patch pv  pvc-0da80c08-5239-11ea-9c8d-42010a8e0096 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
persistentvolume/pvc-0da80c08-5239-11ea-9c8d-42010a8e0096 patched
$ kubectl patch pv  pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
persistentvolume/pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096 patched
$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                     STORAGECLASS   REASON   AGE
pvc-0da80c08-5239-11ea-9c8d-42010a8e0096   8Gi        RWO            Retain           Bound    minimal-ruby-app-4349298-staging/staging-postgres         standard                7d22h
pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096   8Gi        RWO            Retain           Bound    minimal-ruby-app-4349298-production/production-postgres   standard                7d22h

새 PostgreSQL 설치하기

caution
더 최신 버전의 PostgreSQL을 사용하면 이전 버전인 0.7.1 PostgreSQL이 삭제됩니다. 기존 데이터가 삭제되지 않도록 하려면 지속적인 볼륨을 유지할 수 있습니다.
note
또한 AUTO_DEVOPS_POSTGRES_CHANNEL, AUTO_DEVOPS_POSTGRES_DELETE_V1, POSTGRES_VERSION 변수를 특정 환경에 적용 범위 지정할 수 있습니다. 예를 들어 staging과 같이 특정 환경에 적용할 수 있습니다.
  1. AUTO_DEVOPS_POSTGRES_CHANNEL을 2로 설정합니다. 이렇게 하면 더 최신 버전인 8.2.1 기반의 PostgreSQL을 사용하게 되며, 이전 버전인 0.7.1 기반의 PostgreSQL이 제거됩니다.
  2. AUTO_DEVOPS_POSTGRES_DELETE_V1을 비어있지 않은 값으로 설정합니다. 이 플래그는 데이터베이스의 실수적인 삭제를 방지하는 안전 장치입니다.
  3. POSTGRES_VERSION이 설정되어 있다면, 최소한 9.6.16 이후로 설정되었는지 확인하십시오. 이는 Auto DevOps에서 지원하는 최소한의 PostgreSQL 버전입니다. 또한 사용 가능한 태그 디렉터리도 참조하십시오.
  4. PRODUCTION_REPLICAS를 0으로 설정합니다. 다른 환경의 경우 환경 범위를 사용하여 REPLICAS를 설정합니다.
  5. DB_INITIALIZE 또는 DB_MIGRATE 변수가 설정되어 있는 경우, 변수를 제거하거나 일시적으로 변수 이름을 XDB_INITIALIZE 또는 XDB_MIGRATE로 변경하여 비활성화합니다.
  6. 브랜치에 대해 새 CI 파이프라인을 실행합니다. 이 경우 main에 대해 새 CI 파이프라인을 실행합니다.
  7. 파이프라인이 성공적으로 완료되면 새 PostgreSQL이 설치된 상태로 애플리케이션이 업그레이드됩니다. 이 시점에는 복제본이 없으므로 애플리케이션에 트래픽이 제공되지 않습니다(새로운 데이터가 들어오는 것을 방지하기 위해).

복원

  1. 새 PostgreSQL의 pod 이름을 가져옵니다. 예를 들어, pod 이름이 production-postgresql-0인 경우: 

    $ kubectl get pod --namespace "$APP_NAMESPACE" -l app=postgresql
NAME                      READY   STATUS    RESTARTS   AGE
production-postgresql-0   1/1     Running   0          19m

  2. 백업 단계에서 덤프 파일을 pod로 복사합니다: 

    kubectl cp --namespace "$APP_NAMESPACE" backup.sql production-postgresql-0:/tmp/backup.sql

  3. pods에 연결합니다: 

    kubectl exec -it production-postgresql-0 --namespace "$APP_NAMESPACE" -- bash

  4. pod에 연결된 후, 다음 명령을 실행하여 데이터베이스를 복원합니다.

    • 데이터베이스 암호를 요청받으면, 기본값은 testing-password입니다.
    • USERNAME은 PostgreSQL에 구성된 사용자 이름입니다. 기본값은 user입니다.
    • DATABASE_NAME은 일반적으로 환경 이름입니다. 
    ## 형식은:
# psql -U USERNAME -d DATABASE_NAME < /tmp/backup.sql
   
psql -U user -d production < /tmp/backup.sql

  5. 복원이 완료된 후 데이터가 올바르게 복원되었는지 확인할 수 있습니다. psql을 사용하여 데이터의 정확성을 검사할 수 있습니다.

애플리케이션 복구

데이터베이스가 복원되었음을 확인한 후, 다음 단계를 실행하여 애플리케이션을 복구합니다:

  1. 이전에 제거되거나 비활성화되었던 DB_INITIALIZE와 DB_MIGRATE 변수를 복원합니다.
  2. PRODUCTION_REPLICAS 또는 REPLICAS 변수를 원래 값으로 복원합니다.
  3. 브랜치에 대해 새 CI 파이프라인을 실행합니다. 이 경우 main에 대해 새 CI 파이프라인을 실행합니다. 파이프라인이 성공적으로 완료되면 애플리케이션이 이전과 같이 트래픽을 제공해야 합니다.