circleback 모드를 사용하는 고급 파이프 배열

This tutorial covers:

1. Orchestrating triggers for a dependent pipeline
2. Intro to the circleback pattern
3. Creating the config for a circleback pipeline

여러 팀이 많은 프로젝트에서 일하기 때문에, 당신의 소프트웨어에 하나의 파이프라인만 제공하는 것만으로는 부족합니다.테스트와 발표에 앞서 이 항목들은 구축과 통합이 필요하다.그렇다면 개발팀은 이런 상황을 어떻게 처리할까?많은 팀들이 소프트웨어를 더욱 작은 부분으로 분해함으로써 이 문제를 해결하는데, 이런 부분은 더욱 적게 하고 유지보수와 구축이 더욱 쉽다.이런 방법은 마이크로 서비스 체계 구조를 우리 업계에서 점점 보편화시켰다.
단점은 소프트웨어를 더 작은 부분으로 분해하면 복잡성이 증가한다는 것이다.더 많은 부품과 더 복잡한 결합은 테스트 응용 프로그램과 생산 과정에서 그것들을 조작하는 것을 더욱 어렵게 한다.
CI/CD 파이프는 여기서도 예외가 아니다.에서 우리는 다른 파이프에서 터치 파이프를 연구했다.이 기사는 한 배치가 다른 배치를 시작할 수 있도록 Circleci에서 여러 항목을 연결하는 방법을 설명한다.
본문에서 우리는 더욱 진일보할 것이다.나는 첫 번째 파이프가 다른 파이프를 촉발할 뿐만 아니라, 다른 파이프가 완성되기를 기다리고 있는 예시를 제공할 것이다.나는 작업을 끝낼 때 신호를 보내기 위해 두 번째 파이프로 되돌아오는 것을 circleback 모드라고 부른다.이 모델을 사용하면 더욱 좋은 통합 테스트와 더욱 복잡한 배치와 발표 장면을 실현할 수 있다.

선결 조건

이 강좌는 고급 파이프 편성 기술을 소개하기 때문에Circleci와 DevOps의 경험을 갖추어야 한다.

이 강좌는 이전의 강좌를 바탕으로 한다.

참고 자료 및 샘플 코드
이 예제의 소스 코드는 두 저장소에 있습니다.

Pipeline A - does the triggering

Pipeline B - gets triggered and circles back .

링 백 모드 소개
이러한 여러 파이프의 순환 배열에는 세 가지 절차가 있다.

첫 번째 파이프 대기

두 번째 파이프 종료

첫 번째 파이프에서 결과를 검색합니다. 다른 설명 방법은 두 번째 파이프가 첫 번째 파이프를 호출하거나'되돌아오는'것입니다. 첫 번째 파이프가 끊기고 신호가 계속되기를 기다리는 것입니다.

또 다른 방법은 첫 번째 파이프의 운행을 유지하고 두 번째 파이프가 완성되었는지 정기적으로 검사하는 것이다.이런 방법의 주요 단점은 운행 작업의 연속 윤번 조회 원가가 증가하는 것이다.
두 번째 파이프의 상태에 따라 첫 번째 파이프가 성공적으로 종료되거나 실패할 때까지 계속 실행됩니다.


왜 파이프는 다른 프로젝트가 완성되기를 기다려야 합니까?
인용문에서 언급한 바와 같이 이것은 여러 항목을 처리하기 때문에 발생하는 복잡성을 통제하는 선진적인 기술이다.이것은 여러 개의 상호 의존 프로젝트에 종사하는 단체가 사용할 수 있으며, 그들은 이 프로젝트를monorepo와 같은 단일 저장소에 넣고 싶지 않다.또 다른 용도는 테스트를 위해 하드웨어 회사와 같은 집중적인 저장소를 구축하는 것이다.이 기술은 마이크로 서비스 응용 프로그램의 통합 테스트나 복잡한 배치 장면을 편성하는 데도 사용된다.가능성이 많다.

