Gitlab-CI 관측 가능성 모범 사례¶

GitLab¶

GitLab은 GitLab Inc.에서 개발했으며, MIT 라이선스를 사용하는 웹 기반의 Git 리포지토리 관리 도구로, wiki 및 이슈 추적 기능을 갖추고 있습니다. Git을 코드 관리 도구로 사용하며, 이를 기반으로 구축된 웹 서비스입니다.

CI/CD¶

CI/CD는 지속적 통합(Continuous Integration: CI), 지속적 전달(Continuous Delivery: CD), 지속적 배포(Continuous Deployment: CD)의 약자입니다.
지속적 통합의 핵심은 여러 개발자의 작업을 하나의 코드 리포지토리에 통합하는 것입니다. 일반적으로 하루에 여러 번 수행되며, 주된 목적은 통합 오류를 조기에 발견하여 팀의 결속력을 강화하고 협업을 원활하게 하는 것입니다.
지속적 전달은 배포 또는 릴리스 과정에서 발생하는 고유한 마찰을 최소화하는 것을 목표로 합니다. 이를 구현하면 빌드 배포의 각 단계를 자동화하여 언제든지 안전하게 코드를 릴리스할 수 있습니다(이상적으로).
지속적 배포는 더 높은 수준의 자동화로, 코드에 중요한 변경이 있을 때마다 자동으로 빌드/배포를 수행합니다.
몇 가지 CI/CD 도구:

Jenkins

GitLab CI

Travis CI

GoCD

GitLab CI¶

GitLab CI/CD(이하 GitLab CI)는 GitLab 기반의 CI/CD 시스템으로, CI/CD 분야의 후발 주자이지만 이미 Forrester Wave 지속적 통합 도구에서 선두 자리를 차지하고 있습니다. 개발자는 .gitlab-ci.yml을 통해 프로젝트에 CI/CD 파이프라인을 구성할 수 있으며, 커밋 후 시스템이 자동/수동으로 작업을 실행하여 CI/CD 작업을 완료합니다. 또한 구성이 매우 간단하며, CI Runner는 Go 언어로 작성되어 최종적으로 단일 파일로 패키징되므로, Runner 프로그램 하나와 jobs 실행 플랫폼(예: 베어메탈 + SSH, Docker 또는 Kubernetes 등, Docker를 권장합니다. 구축이 매우 쉽기 때문입니다)만 있으면 완전한 CI/CD 시스템을 실행할 수 있습니다.

Guance¶

"Guance"는 클라우드 시대의 시스템 관측 가능성 플랫폼입니다. 이 플랫폼은 인프라, 로그, 메트릭, 이벤트, 애플리케이션 성능 모니터링(APM), 실제 사용자 모니터링(RUM), 신서틱 모니터링, 시스템 수준 보안 점검 등의 기능 모듈을 포함하며, 이러한 기능에서 생성되는 Logging, Metrics, Tracing 세 가지 유형의 데이터에 대한 전체 연결 수준의 데이터 분석 및 인사이트 기능을 제공합니다. H5, iOS, Android, 미니 프로그램 등 다양한 애플리케이션을 완벽하게 지원하며, 사용자 액세스 행동 및 실제 경험을 완전히 추적할 수 있도록 하여 페이지 성능, 리소스 호출, 오류 알림, 비즈니스 액세스 등 일련의 데이터 및 분석 뷰를 제공합니다. 분산 추적과 연동하여 애플리케이션 성능과 각 요청 뒤의 실제 요구 사항을 실시간으로 파악할 수 있도록 지원합니다. 유연한 시나리오 레이아웃, 다양한 차트 선택, 드래그 앤 드롭 상호 작용 경험을 통해 사용자 맞춤형 대시보드를 쉽게 구축할 수 있습니다. 통합된 데이터 쿼리 방식을 지원하며, 다양한 데이터 유형을 구성할 수 있어 간편하게 사용할 수 있습니다.

DataKit¶

DataKit은 Guance의 오픈소스 수집 도구입니다. 오픈소스 주소: https://github.com/DataFlux-cn/datakit

배경 소개¶

