Kubernetes에 앱 배치하기

Continuous Delivery 2027년 2월 12일에 다음 지역에서 서비스가 중단됩니다: AU-SYD, CA-MON, CA-TOR, US-EAST. 코드 위험 분석기 및 DevOps Insights 또한 해당 날짜에 모든 지역에서 더 이상 사용되지 않습니다. 그러나 한 지역에서 이러한 기능을 활발하게 사용하지 않는 경우 해당 지역의 기능은 조기에 중단되고 새 인스턴스 수락이 중단될 수 있습니다. 자세히 보기

이 학습서에서는 다른 배치 전략을 사용하여 열린 도구 체인을 작성하는 방법에 대해 설명합니다. 또한 IBM Cloud® Continuous Delivery 서비스에서 도구 체인을 구현하는 방법과 도구 체인을 사용하여 단순 웹 애플리케이션(앱)을 개발하고 배치하는 방법에 대해서도 배웁니다.

이 학습서는 브라우저 기반입니다. Terraform IBM Cloud 제공자 예제인 ibm-cd-toolchain-simple-helm 에서 보여준 것과 유사한 개방형 툴체인을 Terraform으로 생성할 수도 있습니다.

이 학습서에서는 배치 대상으로 Kubernetes가 있는 배치 전략을 사용합니다. 이 학습서에서 사용되는 도구 체인은 코드 스캐닝, 승인 테스트, Git 저장소, 그리고 지속적 통합 및 지속적 딜리버리 기능 등의 표준 DevOps 사례를 구현합니다. Kubernetes 클러스터와 도구 체인을 작성한 후 앱의 코드를 변경하고 Git Repos and Issue Tracking 저장소로 변경을 밀어넣습니다. 변경사항을 저장소에 푸시하면, Tekton 기반 딜리버리 파이프라인이 코드를 자동으로 빌드 및 배치합니다.

Tekton은 벤더 중립적인 오픈 소스( Kubernetes )로, 앱을 빌드, 테스트 및 배포하는 데 사용할 수 있는 네이티브 프레임워크입니다. Tekton은 지속적 통합 및 지속적 배포 시스템을 구축하기 위한 공유 구성 요소 세트를 제공합니다. 오픈 소스 프로젝트인 Tekton은 Continuous Delivery 재단에서 관리합니다. 이의 목표는 파이프라인, 워크플로우 및 기타 빌딩 블록의 산업 규격을 제공하여 지속적 딜리버리를 현대화하는 것입니다. Tekton을 사용하면, 기본 구현 세부사항의 추상화를 통해 클라우드 제공자 또는 온프레미스 시스템에서 빌드, 테스트 및 배치를 수행할 수 있습니다. Tekton 파이프라인은 Continuous Delivery 에 빌드됩니다.

이 학습서에서 사용되는 템플리트는 Kubernetes에 대한 표준 또는 Lite 계획에 적용됩니다. 표준 계획에서는 DNS 이름을 사용하여 앱에 액세스할 수 있습니다. Lite 계획에서 노드 포트를 사용하여 앱에 액세스할 수 있습니다.

배치 전략을 사용하여 프로덕션 환경에서 애플리케이션을 제어된 방식으로 업데이트할 수 있습니다. 배치 전략을 사용하면 다음과 같은 이점을 얻을 수 있습니다.

  • 애플리케이션 중단 시간을 피할 수 있습니다.
  • 고객에게 영향을 주지 않고 새 기능의 프로덕션 테스트가 가능합니다.
  • 프로덕션 문제가 사용자 서브세트에 미치는 영향을 제한합니다.
  • 문제가 발견되면 이전 버전으로 빠른 롤백이 가능합니다.

가능한 많은 배치 전략을 사용할 수 있습니다. 일반적으로 애플리케이션의 다중 인스턴스를 실행하고 다양한 인스턴스가 업데이트되는 방법을 관리하는 것에 따라 달라집니다. Continuous Delivery에서 다음과 같은 공통 배치 전략을 사전 구성할 수 있습니다.

