GitLab CI/CD 인스턴스 구성
깆랩 관리자는 자신의 인스턴스에 대해 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을 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
러너 등록 토큰 시드 설정
appSetting = Gitlab::CurrentSettings.current_application_settings
appSetting.set_runners_registration_token('<new-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)
도움말