파이프 트리거 구현
우리는 두 개의 파이프가 조화를 필요로 한다

트리거 실행 파이프 A

파이프라인 B를 트리거하고 파이프라인 A

로 돌아갑니다.
파이핑 B는 A에 종속적이며 A를 검증하는 데 사용할 수 있습니다.
두 파이프 모두 API 키를 설정하고 사용할 수 있어야 합니다.파이핑 A의 작업에서 환경 변수로 API 키 세트를 사용할 수 있습니다(CIRCLECI_API_KEY. 이 키 세트는 콜백 시 파이핑 B에서도 사용할 수 있습니다.두 항목에서 설정하거나 조직 수준에서 컨텍스트로 설정할 수 있습니다.이 자습서에서는 두 항목이 동일한 API 키를 사용할 수 있도록 조직 수준에서 컨텍스트circleci_api로 설정합니다.

시작 파이프
이 강좌의 첫 부분은 촉발 과정을 깊이 있게 설명할 것이다.다음 강좌에서 나는 몇 가지 중요한 차이점을 소개할 것이다.

파이프에서 반환하려면 원래 파이프의 ID를 파이프에 전달합니다.그런 다음 API를 통해 읽어들이고 액세스할 수 있습니다.

트리거 파이프의 ID를 저장해야 합니다. 나중에 결과를 얻어야 합니다.

샘플 코드에서 매개변수는 triggering-pipeline-id라고 합니다.

curl --request POST \
                --url https://circleci.com/api/v2/project/gh/zmarkan-demos/circleback-cicd-project-b/pipeline \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
                --data '{"branch":"main","parameters":{"triggering-pipeline-id":"<< pipeline.id >>"}}'

파이핑 ID를 저장하려면 패키지curl 호출$()을 실행하여 변수CREATED_PIPELINE에 지정합니다.응답 본문에서 ID를 추출하려면 jq 도구를 사용하여 파일에 기록합니다pipeline.txt.

CREATED_PIPELINE=$(curl --request POST \
                --url https://circleci.com/api/v2/project/gh/zmarkan-demos/semaphore_demo_project_b/pipeline \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
                --data '{"branch":"main","parameters":{"triggering-pipeline-id":"<< pipeline.id >>"}}' \
              | jq -r '.id'
              )
              echo "my created pipeline"
              echo $CREATED_PIPELINE
              mkdir ~/workspace
              echo $CREATED_PIPELINE > pipeline.txt

파일pipeline.txt이 생성되었으므로 persist_to_workspace을 사용하여 파일을 저장하고 다음 작업에 사용합니다.

- persist_to_workspace:
            root: .
            paths: 
              - pipeline.txt  

전체 작업 구성은 다음과 같습니다.

...
jobs:
  trigger-project-b-pipeline:
      docker: 
        - image: cimg/base:2021.11
      resource_class: small
      steps:
        - run:
            name: Ping another pipeline
            command: |
              CREATED_PIPELINE=$(curl --request POST \
                --url https://circleci.com/api/v2/project/gh/zmarkan-demos/semaphore_demo_project_b/pipeline \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
                --data '{"branch":"main","parameters":{"triggering-pipeline-id":"<< pipeline.id >>"}}' \
              | jq -r '.id'
              )
              echo "my created pipeline"
              echo $CREATED_PIPELINE
              mkdir ~/workspace
              echo $CREATED_PIPELINE > pipeline.txt
        - persist_to_workspace:
            root: .
            paths: 
              - pipeline.txt  
...

대기 예약
마지막 작업은 파이프 B를 트리거하여 파이프 a로 돌아가기 전에 파이프 B를 완료해야 합니다. 다음과 같이 CirclecI에서 approval 작업을 사용할 수 있습니다.

...
workflows:
  node-test-and-deploy:
    jobs:
      ...
      - trigger-project-b-pipeline:
          context: 
            - circleci-api
          requires:
            - build-and-test
          filters:
            branches:
              only: main
      - wait-for-triggered-pipeline:
          type: approval
          requires: 
            - trigger-project-b-pipeline
      - check-status-of-triggered-pipeline:
          requires:
            - wait-for-triggered-pipeline
          context:
            - circleci-api
      ...

작업trigger-project-b-pipeline을 완료한 후 wait-for-triggered-pipeline를 입력합니다.이 작업 유형은 approval이므로 수동으로 승인하는 사람이 있을 때까지 기다립니다.(자세한 내용은 다음 섹션에서 설명합니다.)승인 후 후속 작업을 계속하기 위해 requires 섹션을 추가합니다.
CircleciCI API를 사용하는 두 작업 모두context가 지정되어 있으므로 API 태그를 환경 변수로 사용할 수 있습니다.

파이프 A로 돌아가기
지금 우리는 이미 파이프 A를 완성했고, 지금은 파이프 B가 빛을 발할 때이다.Circleciapproval의 업무는 특수한 업무로 받아들여지기를 기다려야 한다.그것은 보통 인공 납품 담당자나 정보 안전 엔지니어의 승인을 받을 때까지 파이프를 대기 상태로 유지하는 데 쓰인다.
이때 파이핑 B는 파이핑 A의 ID를 알고 있으므로 approval API를 사용하여 파이핑 A를 가져올 수 있습니다.실행 중인 파이프의 ID만 있고 승인할 실제 작업이 없으므로 여러 API 호출이 필요합니다.

모든 일자리 확보

명칭별 승인 작업 찾기

승인 작업 요청

승인 작업을 통해 파이핑 A가 계속됩니다.
파이프 B의 테스트가 실패하면 이 작업은 자동으로 실패합니다.이 경우 필요한 작업을 포함하는 워크플로는 계속되지 않습니다.파이프에서 사용할 수 있습니다 post-steps. 파이프는 항상 실행됩니다.전체 작업 흐름은 다음 예시 코드 블록에 표시됩니다.
매개변수:

parameters:
  triggering-pipeline-id:
    type: string
    default: ""

...

workflows:
  node-test-and-deploy:
    jobs:
      - build-and-test:
          post-steps:
            - approve-job-in-triggering-pipeline
          context: 
            - circleci-api       

API 호출을 승인하는 스크립트를 실행하면 이렇게 할 수 있습니다.이 강좌에서 나는 command을 사용했다.

...
commands:
  approve-job-in-triggering-pipeline:
    steps:
      - run:
          name: Ping CircleCI API and approve the pending job
          command: |
            echo << pipeline.parameters.triggering-pipeline-id >>
            if ! [-z "<< pipeline.parameters.triggering-pipeline-id >>"] 
            then
              workflow_id=$(curl --request GET \
                --url https://circleci.com/api/v2/pipeline/<< pipeline.parameters.triggering-pipeline-id >>/workflow \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
              | jq -r '.items[0].id')

              echo $workflow_id

              waiting_job_id=$(curl --request GET \
                --url https://circleci.com/api/v2/workflow/$workflow_id/job \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
              | jq -r '.items[] | select(.name == "wait-for-triggered-pipeline").id')

              echo $waiting_job_id

              curl --request POST \
                --url https://circleci.com/api/v2/workflow/$workflow_id/approve/$waiting_job_id \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json"

            fi
          when: always       
...

스크립트는 먼저 triggering-pipeline-id 파이프 파라미터가 존재하는지 검사합니다.이 매개 변수가 존재할 때만 계속됩니다.명령의 행when: always은 종료 상태와 관계없이 명령이 실행되도록 합니다.
그런 다음 API 호출을 세 번 수행합니다.

파이프에서 워크플로우 ID를 가져옵니다.이 예시 항목에 대해 이 파이프에는 하나의 작업 흐름만 있다.

이 워크플로의 작업을 가져오고jq 승인 작업 이름wait-for-triggered-pipeline과 일치하는 작업을 선택하여 승인 작업의 ID

를 추출합니다.

대기 작업 ID를 사용하여 승인 엔드포인트에 요청

이 자습서에서는 워크플로우 ID와 작업 ID 등의 결과를 로컬 bash 변수에 저장하고 다음 API 호출에서 사용합니다.
주의: 응답에서 보낼 수 있는 작업 수를 초과하면 페이지를 처리해야 할 수도 있습니다.
이제 승인 요청을 보냈습니다. 파이핑 B가 완료되었으므로 파이핑 A가 다시 실행되어야 합니다.

B 결과로 파이프 A 업데이트하기
파이핑 A가 승인되면 워크플로의 다음 작업이 시작됩니다.워크플로우 다이어그램에 필요한 경우 파이핑 A는 여러 작업을 트리거할 수 있습니다.
우리는 여전히 이전의 작업 절차의 결과를 나타낼 기미가 보이지 않는다.이러한 정보를 얻으려면 API를 사용하여 파이핑 A에서 B의 상태를 다시 가져올 수 있습니다. 예제 작업은 다음과 같습니다. check-status-of-triggered-pipeline.
먼저 트리거 파이프의 ID, 즉 파이프 B를 읽어들여야 합니다. 이 ID는 이전 단계에서 작업공간에 유지된 ID와 동일합니다.cat로 검색:

 - attach_workspace:
          at: workspace
      - run:
          name: Check triggered workflow status
          command: |
            triggered_pipeline_id=$(cat workspace/pipeline.txt)

그런 다음 API를 사용하여 워크플로우를 읽어들입니다.jq를 사용하여 반환된 워크플로우 배열에서 첫 번째 항목의 상태만 가져옵니다.

created_workflow_status=$(curl --request GET \
                --url "https://circleci.com/api/v2/pipeline/${triggered_pipeline_id}/workflow" \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
              | jq -r '.items[0].status'
            )

상태가 비success인지 확인합니다.그렇지 않으면 exit를 사용하여 코드-1에서 작업을 종료하십시오.워크플로가 성공하면 워크플로가 종료됩니다.

if [["$created_workflow_status" != "success"]]; then
              echo "Workflow not successful - ${created_workflow_status}"
              (exit -1) 
            fi

            echo "Created workflow successful"

다음은 작업의 전체 구성check-status-of-triggered-pipeline입니다.

 check-status-of-triggered-pipeline:
    docker: 
      - image: cimg/base:2021.11
    resource_class: small 
    steps:
      - attach_workspace:
          at: workspace
      - run:
          name: Check triggered workflow status
          command: |
            triggered_pipeline_id=$(cat workspace/pipeline.txt)
            created_workflow_status=$(curl --request GET \
                --url "https://circleci.com/api/v2/pipeline/${triggered_pipeline_id}/workflow" \
                --header "Circle-Token: $CIRCLECI_API_KEY" \
                --header "content-type: application/json" \
              | jq -r '.items[0].status'
            )
            echo $created_workflow_status
            if [["$created_workflow_status" != "success"]]; then
              echo "Workflow not successful - ${created_workflow_status}"
              (exit -1) 
            fi

            echo "Created workflow successful"

결론
본고에서 우리는 복잡한 파이프 배열 모델의 예시를 되돌아보았는데, 나는 그것을'circleback'이라고 명명했다.circleback 모드에서 의존 파이프를 만들고 완성하기 전에 종료를 기다릴 수 있습니다.이것은 두 항목에서 여러 개의 API 키를 생성하고 승인 작업과Circleci를 사용하는 작업공간 기능을 포함하여 작업 흐름에서 파이프 ID를 저장하고 전달하는 등 값을 포함한다.예제 항목은 다른 저장소에 있습니다.project A 및 project B.
만약 이 문장이 당신에게 도움이 된다면, 나는 그것에 대해 어떤 문제나 건의가 있거나, 미래의 문장과 지침에 대해 어떤 생각을 가지고 있는지 알고 싶습니다. email me