2.3.4. 방법 및 도구


근본적으로 애플리케이션 승격은 앞서 언급한 애플리케이션 구성 요소를 한 환경에서 다른 환경으로 이동하는 프로세스입니다. 다음 하위 섹션에서는 애플리케이션 승격 자동화에 대한 전체적인 솔루션을 논의하기 전에 다양한 구성 요소를 직접 이동하는 데 사용할 수 있는 툴을 간략하게 설명합니다.

참고

빌드 및 배포 프로세스 중 사용할 수 있는 삽입 지점이 많이 있습니다. BuildConfigDeploymentConfig API 오브젝트 내에 정의됩니다. 이러한 후크를 사용하면 데이터베이스 및 OpenShift Container Platform 클러스터 자체와 같이 배포된 구성 요소와 상호 작용할 수 있는 사용자 정의 스크립트를 호출할 수 있습니다.

따라서 이러한 후크를 사용하여 환경 간에 애플리케이션을 효과적으로 이동하는 구성 요소 관리 작업을 수행할 수 있습니다. 예를 들어 후크 내에서 이미지 태그 작업을 수행할 수 있습니다. 그러나 다양한 후크 포인트는 특정 환경 내에서 애플리케이션의 라이프사이클을 관리하는 데 가장 적합합니다(예: 새 버전의 애플리케이션이 배포될 때 데이터베이스 스키마 마이그레이션을 수행하기 위해 사용) 환경 간에 애플리케이션 구성 요소를 이동하는 것이 좋습니다.

2.3.4.1. API 오브젝트 관리

하나의 환경에 정의된 대로 리소스는 새 환경으로 가져오기 위해 JSON 또는 YAML 파일 콘텐츠로 내보냅니다. 따라서 JSON 또는 YAML로 API 오브젝트의 표현식은 애플리케이션 파이프라인을 통해 API 오브젝트를 승격하는 작업 단위 역할을 합니다. oc CLI는 이 콘텐츠를 내보내고 가져오는 데 사용됩니다.

작은 정보

파일에 저장된 JSON 또는 YAML로 OpenShift Container Platform을 통한 승격 흐름에는 필요하지 않지만 SCM 시스템에서 콘텐츠를 저장하고 검색할 수 있습니다. 이를 통해 분기 생성, 다양한 라벨 또는 버전에 연결된 태그를 비롯하여 SCM의 버전 관리 관련 기능을 활용할 수 있습니다.

2.3.4.1.1. API 오브젝트 상태 내보내기

oc export 를 사용하여 API 오브젝트 사양을 캡처해야 합니다. 이 작업은 오브젝트 정의(예: 현재 네임스페이스 또는 할당된 IP 주소)에서 환경별 데이터를 제거하여 다른 환경에서 재생성할 수 있습니다(예: 오브젝트의 필터링되지 않은 상태를 출력하는 oc get 작업 제외).

라벨에 단일 작업에서 Pod 그룹을 선택하고 관리할 수 있으므로 API 오브젝트에서 레이블을 추가, 수정 또는 제거할 수 있는 oc 레이블 을 사용하면 승격 흐름을 위해 수집되는 오브젝트 집합을 구성하는 것으로 유용할 수 있습니다. 이를 통해 올바른 오브젝트 세트를 쉽게 내보낼 수 있으며, 레이블이 새 환경에서 오브젝트를 생성할 때 전달되므로 각 환경에서 애플리케이션 구성 요소를 보다 쉽게 관리할 수 있습니다.

참고

API 오브젝트에는 종종 보안을 참조하는 DeploymentConfig 와 같은 참조가 포함되어 있습니다. 하나의 환경에서 다른 환경으로 API 오브젝트를 이동할 때 이러한 참조도 새 환경으로 이동해야 합니다.

마찬가지로 DeploymentConfig 와 같은 API 오브젝트에는 외부 레지스트리를 참조하는 ImageStreams 에 대한 참조가 포함되는 경우가 많습니다. 하나의 환경에서 다른 환경으로 API 오브젝트를 이동할 때 이러한 참조를 새 환경 내에서 확인할 수 있는지 확인해야 합니다. 즉, 참조를 확인할 수 있어야 하며 ImageStream 이 새 환경에서 액세스할 수 있는 레지스트리를 참조해야 합니다. 자세한 내용은 이미지 이동프로모션 Caveats 를 참조하십시오.

2.3.4.1.2. API 오브젝트 상태 가져오기
2.3.4.1.2.1. 초기 생성

애플리케이션이 새 환경에 처음 소개되는 경우 API 오브젝트의 사양을 표시하고 oc create 를 실행하여 적절한 환경에서 애플리케이션을 생성하는 JSON 또는 YAML로 충분합니다. oc create 를 사용하는 경우 --save-config 옵션을 고려하십시오. 주석 목록에 있는 오브젝트에 구성 요소를 저장하면 나중에 oc apply 를 사용하여 오브젝트를 수정할 수 있습니다.

2.3.4.1.2.2. 반복적 수정

다양한 스테이징 환경이 초기에 설정되고, 승격 주기가 시작되고 애플리케이션이 스테이지에서 단계로 이동하면 애플리케이션의 일부인 API 오브젝트의 수정이 포함될 수 있습니다. 이러한 API 오브젝트의 변경 사항은 OpenShift Container Platform 시스템의 구성을 나타내기 때문에 가능합니다. 이러한 변경에 대한 동기는 다음과 같습니다.

  • 스테이징 환경 간의 환경 차이점에 대한 회계입니다.
  • 애플리케이션에서 지원하는 다양한 시나리오 확인.

oc CLI를 사용하여 API 오브젝트를 다음 단계의 환경으로 전송합니다. API 오브젝트를 수정하는 다양한 oc 명령 세트가 있지만 이 주제에서는 oc apply, which computes and applies differences between objects에 중점을 둡니다.

특히 oc apply 를 기존 오브젝트 정의와 함께 입력으로 사용하는 3방향 병합으로 볼 수 있습니다. 다음과 같은 3방향 병합을 수행합니다.

  1. 상기 명령 입력은, The input to the command,
  2. 상기 객체의 현재 버전, 및 The current version of the object, and
  3. 현재 오브젝트에 주석으로 저장된 최신 사용자 지정 오브젝트 정의입니다.

그런 다음 기존 오브젝트가 결과로 업데이트됩니다.

오브젝트가 소스와 대상 환경 간에 동일할 것으로 예상되는 경우와 같이 API 오브젝트의 추가 사용자 정의가 필요한 경우 oc set 와 같은 oc 명령을 사용하여 업스트림 환경의 최신 오브젝트 정의를 적용한 후 오브젝트를 수정할 수 있습니다.

몇 가지 구체적인 사용은 시나리오와 예에 인용되어 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat, Inc.