- 설치
- SSL 활성화
- GitLab 컨테이너 레지스트리 활성화
- Docker 데몬에 레지스트리 및 GitLab Runner 신뢰 설정
- GitLab Runner 활성화
- 패키지 메타데이터 데이터베이스 활성화
오프라인 Self-Managed형 GitLab 인스턴스 설치
이것은 완전히 오프라인에서 Self-Managed형 GitLab 인스턴스를 설치, 구성 및 사용하는 데 도움이 되는 단계별 가이드입니다.
설치
my-host.internal로 해결되고, 해당 서버에 필요한 패키지 파일을 다운로드하기 위해 인터넷에 액세스할 수 있는 다른 서버에 액세스할 수 있다고 가정합니다.이 프로세스에 대한 비디오 안내를 보려면 오프라인 GitLab 설치: 다운로드 및 설치를 참조하세요.
GitLab 패키지 다운로드
인터넷에 액세스할 수 있는 동일한 운영 체제 유형의 서버를 사용하여 매뉴얼으로 GitLab 패키지를 다운로드하고 관련 의존성을 매뉴얼으로 다운로드해야 합니다.
오프라인 환경에서 로컬 네트워크에 액세스할 수 없는 경우 필요한 패키지를 USB 드라이브와 같은 물리적 미디어를 통해 매뉴얼으로 전송해야 합니다.
Ubuntu에서 인터넷에 액세스할 수 있는 서버에서 다음 명령을 사용하여이 작업을 수행할 수 있습니다.
# 리포지터리를 준비하는 bash 스크립트 다운로드
curl --silent "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh" | sudo bash
# gitlab-ee 패키지 및 의존성을 /var/cache/apt/archives에 다운로드
sudo apt-get install --download-only gitlab-ee
# apt 다운로드 폴더의 내용을 장착된 미디어 장치로 복사
sudo cp /var/cache/apt/archives/*.deb /path/to/mount
GitLab 패키지 설치
전제 조건:
- 오프라인 환경에서 GitLab 패키지를 설치하기 전에 필요한 모든 의존성을 먼저 설치했는지 확인하세요.
Ubuntu를 사용하는 경우 dpkg를 사용하여 복사 한 .deb 패키지를 설치할 수 있습니다. 하지만 아직 GitLab 패키지를 설치하지 마십시오.
# 물리적 미디어 장치로 이동
sudo cd /path/to/mount
# 의존성 패키지 설치
sudo dpkg -i <package_name>.deb
패키지를 설치하는 방법은 여러분의 운영 체제에 맞는 관련 명령을 사용하세요. 설치한 후에는 SSL을 매뉴얼으로 구성할 수 있습니다.
서버의 IP 주소에 바인드하는 대신 IP 해결을 위한 도메인을 설정하는 것이 권장됩니다. 이렇게 하면 인증서의 CN에 대한 안정적인 대상이 보장되며 장기적인 해결이 간단해집니다.
Ubuntu의 경우 EXTERNAL_URL을 사용하여 EXTERNAL_URL을 지정하고 GitLab 패키지를 설치하는 다음 예제가 있습니다.
sudo EXTERNAL_URL="http://my-host.internal" dpkg -i <gitlab_package_name>.deb
SSL 활성화
새로 생성된 인스턴스에 대해 SSL을 활성화하려면 다음 단계를 따르세요. 이러한 단계는 Omnibus의 NGINX 구성에서 SSL을 매뉴얼으로 구성하는 단계를 반영합니다:
-
/etc/gitlab/gitlab.rb를 다음과 같이 변경하세요.# external_url을 "http"에서 "https"로 업데이트 external_url "https://my-host.internal" # Let's Encrypt를 false로 설정 letsencrypt['enable'] = false -
자체 서명 인증서를 생성하기 위해 다음과 같은 디렉터리를 생성하고 적절한 권한을 설정하세요.
sudo mkdir -p /etc/gitlab/ssl sudo chmod 755 /etc/gitlab/ssl sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/gitlab/ssl/my-host.internal.key -out /etc/gitlab/ssl/my-host.internal.crt -
변경 사항을 적용하려면 다음 명령을 실행하여 인스턴스를 재구성하세요.
sudo gitlab-ctl reconfigure
GitLab 컨테이너 레지스트리 활성화
컨테이너 레지스트리를 활성화하려면 다음 단계를 따르세요. 이러한 단계는 기존 도메인 아래 컨테이너 레지스트리를 구성하는 단계를 반영합니다:
-
/etc/gitlab/gitlab.rb를 다음과 같이 변경하세요.# external_registry_url을 external_url과 일치하도록 변경하되 포트 4567을 추가하세요. external_url "https://gitlab.example.com" registry_external_url "https://gitlab.example.com:4567" -
변경 사항을 적용하려면 다음 명령을 실행하여 인스턴스를 재구성하세요.
sudo gitlab-ctl reconfigure
Docker 데몬에 레지스트리 및 GitLab Runner 신뢰 설정
Docker 데몬에 인증서를 제공하여 레지스트리에서 신뢰하는 인증서를 사용하는 단계를 따르세요:
sudo mkdir -p /etc/docker/certs.d/my-host.internal:5000
sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/docker/certs.d/my-host.internal:5000/ca.crt
GitLab Runner에 인증서를 제공하여 다음 단계를 따라 실행 중인 Runner에 신뢰할 수 있는 인증서를 설치하세요.
sudo mkdir -p /etc/gitlab-runner/certs
sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/gitlab-runner/certs/ca.crt
GitLab Runner 활성화
Docker 서비스로서 GitLab Runner를 설치하는 단계와 유사한 프로세스를 따라 실행하기 위해 먼저 Runner를 등록해야 합니다:
$ sudo docker run --rm -it -v /etc/gitlab-runner:/etc/gitlab-runner gitlab/gitlab-runner register
CA 인증서 업데이트 중...
런타임 플랫폼 arch=amd64 os=linux pid=7 revision=1b659122 version=12.8.0
시스템 모드에서 실행 중입니다.
gitlab-ci 코디네이터 URL을 입력하세요 (예: https://gitlab.com/):
https://my-host.internal
이 러너에 대한 gitlab-ci 토큰을 입력하세요:
XXXXXXXXXXX
이 러너에 대한 gitlab-ci 설명을 입력하세요:
[eb18856e13c0]:
이 러너에 대한 gitlab-ci 태그를 입력하세요 (쉼표로 구분):
등록 중... 성공함 runner=FSMwkvLZ
실행자: custom, docker, virtualbox, kubernetes, docker+machine, docker-ssh+machine, docker-ssh, parallels, shell, ssh 중에서 선택하세요:
docker
기본 Docker 이미지를 입력하세요 (예: ruby:2.6):
ruby:2.6
러너(runner)가 성공적으로 등록되었습니다. 실행하려면 시작할 수 있지만 이미 실행 중인 경우 구성이 자동으로 다시로드됩니다!
이제 Runner에 몇 가지 추가 구성을 추가해야 합니다.
/etc/gitlab-runner/config.toml을 다음과 같이 변경하세요.
- 볼륨에 Docker 소켓 추가
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"] - 실행자 구성에
pull_policy = "if-not-present"를 추가하세요.
이제 Runner를 시작할 수 있습니다.
sudo docker run -d --restart always --name gitlab-runner -v /etc/gitlab-runner:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
90646b6587127906a4ee3f2e51454c6e1f10f26fc7a0b03d9928d8d0d5897b64
호스트 OS에 대한 레지스트리 인증
Docker 레지스트리 인증 문서에 언급된대로, 특정 버전의 Docker는 OS 수준에서 인증된 인증서 체인을 신뢰해야 합니다.
Ubuntu의 경우 다음과 같이 update-ca-certificates를 사용하여야 합니다.
sudo cp /etc/docker/certs.d/my-host.internal\:5000/ca.crt /usr/local/share/ca-certificates/my-host.internal.crt
sudo update-ca-certificates
모두 잘 되면 이렇게 보일 것입니다:
1개 추가, 0개 제거; 완료.
/etc/ca-certificates/update.d/에서 후킹 중...
완료.
버전 확인 및 서비스 핑 비활성화
버전 확인과 서비스 핑은 GitLab 사용자 경험을 개선하고, 사용자가 가장 최신의 GitLab 인스턴스에 있는지 확인합니다. 이 두 서비스는 오프라인 환경에서 GitLab 서비스에 연결을 시도하고 실패하지 않도록 끌 수 있습니다.
자세한 내용은 서비스 핑 켜기/끄기를 참조하세요.
NTP 구성
GitLab 15.4 및 15.5에서, Gitaly Cluster는 pool.ntp.org에 액세스 가능하다고 가정합니다. pool.ntp.org에 액세스할 수 없는 경우, Gitaly 및 Praefect 서버에서 시간 서버 설정 사용자화를 조정하여 접근 가능한 NTP 서버를 사용할 수 있도록 합니다.
오프라인 인스턴스에서는 항상 GitLab Geo check Rake task이 pool.ntp.org을 사용하므로 실패합니다. 이 오류를 무시할 수 있지만, 이를 해결하는 방법에 대해 더 읽어 볼 수 있습니다.
패키지 메타데이터 데이터베이스 활성화
패키지 메타데이터 데이터베이스를 활성화하면 지속적인 취약점 스캐닝 및 CycloneDX 파일의 라이선스 스캔를 가능하게 합니다. 이 프로세스는 패키지 메타데이터 데이터베이스라고 불리는 라이선스 및/또는 고려 사항 데이터의 사용을 요구하며, EE 라이선스에 따라 라이선스가 부여됩니다. 패키지 메타데이터 데이터베이스 사용에 대한 다음 사항을 주목하십시오.
- 우리는 재량에 따라 언제든지 페지 속의 패키지 메타데이터 데이터베이스 전체 또는 일부를 변경하거나 중단할 수 있습니다.
- 패키지 메타데이터 데이터베이스에는 제3자 웹사이트 또는 자원으로 연결될 수 있습니다. 이러한 링크는 편의를 위해 제공되었을 뿐이며, 해당 웹사이트나 자원에서 제공되는 제3자 데이터, 콘텐츠, 제품 또는 서비스에 대해서는 책임이 없습니다.
- 패키지 메타데이터 데이터베이스는 부분적으로 제3자가 제공한 정보를 기반으로 하며, GitLab은 해당 콘텐츠의 정확성이나 완전성에 대해 책임지지 않습니다.
패키지 메타데이터는 다음 Google Cloud Provider (GCP) 버킷에 저장됩니다.
- 라이선스 스캔 - prod-export-license-bucket-1a6c642fc4de57d4
- 의존성 스캔 - prod-export-advisory-bucket-1a6c642fc4de57d4
gsutil 도구를 사용하여 패키지 메타데이터 익스포트 다운로드
-
gsutil도구를 설치합니다. -
GitLab 레일스 디렉터리의 루트를 찾습니다.
export GITLAB_RAILS_ROOT_DIR="$(gitlab-rails runner 'puts Rails.root.to_s')" echo $GITLAB_RAILS_ROOT_DIR -
동기화할 데이터 유형을 설정합니다.
# 라이선스 스캔을 위해 export PKG_METADATA_BUCKET=prod-export-license-bucket-1a6c642fc4de57d4 export DATA_DIR="licenses" # 의존성 스캔을 위해 export PKG_METADATA_BUCKET=prod-export-advisory-bucket-1a6c642fc4de57d4 export DATA_DIR="advisories" -
패키지 메타데이터 익스포트를 다운로드합니다.
# 패키지 메타데이터 익스포트를 다운로드하려면 Google Cloud Storage 버킷으로의 아웃바운드 연결이 허용되어야 합니다. # v1 객체는 더 이상 사용되지 않으며 16.3부터 사용이 중지되었으므로 -y "^v1\/"를 사용하여 v2 객체만 다운로드합니다. mkdir -p "$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/$DATA_DIR" gsutil -m rsync -r -d -y "^v1\/" gs://$PKG_METADATA_BUCKET "$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/$DATA_DIR" # 또는 GitLab 인스턴스가 Google Cloud Storage 버킷에 연결할 수 없는 경우, 패키지 메타데이터 익스포트는 허용된 액세스를 가진 기계를 사용하여 다운로드한 후 GitLab 레일스 디렉터리의 루트로 복사할 수 있습니다. rsync rsync://example_username@gitlab.example.com/package_metadata/$DATA_DIR "$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/$DATA_DIR"
Google Cloud Storage REST API를 사용하여 패키지 메타데이터 익스포트 다운로드
Google Cloud Storage API를 사용하여 패키지 메타데이터 익스포트를 다운로드할 수도 있습니다. 내용은 다음 위치에서 사용할 수 있습니다. https://storage.googleapis.com/storage/v1/b/prod-export-license-bucket-1a6c642fc4de57d4/o 및 https://storage.googleapis.com/storage/v1/b/prod-export-advisory-bucket-1a6c642fc4de57d4/o. 이를 cURL 및 jq을 사용하여 다운로드할 수 있는 예제는 다음과 같습니다.
자동 동기화
귀하의 GitLab 인스턴스는 package_metadata 디렉터리의 내용과 정기적으로 동기화됩니다.
상위 변경 사항으로 로컬 사본을 자동으로 업데이트하려면 크론 작업을 추가하여 주기적으로 새로운 내보내기를 다운로드하도록 구성할 수 있습니다. 예를 들어, 다음과 같은 크론탭을 추가하여 30분마다 실행되는 크론 작업을 설정할 수 있습니다.
라이선스 스캔의 경우:
*/30 * * * * gsutil -m rsync -r -d -y "^v1\/" gs://prod-export-license-bucket-1a6c642fc4de57d4 $GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/licenses
의존성 스캔의 경우:
*/30 * * * * gsutil -m rsync -r -d gs://prod-export-advisory-bucket-1a6c642fc4de57d4 $GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/advisories
변경 사항
패키지 메타데이터 디렉터리가 16.2 릴리스에서 vendor/package_metadata_db에서 vendor/package_metadata/licenses로 변경되었습니다.이 디렉터리가 이미 인스턴스에 존재하고 의존성 스캔을 추가해야 하는 경우 아래 단계를 수행해야 합니다.
- 라이선스 디렉터리의 이름 바꾸기:
mv vendor/package_metadata_db vendor/package_metadata/licenses. -
vendor/package_metadata_db를vendor/package_metadata/licenses로 변경하는 자동화 스크립트 또는 명령어 업데이트하기. -
vendor/package_metadata_db를vendor/package_metadata/licenses로 변경하는 크론 항목 업데이트하기.sed -i '.bckup' -e 's#vendor/package_metadata_db#vendor/package_metadata/licenses#g' [FILE ...]
문제 해결
데이터베이스 데이터 누락
라이선스 또는 고려 사항 데이터가 의존성 디렉터리 또는 MR 페이지에서 누락된 경우, 데이터베이스가 내보낸 데이터와 동기화되지 않은 것이 가능한 원인 중 하나입니다.
package_metadata 동기화는 크론 작업을 사용하여 트리거됩니다 (advisory sync, license sync) 및 관리 설정에서 활성화된 패키지 레지스트리 유형 만 가져옵니다.
vendor/package_metadata 내의 파일 구조는 위에서 활성화된 패키지 레지스트리 유형과 일치해야 합니다. 예를 들어, maven 라이선스 또는 고려 사항 데이터를 동기화하려면 Rails 디렉터리 아래의 패키지 메타데이터 디렉터리는 다음 구조를 가져야 합니다.
- 라이선스의 경우:
$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/licenses/v2/maven/**/*.ndjson. - 고려 사항의 경우:
$GITLAB_RAILS_ROOT_DIR/vendor/package_metadata/advisories/v2/maven/**/*.ndjson.
성공적으로 실행된 후 데이터베이스의 pm_ 테이블 아래에 데이터가 채워져 있어야 합니다 (Rails console을 사용하여 확인):
- 라이선스의 경우:
sudo gitlab-rails runner "puts \"Package model has #{PackageMetadata::Package.where(purl_type: 'maven').size} packages\"" - 고려 사항의 경우:
sudo gitlab-rails runner "puts \"Advisory model has #{PackageMetadata::AffectedPackage.where(purl_type: 'maven').size} packages\""
또한, 동기화되는 특정 패키지 레지스트리에 대한 체크포인트 데이터가 있어야 합니다. 예를 들어 Maven의 경우, 성공적인 동기화 실행 후에 체크포인트가 생성되어 있어야 합니다:
- 라이선스의 경우:
sudo gitlab-rails runner "puts \"maven data has been synced up to #{PackageMetadata::Checkpoint.where(data_type: 'licenses', purl_type: 'maven')}\"" - 고려 사항의 경우:
sudo gitlab-rails runner "puts \"maven data has been synced up to #{PackageMetadata::Checkpoint.where(data_type: 'advisories', purl_type: 'maven')}\""
마지막으로, application_json.log 로그를 확인하여 PackageMetadata::SyncService 클래스에 대한 DEBUG 메시지를 검색하여 동기화 작업이 오류 없이 실행되었는지 확인할 수 있습니다. 예: {"severity":"DEBUG","time":"2023-06-22T16:41:00.825Z","correlation_id":"a6e80150836b4bb317313a3fe6d0bbd6","class":"PackageMetadata::SyncService","message":"Evaluating data for licenses:gcp/prod-export-license-bucket-1a6c642fc4de57d4/v2/pypi/1694703741/0.ndjson"}.
도움말