기본
실행 중인 모든 인스턴스를 동시에 중지하고 업데이트하여 새 릴리스를 배치하여 가동 중단 시간을 초래합니다. 롤백을 하려면 이전 버전을 다시 배포해야 하므로 추가적인 다운타임이 발생합니다. 이 전략은 간단하고 빠르며 런타임 자원 요구사항이 적습니다. 이는 가장 위험하며 가동 중단 시간을 초래합니다. 기본 배치 전략은 고가용성이어야 하는 중요한 앱에 권장되지 않습니다.
롤링 업데이트
기본 전략과 유사하게 이 배치 전략은 단순하고 빠르며 런타임 자원 요구사항이 낮습니다. 그러나 각 실행 인스턴스는 개별적으로 작동 중지되고 업데이트되므로 가동 중단 시간을 피하려면 이전 릴리스를 다시 배치해야 합니다. 이러한 시간이 소요되는 접근 방식에서는 프로덕션에서 앱의 현재 버전이 중단되면 문제가 발생할 수 있습니다.
Blue-Green 배치
두 개의 독립된 영구 프로덕션 환경(파란색 및 녹색)을 작성하고 이러한 환경 중 하나만 트래픽을 한 번에 수신합니다. 현재 릴리스는 항상 유휴 환경에 배치되며, 중단 시간이 없이 배치가 완료된 후에는 트래픽이 이 릴리스로 전환됩니다. 변경되지 않은 환경으로만 트래픽을 전환해야 하므로 롤백은 가동 중단 시간을 초래하지 않습니다. 이 전략에는 두 개의 전체 프로덕션 환경이 필요하므로 자원 요구사항이 더 높습니다. 그러나 이 전략에서는 고객 트래픽을 허용하기 전에 프로덕션 환경에서 새 앱 버전을 테스트하는 기능과 같은 강력한 개발자 플로우가 가능합니다. Blue-Green 배치 또한 빠른 롤백을 지원합니다.
카나리아 릴리스
가동 중단 시간이 없는 원래 프로덕션 환경(Blue-Green과 유사)과 동시에 새 릴리스를 배치합니다. 배치를 진행하는 동안 제어된 사용자 서브세트에서 새 버전을 사용할 수 있도록 업데이트된 인스턴스와 원래 인스턴스 둘 다로 전송되는 트래픽의 양이 관리됩니다. 시간이 지남에 따라 이전 프로덕션 환경을 중지할 수 있는 시점인 모든 트래픽이 전송될 때까지 새 버전으로 전송되는 트래픽이 증가합니다. 배치가 진행 중인 동안 신속한 롤백을 위해 모든 트래픽을 원래의 프로덕션 환경으로 라우팅할 수 있습니다. 이 전략은 배포 중에만 두 개의 전체 프로덕션 환경이 필요하므로 전체 리소스 사용량은 블루-그린 배포보다 적습니다. 카나리아 릴리스 배치 전략은 이전 릴리스에서 배치 중인 소프트웨어의 현재 릴리스로 가장 느리게 이동합니다. 카나리아 배치를 통해 조직은 프로덕션에서 나란히 두 개의 서로 다른 소프트웨어 버전을 테스트할 수 있습니다.

시작하기 전에

