간단한 CI/CD 파이핑 생성 방법

확장성과 유연성을 제공하기 때문에 클라우드 네이티브 응용이 부상하고 있다.그러나 이런 유형의 구조도 그 자체의 도전이 있다.CI/CD 파이프라인을 실현하면 대부분의 문제를 해결할 것이다. 예를 들어 납품 과정 정의delivering applications independently와 시스템에서 많은 구축 블록의 관찰성을 얻을 수 있다.
CI/CD 파이프라인은 소프트웨어 납품 과정의 절차를 자동화하는 관건이다.이것은 부팅 코드 구축, 자동화 테스트 실행, 테스트 또는 생산 환경에 배치하는 것을 포함한다.
CI/CD 파이프는 여러 단계로 구성되어 있으며, 이 단계는 순서대로 실행되거나 병렬적으로 실행된다.이미 알고 있는 두 가지 파이프 문법이 있다 — 각본화되고 성명적이다.그것들 사이의 관건적인 차이는 유연성에 있다.
두 구문 모두 Groovy DSL을 기반으로 하지만 스크립트화된 파이핑 구문은 제한이 적습니다.Groovy에서 거의 모든 것을 완성할 수 있습니다.이것은 스크립트가 읽기 어려워지기 쉽다는 것을 의미한다.
다른 한편, 성명성 문법은 더욱 제한적이고 정의가 좋은 구조를 제공하여 더욱 간단한 CI/CD 파이프에 적합하다.이런 문법은'파이프를 코드로 한다'는 개념을 지원한다.따라서 Git와 같은 소스 코드 관리 시스템에 서명할 수 있는 파일을 쓸 수 있습니다.
개발자가 CI/CD 파이프를 더욱 편리하게 설치하기 위해 Microtica 성명성 문법을 지원하여 구축 과정과 원본 코드를 정의한다.

선언적 CI/CD 파이핑

파이프 프로세스가 정상적으로 작동하도록 하기 위해서, 모든 구성 요소/마이크로 서비스에는 마이크로티카라는 파일이 있어야 한다.yaml은 원본 코드의 루트 단계에 있습니다.이 파일은 구축 과정의 규범을 포함합니다.
제작 과정에서 Microtica는 코드에서 사양을 추출합니다.그리고 정의된 절차를 구동하기 위해 상태기를 만듭니다.
Microtica에서는 파이핑 사양명세에 실제 소스가 하나만 있는지 확인하기 위해 UI에서 파이핑 구성을 변경할 수 없습니다.변경 사항은 각 소스 코드 저장소에서 사용할 수 있는 YAML 파일에만 적용됩니다.우리는 이것이 정의, 유지보수, 그리고 가장 중요한 디버깅 과정에서 발생할 수 있는 혼동 문제를 피하는 데 매우 도움이 된다는 것을 발견했다.

CI/CD 파이핑 정의

정의할 수 있는 파이프를 구축하는 절차는 제한이 없습니다.이것은 마이크로티카의 예다.NodeJS 응용 프로그램의 파이프를 구성하는 yaml 파일을 정의합니다.이 파이프는 명령 부분에 정의된 세 가지 특정 명령을 실행합니다.

Pipeline:
 StartAt: Build
 States:
   Build:
     Type: Task
     Resource: microtica.actions.cmd
     Parameters:
       commands:
       - npm install
       - npm test
       - npm prune --production
       sourceLocation: "$.trigger.source.location"
       artifacts: true
     End: true

파이프 — 파이프 세그먼트의 시작점을 정의하는 루트 키

스타타 — 파이프의 첫 번째 동작 정의

주. — 특정 파이프의 상태 목록 정의

타입 — 파이프 동작항상 임무를 설정합니다.

리소스 — 엔진이 사용할 동작입니다.현재, 우리는 마이크로티카를 지지한다.움직여.cmd, bash 스크립트를 실행하는 동작입니다.

매개 변수 — 작업에 지정된 매개변수 세트

명령하다 — bash 명령의 목록입니다.여기에서 구축, 테스트, 코드 품질 검사 등에 사용할 사용자 정의 스크립트

를 정의할 수 있습니다.

소스 위치 — 조작하면 원본 코드의 위치를 찾을 수 있다.너는 이것을 바꾸어서는 안 된다.Git 저장소에서 꺼내면 Microtica는 사용자가 지정한 구성 요소/마이크로 서비스에 부품을 저장합니다. $촉발출처위치는 위치를 정의합니다.

인공 생산물 — 이 값은 이 구축이 S3에 저장되고 배치 기간에 사용될 부품을 생성하는 것을 정의합니다.생성된 작업이 Docker 이미지

