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

Astra Control을 사용하여 사후 분석을 용이하게 하고 애플리케이션을 복원합니다

개요

에 있습니다 "첫 번째 사용 사례"또한, NetApp Astra Control Center를 사용하여 Kubernetes에서 애플리케이션을 보호하는 방법을 시연했습니다. 이 섹션에서는 NetApp Astra 툴킷에서 Python SDK를 사용하여 Astra Control을 통해 애플리케이션 백업을 개발 워크플로우에 직접 통합하는 방법을 설명합니다. 이 방식을 사용하면 CI/CD(Continuous Integration and Continuous Deployment) 프로세스 중에 주문형 백업을 자동화하여 개발 및 운영 환경을 보호할 수 있습니다. 이 애플리케이션 정합성 보장 데이터 보호 계층이 CI/CD 파이프라인 및 운영 애플리케이션에 추가되면서 프로세스에 문제가 발생하면 개발 프로세스가 안전해 비즈니스 연속성 모범 사례를 촉진합니다.

기존 워크플로우에서 응용 프로그램을 새 버전으로 업그레이드할 때 오류가 발생한 후 개발 팀은 고객이 제공하는 버그 보고서를 기반으로 실시간으로 문제 해결을 시도합니다. 또는 문제가 처음 발생할 때 팀이 병렬 디버깅 환경에 응용 프로그램을 다시 배포하여 해당 프로세스를 오프라인으로 만들 수 있습니다. 이전 버전에서 운영 환경으로 이전 코드 기반을 재배포하여 응용 프로그램을 작업 순서로 복원할 수 있습니다.

기존 워크플로우

이 방식은 효과가 있지만, IT 팀은 문제가 발생했을 때 손상된 운영 앱의 상태가 운영 환경에 표시된 버전과 일치하는지 확인해야 합니다. 또한 리포지토리에서 코드를 가져와 시스템 이미지를 다시 배포하여 응용 프로그램을 양호한 실행 상태로 복원함으로써 정상 작동이 확인된 빌드를 운영 환경으로 승격하는 데 시간을 소비해야 합니다. 또한 이 시나리오에서는 프로덕션 데이터베이스 자체가 결함 있는 코드로 인해 손상되었는지 여부를 고려하지 않았습니다. 데이터베이스 데이터를 위한 별도의 백업 프로세스가 마련되어 있는 것이 이상적이지만 게시된 응용 프로그램의 상태와 일치한다고 가정해야 합니까? 여기서 Stateful 및 애플리케이션 정합성이 보장되는 백업, 복원 및 클론 생성 시 Astra Control이 제공하는 이점은 그 가치를 실제로 보여 줍니다.

먼저 Astra Control을 사용하여 응용 프로그램의 상태에 대한 사후 분석을 용이하게 할 수 있습니다. 우리는 응용 프로그램 일관성 있는 방식으로 버기 프로덕션 버전을 병렬 테스트 환경에 복제하는 방식으로 이 작업을 수행합니다. 이 환경을 버그에 따라 문제가 발생한 상태로 두고 실시간으로 문제를 해결할 수 있습니다.

또한 Astra Control은 운영 애플리케이션을 마지막 허용 가능한 백업(해당 코드 버전 이전)으로 복원할 수 있는 데이터 이동 없는 복원 기능을 지원합니다. 복원된 버전은 이전에 할당된 수신 IP를 포함하여 응용 프로그램 일관성 및 상태 저장 방식으로 이전 버기 프로덕션 응용 프로그램의 위치를 가정합니다. 따라서 프런트 엔드에 액세스하는 고객은 백업 버전으로의 전환에 대해 알지 못합니다.

사후 작업 흐름

사용 사례 검증을 위한 사전 요구사항