이 학습서를 시작하기 전에 다음의 자원을 갖추고 있는지 확인하십시오.

  • IBM Cloud 계정. IBM Cloud 계정 유형에 따라 특정 리소스에 대한 액세스가 제한될 수 있습니다. 계정 플랜 한도에 따라, 일부 배치 전략에서 요구되는 특정 기능을 사용하지 못할 수도 있습니다. IBM Cloud 계정에 대한 자세한 내용은 IBM Cloud 계정 설정하기 및 계정 업그레이드를 참조하세요.

  • Kubernetes 클러스터 및 API 키. UI 또는 CLI를 사용하여 해당 자원을 작성할 수 있습니다. 클러스터는 프로비저닝하는 데 다소 시간이 걸릴 수 있습니다. 클러스터의 작성 시에 이는 배치 중, 보류 중 및 준비 단계를 진행합니다. Kubernetes 클러스터에 대한 자세한 정보는 Kubernetes 클러스터를 참조하십시오. Lite 계획에 대해 롤링 및 Blue-Green 배치를 사용할 수 있지만 표준 계획에 대해 Kubernetes 클러스터를 작성해야 합니다.

  • Continuous Delivery 서비스의 인스턴스.

  • 선택사항. 시크릿 관리 볼트(vault)에 저장되어 단일 위치에서 중앙집중식으로 관리되는 시크릿. 다양한 시크릿 관리 및 데이터 보호 오퍼링의 선택에 대한 자세한 정보는 IBM Cloud 시크릿 관리를 참조하십시오. 선택한 시크릿 관리 볼트 제공자의 인스턴스가 아직 없는 경우, 이를 작성하십시오.

  • 선택사항. 컨테이너 레지스트리 명령행을 사용하여 작성된 네임스페이스. 네임스페이스를 만들려면 다음 명령을 입력합니다:

    ibmcloud cr namespace-add <my namespace>

    또는 컨테이너 레지스트리 페이지에서 네임스페이스를 작성할 수도 있습니다. 이 위치에서의 네임스페이스 작성에 대한 자세한 정보는 IBM Cloud Container Registry 서비스를 참조하십시오.

관련 컨텐츠

도구 체인 작성

이 단계에서는 Kubernetes 애플리케이션 개발 도구 체인을 작성합니다. 대상 Kubernetes 클러스터는 IBM Cloud API 키와 Kubernetes 클러스터 이름을 사용하여 도구 체인 설정 중에 구성됩니다. Delivery Pipeline 구성을 업데이트하여 나중에 해당 설정을 변경할 수 있습니다. 대상 Git 저장소 분기에 병합된 코드는 자동으로 빌드되고 검증되어 Kubernetes 클러스터에 배치됩니다.

Kubernetes 애플리케이션 개발 도구 체인을 작성하려면 다음을 클릭하십시오.

도구 체인 작성

또는 IBM Cloud 콘솔에서 메뉴 아이콘( 햄버거 아이콘) > 플랫폼 자동화 > 툴체인(Toolchains) 을 클릭합니다. 도구 체인 페이지에서 도구 체인 작성을 클릭하십시오. 툴체인 만들기 페이지에서 Kubernetes 앱 개발을 클릭합니다.

도구 체인 이름 및 지역 구성

도구 체인 설정에 대한 기본 정보를 검토하십시오. 도구 체인의 이름은 IBM Cloud에서 해당 도구 체인을 식별합니다. 도구 체인의 이름이 IBM Cloud의 동일한 지역 및 리소스 그룹에 대해 도구 체인 내에서 고유한지 확인하십시오.

도구 체인 지역은 클러스터 및 레지스트리 지역과 다를 수 있습니다.

Kubernetes 보안 앱 툴체인 이름 및 지역
Kubernetes 보안 앱 툴체인 이름 및 지역

배치 전략 선택

도구 체인은 지속적인 배치 파이프라인을 작성하여 IBM Cloud® Kubernetes Service에 애플리케이션 도커 이미지를 배치합니다. 사용할 배치 전략을 선택하십시오. 선택하는 배치 전략(롤링, Blue-Green 또는 카나리아)에 따라 자세한 정보를 제공해야 합니다.

  1. 도구 체인에 사용할 배치 전략을 클릭하십시오.

    Kubernetes 안전한 애플리케이션 배포 전략
    배포 전략

  2. 계속을 클릭합니다.

애플리케이션 소스 코드 저장소 구성

애플리케이션 단계에서 애플리케이션 소스 코드 저장소에 대해 권장되는 옵션이 기본적으로 표시됩니다. 기본 Git 통합에 사용 가능한 모든 옵션을 보려면 고급 옵션을 클릭하십시오. 기본적으로, 도구 체인은 샘플 앱을 IBM 호스팅 Git Repos and Issue Tracking 저장로서 복제하는 기본 샘플을 사용합니다.

