📣 GitLab의 Selected Partner 인포그랩에서, OpenAI 기술 기반으로 자체 개발한 자동화 번역 프로그램을 통해 GitLab 공식 문서의 한글판을 국내 최초로 제공합니다.
This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
sole discretion of GitLab Inc.
GitLab CI/CD 파이프라인에 의존하는 환경/배포 기능 지원: 보호된 환경, 배포 승인, 배포 안전성 및 환경 롤백. 이러한 기능들은 CI Access 모드에서 이미 사용 가능하지만, GitOps 모드에서는 사용 불가능합니다.
제안
개요
GitLab 환경과 GitLab 에이전트 간에 1:1 관계가 있습니다.
GitLab 환경은 연결된 에이전트에 의해 생성된 모든 리소스를 추적합니다. 이는 매니패스트 파일에 작성된 리소스뿐만 아니라 나중에 생성된 리소스(예: 배포 매니페스트 파일에 의해 생성된 Pod)도 포함됩니다.
GitLab 환경은 배포 => 복제본 세트 => Pod와 같은 의존성 그래프를 렌더링합니다. 이는 ArgoCD 스타일의 리소스 뷰를 제공하기 위함입니다.
GitLab 환경에는 건강한, 진행 중, 또는 저하된과 같은 리소스 상태의 요약을 나타내는 리소스 상태가 있습니다.
flowchart LR
subgraph Kubernetes["Kubernetes"]
subgraph ResourceGroupProduction["프로덕션"]
direction LR
ResourceGroupProductionService(["서비스"])
ResourceGroupProductionDeployment(["배포"])
ResourceGroupProductionPod1(["Pod1"])
ResourceGroupProductionPod2(["Pod2"])
end
subgraph ResourceGroupStaging["스테이징"]
direction LR
ResourceGroupStagingService(["서비스"])
ResourceGroupStagingDeployment(["배포"])
ResourceGroupStagingPod1(["Pod1"])
ResourceGroupStagingPod2(["Pod2"])
end
end
subgraph GitLab
subgraph 조직
subgraph 프로젝트
environment1["프로덕션 환경"]
environment2["스테이징 환경"]
end
end
end
environment1 --- ResourceGroupProduction
environment2 --- ResourceGroupStaging
ResourceGroupProductionService -.- ResourceGroupProductionDeployment
ResourceGroupProductionDeployment -.- ResourceGroupProductionPod1
ResourceGroupProductionDeployment -.- ResourceGroupProductionPod2
ResourceGroupStagingService -.- ResourceGroupStagingDeployment
ResourceGroupStagingDeployment -.- ResourceGroupStagingPod1
ResourceGroupStagingDeployment -.- ResourceGroupStagingPod2
GitLab Frontend는 브라우저 쿠키로 사용자 액세스를 인증/권한 부여합니다. 액세스가 금지된 경우 Frontend는 “이 환경에 배포 한 에이전트에 액세스 권한이 없습니다. “user_access”에서 허용되는 경우 에이전트 관리자에게 문의하십시오. <해결 방법="" 문서="" 링크="">를 참조하십시오"라는 오류 메시지를 표시합니다.해결>
사용자가 에이전트에 액세스 권한을 획들한 후, GitLab Frontend는 쿠버네티스의 특정 리소스 유형(예: Deployment, Pod)을 다음과 같은 매개변수로 가져옵니다:
namespace … #{environment.kubernetesNamespace}
리소스가 없는 경우, 사용자가 이러한 label을 자원에 포함시키지 않았을 가능성이 높습니다. 이 경우 Frontend는 “환경에 대한 리소스를 찾을 수 없습니다. 리소스에 GitLab 보존 레이블이 있는지 확인하십시오. <해결 방법="" 문서="" 링크="">를 참조하십시오"라는 경고 메시지를 표시합니다.해결>
의존성 그래프
GitLab Frontend는 리소스 간의 의존성을 식별하기 위해 Owner References를 사용합니다. 이것들은 metadata.ownerReferences 필드에 리소스에 포함됩니다.
소유자 참조가 없는 리소스의 경우, Well-Known Labels, Annotations and Taints를 보완하여 사용할 수 있습니다. 예를 들어 EndpointSlice는 metadata.ownerReferences를 가지고 있지 않지만 부모 Service 리소스를 참조하는 kubernetes.io/service-name를 사용할 수 있습니다.
리소스의 상태
GitLab Frontend는 가져온 리소스에서 상태 요약을 계산합니다. 예를 들어 ArgoCD의 리소스 상태와 유사하게 정상, 진행 중, 장애, 중지됨 등이 있을 수 있습니다. 이 공식은 아직 결정되지 않았습니다.