GitLab CI/CD: 파이핑 설정 설명서

이 문서는 GitLab을 사용하여 응용 프로그램을 위한 성공적인 CICD를 만드는 데 관한 것입니다.

The modern development moves faster and demands more from developers than ever. Tools and concepts around CICD help developers deliver value faster and more transparently.

지속적 통합 (CI) 과 연속 교부, 연속 배치 (CD) 의 줄임말로 CICD라는 단어를 들어본 적이 있을 것이다.간단히 말해서 CICD는 소프트웨어 개발자가 명령 또는 버튼을 통해 한 환경에서 다른 환경으로 소프트웨어를 전달할 수 있도록 하는 자동화 능력과 실천입니다.

Tl;박사 01 명
GitLab에서 파이프를 만드는 것은 매우 간단해서 모든 사람이 할 수 있다.설치에는 원격 시스템 1대와 GitLab 저장소가 필요합니다.다음 과정에서는 원격 시스템을 쉽게 설정하고 YAML 파일 구성에 대한 기본 지식을 안내합니다.
   1. 요구
   2. 원격 컴퓨터에 GitLab runner 에이전트 설정
   3. 파이핑 구성
   4. 지속적인 통합
   5. 연속 배송

1. 요구CI/CD을 깊이 연구하기 전에 다음과 같은 내용이 준비되어 있음을 확보해야 한다.
    1. GitLab 라이브러리
    2. 원격 서버
GitLab에 저장소를 만들고 항목을 설정합니다.우리는 git이 설치된 원격 기계가 한 대 더 필요하다.원격 실례는 우리의 파이프 스크립트를 실행할 수도 있고 프로젝트를 배치할 수도 있습니다.

2. GitLab runner 에이전트 설정
GitLab Runner는 jobs을 실행하고 결과를 GitLab로 전송하는 데 사용하는 도구입니다.Linux, macOS 및 Windows에서 실행되도록 설계되었습니다.

1. GitLab Runner 설치
여기는 link부터 다른 installation methods까지 당신에게 적합한 원격 기계를 선택할 수 있습니다.
내가 여기서 보여준 것은 Linux x86-64의 2진법 설치 방법이다.기본적으로 바이너리 파일을 /usr/local/bin/ 디렉터리에 다운로드하여 실행할 수 있도록 하면 된다.
시스템 아키텍처에 따라 binary fle을 선택합니다.터미널에 시스템 아키텍처를 이해하려면 arch을 입력합니다.

바이너리 다운로드

# Linux x86-64
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

실행 권한 부여

  sudo chmod +x /usr/local/bin/gitlab-runner

GitLab CI 사용자 생성

  sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

설치 및 서비스로 실행

  sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
  sudo gitlab-runner start

 

2.주자등록
달리기 선수는 세 가지 유형이 있다.

Shared (모든 프로젝트에 적용)

Group (그룹의 모든 항목)

특정(특정 항목용)

 
우리는 여기에 특정한 주자를 설치할 것이다.이렇게 해야만 네가 이 프로젝트의 소유권을 확보할 수 있다.자, 다음 절차를 통해 달리기 선수를 등록합시다.

에서 프로젝트 설정 >CI/CD로 이동하여 Runner 섹션을 확장합니다.

공유 주자 사용 안 함 버튼을 클릭합니다.

등록 영패에 주의하세요.

등록 토큰이 있는지 확인하고 GitLab Runner를 등록할 수 있습니다.

에서 다음 명령을 실행합니다.

sudo gitlab-runner register

 
이 명령은 등록 문제를 알려 줍니다

