지원콘솔개발자평가판 시작연락처

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

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

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

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

    1. 레지스트리가 공유되는 경우 oc tag 를 사용하기만 하면 됩니다. 

      $ 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 get -o yaml --export dc,is,svc,route,secret,sa -l promotion-group=<application_name> > 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

        apply 와 마찬가지로,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.