Kubernetes 보안 앱 저장소
Kubernetes 보안 앱 저장소

앱 저장소의 이름은 변경이 가능합니다. 저장소의 지역은 도구 체인의 지역과 동일하게 유지됩니다.

도구 체인 템플리트는 샘플 NodeJS 앱을 제공합니다. 도구 체인의 기존 애플리케이션 저장소를 링크하려면, 자체 앱 가져오기를 선택한 후 저장소의 URL을 지정하십시오. 도구 체인은 기존 Git Repos and Issue Tracking 저장소에 대한 링크만 지원합니다.

기본적으로, 애플리케이션 저장소 템플리트는 Git Repos and Issue Tracking 조직으로 복제됩니다. 조직을 변경하려면, 고급 옵션을 사용하고 저장소 소유자를 지정하십시오.

인벤토리 저장소 구성

인벤토리 저장소는 지속적 통합 도구 체인으로 빌드된 아티팩트의 세부사항을 기록합니다. 인벤토리 리포지토리 템플릿의 복제본인 새 인벤토리 리포지토리를 만들거나 툴체인 간에 공유하는 기존 인벤토리 리포지토리를 사용할 수 있습니다.

Kubernetes 보안 앱 인벤토리 저장소
Kubernetes 보안 앱 인벤토리 저장소

기본적으로, 인벤토리 저장소 템플리트는 Git Repos and Issue Tracking 조직에 복제됩니다. 조직을 변경하려면, 고급 옵션을 선택하고 저장소 소유자를 지정하십시오.

안전하게 시크릿 저장

이 도구 체인 내의 여러 도구에서는 IBM Cloud API 키 등의 시크릿이 필요합니다. 모든 시크릿을 시크릿 볼트(vault)에 안전하게 저장한 후 도구 체인에서 필요하면 이를 참조해야 합니다.

IBM Cloud의 사용을 통해, 중요한 데이터의 보호와 시크릿의 중앙집중화에 도움이 되는 다양한 시크릿 관리 및 데이터 보호 오퍼링 중에서 선택할 수 있습니다. 시크릿 단계에서는 도구 체인에서 추가 또는 제거할 시크릿 볼트(vault) 통합을 지정할 수 있습니다. 전제조건 포함 및 힌트를 사용한 볼트(vault) 통합의 추가 및 제거에 대한 자세한 정보는 IBM Cloud 시크릿 관리를 참조하십시오.

템플리트 내에서 힌트를 사용하여, 도구 체인은 사전 구성된 시크릿으로 자동 채워집니다. 도구 체인에 연결된 볼트(vault) 통합에서 시크릿을 수동으로 선택할 필요가 없습니다.

이 학습서에서는 시크릿 볼트(vault)로서 IBM Secrets Manager를 사용합니다.

Kubernetes 보안 앱 비밀번호 옵션
Kubernetes 보안 앱 비밀번호 옵션

IBM Secrets Manager는 도구 체인의 일부인 API 키, 이미지 서명 또는 HashiCorp 신임 정보 등의 시크릿을 안전하게 저장하고 적용합니다.

Kubernetes 보안 앱 비밀 옵션
Kubernetes 보안 앱 비밀 옵션

IBM Key Protect 또는 HashiCorp, 에서 비밀을 관리하는 방법에 대한 자세한 내용은 비밀을 참조하세요.

배치 대상 구성

앱이 배치될 대상 Kubernetes 클러스터를 구성하십시오. 앱이 빌드, 테스트 및 스캔 단계를 통과한 이후, 파이프라인은 빌드된 앱 이미지를 대상 Kubernetes 클러스터에 배치합니다. 이 배치에서 이제 승인 테스트 또는 통합 테스트를 위한 준비를 마쳤습니다.