다음 도구 또는 플랫폼이 전제 조건으로 구축 및 구성되었습니다.

  • Red Hat OpenShift Container Platform

  • NetApp ONTAP 시스템에 백엔드가 구성된 OpenShift에 설치된 NetApp Astra Trident

  • NetApp ONTAP 백엔드를 가리키는 기본 스토리지 클래스 구성

  • OpenShift 클러스터에 설치된 NetApp Astra Control Center

  • OpenShift 클러스터가 Astra Control Center에 관리 클러스터로 추가되었습니다.

  • Jenkins가 OpenShift 클러스터에 설치되어 있습니다.

  • 생산 환경에 설치된 Magento 응용 프로그램. 이 활용 사례의 운영 환경은 Red Hat OpenShift 클러스터의 'magento-prod’라는 네임스페이스입니다.

  • 운영 애플리케이션은 Astra Control Center에서 관리합니다.

  • Astra Control로 캡처한 운영 애플리케이션의 정상 작동이 확인된 백업입니다.

파이프라인 복제 및 복원

애플리케이션이 새 버전으로 업그레이드되었다는 점을 고려하면 프로덕션 환경('magento-prod')의 애플리케이션이 업그레이드 후 의도한 대로 작동하지 않습니다. 프런트 엔드 쿼리에서 반환되는 데이터가 요청과 일치하지 않거나 데이터베이스가 실제로 손상되었다고 가정해 보겠습니다. 파이프라인을 클론 복제 및 복원하려면 다음 단계를 완료하십시오.

실패한 앱
  1. Jenkins에 로그인하고 새 항목, 파이프라인을 차례로 클릭하여 파이프라인을 생성합니다.

  2. Jenkinsfile에서 파이프라인을 복사합니다 "여기".

  3. Jenkins 파이프라인 섹션에 파이프라인을 붙여넣은 다음 저장을 클릭합니다.

  4. 운영 환경의 현재 Magento 응용 프로그램 버전, Astra Control Center FQDN, API 토큰, 운영 및 디버그 환경의 인스턴스 ID 및 응용 프로그램 이름 또는 네임스페이스, 소스 및 대상 클러스터 이름과 같은 각 세부 정보로 Jenkins 파이프라인의 매개 변수를 채웁니다. 이 활용 사례를 위해 운영 환경은 'magento-prod’라는 네임스페이스이며, 디버그 환경은 Red Hat OpenShift 클러스터에 구성된 'magento-debug’라는 네임스페이스입니다.

    MAGENTO_VERSION = '2.4.1-debian-10-r14'
    ASTRA_TOOLKIT_VERSION = '2.0.2'
    ASTRA_API_TOKEN = 'xxxxx'
    ASTRA_INSTANCE_ID = 'xxx-xxx-xxx-xxx-xxx'
    ASTRA_FQDN = 'netapp-astra-control-center.org.example.com'
    PROD_APP_NAME = 'magento-prod'
    DEBUG_APP_NAME = 'magento-debug'
    DEBUG_NAMESPACE = 'magento-debug'
    PROD_KUBERNETES_CLUSTER = 'ocp-vmw'
    DEBUG_KUBERNETES_CLUSTER = 'ocp-vmw'
  5. 지금 구축을 클릭합니다. 파이프라인은 실행을 시작하고 단계를 진행합니다. 응용 프로그램은 먼저 현재 상태에서 디버그 환경으로 복제되고 응용 프로그램은 알려진 작업 백업으로 복원됩니다.

    사후 파이프라인
  6. 복제된 응용 프로그램이 버그 포함 버전인지 확인합니다.

    클론 생성된 앱에 실패했습니다
  7. 운영 환경이 작업 중인 백업으로 복원되고 운영 중인 애플리케이션이 예상대로 작동하는지 확인합니다.

    Prod 앱을 복원했습니다

이 두 가지 작업을 함께 수행할 경우 일반 비즈니스 운영으로 더 빠르게 되돌릴 수 있습니다. 이 사용 사례를 실제 작동 중인 경우 비디오를 시청하십시오 "여기".