CI
리뷰 환경
리뷰 환경은 1시간 후에 자동으로 제거됩니다. 리뷰 환경을 더 오래 유지해야 하는 경우 환경 페이지에서 해당 환경을 고정할 수 있습니다. 그러나 작업을 완료한 경우에는 Cleanup
단계에서 작업을 수동으로 트리거하는 것이 중요합니다. 이렇게 함으로써 클러스터가 다른 병합 요청을 위한 리뷰 앱을 실행하는 데 충분한 리소스를 확보할 수 있습니다.
자세한 내용은 환경 문서를 참조하세요.
OpenShift CI 클러스터
우리는 Google Cloud에서 수락 테스트 및 QA 스위트를 포함한 OpenShift 클러스터를 관리합니다.
이러한 클러스터에 연결하기 위한 kubeconfig 파일은 1Password 클라우드 네이티브 보관함에 저장되어 있습니다. ocp-ci
를 검색하세요.
CI 클러스터는 이 프로젝트에서 scripts/create_openshift_cluster.sh
를 사용하여 시작되었습니다. KUBECONFIG_OCP_4_7
라는 CI 변수를 사용하여 스크립트가 kubeadmin으로 클러스터에 연결할 수 있습니다. 4_7
은 대상 OpenShift 클러스터의 주요 및 마이너 버전을 나타냅니다.
이 스크립트의 사용 방법은 OpenShift 클러스터 설정 문서를 참조하세요.
“public” 및 “dev” 클러스터
이 프로젝트에는 두 가지 종류의 OpenShift CI 클러스터를 유지합니다:
-
public
CI 클러스터는gitlab.com
에서 매일 CI 파이프라인을 실행합니다. -
dev
CI 클러스터는dev.gitlab.org
에서 태그를 지정하고 공식 릴리스를 생성합니다.
모든 클러스터는 cloud-native
GCP 프로젝트에 배포되며 DNS 기본 도메인으로 k8s-ft.win
을 사용하므로, 설정 문서 및 스크립트를 통해 배포됩니다. public에 배포된 모든 OpenShift 버전에 대응하는 dev에 해당 버전과 동일한 클러스터가 배포됩니다. 두 클러스터 모두 cloud-native
GCP 프로젝트에 배포되며 DNS 기본 도메인으로 k8s-ft.win
을 사용합니다.
OpenShift 클러스터 확장
OpenShift 클러스터는 리소스를 풀링하는 데 machineset
을 사용합니다. 기본 배포에는 4개의 machineset
이 있고 이 중 2개가 사용됩니다.
우리는 이 접근 방식을 유지하고 2개의 활성 machineset
을 2개의 노드로 확장합니다.
OpenShift 확장 문서를 따르면:
$ export KUBECONFIG=~/work/ocp/kubeconfig_4_8
$ oc get machinesets -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
ocp-ci-4717-abcde-worker-a 1 1 1 1 59d
ocp-ci-4717-abcde-worker-b 1 1 1 1 59d
ocp-ci-4717-abcde-worker-c 0 0 59d
ocp-ci-4717-abcde-worker-f 0 0 59d
작업량을 처리하기 위해 일시적인 용량을 생성합니다:
$ oc scale --replicas=1 machineset ocp-ci-4717-abcde-worker-c -n openshift-machine-api
machineset.machine.openshift.io/ocp-ci-4717-abcde-worker-c scaled
$ oc get machinesets -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
ocp-ci-4717-abcde-worker-a 1 1 1 1 59d
ocp-ci-4717-abcde-worker-b 1 1 1 1 59d
ocp-ci-4717-abcde-worker-c 1 1 59d
ocp-ci-4717-abcde-worker-f 0 0 59d
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ocp-ci-4717-abcde-master-0.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-1.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-2.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-a-wz8ts.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-b-shnf4.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-c-5gq6r.c.cloud-native-123456.internal NotReady worker 15s v1.20.0+2817867
machineset
중 하나를 축소합니다:
oc scale --replicas=0 machineset ocp-ci-4717-abcde-worker-a -n openshift-machine-api
축소가 완료될 때까지 기다립니다:
$ oc scale --replicas=2 machineset ocp-ci-4717-abcde-worker-a -n openshift-machine-api
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ocp-ci-4717-abcde-master-0.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-1.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-b-shnf4.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-c-5gq6r.c.cloud-native-123456.internal Ready worker 7m18s v1.20.0+2817867
external-dns
external-dns는 Bitnami Helm Chart를 사용하여 ci/scripts/install_external_dns.sh를 사용해 설치되었습니다. 이 도구는 외부로 노출된 로드 밸런서로 생성된 NGINX Ingress 컨트롤러 서비스를 위해 DNS 항목을 생성하여 QA 작업이 인스턴스에 도달할 수 있도록 합니다.
구성
작업 타임아웃
참고: 작업에 대한 제한 시간을 구성할 수 있습니다. 제한 시간에 도달하면 GitLab 컨트롤러는 작업이 시간 내에 완료되지 않았음을 나타내는 오류를 반환합니다.
이를 구성하려면 deploy/chart/values.yaml
의 env
값을 업데이트하세요.
Kubernetes CI 클러스터
GKE를 사용하여 Google Cloud의 Kubernetes 클러스터를 관리합니다. 이러한 클러스터는 OpenShift CI 클러스터에서 실행되는 동일한 수용 테스트를 실행하는 데 사용됩니다.
클러스터는 charts/gitlab
의 gke_bootstrap_script.sh 스크립트를 사용하여 생성됩니다.
$ CLUSTER_NAME='gitlab-operator' \
PROJECT='cloud-native-182609' \
REGION='europe-west3' \
ZONE_EXTENSION='a' \
USE_STATIC_IP='false' \
EXTRA_CREATE_ARGS='' \
./scripts/gke_bootstrap_script.sh up
demo/.kube/config
가 생성되며, 개발을 위해 클러스터에 kubectl
또는 k9s
로 연결할 수 있습니다.
그런 다음 새로운 클라우드 DNS 레코드 세트를 만들어 클러스터 엔드포인트 IP 주소에 연결합니다.
$ ENDPOINT="$(gcloud container clusters describe gitlab-operator --zone europe-west3-a --format='value(endpoint)')"
$ gcloud dns record-sets create gitlab-operator.k8s-ft.win. \
--rrdatas=$ENDPOINT --type A --ttl 60 --zone k8s-ftw
클러스터가 생성되고 DNS로 연결된 후 ./scripts/install_certmanager
스크립트를 실행하여 Letsencrypt TLS 인증서를 설정합니다.
$ KUBECONFIG=demo/.kube/config \
CLUSTER_NAME=gitlab-operator \
BASE_DOMAIN=k8s-ft.win \
GCP_PROJECT_ID=cloud-native-182609 \
./scripts/install_certmanager.sh 'kubernetes'
클러스터 도메인에 대해 와일드카드 인증서가 발급되면 클러스터는 테스트를 실행할 준비가 됩니다.
CI 클러스터의 경우 Google Cloud에서 서비스 계정을 생성하고, Google Cloud의 인증 문서의 단계를 따릅니다. 이를 통해 이 프로젝트용으로 CI 변수 KUBECONFIG_GKE
와 GOOGLE_APPLICATION_CREDENTIALS
을 생성할 수 있습니다. 이 과정은 스크립트화되어 있으며, scripts/create_gcloud_sa_kubeconfig.sh를 참조하세요. 이 kubeconfig 파일은 1Password 클라우드 네이티브 저장소에 저장됩니다. ‘gitlab-operator’를 검색하세요.
Kubernetes 클러스터 확장
GKE 클러스터에서 워커 노드를 추가하거나 제거하기 위해 gcloud CLI를 사용합니다. Google Cloud 웹 UI도 사용할 수 있습니다.
예를 들어, gitlab-operator
CI 클러스터를 4노드로 확장하는 경우:
$ gcloud container clusters resize \
gitlab-operator --num-nodes 4
QA 파이프라인
기본적으로 QA 파이프라인에는 작은 일부 빠른 엔드 투 엔드 기능 테스트인 스모크 스위트가 포함되어 기본 기능이 작동하는지 빠르게 확인합니다. 추가 테스트가 필요한 경우, 특정 클러스터의 Full suite의 엔드 투 엔드 테스트를 수동으로 트리거하는 qa_<cluster>_full_suite_manual_trigger
작업을 실행할 수 있습니다.
테스트에서 실패를 디버깅하려면 QA 실패 조사 가이드를 따르세요.
컨테이너 빌드
Kubernetes 빌드x 드라이버를 구성하여 Operator 이미지를 여러 아키텍처로 빌드할 수 있습니다. BUILDX_K8S_*
변수를 설정하여 대상 아키텍처의 쉼표로 구분된 문자열 (예: amd64,arm64
)로 BUILDX_ARCH
를 설정하세요. BUILDX_K8S_DISABLE
가 true
로 설정된 경우 - 빌드할 플랫폼 수를 amd64
로 자동으로 줄일 수 있습니다.
Kubernetes 드라이버가 구성되지 않은 경우 하나의 아키텍처만 (교차로) 컴파일할 수 있습니다.