API 키에 필수 액세스 권한이 있는 경우, 저장소에서 작성, 검색되거나 수동으로 지정된 API 키를 사용하여 다음의 필드가 자동으로 로드됩니다. API 키가 유효한 경우, 컨테이너 레지스트리 지역 및 네임스페이스 클러스터 지역, 이름, 네임스페이스 및 자원 그룹의 값은 자동으로 채워집니다. 자체 구성과 일치하도록 해당 필드를 업데이트할 수 있습니다.

  • 앱 이름: 앱의 이름입니다. 기본 앱 이름은 hello-containers입니다.

  • IBM Cloud API 키: 다수의 태스크에서 ibmcloud CLI 도구와의 상호작용에 사용되는 API 키입니다. 다음 방법 중 하나를 사용하여 사용하고자 하는 API 키를 지정하십시오.

    • 키 아이콘을 클릭하여 자체 선택한 시크릿 볼트(vault)에서 기존의 API 키를 가져오십시오.
    • 기존의 API 키를 복사하여 붙여넣으십시오.
    • 새로 작성을 클릭하여 API 키를 작성하십시오.
    • 기존의 API 키가 없으면, 신규 api-key 생성을 수행하십시오.

    생성된 API 키를 자체 선택한 기존의 시크릿 볼트(vault)에 즉시 저장할 수 있습니다.

사용자가 지정한 배치 전략을 사용하여 앱이 배치됩니다. 다음 예제는 롤링 또는 Blue-Green 배치에 대한 세부사항을 보여줍니다.

Kubernetes 보안 애플리케이션 배포 대상 세부 정보(롤링 또는 블루-그린 방식
Kubernetes ) 보안 애플리케이션 롤링 배포 대상 세부 정보

카나리아 배포 전략을 선택한 경우 추가 배포 대상 세부 정보를 지정해야 합니다.

  • 카나리아 단계 크기: 카나리아 배치의 새 릴리스로 경로 재지정할 트래픽의 양을 정의합니다.

  • 카나리아 단계 간격: 카나리아 배치의 새 릴리스로 이동하기 위해 각 카나리아 테스트 사이의 시간 간격을 정의합니다.

Kubernetes 보안 앱 배포 대상 세부 정보 보안 앱
Kubernetes 카나리아 배포 대상 세부 정보

선택적 도구 통합 추가

추가 구성 없이 IBM Cloud® DevOps Insights 도구 통합을 도구 체인에 추가할 수 있습니다.

DevOps Insights 는 작성된 도구 체인에 포함되어 있습니다. DevOps Insights에 대한 구성 단계는 제공하지 않아도 됩니다. 지속적 통합 파이프라인은 도구 체인에 포함된 DevOps Insights 인스턴스를 자동으로 사용합니다. DevOps Insights에서는 모든 자체 팀과 릴리스의 속도와 품질에 대한 가시성을 제공하기 위해 코드, 테스트, 빌드 및 배치 데이터를 집계합니다.

계속을 클릭합니다.

도구 체인 설정 완료

요약 페이지에서 작성을 클릭하십시오. 여러 단계가 자동으로 실행되어 도구 체인을 설정합니다.

파이프라인이 작성된 후 개별 도구 체인 통합을 구성할 수 있습니다.

Kubernetes 보안 애플리케이션 툴체인 요약
Kubernetes 보안 애플리케이션 툴체인 요약

새 도구 체인 탐색

도구 체인을 작성하고 나면 도구 체인의 일부인 각 도구 통합이 다이어그램에 표시됩니다.

파이프라인 탐색