입력 조정기 URL (https://gitlab.com/)

당신이 획득한 토큰을 입력하세요.

이 주자의 설명을 입력하세요.

주자의 라벨을 입력하세요.항목에 여러 주자가 사용되지 않으면 비워 두십시오.

선택 runner executer(예: shell)

 
GitLab 실행 프로그램이 루트 권한을 가지도록 허용하는 것이 우리의 한 가지 더 할 일이다.ci/cd 작업에 필요한 권한 (sudo) 명령을 사용하지 않으려면 이 명령을 사용할 필요가 없습니다
다음 줄을 /etc/sudoers 파일의 끝에 추가합니다.

gitlab-runner ALL=(ALL) NOPASSWD:ALL

모든 것이 준비되었으니, 지금 우리는 파이프에 들어갈 준비가 되어 있다.

3. 파이핑 구성
우리는 루트 디렉터리에 있는 .gitlab-ci.yml 파일을 저장해야 한다. 이 파일은 파이프의 구조와 순서를 정의하고 GitLab Runner을 사용하여 무엇을 실행하는지 확인해야 한다.
YAML 파일의 기본 원리를 자세히 살펴보겠습니다.

작업.gitlab-ci.yml 파일의 가장 기본적인 요소입니다.말 그대로 우리는 극본을 쓴다.작업은 runners에서 선택하고 프로그램이 실행되는 환경에서 실행됩니다.

  job 1:
    script: "execute script for job1"

  job 2:
    script: "execute script for job2"

무대.
그것은 파이프에서 서로 다른 stages을 정의하는 데 도움이 된다.정의 순서는 작업의 최종 집행 순서가 될 것이다.

  stages:
    - build
    - test
    - deploy

단계.
그것은 stages에 의존하고 jobs을 다른 단계로 나눌 수 있도록 허용한다.jobs의 stage은 병행 집행되었다.

  stages:
    - build
    - test
    - deploy

  job 0:
    stage: .pre
    script: make something useful before build stage

  job 1:
    stage: build
    script: make build dependencies

  job 2:
    stage: build
    script: make build artifacts

  job 3:
    stage: test
    script: make test

  job 4:
    stage: deploy
    script: make deploy

  job 5:
    stage: .post
    script: make something useful at the end of the pipeline

.pre과 .post단계는 모든 파이프에 적용됩니다.사용자 정의 단계는 .pre 이후와 .post 이전에 실행됩니다.
두 가지 에지 사례가 더 있습니다.

에 stages에 .gitlab-ci.yml이 정의되어 있지 않으면 기본적으로 build, test과 deploy을 작업 단계로 허용한다.

작업이 stage을 지정하지 않으면 이 작업은 자동으로 test 단계에 분배된다.

4. 지속적인 통합
코드가 전송될 때마다 프로그램이 갑자기 발생하지 않도록 스크립트를 설정하고 테스트할 수 있습니다.
간단한 CI 를 만들어 보겠습니다.

stages:
  - test

Test:
  stage: test
  script:
    - echo "write your test here."
    - test -f "index.html"

상기 작업은 index.html 파일이 존재하는지 검사할 것이다.만약 그것이 존재하지 않는다면, 일은 실패할 것이다.여기서 CI는 코드가 저장소로 전송될 때마다 실행됩니다. 비록 우리는 작업 Test에 대해 어떠한 제어도 하지 않았지만.
알겠습니다. 물품 인도 문제를 계속 토론합시다.

5. 연속 배송
지속적인 교부는 일종의 개발 실천이다. 이런 실천에서 코드 변경은 자동으로 생산 환경에 발표될 준비를 한다.지속적인 통합을 통해 고객에게 지속 가능한 방식으로 새로운 변경 사항을 신속하게 발표할 수 있습니다.

stages:
  - test
  - deploy

Test:
  stage: test
  script:
    - echo "write your test here."
    - test -f "index.html"

Deploy:
  only:
    refs:
      - master
  stage: deploy
  script:
    - sudo cp -R ./index.html /var/www/html/

여기서 Deploy 키워드가 있는 only 작업을 볼 수 있습니다. 이 작업은 master 지점 작업에서만 터치할 수 있습니다.
어떤 작업이 실패하든지 간에 컨트롤러에서 로그를 볼 수 있습니다.그것은 네가 전진하는 것을 도울 것이다.

결론
우리 도착했어!우리는 과학 기술의 여행에서 또 한 걸음 내디뎠다.현대 소프트웨어 개발에서 CICD는 반드시 고려해야 할 요소이다.그래서 나는 이 지침이 모든 사람에게 의미가 있기를 바란다.
 
 

“ Releasing software is too often an art; it should be an engineering discipline. ” -- David Farley