2.3.5.2. 반복 가능한 프로모션 프로세스


파이프라인에 대한 다양한 스테이징 환경을 설정한 후 반복 가능한 단계 세트를 통해 승격 파이프라인을 통해 애플리케이션의 각 반복을 검증할 수 있습니다. 소스 환경의 이미지 또는 API 오브젝트가 변경될 때마다 이러한 기본 단계가 수행됩니다.

업데이트된 이미지 이동 업데이트된 API 오브젝트 이동 환경별 사용자 정의 적용

  1. 일반적으로 첫 번째 단계는 애플리케이션과 관련된 이미지 업데이트를 파이프라인의 다음 단계로 승격하는 것입니다. 위에서 언급했듯이 이미지 승격의 주요 차이점은 OpenShift Container Platform 레지스트리가 스테이징 환경 간에 공유되는지 여부입니다.

    1. 레지스트리를 공유하는 경우 oc 태그 를 활용합니다.

      $ oc tag <project_for_stage_N>/<imagestream_name_for_stage_N>:<tag_for_stage_N> <project_for_stage_N+1>/<imagestream_name_for_stage_N+1>:<tag_for_stage_N+1>
    2. 레지스트리가 공유되지 않는 경우 소스 및 대상 레지스트리에 로그인하여 애플리케이션 이미지를 적절하게 푸시할 때 승격된 각 파이프라인 레지스트리의 액세스 토큰을 활용할 수 있습니다.

      1. 소스 환경 레지스트리에 로그인합니다.

        $ docker login -u <username> -e <any_email_address> -p <token_value> <src_env_registry_ip>:<port>
      2. 애플리케이션의 이미지를 가져옵니다.

        $ docker pull <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
      3. 애플리케이션 이미지를 대상 레지스트리의 위치에 태그하고, 대상 스테이징 환경을 준수하는 데 필요한 네임스페이스, 이름 및 태그를 업데이트합니다.

        $ docker tag <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag> <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
      4. 대상 스테이징 환경 레지스트리에 로그인합니다.

        $ docker login -u <username> -e <any_email_address> -p <token_value> <dest_env_registry_ip>:<port>
      5. 이미지를 대상으로 푸시합니다.

        $ docker push <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
        작은 정보

        외부 레지스트리에서 새 버전의 이미지를 자동으로 가져오려면 oc tag 명령에 --scheduled 옵션이 있습니다. 사용하는 경우 ImageStreamTag 참조는 이미지를 호스팅하는 레지스트리에서 주기적으로 가져옵니다.

  2. 다음으로 애플리케이션 진화에서 API 오브젝트에 대한 기본 변경이나 애플리케이션을 구성하는 API 오브젝트 집합에서 추가 및 삭제 작업을 수행해야 하는 경우가 있습니다. 애플리케이션 API 오브젝트의 이러한 진화가 발생하면 OpenShift Container Platform CLI는 하나의 스테이징 환경에서 다음 단계로 변경할 수 있는 광범위한 옵션을 제공합니다.

    1. 프로모션 파이프라인을 처음 설정할 때와 동일한 방식으로 시작합니다.

      $ oc login <source_environment>
      $ oc project <source_project>
      $ oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml
      $ oc login <target_environment>
      $ oc <target_project>
    2. 단순히 새 환경에서 리소스를 생성하는 대신 업데이트합니다. 이 작업은 다음과 같은 몇 가지 방법으로 수행할 수 있습니다.

      1. 더 보수적인 접근 방식은 oc apply 를 활용하고 대상 환경의 각 API 오브젝트에 새로운 변경 사항을 병합하는 것입니다. 이렇게 하면 --dry-run=true 옵션을 사용하고 실제로 오브젝트를 변경하기 전에 결과 오브젝트를 검사할 수 있습니다.

        $ oc apply -f export.yaml --dry-run=true

        충족되면 실제로 apply 명령을 실행합니다.

        $ oc apply -f export.yaml

        apply 명령은 경우에 따라 더 복잡한 시나리오에 도움이 되는 추가 인수를 사용합니다. 자세한 내용은 oc apply --help 를 참조하십시오.

      2. 또는 더 간단하고 공격적인 접근 방식은 oc replace 를 활용하는 것입니다. 이 업데이트 및 교체와 함께 예행 연습이 없습니다. 가장 기본적인 형태로 다음을 실행합니다.

        $ oc replace -f export.yaml

        적용되는 것과 마찬가지로Replace 는 보다 정교한 동작에 대한 추가 인수를 사용합니다. 자세한 내용은 oc replace --help 를 참조하십시오.

  3. 이전 단계에서는 도입된 새 API 오브젝트를 자동으로 처리하지만, 소스 환경에서 API 오브젝트가 삭제된 경우 oc delete 를 사용하여 대상 환경에서 수동으로 삭제해야 합니다.
  4. API 오브젝트에 포함된 환경 변수 튜닝은 스테이징 환경마다 다를 수 있으므로 필요한 값이 필요할 수 있습니다. 이를 위해 oc set env 를 사용하십시오.

    $ oc set env <api_object_type>/<api_object_ID> <env_var_name>=<env_var_value>
  5. 마지막으로 oc rollout 명령 또는 위의 Deployments 섹션에서 설명하는 다른 메커니즘 중 하나를 사용하여 업데이트된 애플리케이션의 새 배포를 트리거합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.