파이프라인을 탐색하여 도구 체인 플로우 및 각 파이프라인 내에서 실행되는 다양한 옵션을 이해할 수 있습니다. 방금 작성한 도구 체인에는 세 개의 파이프라인이 포함되어 있습니다.

  • 가져오기 요청 파이프라인: 개발자가 개발 분기의 변경사항을 마스터 분기로 또는 저장소의 다른 분기로 병합할 때 실행됩니다. 가져오기 요청 파이프라인은 애플리케이션 소스 코드에서 단위 테스트 및 정적 스캔을 실행합니다.
  • 지속적 통합 파이프라인: 애플리케이션 소스 코드 저장소의 마스터 분기로 변경사항을 병합할 때 실행됩니다. 지속적 통합 파이프라인은 애플리케이션 소스 코드, CIS 검사 및 BOM(Bill Of Materials) 검사에서 단위 테스트, 코드 적용 범위 및 정적 스캔을 실행합니다. 또한 지속적 딜리버리 파이프라인은 도구 체인의 구성대로 2진 빌드 아티팩트를 생성한 후 이를 IBM Cloud® Kubernetes Service에 업로드합니다. 그리고 지속적 통합 파이프라인은 빌드 아티팩트의 메타데이터를 생성한 후 이를 인벤토리 저장소에 저장합니다.
  • 지속적 배치 파이프라인: 배치 환경에 빌드 아티팩트를 배치합니다. 파이프라인은 상태 확인을 실행하여 앱의 성공적인 배치를 확인합니다. 지속적 통합 파이프라인이 성공적으로 완료되면, 이 파이프라인을 수동으로 트리거해야 합니다. 선택된 배치 전략에 따라, 더 많은 트리거가 지속적 딜리버리 파이프라인에 추가됩니다.

가져오기 요청 및 지속적 통합 파이프라인 실행

가져오기 요청 파이프라인을 시작하려면, 앱 저장소에서 병합 요청을 작성하십시오.

  1. 도구 체인의 개요 페이지에 있는 저장소 카드에서, compliance-app-<timestamp> 앱 저장소를 클릭하십시오.
  2. 마스터 저장소에서 분기를 작성하십시오.
  3. 샘플 노드 앱이나 readme 파일에서 일부 코드를 업데이트한 후 해당 변경사항을 저장하십시오.
  4. 병합 요청을 제출하십시오.
  5. 도구 체인의 개요 페이지에 있는 저장소 카드에서, pr-pipeline 저장소를 클릭하여 가져오기 요청 파이프라인을 시작하십시오. 앱 저장소의 대응되는 병합 요청은 가져오기 요청 파이프라인의 모든 단계가 성공적으로 완료될 때까지 보류 상태를 유지합니다.
  6. 가져오기 요청 파이프라인 실행에 성공하면, 이를 선택하여 완료된 단계를 탐색할 수 있습니다.

풀 리퀘스트 파이프라인
리퀘스트 파이프라인

지속적 통합 파이프라인을 시작하려면, 앱 저장소에서 지속적 통합 병합 요청을 병합하십시오.

  1. 병합 요청으로 이동하십시오.
  2. 변경사항이 앱 저장소의 마스터 분기에 복사되도록 요청을 병합하십시오. 지속적 통합 파이프라인은 자동으로 트리거됩니다.
  3. Continuous Integration 도구 체인 개요 페이지의 저장소 카드에서 ci-pipeline 저장소를 클릭하여 Continuous Integration 파이프라인을 시작하십시오.
  4. 지속적 통합 파이프라인 실행에 성공하면, 파이프라인 실행을 클릭하여 완료된 단계를 탐색할 수 있습니다.

지속적 통합 파이프라인
통합 파이프라인

왼쪽으로 이동 연습

보안 앱 개발 업계에서 시프트 레프트는 결함 및 보안 취약점과 같은 문제를 예방 및 발견하고 소프트웨어 배포 프로세스 초기에 규정 준수 검사를 실행하는 관행입니다. 개발 주기 초기에 품질 검사를 진행하는 이러한 관행에는 다음과 같은 사례가 포함됩니다:

  • 코드 또는 저장소 자체에서 실행될 수 있으며 빌드된 이미지가 필요 없는 실행 검사(가급적 빨리). 이러한 검사는 비호환 코드가 저장소의 마스터 분기에 병합되지 않도록 방지합니다. 풀 리퀘스트 파이프라인에서 증거가 수집되지 않기 때문에 개발 프로세스 초기에 규정 준수 검사를 수행하는 것이 목표입니다.
  • 모든 검사는 모든 파이프라인 실행에서 실행됩니다. 이전 검사에 실패하는 경우, 파이프라인은 다음 검사를 진행합니다. 실행 중에 실패가 있는지 평가하려면, 파이프라인 평가자가 있는 파이프라인의 최종 단계를 확인하십시오.

