Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

Trident Protect 실행 후크 관리

기여자 netapp-aruldeepa

실행 후크는 관리되는 앱의 데이터 보호 작업과 함께 실행되도록 구성할 수 있는 사용자 지정 작업입니다. 예를 들어, 데이터베이스 앱이 있는 경우 실행 후크를 사용하여 스냅샷 전에 모든 데이터베이스 트랜잭션을 일시 중지하고 스냅샷이 완료된 후 트랜잭션을 다시 시작할 수 있습니다. 이를 통해 애플리케이션과 일관된 스냅샷이 보장됩니다.

실행 후크의 유형

Trident Protect는 실행 가능 시기에 따라 다음 유형의 실행 후크를 지원합니다.

  • 사전 스냅샷

  • 스냅샷 이후

  • 사전 백업

  • 백업 후

  • 복원 후

  • 장애 조치 후

실행 순서

데이터 보호 작업이 실행되면 실행 후크 이벤트는 다음 순서로 발생합니다.

  1. 적용 가능한 사용자 정의 사전 작업 실행 후크는 해당 컨테이너에서 실행됩니다. 필요한 만큼 사용자 정의 사전 작업 후크를 만들고 실행할 수 있지만, 작업 전에 이러한 후크를 실행하는 순서는 보장되지 않으며 구성할 수도 없습니다.

  2. 해당되는 경우 파일 시스템이 정지됩니다. "Trident Protect를 사용하여 파일 시스템 동결을 구성하는 방법에 대해 자세히 알아보세요.".

  3. 데이터 보호 작업이 수행됩니다.

  4. 해당되는 경우 동결된 파일 시스템이 동결 해제됩니다.

  5. 적용 가능한 모든 사용자 정의 사후 작업 실행 후크는 해당 컨테이너에서 실행됩니다. 필요한 만큼 사용자 정의 사후 작업 후크를 만들고 실행할 수 있지만, 작업 후 이러한 후크의 실행 순서는 보장되지 않으며 구성할 수도 없습니다.

동일한 유형의 실행 후크를 여러 개 생성하는 경우(예: 사전 스냅샷), 해당 후크의 실행 순서는 보장되지 않습니다. 하지만 서로 다른 유형의 후크 실행 순서는 보장됩니다. 예를 들어, 다양한 유형의 후크를 모두 포함하는 구성을 실행하는 순서는 다음과 같습니다.

  1. 스냅샷 전 후크 실행됨

  2. 스냅샷 후 후크 실행됨

  3. 사전 백업 후크 실행됨

  4. 백업 후 후크 실행됨

참고 이전 주문 예시는 기존 스냅샷을 사용하지 않는 백업을 실행할 때만 적용됩니다.
참고 프로덕션 환경에서 실행 후크 스크립트를 활성화하기 전에 항상 테스트해야 합니다. 'kubectl exec' 명령을 사용하면 편리하게 스크립트를 테스트할 수 있습니다. 프로덕션 환경에서 실행 후크를 활성화한 후 결과 스냅샷과 백업을 테스트하여 일관성이 있는지 확인하세요. 앱을 임시 네임스페이스에 복제하고 스냅샷이나 백업을 복원한 다음 앱을 테스트하면 됩니다.
참고 스냅샷 이전 실행 후크가 Kubernetes 리소스를 추가, 변경 또는 제거하는 경우 해당 변경 사항은 스냅샷이나 백업 및 이후의 모든 복원 작업에 포함됩니다.

사용자 정의 실행 후크에 대한 중요 참고 사항

앱의 실행 후크를 계획할 때 다음 사항을 고려하세요.

  • 실행 후크는 스크립트를 사용하여 작업을 수행해야 합니다. 여러 개의 실행 후크가 동일한 스크립트를 참조할 수 있습니다.

  • Trident Protect에서는 실행 후크가 사용하는 스크립트가 실행 가능한 셸 스크립트 형식으로 작성되어야 합니다.

  • 스크립트 크기는 96KB로 제한됩니다.

  • Trident Protect는 실행 후크 설정과 일치 기준을 사용하여 스냅샷, 백업 또는 복원 작업에 적용할 수 있는 후크를 결정합니다.

