개발자 가이드

이 개발자 가이드는 새로운 개발자가 이 프로젝트에 기여하기 위해 환경을 설정하는 방법을 안내하는 것을 목표로 합니다.

개발 환경 설정

오퍼레이터의 개발을 위해 시스템을 설정하려면 아래 단계를 따르세요:

  1. gitlab-operator 리포지토리를 GOPATH에 클론합니다.

    git clone git@gitlab.com:gitlab-org/cloud-native/gitlab-operator.git
cd gitlab-operator

  2. 런타임 종속성을 관리하기 위해 asdf를 설치합니다.

  3. 런타임 종속성을 설치합니다.

    cut -d' ' -f1 .tool-versions | xargs -i asdf plugin add {}
asdf plugin add opm https://gitlab.com/dmakovey/asdf-opm.git
asdf install

  4. 리포지토리의 루트에서 task를 실행하여 사용 가능한 명령을 확인합니다.

    우리는 이 프로젝트에서 make 대신 task from taskfile.dev를 사용합니다. 그 이유는 여기입니다.

    brew install task를 통해 task를 설치하지 마세요. 그 경우 Taskwarrior가 설치되어 다릅니다. 위의 asdf 플러그인을 사용하든, 아니면 taskfile.dev에서 설치 지침을 따르세요.

    우리의 작업 정의는 Taskfile.yaml에서 확인할 수 있습니다.

프로젝트 구조

GitLab Operator는 Operator SDK v1.0.0을 사용하여 구축되었으며, 따라서 Kubebuilder v2 레이아웃 형식을 사용합니다. 프로젝트 디렉토리에 변경 사항이 있었고 operator SDK에서 사용되는 도구 일부를 알 필요가 있습니다.

$ pwd
gitlab-operator
$ tree -dL 2 .
.
├── api
│   └── v1beta1
├── bundle
│   ├── manifests
│   ├── metadata
│   └── tests
├── config
│   ├── certmanager
│   ├── crd
│   ├── default
│   ├── deploy
│   ├── manager
│   ├── manifests
│   ├── prometheus
│   ├── rbac
│   ├── samples
│   ├── scorecard
|   ├── test
│   └── webhook
├── controllers
│   ├── backup
│   ├── gitlab
│   ├── helpers
│   ├── runner
│   ├── settings
│   ├── testdata
│   └── utils
├── doc
├── hack
│   └── assets
├── helm
│   └── testdata
└── scripts
    └── manifests

  • controllers 디렉터리는 GitLab 및 GitLab 백업 컨트롤러에 대한 컨트롤러 구현을 포함합니다.

  • api 디렉터리는 오퍼레이터가 소유하는 GitLab 및 GLBackup 리소스에 대한 API 리소스 정의를 포함합니다. API 정의는 API 버전별로 그룹화되어 있습니다.

    api/<api_version> 내의 *_types.go 파일은 사용자 정의 리소스 정의 및 OLM에서 사용하는 Cluster Service Version 파일을 생성하는 데 사용되는 사양 정의 및 마커를 포함합니다.

  • config/samples 디렉터리는 GitLab 사용자 정의 리소스에 대한 예제 매니페스트를 포함합니다.

  • config/test 디렉터리는 통합 테스트를 실행하는 데 사용되는 매개변수화된 GitLab 정의를 포함합니다.

    예시는 다음과 같습니다:

    // +kubebuilder:rbac:groups=core,resources=configmaps,verbs=get;list;watch;create;update;patch;delete

    config/rbac/custom의 내용은 수동으로 생성되었으며 RBAC 마커의 영향을 받지 않습니다.

    config 디렉토리의 다른 대부분의 내용은 자동으로 생성되지만 kustomize를 사용하여 수정할 수 있습니다.

  • hack/assets 경로는 컨테이너 이미지가 빌드될 때 오퍼레이터 이미지 내부로 푸시되어야 하는 리소스를 포함합니다. 여기서 릴리스 파일이 삽입됩니다.

오퍼레이터 배포하기

오퍼레이터 배포에 대한 지침은 설치 문서를 참조하세요.

디버깅

기능 개발 및 테스트 작성에 도움이 되는 몇 가지 함수가 controllers/gitlab/template_test.go에 추가되었습니다.

  • dumpTemplate(template)
  • dumpTemplateToFile(template, filename)
  • dumpHelmValues(values)
  • dumpHelmValuesToFile(values, filename)

dumpTemplate() 함수는 GitLab 어댑터에서 템플릿 객체를 가져와 Helm 차트의 렌더링된 YAML를 문자열로 반환합니다. Go 테스트 프레임워크는 stdout에 작성된 모든 내용을 흡수하므로, dumpTemplateToFile()는 검사를 위해 YAML을 파일에 작성합니다. 단순히 파일 이름만 제공할 경우 해당 파일은 테스트 파일이 위치한 하위 디렉터리에 작성되며, 테스트가 시작된 디렉터리에 작성되지 않습니다. 테스트가 시작된 위치에 파일을 작성하려면 절대 파일 경로가 필요합니다.

유사하게, dumpHelmValues()는 Helm 값의 YAML 표현을 문자열로 반환합니다. 이는 모든 테스트의 시작 부분에서 원하는 값이 설정되었는지 확인하는 데 사용할 수 있습니다. dumpHelmValues() 함수는 검사를 위해 YAML을 파일에 기록하며, 파일 이름 인자는 dumpTemplateToFile()와 동일한 제한이 있습니다.