개요
구성한 파이프라인에 대해 설명한다.
Stacks
| stack | version |
|---|---|
| gitlab(helm) | gitlab-6.8.2 |
| harbor(helm) | harbor-1.11.0 |
| argo(helm) | argo-cd-5.23.1 |
| Kaniko | v1.9.1 |
Gitlab-runner
GitLab CI/CD 파이프라인에서 사용, GitLab 서버와 연결되어 파이프라인의 작업을 실행합니다.
Harbor
여기선 docker registry 역할만 수행합니다.
KANIKO
카니코를 처음 접한 사람들도 있을 것이다. 보통 컨테이너하면 도커를 많이 생각할 것이다. 아래 내용은 클러스터에서 도커를 이용한 빌드보다 카니코를 이용해서 빌드했을 때 장점들이다.
- 권한 Docker를 클러스터에서 사용하여 이미지를 빌드할 경우, 호스트 시스템에 대한 권한 문제가 발생할 수 있습니다. Docker는 루트 권한으로 실행되어야 하므로, Docker 호스트 시스템에 대한 루트 권한을 부여해야합니다. 이는 보안 취약점으로 이어질 수 있습니다. 따라서 Kaniko와 같은 빌드 도구를 사용하여 컨테이너 내에서 이미지를 빌드하는 것이 좋습니다.
- version 호환 Docker를 클러스터에서 사용하여 이미지를 빌드하면 호스트 시스템과 Docker 버전이 호환되지 않을 수 있습니다. 이는 이미지를 배포할 때 호환성 문제를 유발할 수 있습니다. 따라서 Kaniko와 같은 빌드 도구를 사용하여 이미지를 빌드하면 호환성 문제를 최소화할 수 있습니다.
- docker daemon 의존성 Docker를 클러스터에서 사용하여 이미지를 빌드할 경우, 도커 데몬(Docker Daemon)에 대한 의존성이 있으므로, 도커 데몬을 설치하고 구성해야합니다. 이는 관리 및 유지 관리를 더 복잡하게 만들 수 있습니다. 따라서 Kaniko와 같은 빌드 도구를 사용하면 이러한 의존성 문제를 해결할 수 있습니다.
GitHub - GoogleContainerTools/kaniko: Build Container Images In Kubernetes
Install via helm
HELM
Gitlab
Deploy the GitLab Helm chart | GitLab
Configure charts using globals | GitLab
Harbor
Harbor – Harbor 2.7 Documentation
Argo cd
Installation - Argo CD - Declarative GitOps CD for Kubernetes
🧐 저는 위 스택들을 클러스터에 셋팅할 때 helm pull 을 통해서 차트를 마스터노드에 설치하여 구성하였습니다. 이유는 버전과 호환이나 혹은 upgrade 과정에서 버전 충돌 문제가 있었습니다.
gitlab 을 설치하는 과정에서 동식문서에 있는 helm install , helm upgrade —install 이와 같이 작업을 하여 default values 파일들을 사용했습니다. 그런데 차트 안에 있는 postgresql 버전이 적절하지 않아 에러가 나타났습니다.
원인은 전에 13 설치되어 있었고 upgrade 하면서 12.7 으로 변경된거였습니다. pvc의 경우는 config가 그대로 있다보니 여기서 충돌이 있었던 것으로 예상됩니다.
만약 위와 같은 문제를 피하고 싶다면 pull 을 통해서 관리하는 것도 나쁘지 않다고 생각합니다.
