도구 체인 및 파이프라인 고려사항

대부분의 애플리케이션은 서로 다른 소스 저장소가 있는 여러 마이크로서비스로 구성됩니다. 일반적으로 단일 도구 체인은 논리적으로 그룹화된 마이크로서비스를 호스트하는 데 사용됩니다. 일반적으로 하나의 도구 체인과 하나의 파이프라인을 사용하거나 가능한 한 적은 파이프라인을 사용하지만 여러 트리거를 사용하십시오. 각 파이프라인 내에서 필요한 수의 트리거 (파이프라인당 최대 1024개의 트리거) 를 복제하고 구성할 수 있습니다. 이 전략은 공통 프로세스, 스크립트 및 구성 파일을 적용하는 데 도움이 됩니다. 자세한 정보는 하나의 CI 도구 체인에서 여러 앱 구성 을 참조하십시오.

이 접근 방식에는 다음과 같은 장점이 있습니다.

• 더 적은 파이프라인을 사용하면 중복을 방지하고 오류를 줄입니다. 예를 들어, 환경 특성 또는 시크릿이 추가, 편집 또는 삭제되는 경우에도 업데이트를 더 쉽게 유지보수할 수 있습니다.
• 이 접근 방식을 사용하면 서비스 온보딩이 더 빠릅니다. 마이크로서비스에 대한 Git 통합을 추가하고 Git 및 수동 트리거를 복제한 후 필요에 따라 수정하십시오. 그런 다음 .pipeline-config.yaml 파일 및 스크립트가 마이크로서비스에 대해 구현되었는지 확인하십시오.

이 접근 방식에는 다음과 같은 단점이 있습니다.

• 하나의 편집은 동일한 파이프라인을 사용 중인 모든 팀에 영향을 줄 수 있습니다.
• 사용자 액세스는 Identity and Access Management(IAM) 를 사용하여 관리되며 파이프라인 레벨이 아닌 도구 체인 레벨에서 설정됩니다. 따라서 여러 서비스에 대해 단일 도구 체인을 사용하는 경우 팀의 모든 구성원이 다른 팀의 파이프라인을 볼 수 있습니다. IAM에서 사용자의 액세스 권한에 따라 파이프라인을 편집, 삭제 또는 트리거할 수 있습니다.

청구 고려사항

Continuous Delivery 서비스는 CD 인스턴스당 권한 부여된 사용자 수 및 도구 체인에 사용하는 리소스 그룹 수에 따라 비용 청구를 결정합니다. 저장소에 대한 액세스 권한이 있는 사용자도 권한 부여된 사용자로 간주됩니다. 자세한 정보는 권한 부여된 사용자를 참조하십시오. 비용을 줄이려면 모든 도구 체인이 동일한 리소스 그룹에 있는지 확인하십시오. 이를 수행해도 애플리케이션 환경을 포함하는 다른 리소스 그룹에 배치하는 도구 체인의 기능에는 영향을 주지 않습니다.

DevSecOps 저장소 고려사항

여러 마이크로서비스로 구성된 애플리케이션을 만드는 경우 대부분DevSecOps 증거 저장소를 제외한 저장소는 마이크로서비스 전체에서 공유될 수 있습니다.

자세한 내용은 다음을 참조하세요.어떻게DevSecOps 파이프라인은 저장소를 사용합니다..

IBM Cloud Object Storage 고려사항

공유 인벤토리 저장소 및 공유 문제 저장소를 사용 중인 경우 IBM Cloud® Object Storage 의 공유 인스턴스도 사용할 수 있습니다. 다음 단계를 완료하십시오.

1. 도구 체인 및 파이프라인에서 사용할 IBM Cloud Object Storage 의 인스턴스 를 작성하십시오.
2. 해당 공유 IBM Cloud Object Storage 인스턴스 내에서 마이크로서비스당 하나의 Object Storage 버킷을 작성하십시오.
3. 적용 가능한 경우 cos-bucket-name 환경 특성을 설정하여 IBM Cloud Object Storage 버킷을 사용하도록 파이프라인 및 트리거를 설정하십시오.

동일한 CI, CD및 CC 파이프라인 내의 모든 마이크로서비스는 배치 환경에 관계없이 하나의 Object Storage 버킷을 공유합니다. Object Storage 버킷은 증거 저장소와 유사하게 작동하지만 대형 증거 저장소에서 발생할 수 있는 성능 문제가 없습니다. 대형 Object Storage 버킷에서는 성능 문제가 발생하지 않으므로 Object Storage 버킷에서 증거를 제거할 필요가 없습니다.

다중 환경에 배치

여러 가지 방법으로 CD 파이프라인을 사용하여 여러 대상 환경에 배치할 수 있습니다.

각 targeted environment 에는 인벤토리 저장소에 해당 분기가 있어야 합니다. 여기서 변경사항은 source 에서 target 분기로 승격됩니다.

다음과 같은 선택적 디자인이 사용자의 아키텍처에 적합할 수 있습니다.

• 대상 환경마다 하나의 수동 트리거를 사용하십시오. 트리거를 복제한 후 새 환경에 맞게 환경 특성을 편집하십시오.
• 특정 구성 설정이 파일에 저장되는 대상 환경당 하나의 폴더가 있는 Git 구성 저장소를 사용하십시오.

실행되는 스크립트 식별

단계에 대해 실행되는 스크립트를 식별하려면 파이프라인 실행 (CI 파이프라인이 권장됨) 을 여십시오. 태스크를 펼친 후 run-stage 를 클릭하여 로그를 여십시오. run-stage 로그의 시작 부분은 스크립트가 있는 저장소를 포함하여 스테이지에서 사용된 스크립트에 대한 정보를 제공합니다. 로그에서 스크롤하여 실행된 스크립트에 대한 세부사항을 찾을 수 있습니다. 예를 들어, code-compliance-checks 태스크의 run-stage 로그에는 스테이지에 대한 환경 특성을 포함하는 다음 정보가 있을 수 있습니다.

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

이 예제에서 실행되는 스크립트는 commons library 에 있는 /opt/commons/compliance-checks/run.sh 입니다. 이 공통 라이브러리를 소스로 사용하여 특정 에지 케이스에 맞게 사용자 정의할 수 있는 코드를 복사하십시오. 예제에서 compliance-checks/run.sh 는 compliance-commons library 에 있습니다.

기본 스크립트 대체

기본 스크립트를 대체하려면 다음 단계를 완료하십시오.

1. 스테이지 로그에서 기본 스크립트를 식별하는 스니펫을 복사하십시오.

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

1. 스니펫을 .pipeline-config.yaml 파일에 붙여넣으십시오.
2. 스크립트가 호출되기 전이나 후에 사용자 정의 코드를 추가하십시오.
3. 필요에 따라 특성을 편집, 삭제 또는 추가하십시오.

다음 예제는 .pipeline-config.yaml 파일에서 업데이트된 스크립트를 표시합니다.

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

자세한 정보는 사용자 정의 스크립트 를 참조하십시오.