GitLab CI/CD 파이핑과 Cloudsmith 저장소 통합

GitLab CI/CD란 무엇입니까?


GitLab CI/CD는 GitLab에 내장된 도구입니다.자동화된 작업을 만들 수 있습니다. 이러한 작업을 사용하여 연속적인 통합과 지속적인 납품/배치 과정을 형성할 수 있습니다.
소스 저장소에 yaml 파일.gitlab-ci.yml을 추가하여 GitLab CI/CD를 구성할 수 있습니다.이 파일은 코드 변경이 저장소로 전송될 때 파이프를 생성합니다.파이프는 일련의 단계로 구성되어 있으며, 각 단계마다 여러 개의 작업이나 스크립트를 포함할 수 있다.그런 다음 GitLab Runner 에이전트가 작업을 실행합니다.
GitLab 내부 인스턴스의 경우 파이프를 실행하기 위해 여러 운영 체제를 지원하는 GitLab runner 에이전트를 자신의 인스턴스에 설치할 수 있습니다.그러나 다음 예시에서 간단함을 유지하기 위해gitlab를 사용할 것입니다.com 및 기본 관리되는 GitLab runner 환경

Cloudsmith와 Gitlab CI/CD를 결합하여 사용하는 이유


그렇다면 Gitlab CI/CD 파이핑에서 Cloudsmith를 사용하는 이유는 무엇입니까?응, 몇 가지 이유가 있어.

  • 공통성 - Cloudsmith는 20여 가지 패키지 형식을 지원하기 때문에 프로젝트가 어떤 작업을 생성하든 개인 Cloudsmith 저장소
  • 에서 귀착점을 찾을 수 있습니다

  • 제어 - Cloudsmith 개인 저장소는 광범위한 안전과 접근 제어를 제공하여 내부 개발, 배치, 심지어 외부 고객에게 분배하는 등 작업 흐름에 적응하도록 한다.사용 가능한 세분화 권한 시스템으로 액세스 제어를 사용자 정의하고 필요에 따라 저장소를 잠그거나 열 수 있습니다.

  • 자동화 및 통합 – Cloudsmith CLI 및 특정 패키지 관리자에 대한 기본 지원으로 인해 Cloudsmith 개인 저장소는 개발 또는 배포 과정에서 다른 도구와 원활하게 작동할 수 있습니다.그것은 당신에게 크로스 패키지와 의존 항목의 단일한 진상 출처를 제공합니다.

  • 성능 및 신뢰성 - 클라우드 네이티브 플랫폼으로서 Cloudsmith는 저장소의 가용성과 성능을 관리합니다.서버, 컨테이너, 가상 머신 그룹을 관리할 염려가 없습니다.Dell의 초고속 CDN 및 다중 지역 인프라를 포함한 전 세계적인 성능으로 소프트웨어 패키지를 전 세계에 공급할 수 있습니다.믿을 만하고 빠르며 안전하다.
  • 그뿐만이 아닙니다.Cloudsmith는 사용자 정의 도메인 지원, 구성 가능한 업스트림 에이전트 및 캐시, 구성 가능한 에지 캐시 규칙, 다운로드 로그/통계 등의 기능을 통해 모든 패키지 관리 요구 사항에 최상의 솔루션을 제공하기 위한 것입니다.고속 CI/CD 워크플로우에 이상적인 도구입니다. 이것이 바로 GitLab CI/CD가 작성하는 워크플로우 유형입니다.

    우리 예를 하나 봅시다.


    좋아, 우리 업무 예시부터 시작합시다.먼저 GitLab 저장소에 구축할 소스 코드가 필요합니다.이 예에서 Ruby 소스 코드를 Ruby Gem 패키지에 구축합니다.
    GitLab의 프로젝트에는 다음과 같은 구조가 있습니다.

    앞에서 말한 바와 같이 여기서 중요한 것은 .gitlab-ci.yml 문건이다.이것이 바로 우리가 GitLab CI/CD 파이프를 정의하는 곳입니다. 변경 사항을 GitLab repo로 전송하면 이 파이프가 실행됩니다.
    어디 보자.gitlab ci.yml 파일:
    image: "ruby:2.5"
    
    variables:
      RUBYGEMS_HOST: "https://ruby.cloudsmith.io/demo/examples-repo"
    
    
    stages:
      - build
      - push
    
    build:
      stage: build
      script:
        - gem build cloudsmith-ruby-example.gemspec
      artifacts:
        paths:
          - cloudsmith-ruby-example-*
    
    push:
      stage: push
      script:
        - mkdir -p ~/.gem
        - mv $CLOUDSMITH_API_KEY ~/.gem/credentials && chmod 0600 ~/.gem/credentials
        - gem push cloudsmith-ruby-example-1.0.1.gem
    
    이 파이프 (이 예에서는 Ruby 2.5)를 실행하는 GitLab runner를 위해 Docker 컨테이너를 만들 때 사용할 이미지를 지정합니다.
    다음은 환경 변수 RUBYGEMS_HOST 를 추가합니다.Cloudsmith 패키지 저장소의 URL을 정의하는 곳입니다. 구축 결과를 이 저장소로 전송합니다.
    그리고 우리는 이 파이프에서 두 단계, 구축 단계와 전송 단계를 정의했다.

    구축 단계


    build:
      stage: build
      script:
        - gem build cloudsmith-ruby-example.gemspec
      artifacts:
        paths:
          - cloudsmith-ruby-example-*
    
    이 단계는 상당히 간단하다.우리는 단지 gem build 명령을 실행하여 우리의 루비 원본 코드를 구축할 수 있다. 예를 들어cloudsmith 루비 예시에서 정의한 것처럼.gemspec 파일입니다.다음 단계에서 사용할 수 있도록 임시 저장 구축된 출력이 필요하기 때문에 artifact 작업을 정의했습니다.
    이것은 파이프의 다른 단계가 새로운runner 실례에서 실행되기 때문에 다음 단계는 이전 단계에서 구축된 패키지에 접근할 수 없습니다.또한 같은 단계에서 구축과 전송에 필요한 모든 작업을 수행할 수 있기 때문에 같은 유도에서 이러한 상황을 피할 수 있지만, 더 복잡한 파이프에 대해서는 여러 단계가 있을 수 있습니다.

    추진 단계


    push:
      stage: push
      script:
        - mkdir -p ~/.gem
        - mv $CLOUDSMITH_API_KEY ~/.gem/credentials && chmod 0600 ~/.gem/credentials
        - gem push cloudsmith-ruby-example-1.0.1.gem
    
    푸시 단계가 좀 복잡해요.이것은 우리가 우리의 가방을 개인 클라우드 smith로 돌려보낼 것이기 때문에 신분 검증이 필요하다.Ruby 패키지 관리자 gem을 사용하면 인증 자격 증명 (예: Cloudsmith API 키) 을 자격 증명 파일에 저장할 수 있습니다. 이 파일은 ~/.gem/credentials 에 있습니다. 물론 이 자격 증명 파일을 원본 코드와 함께 GitLab 저장소에 체크 인하고 싶지 않습니다!
    따라서 GitLab을 사용하여 소스 코드 저장소에 변수를 추가할 수 있습니다.CLOUDSMITH_API_KEY라는 파일 변수를 만들고 푸시 절차의 일부로 작업을 추가하여 명령을 실행하기 전에 필요한 위치로 이동할 수 있습니다.
    GitLab 저장소 설정에 이 파일 변수를 추가할 수 있습니다.

    현재, 우리의 전송 절차가 실행될 때, gem pushmkdir 작업은 필요한 mv 파일 (우리의 Cloudsmith API 키를 포함) 을 만들 것입니다. 이 모든 것들은runner 실례의 어떤 로그에서도 우리의 API 키를 공개하지 않고, 우리의 원본 코드를 서명하지 않습니다.
    푸시 절차의 마지막 작업은 실행~/.gem/credentials해서 우리가 구축한 가방을 우리의 개인 Cloudsmith repo에 업로드하는 것입니다. 왜냐하면 Cloudsmith 메모리 라이브러리는 gem push 패키지 관리자에게 완전한 본체 지원을 제공하기 때문입니다.
    트리거 파이프
    남은 것은 원본 코드를 변경한 다음 변경 사항을 제출하고 Gitlab repo로 보내는 것입니다.우리가 이렇게 할 때 무슨 일이 일어날지 봅시다.
    우리는 변화, 약속, 추진:

    Gitlab CI/CD 파이핑 시작, 구축 단계:

    구축 단계gem를 실행하여 패키지를 구축한 다음 GitLab의 임시 공작물 저장소에 저장합니다.

    구축 단계가 완료되면 푸시 단계가 실행됩니다.

    푸시 단계에서 임시 공작물 저장소에서 패키지를 다운로드하여 필요한 gem build 파일을 만들고 실행~/gem/credentials하여 패키지를 개인 Cloudsmith 저장소에 업로드합니다.

    이렇게 하면 파이핑이 완료되고 통과로 보고됩니다.

    만약 우리가 지금 Cloudsmith에 로그인하고 우리의 "examples repo"저장소를 검사한다면, 우리는 우리가 방금 구축한 루비 젬이 이미 존재하는 것을 볼 수 있다.

    마지막 생각


    Cloudsmith에서 네이티브 도구를 지원하는 패키지(예: Ruby)를 구축하든 Cloudsmith CLI를 사용하여 원본 파일이나 다른 바이너리 작업을 푸시하든 개인 Cloudsmith 저장소를 GitLab CI/CD 파이프라인과 쉽게 통합할 수 있습니다.몇 줄만 설정하면 개인 Cloudsmith 저장소를 추가할 수 있고 정상적으로 작동할 수 있습니다.
    패키지 관리는 복잡하고 어려울 수 있습니다. 만약에 자신의 패키지 관리 솔루션과 인프라 시설을 동시에 관리하려고 한다면 더욱 그렇습니다.당신이 집중적이고 위탁 관리되며 안전한 하도급 관리 서비스에서 얻을 수 있는 생산력과 효율 수익을 직접 시험해 보세요.

    좋은 웹페이지 즐겨찾기