Trident Protect 실행 후크 관리
실행 후크는 관리되는 앱의 데이터 보호 작업과 함께 실행되도록 구성할 수 있는 사용자 지정 작업입니다. 예를 들어, 데이터베이스 앱이 있는 경우 실행 후크를 사용하여 스냅샷 전에 모든 데이터베이스 트랜잭션을 일시 중지하고 스냅샷이 완료된 후 트랜잭션을 다시 시작할 수 있습니다. 이를 통해 애플리케이션과 일관된 스냅샷이 보장됩니다.
실행 후크의 유형
Trident Protect는 실행 가능 시기에 따라 다음 유형의 실행 후크를 지원합니다.
-
사전 스냅샷
-
스냅샷 이후
-
사전 백업
-
백업 후
-
복원 후
-
장애 조치 후
실행 순서
데이터 보호 작업이 실행되면 실행 후크 이벤트는 다음 순서로 발생합니다.
-
적용 가능한 사용자 정의 사전 작업 실행 후크는 해당 컨테이너에서 실행됩니다. 필요한 만큼 사용자 정의 사전 작업 후크를 만들고 실행할 수 있지만, 작업 전에 이러한 후크를 실행하는 순서는 보장되지 않으며 구성할 수도 없습니다.
-
해당되는 경우 파일 시스템이 정지됩니다. "Trident Protect를 사용하여 파일 시스템 동결을 구성하는 방법에 대해 자세히 알아보세요.".
-
데이터 보호 작업이 수행됩니다.
-
해당되는 경우 동결된 파일 시스템이 동결 해제됩니다.
-
적용 가능한 모든 사용자 정의 사후 작업 실행 후크는 해당 컨테이너에서 실행됩니다. 필요한 만큼 사용자 정의 사후 작업 후크를 만들고 실행할 수 있지만, 작업 후 이러한 후크의 실행 순서는 보장되지 않으며 구성할 수도 없습니다.
동일한 유형의 실행 후크를 여러 개 생성하는 경우(예: 사전 스냅샷), 해당 후크의 실행 순서는 보장되지 않습니다. 하지만 서로 다른 유형의 후크 실행 순서는 보장됩니다. 예를 들어, 다양한 유형의 후크를 모두 포함하는 구성을 실행하는 순서는 다음과 같습니다.
-
스냅샷 전 후크 실행됨
-
스냅샷 후 후크 실행됨
-
사전 백업 후크 실행됨
-
백업 후 후크 실행됨
|
|
이전 주문 예시는 기존 스냅샷을 사용하지 않는 백업을 실행할 때만 적용됩니다. |
|
|
프로덕션 환경에서 실행 후크 스크립트를 활성화하기 전에 항상 테스트해야 합니다. '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) 파일을 만들고 이름을 지정합니다.
trident-protect-hook.yaml. -
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 -
-
CR 파일에 올바른 값을 채운 후 CR을 적용합니다.
kubectl apply -f trident-protect-hook.yaml
-
괄호 안의 값을 환경의 정보로 바꿔서 실행 후크를 만듭니다. 예를 들어:
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단계: 리소스 백업 만들기
-
사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다.
trident-protect-resource-backup.yaml. -
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 -
-
CR 파일에 올바른 값을 채운 후 CR을 적용합니다.
kubectl apply -f trident-protect-resource-backup.yaml
-
괄호 안의 값을 사용자 환경의 정보로 바꿔 백업을 만듭니다. 예를 들어:
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> -
백업 상태를 확인합니다. 작업이 완료될 때까지 이 예제 명령을 반복해서 사용할 수 있습니다.
tridentctl protect get resourcebackup -n <my_app_namespace> <my_backup_name> -
백업이 성공했는지 확인하세요.
kubectl describe resourcebackup <my_backup_name>
2단계: 실행 후크 실행
-
사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다.
trident-protect-hook-run.yaml. -
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 -
-
CR 파일에 올바른 값을 채운 후 CR을 적용합니다.
kubectl apply -f trident-protect-hook-run.yaml
-
수동 실행 후크 실행 요청을 만듭니다.
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> -
실행 후크 실행 상태를 확인합니다. 작업이 완료될 때까지 이 명령을 반복해서 실행할 수 있습니다.
tridentctl protect get exechooksrun -n <my_app_namespace> <my_exec_hook_run_name> -
최종 세부 정보와 상태를 확인하려면 exechooksrun 객체를 설명합니다.
kubectl -n <my_app_namespace> describe exechooksrun <my_exec_hook_run_name>