지난 게시글에 이어 Node.js express 테스트 서버를 띄워 CI/CD를 구축해보는 과정을 정리해보겠다. 생각만큼 쉽지않은 과정이였는데 공부는 많이 되더라...

GitLab Runner

앞서 우리는 GitLab의 파이프라인을 실행하기 위해서 GitLab Runner라는 에이전트가 설치되어 있어야함을 알게 되었다. 본격적으로 CI/CD를 구축하기 전에 GitLab Runner에 대해 이해하고 넘어가보자.

GitLab의 공식 문서에서 발췌한 내용입니다.
https://docs.gitlab.com/runner/

GitLab Runner는 크게 두가지로 구분할 수 있는데 모든 프로젝트에 대해 GitLab에서
관리하는 GitLab-hosted runners와 직접 Runner를 설치하고 자체 인스턴스에 Runner를 등록할 수 있는 self-managed runners이다.

내가 구축해볼 내용은 self-managed runners로 참고한 여러 블로그들이나 GitLab의 공식 문서 내용을 보았을때 일반적으로 많이 사용되는 Runner인듯하다.

Runner registration

서버에 GitLab Runner를 설치한 후 GitLab에 등록하면 Runner는 일반적으로 GitLab Runner를 설치한 동일한 머신에서 작업을 처리한다.

Executors

Runner를 등록할 때 Executor를 선택해야한다.
Executor는 각 작업이 실행되는 환경을 결정하므로 나는 익숙한 shell을 선택했다.

Access to runners

Runner를 등록하기 전에 GitLab의 어느 사용자가 엑세스할 수 있는지, 특정 그룹이나 프로젝트로 제한할지 결정해야한다.

• Instance runners: 모든 프로젝트에서 사용
• Group runners: 해당 그룹의 프로젝트 및 하위 그룹에서 사용
• Project runners: 개별 프로젝트용

Tags

Runner를 등록할 때 태그를 추가할 수 있는데 CI/CD 작업이 실행되면 할당된 태그를 확인하여 어떤 Runner를 사용했는지 알 수 있다.

.gitlab-ci.yml

job:
  tags:
    - runnertest

유의할 점

태그를 사용하지 않고 파이프라인을 실행시키고 싶다면 아래 옵션을 활성화 시켜줘야한다.

Configuring runners

GitLab Runner를 설치하는 과정에서 생성되는 파일인 config.toml 파일을 편집하여 runner를 구성할 수 있다.

기본적인 개념에 대해 알아봤으니 이제 설치부터 배포까지의 과정을

GitLab Runner 설치 및 등록

GitLab Runner 설치

프로젝트 리포지토리의 CICD-Runners 탭에서 새로운 프로젝트 runner를 생성하기 위한 설치 명령어와 토큰을 확인할 수 있다.

Download the binary for your system

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

Give it permission to execute

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

(선택)Create a GitLab Runner user

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

GitLab Runner를 위한 신규 사용자 계정을 만드는 과정인데 만일 기존에 이용중인 사용자를 그대로 사용할거면 만들어주지 않아도 된다.

Install and run as a service

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

sudo gitlab-runner start

유의할 점

Project runners를 등록한다면 반드시 Instance runners를 비활성화 해야한다.

Instance runners는 여러 프로젝트가 공유하기 때문에 특정 프로젝트의 빌드가 리소스를 독점하거나 다른 프로젝트의 빌드를 지연시킬 수 있기 때문이다.

※리소스 충돌 방지※
Project runners를 사용하면 해당 러너의 리소스가 특정 프로젝트에 전용으로 할당되어 다른 프로젝트의 빌드와 충돌하는 것을 방지할 수 있다.

GitLab Runner 등록

명령어를 통해 해당 프로젝트 runner를 등록하는 과정을 진행할 수 있다.

sudo gitlab-runner register

내가 등록했던 로그가 날라가서 다른 블로그의 이미지를 참고했다.

Runner 등록 확인

명령어와 동일한 탭에서 정상적으로 등록됐는지 확인할 수 있다.

※Runner의 설치 위치?※

이 부분에 대해서 많은 고민을 했다.

젠킨스를 활용했을 땐 SSH를 이용해서 배포하는 방식으로 했어서 그런지 test-server와 product-server 사이에서 당연히 test-server에 runner를 설치해야된다고 생각했기 때문이다.