단위 테스트 및 취약성 스캔의 결과는 도구 체인 내의 DevOps Insights 인스턴스에 공개됩니다. 해당 결과를 검토하려면, 도구 체인 내의 DevOps Insights 타일을 클릭한 후 품질 대시보드 페이지로 이동하십시오.

도구체인 지속적 통합
지속적 통합

파이프라인 실행 중에 실패가 있는지 평가하려면, 파이프라인 평가자가 있는 파이프라인의 최종 단계를 확인하십시오.

지속적 딜리버리 파이프라인 탐색

가져오기 요청 및 지속적 통합 파이프라인은 모든 배치 전략에서 공통입니다. 지속적 딜리버리 파이프라인 설계 및 구현 변경사항은 이 학습서에서 이전에 선택된 배치 전략을 기반으로 합니다.

이 학습서에서는 샘플 앱을 사용하여 롤링 배치 전략이 어떻게 작동하는지 설명합니다.

롤링 배치 탐색

이 학습서에서 사용되는 롤링 배치 전략은 Continuous Delivery 서비스를 사용하여 배치 전략을 사용하여 Kubernetes에서 프로덕션 워크로드를 실행하는 방법을 설명합니다. 지속적 전달 파이프라인은 롤링 배치를 위한 두 개의 트리거를 제공합니다. 다음의 방법 중 하나로 지속적 딜리버리 파이프라인을 시작할 수 있습니다.

  • 지속적 딜리버리 파이프라인을 수동으로 트리거합니다.
  • 인벤토리 저장소에서 각 Merge 조치 이후에 지속적 딜리버리 파이프라인을 자동으로 트리거합니다. 병합 후에는 지속적 딜리버리 파이프라인 실행을 수동으로 트리거해야 합니다.

Git Repos and Issue Tracking 트리거는 자동 지속적 딜리버리 파이프라인을 트리거하도록 설정되지만, 이는 기본적으로 사용되지 않습니다. 처음으로 변경사항을 승격한 후에 이 트리거를 사용할 수 있습니다.

롤링 배포를
위한 지속적 전달 파이프라인 트리거 롤링 배포를 위한 지속적 전달 파이프라인 내 트리거

롤링 배치 전략은 새 소프트웨어 버전으로 모든 프로덕션 인스턴스를 증분식으로 업데이트하므로 가동 중단 시간이 발생하지 않습니다. 그러나 롤백 배치 전략에서는 이전 릴리스를 재배치해야 하며 이는 완료하는 데 다소 시간이 걸릴 수 있습니다.

지속적 전달 파이프라인 실행이 성공한 후에는 지속적 전달 파이프라인의 perform deployment 단계에서 앱 URL을 찾을 수 있습니다.

URL 용 앱을 롤링 배포 애플리케이션 을 연속 배포 파이프라인에 추가
URL

다음 단계

Kubernetes에서 실행 중인 샘플 앱을 제거하려면, Kubernetes 클러스터를 정리해야합니다.

  1. Kubernetes 클러스터 홈 페이지로 이동하십시오.

  2. 샘플 앱이 실행 중인 클러스터를 선택하십시오.

  3. Kubernetes 대시보드를 클릭하십시오.

  4. 샘플 앱이 실행 중인 위치에서 네임스페이스를 선택하십시오.

    Kubernetes 네임스페이스
    Kubernetes 네임스페이스

  5. 선택된 네임스페이스 내에 나열된 관련 배치, 서비스 및 인그레스(ingress)를 삭제하십시오.

도움이 필요하십니까?

IBM Cloud IBM 의 에 의해 구동되는 AI 어시스턴트는 에서 일하는 것과 이용 가능한 제품과 서비스 카탈로그를 활용하여 솔루션을 구축하는 것에 대해 배울 수 있도록 설계되었습니다. watsonx IBM Cloud AI 어시스턴트로부터 도움 받기를 참조하세요.

추가 지원 옵션은 Continuous Delivery에 대한 도움말 및 지원 받기를 참조하십시오.