워크스페이스 변경사항을 엔드투엔드(E2E)로 테스트하려면 워크스페이스 지원이 포함된 GitLab을 배포하십시오. Helm 차트가 있는 Cloud Native GitLab(CNG)이나 Linux 패키지를 사용하여 배포할 수 있습니다.

전제 조건#

• CNG 전제 조건
• AWS CLI 구성
• Sandbox Cloud에 대한 액세스

CNG로 워크스페이스 변경사항 테스트#

클라우드 네이티브 GitLab 배포로 워크스페이스 변경사항을 테스트하려면 이 방법을 사용하십시오. 지침은 AWS 중심입니다.

클라우드 인프라 설정#

1. GitLab 클라우드 샌드박스에 접속하여 AWS 계정에 로그인합니다.

2. AWS Management Console에서 Route 53으로 이동하여 도메인을 등록합니다.

3. Route 53 대시보드에서 도메인으로 공개 호스팅 DNS 영역을 생성합니다.

4. EKS에 Kubernetes 클러스터를 설정하고 사용자에게 AmazonEKSClusterAdminPolicy 정책을 부여합니다.

5. 로컬 셸에 kubeconfig 항목을 추가합니다:

   aws eks update-kubeconfig --name <eks-cluster> --region <region>
   kubectl config use-context <context-name>
   

Helm 차트로 GitLab 설치#

1. GitLab Helm 차트에 대한 네임스페이스를 생성합니다:

   kubectl create namespace <gitlab-helm-chart-namespace>
   

2. GitLab 라이선스를 포함하는 일반 시크릿을 생성합니다:

    kubectl create secret generic <gitlab-license-secret-name> \
        --from-file=license=<path-to-license> \
        --namespace=<gitlab-helm-chart-namespace>
   

3. 다음 수정 사항으로 GitLab을 설치하려면 CNG 빠른 시작 가이드를 따르십시오:

   1. GitLab 도메인을 등록한 도메인을 기반으로 하는 서브도메인으로 설정합니다. 예를 들어 도메인이 workspace-test.com인 경우 mygitlab.workspaces-test.com을 사용합니다.

   2. 라이선스를 구성하기 위해 다음 CLI 옵션을 추가합니다:

      --set global.extraEnv.GITLAB_LICENSE_MODE=test \
      --set global.extraEnv.CUSTOMER_PORTAL_URL=https://customers.staging.gitlab.com \
      --set global.gitlab.license.secret=<gitlab-license-secret-name>
      

4. Ingress 리소스를 검사하여 공개적으로 접근 가능한 IP를 추출합니다:

    kubectl get ingress -n <gitlab-helm-chart-namespace>
   

5. AWS 호스팅 영역 대시보드에서 추출한 주소를 가리키는 서브도메인으로 A 유형의 ALIAS 레코드를 생성합니다.

6. GitLab 배포에 접근합니다.

기타 GitLab 관련 구성 및 설정은 CNG 리포지토리를 참조하십시오.

Helm 배포 확인#

설치 후 다음을 확인하십시오:

• GitLab 배포에 접근할 수 있습니다.

• KAS 파드 로그에 변경사항과 관련된 메시지가 표시됩니다:

  kubectl logs -f deployment/gitlab-kas -n <gitlab-helm-chart-namespace>
  

클라우드 리소스 정리#

테스트가 완료되면:

1. Route 53에서 DNS 레코드를 제거합니다.

2. Helm 릴리스를 제거합니다:

    helm uninstall <release-name> -n <gitlab-helm-chart-namespace>
   

Linux 패키지로 워크스페이스 변경사항 테스트#

Linux 패키지 GitLab 설치로 워크스페이스 변경사항을 테스트하려면 이 방법을 사용하십시오. 지침은 AWS 중심입니다.

E2C 인프라 설정#

1. GitLab 클라우드 샌드박스에 접속하여 AWS 계정에 로그인합니다.
2. Linux 패키지 요구사항을 충족하는 E2C 인스턴스를 프로비저닝합니다.
3. SSH 접근을 위한 키 쌍을 저장합니다.
4. 선택 사항. 서브도메인을 획득하고 E2C 인스턴스의 공개 IP를 매핑하여 공개 도메인 이름으로 GitLab을 노출합니다.

Linux 패키지로 GitLab 설치#

1. scp와 같은 도구를 사용하여 VM으로 GitLab 라이선스를 전달합니다.

2. 테스트하려는 변경사항이 포함된 머지 요청에서 ee-package 빌드를 트리거합니다.

3. 빌드된 패키지를 VM으로 다운로드하고 설치합니다:

   # OS/아키텍처에 맞는 패키지 다운로드
   wget <package-url>
   
   # 패키지 설치(Ubuntu/Debian 예시)
   sudo dpkg -i <package-file>
   

4. CLI 지침에 따라 GitLab 인스턴스를 구성합니다. 다음에 주의하십시오:

   • 외부 URL
   • 라이선스 파일 위치
   • 라이선스 유효성 검사를 위한 스테이징 고객 플랫폼
   • KAS 구성
   • 워크스페이스 관련 KAS 구성

5. 설치를 완료하고 GitLab 배포에 접근합니다.

패키지 설치 확인#

설치 후 다음을 확인하십시오:

• GitLab 배포에 접근할 수 있습니다.

• 모든 서비스가 실행 중입니다:

  sudo gitlab-ctl status
  

• KAS 로그에 예상 동작이 표시됩니다:

  sudo gitlab-ctl tail gitlab-kas
  

E2C 리소스 정리#

테스트가 완료되면:

1. Route 53에서 DNS 레코드를 제거합니다.
2. E2C 인스턴스를 중지하거나 삭제합니다.

문제 해결#

타이밍 오류#

• CNG 배포: KAS가 에이전트 엔드포인트를 호출하려고 하지만 오류가 발생하면 KAS 배포를 재시작합니다:

  kubectl rollout restart deployment/gitlab-kas -n <gitlab-helm-chart-namespace>
  

• Linux 패키지 배포: GitLab 웹 서비스에 연결할 수 없어 KAS가 에이전트 엔드포인트를 호출하려고 하지만 오류가 발생하면 KAS 서비스를 재시작합니다:

  sudo gitlab-ctl restart gitlab-kas
  

도메인 재사용 문제#

도메인 이름을 재사용하고 GitLab 배포에서 422 오류가 발생하면 해당 도메인과 관련된 쿠키를 삭제하십시오.

종속 서비스 테스트#

병합되지 않은 머지 요청이 있는 GitLab Rails와 같은 다른 서비스에 대해 테스트하는 경우, 머지 요청의 파이프라인에서 CNG 이미지 빌드를 확인하고 해당 이미지를 사용하도록 CNG 차트를 업데이트합니다.