SSH를 통해 배포 삽질하는 과정이 복잡하고 에러가 너무 많이나는 바람에 이게 맞나? 싶은 기분이 들 때쯤 공식 문서를 다시한번 들여다봤다.

"Runners usually process jobs on the same machine where you installed GitLab Runner."
Runner는 일반적으로 GitLab Runner를 설치한 동일한 머신에서 작업을 처리합니다.

설치한 머신에서 작업을 처리한다고 하면 굳이 test-server에 설치하여 SSH로 배포할 것이 아니라 product-server에 설치하고 그 서버에서 배포하고 실행하면 되는게 아니겠는가?

그래서 나는 서비스할 서버에 runner를 설치하기로 결정했다. (더 좋은 방법이 있겠지만!)

CI/CD 구축하기

.gitlab-ci.yml 작성

stages: # Pipeline 선언
    - build
    - deploy

before_script:
    - export PATH=$PATH:/root/.nvm/versions/node/v20.10.0/bin # npm 명령어를 사용하기 위한 절대경로 설정
    - sudo pm2 delete all || true

Build:
    stage: build
    cache:
        paths:
            - node_modules
    script:
        - sudo -E env "PATH=$PATH" npm install
deploy:
    stage: deploy
    variables:
        PM2_HOME: '/home/gitlab-runner/.pm2'
    script:
        - echo "Deploying the project to product-server..."
        - cp -r * /home/ubuntu/product3
        - sudo -E env "PATH=$PATH" pm2 list
        - sudo -E env "PATH=$PATH" pm2 start /home/ubuntu/product3/app.js
        - sudo -E env "PATH=$PATH" pm2 save
        - sudo -E env "PATH=$PATH" pm2 list

※작업 중 시행착오※

• pm2, node와 관련된 명령어 찾을 수 없음 오류
  

  • 설치가 안되어있어 나는 경우도 있지만 나같은 경우 절대 경로로 선언해주니 정상 동작함

• 권한 없음 오류

  

  • gitlab-runner 계정과 ubuntu, root 계정들을 돌아다니면서 테스트했더니 나는 것으로 파악되었음 >> gitlab-runner 계정으로 통일 했더니 해결

• -sudo npm start 무한 루프

  script:
  	- sudo -E env "PATH=$PATH" npm start

  • 당연함. 하지만 겪기전까진 예상하지 못함^^ >> pm2를 통해 백그라운드에서 서버가 실행될 수 있도록 함

변경사항을 푸시해주고 이제 파이프라인이 잘 동작하는지 확인해보자.

결과

파이프라인 확인

deploy 로그 확인

• pm2 list 확인 시 동작하는 프로세스가 없음을 확인할 수 있다.
• pm2 start && save 이후 테스트 서버가 무사히 동작 중임을 확인할 수 있다.

홈페이지 접근 확인

test-server에서 개발된 소스를 product-server로 배포하기까지의 과정을 담아봤다. 단순히 EC2에 node를 설치한 환경에 배포하는 과정일 뿐인데 삽질을 참 많이 하게됐다. 그러면서 드는 생각은 도커를 활용하여 배포하는 것이 훨씬 수월하고 많이 사용되는 방법이 아닐까 싶었다.

일경험 회사의 서비스 환경은 지금 테스트한 환경과 동일하게 EC2로 운영되고있다. 이미 장애 없이 잘 돌아가고 있는 서비스를 위험하게 만들 수는 없기 때문에 아마 CD가 아닌 CI 과정만 적용해야겠다.

이것만으로도 충분한 개선이라고 판단하고있다. (왜냐면 소스를 복사 붙여넣기로 하고있었음)

CI만 적용하는 과정이기에 더이상 관련된 포스팅은 안 할 수도 있겠다. 하지만 일경험 회고를 통해 프로세스를 개선한 후기도 함께 작성하면 좋겟다! 아듀!!

[참고]
https://docs.gitlab.com/ee/topics/build_your_application.html
https://velog.io/@leesomyoung/CICD%EB%A5%BC-%EC%9C%84%ED%95%9C-gitlab-pipeline-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0#2-gitlab-runner-%EC%84%A4%EC%B9%98-%EB%B0%8F-%EB%93%B1%EB%A1%9D