인 경우 이 값을false로 설정해야 합니다.

종점 — 파이핑의 마지막 작업임을 정의합니다.

Microtica 작업을 수행하는 bash 명령을 지원합니다.미래에 우리는 개발자가 자신의 사용자 정의 조작을 정의할 수 있도록 허용할 계획이다.

Docker 이미지 배포 준비

위의 예제에 따라 확장 파이프라인을 만들고 추가 단계를 추가하여 Docker 이미지를 배치합니다.

Pipeline:
  StartAt: Build
  States:
    Build:
      Type: Task
      Resource: microtica.actions.cmd
      Parameters:
        environmentVariables:
          pipelineId: "$.pipeline.id"
          version: "$.commit.version"
        commands:
        - echo Starting build procedure...
        - npm install
        - npm test

        - echo Logging in to Amazon ECR...
        - $(aws ecr get-login --region $AWS_REGION --no-include-email)

        - echo Checking if repository exists in ECR. If not, create one
        - repoExists=`aws ecr describe-repositories --query "repositories[?repositoryName=='$pipelineId']" --output text`
        - if [ -z "$repoExists" ]; then aws ecr create-repository --repository-name $pipelineId; fi

        - awsAccountId=$(echo $CODEBUILD_BUILD_ARN | cut -d':' -f 5)
        - artifactLocation=$awsAccountId.dkr.ecr.$AWS_REGION.amazonaws.com/$pipelineId

        - echo Build Docker image...
        - docker build -t $pipelineId .
        - docker tag $pipelineId $artifactLocation:$version
        - docker tag $pipelineId $artifactLocation:latest

        - echo Push Docker image
        - docker push $artifactLocation
        sourceLocation: "$.source.location"
        artifacts: false
      End: true

이 예에서, 우리는 우선 환경 변수를 step가 실행될 때 환경 변수를 주입하는 environmentVariables 매개 변수 ($.pipeline.id와 $.commit.version을 사용합니다) 를 사용합니다.
최신 예제의 CI/CD 파이핑은 코드를 구축하고 테스트하기 위해 필요한 명령을 먼저 실행합니다.완료되면 Microtica는 ECR 저장소를 생성합니다(없는 경우).
ECR 저장소가 생기면 마지막 단계는 새로운 Docker 이미지를 만들어서 저장소로 밀어넣는 것입니다.

마이크로티카를 정의한 다음에yaml 파일입니다. 파이프를 구축하여 포털에서 마법사를 사용하여 구성 요소나 마이크로 서비스를 만들 때 마이크로틱에서 구축 과정을 자동화할 수 있습니다.이 옵션은 저장소에 웹훅을 추가합니다.
웹훅은 새 코드를 저장소 지점으로 전송할 때마다 구축 과정을 촉발하는 감청기입니다.이런 방식을 통해 당신은 최신 변화를 계속 처리하고 있다는 것을 확보할 수 있다.
Docker 이미지를 구축하면 Kubernetes 그룹에 배치할 수 있는 작업을 제공합니다.이 작업은 마이크로 서비스 세부 정보에서 수행할 수 있습니다. — 그룹에 추가하거나 Kubernetes 대시보드에서 - 마이크로 서비스 - 배치합니다.

Kubernetes 클러스터에 마이크로 서비스를 배치할 때 확장 옵션을 선택할 수 있습니다.또한 귀하는 귀하의 마이크로 서비스 설정을 연속으로 교부할 수 있습니다.

파이핑 개요

일단 수동 또는 자동으로 구축을 촉발하면 포털에서 구축 과정을 따라 이벤트를 실시간으로 보십시오.구문이 실패하면 화면에 빨간색 표시를 하고 로그에 오류를 표시합니다.
Pipelines overview 페이지에서 구성 요소와 마이크로 서비스의 모든 파이프를 조작하고 상태를 추적합니다.Microtica 여러 개의 실패한 구축이 검출되었을 때 파이프를 건강하지 않다고 표시합니다.
이 페이지에서 프로젝트 기록의 생성에 접근할 수 있습니다.더 중요한 것은 로그를 검사해서 문제를 발견할 수 있다는 것입니다.

우리는 수동 오류를 없앨 수 있기 때문에 자동화 파이프를 강력히 지원한다.또한 신뢰할 수 있고 지속 가능한 소프트웨어 납품에 매우 중요하다.
그것들은 소프트웨어 개발자들의 업무 효율을 더욱 높여 수동으로 파이프 절차를 집행할 필요가 없게 한다.무엇보다 신제품 발표에 따른 압력을 줄였다.
그리고 만약 당신이 이 과정에서 어떤 어려움을 겪게 된다면 언제든지 저에게 연락 주세요.