참고 실행 후크는 종종 실행 중인 애플리케이션의 기능을 감소시키거나 완전히 비활성화하기 때문에 사용자 정의 실행 후크가 실행되는 데 걸리는 시간을 최소화하려고 항상 노력해야 합니다. 연관된 실행 후크로 백업 또는 스냅샷 작업을 시작한 후 취소하더라도 백업 또는 스냅샷 작업이 이미 시작된 경우 후크는 계속 실행될 수 있습니다. 즉, 백업 후 실행 후크에 사용된 로직은 백업이 완료되었다고 가정할 수 없습니다.

실행 후크 필터

애플리케이션에 대한 실행 후크를 추가하거나 편집할 때 실행 후크에 필터를 추가하여 후크가 일치할 컨테이너를 관리할 수 있습니다. 필터는 모든 컨테이너에서 동일한 컨테이너 이미지를 사용하지만 각 이미지를 다른 목적으로 사용할 수 있는 애플리케이션(예: Elasticsearch)에 유용합니다. 필터를 사용하면 실행 후크가 일부 컨테이너에서만 실행되는 시나리오를 만들 수 있지만 반드시 모든 컨테이너에서 실행되는 것은 아닙니다. 단일 실행 후크에 대해 여러 필터를 만드는 경우 논리적 AND 연산자를 사용하여 결합됩니다. 실행 후크당 최대 10개의 활성 필터를 가질 수 있습니다.

실행 후크에 추가하는 각 필터는 정규 표현식을 사용하여 클러스터의 컨테이너와 일치시킵니다. 후크가 컨테이너와 일치하면 후크는 해당 컨테이너에서 연관된 스크립트를 실행합니다. 필터에 대한 정규 표현식은 RE2(Regular Expression 2) 구문을 사용하는데, 이 구문은 일치 항목 목록에서 컨테이너를 제외하는 필터를 만드는 것을 지원하지 않습니다. Trident protect가 실행 후크 필터의 정규 표현식에 대해 지원하는 구문에 대한 정보는 다음을 참조하세요. "정규 표현식 2(RE2) 구문 지원" .

참고 복원 또는 복제 작업 후에 실행되는 실행 후크에 네임스페이스 필터를 추가하고 복원 또는 복제 소스와 대상이 다른 네임스페이스에 있는 경우, 네임스페이스 필터는 대상 네임스페이스에만 적용됩니다.

실행 후크 예제

방문하세요 "NetApp Verda GitHub 프로젝트" Apache Cassandra 및 Elasticsearch와 같은 인기 있는 앱에 대한 실제 실행 후크를 다운로드합니다. 또한 사용자 정의 실행 후크를 구성하는 데 필요한 예제를 보고 아이디어를 얻을 수 있습니다.

실행 후크 만들기

Trident protect를 사용하여 앱에 대한 사용자 정의 실행 후크를 만들 수 있습니다. 실행 후크를 생성하려면 소유자, 관리자 또는 멤버 권한이 필요합니다.