마이크로서비스가 점점 보편화되면서 기업은 기존의 모놀리식 서비스 아키텍처에서 마이크로서비스 아키텍처로 전환하기 시작했습니다. 마이크로서비스의 특징 중 하나는 많은 엔지니어링 모듈로 구성되어 배포가 상대적으로 번거롭다는 점입니다. CICD 도구는 통합 전달 및 배포를 잘 지원하지만, 배포 과정에서 발생하는 일부 문제를 통계적으로 분석하기는 어렵습니다. Guance의 강력한 관측 기능과 사용자 정의 뷰 기능을 활용하면 소프트웨어의 지속적 배포 과정에서 발생하는 문제를 효과적으로 확인하고 분석할 수 있습니다.

아키텍처 흐름¶

개발자가 코드를 커밋 및 푸시합니다.

GitLab Runner가 GitLab에 등록합니다.

GitLab 트리거가 GitLab-CI를 실행합니다.

GitLab-CI 실행 완료 후, webhook을 트리거하여 데이터를 DataKit으로 푸시합니다.

DataKit이 태그를 추가하여 Guance 플랫폼으로 푸시합니다.

사전 조건¶

DataKit 설치
DataKit 수집 버전 >= 1.2.13

DataKit에서 GitLab-CI 활성화¶

gitlab.conf 편집¶

cd conf.d/gitlab cp gitlab.conf.sample gitlab.conf

gitlab.conf 전체 내용

[[inputs.gitlab]]
## 아래 URL에서 메트릭을 수집해야 하는 경우 true로 설정
enable_collect = false

## param type: string - default: http://127.0.0.1:80/-/metrics
prometheus_url = "http://127.0.0.1:80/-/metrics"

## param type: string - optional: time units are "ms", "s", "m", "h" - default: 10s
interval = "10s"

## datakit은 활성화 시 /v1/gitlab에서 gitlab ci 데이터를 수신 대기할 수 있음
enable_ci_visibility = true

## gitlab-ci 데이터에 대한 추가 태그.
## 이 태그는 기존 태그를 덮어쓰지 않음.
[inputs.gitlab.ci_extra_tags]
# some_tag = "some_value"
# more_tag = "some_other_value"

## gitlab 메트릭에 대한 추가 태그
[inputs.gitlab.tags]
# some_tag = "some_value"
# more_tag = "some_other_value"

매개변수 설명
enable_collect: false # 메트릭 수집 비활성화
prometheus_url : 메트릭 수집 주소
enable_ci_visibility: true # gitlab-ci 활성화

DataKit 재시작¶

datakit --restart

GitLab 설치 및 구성¶

이미 설치된 경우 무시하세요.

Docker로 GitLab 설치¶

docker run --name=gitlab -d -p 8899:8899 -p 2443:443 --restart always --volume /data/midsoftware/gitlab/config:/etc/gitlab --volume /data/midsoftware/gitlab/logs:/var/log/gitlab --volume /data/midsoftware/gitlab/data:/var/opt/gitlab docker.io/gitlab/gitlab-ce

포트 설명

포트	설명
8899	GitLab UI 포트
2443	GitLab SSL 포트

설정 파일 수정: gitlab.rb¶

# 접속 주소
external_url 'http://192.168.91.11:8899'

# 타임아웃 시간 설정, 기본값 10(단위: s)
gitlab_rails['webhook_timeout'] = 60

GitLab 재시작¶

docker restart gitlab

GitLab 버전 확인¶

[root@middle config]# docker exec -it gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
14.6.2

GitLab 초기 비밀번호 확인¶

[root@middle config]# docker exec -it gitlab cat /etc/gitlab/initial_root_password |grep Password
#          2. 비밀번호가 UI 또는 명령줄을 통해 수동으로 변경되지 않았습니다.
Password: yBY9toQ0SJ8fxh3mndHPzfWclVUDZ/J8e8O4bDsal2E=

계정은 root이며, 브라우저로 http://ip:8899에 접속하여 비밀번호를 변경합니다.

첫 번째 프로젝트 생성¶

menu -> Projects -> your projects -> new projects -> create blank project 선택. 프로젝트 이름을 입력합니다.

GitLab Runner 설치 및 구성¶

이미 설치된 경우 무시하세요.

Docker로 GitLab Runner 설치¶

docker run -d --name gitlab-runner --restart always \
    -v /data/midsoftware/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest

GitLab Runner 인증 키¶

GitLab Runner는 현재 전역 구성을 지원하지 않으므로, Runner의 키는 프로젝트 내에서만 확인할 수 있습니다. 방금 생성한 프로젝트로 이동하여 settings -> runners를 선택하고 키를 복사합니다. 다음 Runner 등록 시 필요합니다.

