오늘날의 소프트웨어 개발 환경에서는 빠른 배포와 지속적인 통합이 필수적입니다. GitOn은 이러한 DevOps 흐름을 지원하는 강력한 도구로, CI/CD 파이프라인을 통해 소스 코드의 통합, 빌드, 테스트, 배포 과정을 자동화합니다. GitOn에서 CI/CD를 효과적으로 수행하기 위해서는 먼저 Agent를 등록해야 하며, 이 과정은 GitOn의 핵심 기능 중 하나입니다.
Agent는 CI/CD 파이프라인을 실행하기 위해 서버에 설치되는 중요한 구성 요소로, 원격 서버에서 지속적인 빌드 및 배포를 가능하게 합니다. 만약 GitOn이 Docker로 설치되어 있거나 Kubernetes 클러스터가 구축되어 있다면, 별도의 Agent 설치 없이도 CI/CD 파이프라인을 바로 구성할 수 있습니다. 그렇지 않다면 원격 서버에 Agent를 설치하고, Job Executors를 설정해 각 작업의 실행 방식을 명확히 해야 합니다.
이번 블로그에서는 GitOn에서 Agent 등록부터 Job Executor 설정, 그리고 CI/CD 파이프라인 구성까지의 전체 과정을 Step-by-Step으로 함께 진행해보겠습니다.
1. Agent 등록
먼저 Agent 서버로 사용할 VM이나 Bare Metal 서버(예: EC2와 같은 클라우드 서버)를 준비해야 합니다. GitOn Agent는 설치 방식에 따라 두 가지 방법으로 설치할 수 있습니다.
첫번째는 Docker를 통한 DooD(Docker out of docker) 방식으로, 도커 소켓(/var/run/docker.sock)을 컨테이너 내부와 호스트가 공유하여 컨테이너 내부에서 호스트의 도커를 사용할 수 있는 방식입니다.
이 방식에서는 원격 호스트에 Docker Daemon이 사전에 설치되어 있어야 하며, DooD 방식은 Dind (Docker in Docker) 방식과 비교해 보안 이슈가 존재하지 않아 상대적으로 더 권장되는 방법입니다.
두번째는 호스트에 agent배포에 필요한 설치파일을 다운받아서 Script를 통해 agent를 서비스등록 형태로 설치하는 방식입니다.
이 방식은 원격 호스트의 shell 환경에서 명령어를 통해 빌드 작업이나 배포를 해야할 경우 필수적으로 해당방법으로 agent등록을 진행하셔야 합니다.
이번 구성에서는 두 가지 방법 모두를 사용하여 agent를 등록해보고, CI/CD Pipeline에서 활용해보도록 하겠습니다.
우선 첫번째 방식으로 Docker 데몬이 설치된 호스트에 Docker command를 통해 agent를 설치해보겠습니다. 해당 방법은 agent의 job이 전부 docker container내에서 수행되기 때문에 원격 호스트에 shell형태로 command 작업이 필요할 경우에는 제약이 있습니다.
Administration -> Agents탭 -> +버튼을 누르면 ‘Run via Docker Container’ -> Show command를 통해 배포 가능한 command가 표시됩니다.
Ex) Docker 배포 command 예시:
docker run -t -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd)/agent/work:/agent/work -e serverUrl=https://giton.example.com -e agentToken=6daa49bc-3534-43a8-aa35-01e59a45123b -h myagent 1dev/agent
해당 command를 복사 후 Docker 데몬이 설치된 원격 호스트에 그대로 붙여넣기하여 배포를 진행하겠습니다.
위 이미지처럼 Docker command를 통해 agent가 배포된 모습을 확인 할 수 있습니다.
이어서 원격 호스트에 압축파일을 받아서 agent.sh 명령으로 agent를 배포해보겠습니다. (이전에 docker로 agent를 배포했던 동일한 서버에 agent 등록을 진행하겠습니다.)
위 이미지처럼 Docker command를 통해 agent가 배포된 모습을 확인 할 수 있습니다.
이렇게 해서 docker 설치 및 서비스 등록 두 Type의 agents 배포가 잘 되었습니다.
2. Job Executor 등록
이어서 Job Executor의 등록을 통해 배포해둔 agent와 매칭 시켜보겠습니다.
첫번째로 원격 docker agent와 매칭될 Remote Docker Executor를 등록해보겠습니다.
Administration -> Job executors 메뉴로 진입 후 Add Executor를 통해 새로운 Executor를 생성해보겠습니다.
Type은 아래와 같이 총 4가지가 존재합니다.
- Kubernetes Executor – k8s cluster에 의해 수행되는 executor
- Server Docker Executor – docker로 설치된 Giton 서버에서 수행되는 docker executor
- Remote Docker Executor – 원격 호스트에서 docker로 설치된 agent 매칭 시 선택
- Remote Shell Executor – 원격 호스트에서 agent.sh로 설치된 agent 매칭 시 선택
3. CI/CD Pipeline 구성
이제 GitOn의 Builds 기능으로 넘어가서 CI/CD Pipeline까지 구성해보겠습니다. CI/CD Pipeline 구성을 하려면 빌드 및 배포를 수행하려는 프로젝트가 필요합니다. (데모를 위해 NodeJS기반 심플한 웹앱 프로젝트를 GitOn에 미리 준비 해두었습니다.)
NodeJS 앱을 Docker Image형태로 빌드 한 후, 해당 Image를 원격 호스트에서 CI/CD Pipeline을 통해 배포를 했을 때의 모습입니다.
이제 CI/CD Pipeline을 어떻게 구성하는지 알아보도록 하겠습니다. GitOn에서 CI/CD 구성을 위한 yaml 파일명은 .onedev-buildspec.yml 입니다. 해당 파일을 프로젝트에 추가할 경우 UI상태에서 Pipeline steps를 구성할 수 있는 메뉴가 표시되게 됩니다.
위 이미지와 같이 ‘+ Add New’ 버튼을 누르게 되면 우측에 새로운 Job을 등록할 수 있는 GUI Editor 메뉴가 표시되게 됩니다. Name은 식별이 가능하게끔 ‘Build & Push to the package registry’ 와 같이 적고 Job Executor는 이전에 만들어둔 remote docker executor를 가진 name을 지정해줍니다.
이후 Steps를 통해 어떤 Type을 순차대로 수행할 것인지 구성이 가능합니다. 초기에 등록할 Job은 Dockerfile을 docker image로 빌드해서 GitOn내의 Package Registry에 Push하는 절차를 등록하겠습니다.
*(사내의 Private registry 혹은 Public registry를 등록해도 무방합니다.)
첫번째로 Checkout Code Type을 눌러 step을 생성해주겠습니다. 이때 name은 식별이 가능하게 ‘checkout’ 으로 적고 나머지 설정은 Skip하겠습니다. Checkout Code step은 Build작업을 수행하기 위해 프로젝트 내 소스코드를 agent에 내려받기 위한 필수 step입니다.
두번째로 Docker Image -> Build Image Type을 눌러 step을 생성해주겠습니다. Name을 ‘docker-image-build-and-push’ 와 같이 적어주고 Build Path 및 Dockerfile은 프로젝트의 루트경로에 Dockerfile이 존재한다면 공란으로 비워 둡니다. Output은 Container registry에 Image를 Push하기위해 Push to Container registry가 되도록 설정해줍니다.
Tags 설정은 docker Image의 tag를 어떻게 지정하여 registry에 push할것인지를 설정하는 항목입니다. 이번 경우는 GitOn내의 Package registry에 push해주기위해 아래와 같이 ‘@build_number@’ 변수와 ‘latest’ 두 개의 tags로 설정을 해두었습니다.
ex) ‘<GitOn URL>/<project name>/@project_name@:@build_number@ <GitOn URL>/<project name>/@project_name@:latest’
이때 ‘project_name’ 및 ‘build_number’ 변수는 GitOn내에서 제공하는 시스템 변수이며, 변수사이를 ‘@@’로 감싸서 표현할 수 있습니다. GitOn에서 제공하는 시스템 변수에 대한 자세한 내용은 아래에서 참고 가능합니다.
Condition부분은 default값인 ‘All previous steps were successful’ 로 놔두면 됩니다. ‘More Settings’ 부분을 클릭하면 하단에 ‘Registry Logins’ 설정이 나오게 됩니다. Docker Image를 빌드한 후 어떤 registry에 push할지를 여기에서 설정할 수 있습니다.
데모에서는 GitOn의 Package registry에 push를 진행할 예정이기 때문에, Registry URL에 <GitOn URL> 을 넣고 username 및 password를 넣어 주겠습니다.
GitOn내 Package registry는 registry 주소가 사내 GitOn의 도메인명이 되겠습니다. 그리고 username 및 password 는 GitOn내에서 사용하는 계정이 됩니다. Username에 GitOn의 Id를 넣어 주고, password는 권한이 없는 사용자가 build yml spec에서 password를 보지 못하게 build job secret 변수를 사전에 등록해두어 해당 변수를 불러올 수 있게 해야 합니다.
잠시 새 창을 띄우고 GitOn으로 접속한 다음, 내 Project 접근 (ex: <GitOn URL>/<project name>) -> Settings ->Build -> Job Secrets -> + Add New 경로를 통해서 아래와 같이 Package registry에 대한 password값을 변수로 등록할 수 있습니다.
이외에도 외부에 노출이 되면 안되는 credential 값인 DB password, build에서 참조되는 시스템 password 값 등을 여기에서 지정을 하면 build spec내에서 자유롭게 참조가 가능합니다.
다시 steps화면으로 돌아와서 password secret 부분에 방금 등록한 package registry의password credential을 리스트에서 불러와 선택하면 됩니다.
Platforms부분에는 ‘linux/amd64,linux/arm64’ 라는 값을 입력해주겠습니다.
CPU Architecture의 종류는 다양하며, 예를 들어 x86_64, x86(386), ARM64, ARM32, MIPS 등이 있습니다.
쉽게 예를들어 MAC OS에서는 2020년부터 Apple Silicon(ARM64)기반 아키텍처를 사용하고 Linux서버 에서는 Intel, AMD기반의 AMD64 아키텍처를 사용하는 경우가 많습니다.
따라서 어떤 아키텍처 환경에서든 Image Build시 호환성을 위해 Multi 아키텍처로 이미지를 빌드할 필요성이 있습니다.
Platforms부분에 범용적으로 사용하는 linux/amd64 및 linux/arm64 아키텍처를 정의하여 Image build시 Multi Architecture build가 가능하게 설정 해두었습니다.
마지막으로 Save를 통해 저장해줍니다, 이렇게 해서 Build Image Type에 대한 step설정을 완료하였습니다.
4. 트리거 설정
다음은 Params & Trigger설정에서 branch가 업데이트 될 때 해당 Job이 자동으로 수행될 수 있도록 Trigger를 설정하겠습니다.
우선 Params & Trigger 설정을 눌러 하단의 Trigger 의 + 버튼을 눌러줍니다. Type에서 Branch update를 클릭해준 후, Branches 옵션에 `*` 를 넣어서 모든 브랜치에서 업데이트가 발생했을 때 해당 Job이 자동 실행되도록 Trigger를 설정 하겠습니다.
지금까지 docker image build 및 package registry에 docker Image를 push하는 과정까지의 Job을 만들어보았습니다.
다음으로는 Deploy Job을 새로 등록하여 새로운 Image가 push될 때마다 원격 호스트에서 최신 이미지를 Pull받아서 자동 배포 하는 Job을 등록해보겠습니다.
+ Add New버튼을 통해 새로운 Job을 등록하는 버튼을 클릭하고, Name과 Job Executor를 이전에 등록한 Remote shell executor로 지정합니다.
첫번째로 +버튼을 통해 Execute Commands type을 눌러 step을 생성해주겠습니다.
Name을 deployment와 같이 식별이 가능하게 적어주고, 원격호스트의 Shell에서 수행할 예정이기 때문에 ‘Run In Container’ 옵션을 비활성화 해주겠습니다.
Interpreter는 기존 값인 ‘Default(Shell on Linux, Batch on Windows)’ 로 두고, Commands부분에는 아래와 같이 script내용을 정의해주겠습니다.
sh
echo "Sign in to the GitOn package registry"
echo @secret:<GitOn URL>@ | docker login <GitOn URL> -u <GitOn Id> --password-stdin
echo "pulling for the latest container image"
docker pull <GitOn URL>/<project name>/<container_name>:latest
echo "Delete the old deployed container"
docker ps --filter "name=<container_name>" -q | xargs -r docker rm -f
echo "Deploy the new deployment container"
docker run -id -p <Host bind port>:8000 --name <container_name>
<GitOn URL>/<project name>/<container_name>:latest
* <>부분으로 감싸진 부분은 자신의 환경에 맞게 Replace해서 채워 넣으면 됩니다.
스크립트의 내용을 간략히 요약하면 ① GitOn의 Package registry에 로그인 후, ② 최신 docker Image를 Pull 받고, ③ 기존 배포된 Old 컨테이너가 존재하면 삭제를 진행해준 다음, ④ 최신 docker Image를 docker command를 이용해서 Run하는 과정까지 정의 되어있습니다.
Remote Shell Executor Type의 Job Executor가 쓰인 이유는 이렇게 원격 호스트에서 컨테이너 배포 자동화를 하려면 Shell형태로 command를 실행 해줘야 하기 때문이며, 이는 필수적인 설정 부분입니다.
이어서 Params & Triggers 부분을 눌러주고 Triggers부분에서 +버튼을 눌러 Job Trigger부분을 정의해주겠습니다. Type을 Branch Update로 지정해주고 Branches에는 ‘*’ 를 입력하고 Applicable Projects옵션에는 현재 작업을 진행중인 Project명을 넣어 주시고 Save하면 됩니다.
ex) node_demo_app
이로서 Branch Update가 발생했을 때 자동으로 Job이 수행되도록 설정이 완료되었습니다.
마지막으로 하단의 Dependencies & Services 부분을 클릭한다음 Job Dependencies 하단의 +버튼을 클릭해주겠습니다.
Job은 이전에 만든 Job name인 ‘Build & Push to package registry’ 를 선택하고, 나머지 설정은 그대로 둔 채 Save하여 Job에 대한 Dependency를 생성해주었습니다.
첫번째 Job인 Image build 및 package registry로 최신 Image의 push가 끝나야지만 두번째 Job에서 최신 이미지를 Pull받아서 지속적인 재 배포 자동화 작업을 진행할 수 있습니다.
좌측 상단에 Save를 눌러 CI/CD Pipeline 설정을 저장해주겠습니다.
Save를 직접 진행 해보거나 위 화면을 보면, 동시에 CI/CD Pipeline이 수행되는 모습을 확인 할 수 있습니다. 이는 mater branch에서 ‘.onedev-buildspec.yml’ 파일을 수정해서 push한거나 마찬가지기 때문에, branch update trigger가 걸려서 Job이 자동으로 수행되게 됩니다.
Package탭으로 이동해서 하나의 Image를 클릭해보면 이전 Job의 Platform옵션에서 정의했던 Multi Architecture Image가 잘 등록되어 있는 것을 확인할 수 있습니다.
또한 CI/CD Pipeline이 시간이 흐른 후 성공적으로 마치게 되면, 웹앱 URL 접근 시 최신 docker image로 재 배포 되어 있는 것을 확인할 수 있습니다.
지금까지 Agent 등록부터 Job Executor 설정, 그리고 CI/CD Pipeline까지의 구성에 대해 Step-by-Step으로 자세히 진행해보았습니다. GitOn을 통한 Agent 등록부터 GUI상에서 쉽게 원하는 대로 CI/CD Pipeline을 구성하는 방법을 습득하는데 많은 도움이 되었으면 좋겠습니다.
다음 블로그에는 GitOn에서의 Issue관리 및 Pull Request를 통해 Git 협업 플랫폼에서 어떻게 소스코드를 관리하는지, 그 흐름을 자세히 살펴보도록 하겠습니다.