CR을 사용하세요
단계
  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다. trident-protect-hook.yaml .

  2. Trident Protect 환경 및 클러스터 구성과 일치하도록 다음 속성을 구성하세요.

    • metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 사용자 환경에 맞게 고유하고 적절한 이름을 선택하세요.

    • spec.applicationRef: (필수) 실행 후크를 실행할 애플리케이션의 Kubernetes 이름입니다.

    • spec.stage: (필수) 실행 후크가 동작 중 어느 단계에서 실행되어야 하는지를 나타내는 문자열입니다. 가능한 값:

      • 사전

      • 우편

    • spec.action: (필수) 지정된 실행 후크 필터가 모두 일치한다고 가정할 때 실행 후크가 수행할 작업을 나타내는 문자열입니다. 가능한 값:

      • 스냅샷

      • 지원

      • 복원하다

      • 장애 조치

    • spec.enabled: (선택 사항) 이 실행 후크가 활성화되어 있는지 비활성화되어 있는지를 나타냅니다. 지정하지 않으면 기본값은 true입니다.

    • spec.hookSource: (필수) base64로 인코딩된 후크 스크립트가 포함된 문자열입니다.

    • spec.timeout: (선택 사항) 실행 후크가 실행될 수 있는 시간을 분 단위로 정의하는 숫자입니다. 최소값은 1분이며, 지정하지 않으면 기본값은 25분입니다.

    • spec.arguments: (선택 사항) 실행 후크에 지정할 수 있는 인수의 YAML 목록입니다.

    • spec.matchingCriteria: (선택 사항) 조건 키 값 쌍의 선택적 목록으로, 각 쌍은 실행 후크 필터를 구성합니다. 실행 후크당 최대 10개의 필터를 추가할 수 있습니다.

    • spec.matchingCriteria.type: (선택 사항) 실행 후크 필터 유형을 식별하는 문자열입니다. 가능한 값:

      • 컨테이너이미지

      • 컨테이너 이름

      • 포드이름

      • 포드레이블

      • 네임스페이스 이름

    • spec.matchingCriteria.value: (선택 사항) 실행 후크 필터 값을 식별하는 문자열 또는 정규 표현식입니다.

      YAML 예시:

    apiVersion: protect.trident.netapp.io/v1
    kind: ExecHook
    metadata:
      name: example-hook-cr
      namespace: my-app-namespace
      annotations:
        astra.netapp.io/astra-control-hook-source-id: /account/test/hookSource/id
    spec:
      applicationRef: my-app-name
      stage: Pre
      action: Snapshot
      enabled: true
      hookSource: IyEvYmluL2Jhc2gKZWNobyAiZXhhbXBsZSBzY3JpcHQiCg==
      timeout: 10
      arguments:
        - FirstExampleArg
        - SecondExampleArg
      matchingCriteria:
        - type: containerName
          value: mysql
        - type: containerImage
          value: bitnami/mysql
        - type: podName
          value: mysql
        - type: namespaceName
          value: mysql-a
        - type: podLabel
          value: app.kubernetes.io/component=primary
        - type: podLabel
          value: helm.sh/chart=mysql-10.1.0
        - type: podLabel
          value: deployment-type=production
  3. CR 파일에 올바른 값을 채운 후 CR을 적용합니다.

    kubectl apply -f trident-protect-hook.yaml
CLI를 사용하세요
단계
  1. 괄호 안의 값을 환경의 정보로 바꿔서 실행 후크를 만듭니다. 예를 들어:

    tridentctl-protect create exechook <my_exec_hook_name> --action <action_type> --app <app_to_use_hook> --stage <pre_or_post_stage> --source-file <script-file> -n <application_namespace>

수동으로 실행 후크 실행

테스트 목적으로 실행 후크를 수동으로 실행할 수 있으며, 실패 후 후크를 수동으로 다시 실행해야 하는 경우에도 사용할 수 있습니다. 실행 후크를 수동으로 실행하려면 소유자, 관리자 또는 멤버 권한이 필요합니다.

실행 후크를 수동으로 실행하는 것은 두 가지 기본 단계로 구성됩니다.

  1. 리소스를 수집하고 백업을 생성하여 후크가 실행될 위치를 결정하는 리소스 백업을 생성합니다.

  2. 백업에 대해 실행 후크를 실행합니다.