GitLab Runner를 GitLab에 등록¶

docker run --rm -v /data/midsoftware/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:latest \
  --url "http://192.168.91.11:8899" \
  --registration-token "U6uhCZGPrZ7tGs6aV8rY" \
  --description "gitlab-runner" \
  --tag-list "docker,localMachine" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

매개변수 설명

매개변수 이름	값	설명
executor	docker	다른 것을 사용하거나 이 매개변수를 제거할 수 있습니다. Docker 환경에 배포하려면 docker를 선택하는 것이 좋습니다.
docker-image	alpine:latest	docker-image 버전, executor와 함께 사용
url	http://192.168.91.11:8899	GitLab 접속 주소
registration-token	token	GitLab admin 토큰
description	gitlab-runner	설명 정보
tag-list	docker,localMachine	태그에 따라 해당 executor를 선택할 수 있습니다.

더 많은 매개변수는 다음을 참조하세요: https://docs.gitlab.com/runner/configuration/advanced-configuration.html

GitLab Webhook 구성¶

방금 생성한 프로젝트로 이동하여 Settings -> Webhooks를 선택하고 url을 입력한 후, pipeline events를 선택하고 저장합니다.

설명:

url: http:///v1/gitlab

Job events 활성화

Pipeline events 활성화

Test -> Pipeline events를 선택하면 파이프라인 이벤트가 트리거되어 데이터가 방금 구성한 webhook 주소로 푸시됩니다. 상태를 확인하여 이 과정이 정상적인지 검증합니다.

.gitlab-ci.yml 작성¶

방금 생성한 프로젝트로 이동하여 CI/CD -> Editor를 선택합니다.

스크립트 내용을 작성합니다. 내용은 다음과 같습니다:

# 실행 이미지 설정
image: busybox:latest

# 전체 파이프라인에는 두 개의 stage가 있음
stages:
  - build
  - test

before_script:
  - echo "Before script section"

after_script:
  - echo "After script section"


build_job:
  stage: build
  only:
    - master
  script:
    - echo "캐시에 내용 쓰기"
    - sleep 80s
    # - d ps 

test_job:
  stage: test
  script:
    - echo "캐시에서 내용 읽기"

저장을 클릭하면 CICD가 자동으로 트리거되며, 트리거 후 과정이 webhook을 통해 방금 구성한 webhook 주소로 푸시됩니다.

webhook 푸시 기록 확인¶

상태 200은 푸시 성공을 의미합니다.

Guance¶

파이프라인이 성공적으로 푸시되면, Guance 플랫폼을 통해 대시보드와 탐색기를 사용하여 파이프라인 실행 전체 상황을 시각적으로 관측할 수 있습니다.

CI 탐색기¶

메뉴 CI 탐색기를 통해 gitlab_pipeline 및 gitlab_job 상세 정보를 확인합니다.

gitlab_pipeline:

gitlab_job:

상세 정보를 클릭하면 플레임 그래프와 job 목록을 확인할 수 있습니다.
플레임 그래프

CI 요약¶

CI 요약에서는 GitLab-CI 파이프라인 및 job 실행 상황을 확인할 수 있습니다. 예: 파이프라인 실행 성공률, 실행 시간, job 실행 성공률, 실행 시간 등.

Gitlab-CI 관측 가능성 모범 사례¶

GitLab¶

CI/CD¶

GitLab CI¶

Guance¶

DataKit¶

배경 소개¶

아키텍처 흐름¶

사전 조건¶

DataKit에서 GitLab-CI 활성화¶

gitlab.conf 편집¶

DataKit 재시작¶

GitLab 설치 및 구성¶

Docker로 GitLab 설치¶

설정 파일 수정: gitlab.rb¶

GitLab 재시작¶

GitLab 버전 확인¶

GitLab 초기 비밀번호 확인¶

첫 번째 프로젝트 생성¶

GitLab Runner 설치 및 구성¶

Docker로 GitLab Runner 설치¶

GitLab Runner 인증 키¶

GitLab Runner를 GitLab에 등록¶

GitLab Webhook 구성¶

.gitlab-ci.yml 작성¶

webhook 푸시 기록 확인¶

Guance¶

CI 탐색기¶

CI 요약¶

이 페이지가 도움이 되었나요? ×

이 페이지가 도움이 되었나요?