GitLab CI/CD 인스턴스 구성
GitLab 관리자는 자체 설치된 인스턴스의 GitLab CI/CD 구성을 관리할 수 있습니다.
새 프로젝트에서 GitLab CI/CD 비활성화
GitLab CI/CD는 기본적으로 모든 새 프로젝트에서 활성화됩니다. 새 프로젝트에서 CI/CD를 기본적으로 비활성화하려면 다음과 같이 설정을 수정할 수 있습니다.
- 자체 컴파일 설치의 경우
gitlab.yml
. - Linux 패키지 설치의 경우
gitlab.rb
.
이미 CI/CD가 활성화된 기존 프로젝트는 변경되지 않습니다. 또한 이 설정은 프로젝트 기본값만 변경하므로 프로젝트 소유자는 프로젝트 설정에서 CI/CD를 여전히 활성화할 수 있습니다.
자체 컴파일 설치의 경우:
-
편집기로
gitlab.yml
을 열고builds
를false
로 설정합니다:## Default project features settings default_projects_features: issues: true merge_requests: true wiki: true snippets: false builds: false
-
gitlab.yml
파일을 저장합니다. -
GitLab을 재시작합니다:
sudo service gitlab restart
Linux 패키지 설치의 경우:
-
/etc/gitlab/gitlab.rb
을 편집하고 다음 줄을 추가합니다:gitlab_rails['gitlab_default_projects_features_builds'] = false
-
/etc/gitlab/gitlab.rb
파일을 저장합니다. -
GitLab을 재구성합니다:
sudo gitlab-ctl reconfigure
needs
작업 한도 설정
needs
에서 정의할 수 있는 작업의 최대 수는 기본적으로 50으로 설정됩니다.
GitLab 관리자는 GitLab Rails 콘솔에 액세스하여 사용자 정의 한도를 선택할 수 있습니다. 예를 들어, 한도를 100
으로 설정하려면:
Plan.default.actual_limits.update!(ci_needs_size_limit: 100)
방향성 비순환 그래프(DAG)를 비활성화하려면 한도를 0
으로 설정합니다. 그런 다음 needs
를 사용하여 구성된 작업을 수행하는 파이프라인은 오류 job can only need 0 others
를 반환합니다.
최대 예약된 파이프라인 빈도 변경
예약된 파이프라인은 모든 cron 값을 구성할 수 있지만 항상 정확한 시간에 실행되는 것은 아닙니다. 내부 프로세스인 파이프라인 예약 워커가 모든 예약된 파이프라인을 대기열에 넣지만 계속해서 실행되지는 않습니다. 워커는 고유한 일정에 따라 실행되며 준비된 예약된 파이프라인은 워커가 다음으로 실행될 때만 대기열에 넣습니다. 예약된 파이프라인은 워커보다 더 자주 실행할 수 없습니다.
파이프라인 예약 워커의 기본 빈도는 3-59/10 * * * *
(10분마다, 0:03
, 0:13
, 0:23
등으로 시작)입니다. GitLab.com의 기본 빈도는 GitLab.com 설정에 나와 있습니다.
파이프라인 예약 워커의 빈도를 변경하려면:
- 인스턴스의
gitlab.rb
파일에서gitlab_rails['pipeline_schedule_worker_cron']
값을 편집합니다. - 변경 사항이 적용되려면 GitLab을 재구성합니다.
예를 들어, 파이프라인의 최대 빈도를 하루에 두 번으로 설정하려면 pipeline_schedule_worker_cron
을 0 */12 * * *
(매일 00:00
과 12:00
)로 설정합니다.
재해 복구
지속적인 다운타임 중 데이터베이스에 가중 부담을 줄이기 위해 애플리케이션의 중요하지만 계산적으로 비용이 많이 드는 부분을 비활성화할 수 있습니다.
인스턴스 러너에서 공정한 스케줄링 비활성화
대량의 작업 대기열을 지울 때, ci_queueing_disaster_recovery_disable_fair_scheduling
피처 플래그를 임시로 활성화할 수 있습니다. 이 플래그는 인스턴스 러너에서 공정한 스케줄링을 비활성화하여 jobs/request
엔드포인트에서 시스템 리소스 사용을 줄입니다.
활성화되면 시스템은 프로젝트 전체에 고르게 분산되는 대신 시스템에 넣은 순서대로 작업이 처리됩니다.
계산 할당량 강제 비활성화
인스턴스 러너에서 계산 할당량 강제 적용을 비활성화하려면 ci_queueing_disaster_recovery_disable_quota
피처 플래그를 임시로 활성화할 수 있습니다. 해당 플래그는 jobs/request
엔드포인트에서 시스템 리소스 사용을 줄입니다.
활성화되면 지난 1시간 동안 생성된 작업은 할당량을 초과한 프로젝트에서 실행될 수 있습니다. 이전 작업은 주기적인 백그라운드 워커(StuckCiJobsWorker
)에 의해 이미 취소되었습니다.
CI/CD 문제 해결 Rails 콘솔 명령어
다음 명령어들은 Rails 콘솔에서 실행됩니다.
대기 중인 파이프라인 취소
project = Project.find_by_full_path('<project_path>')
Ci::Pipeline.where(project_id: project.id).where(status: 'pending').count
Ci::Pipeline.where(project_id: project.id).where(status: 'pending').each {|p| p.cancel if p.stuck?}
Ci::Pipeline.where(project_id: project.id).where(status: 'pending').count
Merge Request 통합 시도
project = Project.find_by_full_path('<project_path>')
mr = project.merge_requests.find_by(iid: <merge_request_iid>)
mr.project.try(:ci_integration)
.gitlab-ci.yml
파일 유효성 검사
project = Project.find_by_full_path('<project_path>')
content = p.ci_config_for(project.repository.root_ref_sha)
Gitlab::Ci::Lint.new(project: project, current_user: User.first).validate(content)
기존 프로젝트에서 AutoDevOps 비활성화
Project.all.each do |p|
p.auto_devops_attributes={"enabled"=>"0"}
p.save
end
러너 등록 토큰 얻기
Gitlab::CurrentSettings.current_application_settings.runners_registration_token
Seed runners registration token
appSetting = Gitlab::CurrentSettings.current_application_settings
appSetting.set_runners_registration_token('<새로운-runners-registration-token>')
appSetting.save!
파이프라인 스케줄 매뉴얼 실행
보통은 보이지 않는 오류를 확인하기 위해 Rails 콘솔을 통해 파이프라인 스케줄을 매뉴얼으로 실행할 수 있습니다.
# schedule_id는 편집 파이프라인 스케줄 페이지에서 얻을 수 있습니다
schedule = Ci::PipelineSchedule.find_by(id: <schedule_id>)
# 스케줄을 실행할 사용자를 선택합니다
user = User.find_by_username('<username>')
# 스케줄 실행
ps = Ci::CreatePipelineService.new(schedule.project, user, ref: schedule.ref).execute!(:schedule, ignore_skip_ci: true, save_on_errors: false, schedule: schedule)