1단계: 리소스 백업 만들기
CR을 사용하세요
단계
  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다. trident-protect-resource-backup.yaml .

  2. Trident Protect 환경 및 클러스터 구성과 일치하도록 다음 속성을 구성하세요.

    • metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 사용자 환경에 맞게 고유하고 적절한 이름을 선택하세요.

    • spec.applicationRef: (필수) 리소스 백업을 생성할 애플리케이션의 Kubernetes 이름입니다.

    • spec.appVaultRef: (필수) 백업 내용이 저장된 AppVault의 이름입니다.

    • spec.appArchivePath: 백업 내용이 저장되는 AppVault 내부 경로입니다. 다음 명령을 사용하여 이 경로를 찾을 수 있습니다.

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'

      YAML 예시:

    ---
    apiVersion: protect.trident.netapp.io/v1
    kind: ResourceBackup
    metadata:
      name: example-resource-backup
    spec:
      applicationRef: my-app-name
      appVaultRef: my-appvault-name
      appArchivePath: example-resource-backup
  3. CR 파일에 올바른 값을 채운 후 CR을 적용합니다.

    kubectl apply -f trident-protect-resource-backup.yaml
CLI를 사용하세요
단계
  1. 괄호 안의 값을 사용자 환경의 정보로 바꿔 백업을 만듭니다. 예를 들어:

    tridentctl protect create resourcebackup <my_backup_name> --app <my_app_name> --appvault <my_appvault_name> -n <my_app_namespace> --app-archive-path <app_archive_path>
  2. 백업 상태를 확인합니다. 작업이 완료될 때까지 이 예제 명령을 반복해서 사용할 수 있습니다.

    tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name>
  3. 백업이 성공했는지 확인하세요.

    kubectl describe resourcebackup <my_backup_name>
2단계: 실행 후크 실행
CR을 사용하세요
단계
  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다. trident-protect-hook-run.yaml .

  2. Trident Protect 환경 및 클러스터 구성과 일치하도록 다음 속성을 구성하세요.

    • metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 사용자 환경에 맞게 고유하고 적절한 이름을 선택하세요.

    • spec.applicationRef: (필수) 이 값이 1단계에서 만든 ResourceBackup CR의 애플리케이션 이름과 일치하는지 확인하세요.

    • spec.appVaultRef: (필수) 이 값이 1단계에서 생성한 ResourceBackup CR의 appVaultRef와 일치하는지 확인하세요.

    • spec.appArchivePath: 이 값이 1단계에서 만든 ResourceBackup CR의 appArchivePath와 일치하는지 확인합니다.

      kubectl get backups <BACKUP_NAME> -n my-app-namespace -o jsonpath='{.status.appArchivePath}'
    • spec.action: (필수) 지정된 실행 후크 필터가 모두 일치한다고 가정할 때 실행 후크가 수행할 작업을 나타내는 문자열입니다. 가능한 값:

      • 스냅샷

      • 지원

      • 복원하다

      • 장애 조치

    • spec.stage: (필수) 실행 후크가 동작 중 어느 단계에서 실행되어야 하는지를 나타내는 문자열입니다. 이 후크 실행은 다른 단계에서 후크를 실행하지 않습니다. 가능한 값:

      • 사전

      • 우편

        YAML 예시:

    ---
    apiVersion: protect.trident.netapp.io/v1
    kind: ExecHooksRun
    metadata:
      name: example-hook-run
    spec:
      applicationRef: my-app-name
      appVaultRef: my-appvault-name
      appArchivePath: example-resource-backup
      stage: Post
      action: Failover
  3. CR 파일에 올바른 값을 채운 후 CR을 적용합니다.

    kubectl apply -f trident-protect-hook-run.yaml
CLI를 사용하세요
단계
  1. 수동 실행 후크 실행 요청을 만듭니다.

    tridentctl protect create exechooksrun <my_exec_hook_run_name> -n <my_app_namespace> --action snapshot --stage <pre_or_post> --app <my_app_name> --appvault <my_appvault_name> --path <my_backup_name>
  2. 실행 후크 실행 상태를 확인합니다. 작업이 완료될 때까지 이 명령을 반복해서 실행할 수 있습니다.

    tridentctl protect get exechooksrun -n <my_app_namespace> <my_exec_hook_run_name>
  3. 최종 세부 정보와 상태를 확인하려면 exechooksrun 객체를 설명합니다.

    kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>