CI/CD에서 파생된 잡다한 이야기(kaniko, aws glue cicd, tekton, git flow, k8s&helm operator...)

docker없이 컨테이너 이미지 빌드

aws 코드시리즈 cicd

tekton

git 전략

k8s operator vs helm

gitops

…etc

 

1. docker없이 이미지 빌드 가능?

→ ㅇㅇ

에스코어

• 글 요약

나온 바탕

클라우드 내부에서 도커 이미지를 빌드한다는 것 == 이미지 내부에서 이미지를 빌드한다는 의미

일반적으로 도커 이미지를 빌드하기 위해서는 도커 데몬이 필요하고,

도커 데몬은 도커의 수행환경으로써 리눅스의 root 권한을 필요로 한다.

그러나 컨테이너 환경의 유저에게 일반적으로 root 권한을 부여하지는 않는다.

도커 데몬의 권한에 대한 문제는 신뢰할 수 있는 사용자에 국한하고 있다.

쿠버네티스 또한 컨테이너를 무분별하게 root 권한으로 수행하는 것을 방지하기 위하여 가이드를 제공하고 있다.

이러한 가이드를 충족하기란 쉽지 않기에 클러스터 내부에서 안전하게 도커 빌드를 수행 할 수 있는 다른 방법을 찾아야 한다.

 

성능 문제

초기 Docker in Docker 기술의 성능이나 보안 문제는 많은 해결책이 나왔으며,

Docker in Docker를 위한 공식 이미지(https://hub.docker.com/_/docker/)도 공개되어 있다.

그러나 해당 페이지에서 docker in docker 의 문제점에 대한 문서를 확인할 수 있으며 필요한 경우에만 사용을 권장하고 있다.

결국 빌드를 위해 클라우드 상에서 도커 데몬을 사용하는건 어려워 보인다.

 

해결 방안

위의 문제를 해결하기 위해 Kaniko (https://github.com/GoogleContainerTools/kaniko), BuildKit (https://github.com/moby/buildkit), Buildah (https://github.com/containers/buildah) 등

이 프로젝트들은 도커 데몬 없이 도커 빌드를 수행하기 위한 기능들을 제공

 

장단점

• Kaniko는 전용 도커 이미지 내부에서 빌드됨으로 kaniko를 직접 설치하여 빌드 명령어를 호출하는 작업이나 이미지를 복사하거나 태그를 변경하는 등의 이미지 관리는 불가능
• CI/CD 구성 중 이러한 빌드 명령이나 이미지 관리 등이 필요하다면 Kaniko 보다는 Buildah 같은 설치형 빌드 도구를 고려하는 것이 좋다.

 

• Kaniko vs Buildah vs Buildkit
  • 컨테이너 빌드 도구 선택을 위한 특성 및 성능 비교 (Kaniko, Buildah, Buildkit)

 

2. 도커랑 aws codeseries로 AWS Glue(서버리스 데이터 통합 서비스) cicd 구축하기

Set up CI/CD solution for AWS Glue development using Docker image, AWS CodeCommit, CodePipeline…

• 글 요약

• AWS Glue 콘솔을 사용하여 직접 개발 및 테스트를 수행 ㄱㄴ but 비용이 발생
• 절감하자 → Docker 이미지를 사용하여 로컬에서 Glue 작업 스크립트를 개발
• ( 이 방식 단점: 스크립트를 로컬 컴퓨터에서 개발 및 프로덕션 환경으로 수동으로 마이그레이션해야 한다는 것
• 시간이 많이 걸리고 비생산적일 수도)
• 따라서 이 기사에서는 Docker 이미지를 사용하여 로컬 Glue 스크립트 개발의 비용 절감 이점을 활용하고,
• 코드시리즈(AWS CodeCommit, AWS CodePipeline 및 AWS CodePipeline)을 사용하여 CI/CD 파이프라인을 설정할 수 있도록 지원하는 솔루션을 제시
• AWS CodeBuild를 사용하면 로컬 스크립트를 AWS 환경으로 쉽게 마이그레이션할 수 있음

 

++ aws glue cicd (요건 테라폼이랑 깃헙액션을 쓴다)

Streamlining AWS Glue CI/CD

 

 

aws 나오니까 eks cicd 아키텍처는 어찌 짜려나 궁금해짐

 

-eks & codepipeline

https://blog.kyobodts.co.kr/2023/12/19/eks-%EB%B0%8F-codepipeline-%ED%99%9C%EC%9A%A9-ci-cd-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95/

 

 

https://potato-yong.tistory.com/130

https://blog.leaphop.co.kr/blogs/51

 

 

3. 툴은 참 많지요

• https://katalon.com/resources-center/blog/ci-cd-tools

누가 평가한건지 잘은 몰라도 cicd top 10 중에 jenkins가 아니라 Tekton이 1등을 함

https://theqalead.com/tools/best-ci-cd-tools/

 

Tekton?

Tekton 사용해보기 (1) Tekton으로 쿠버네티스에서 CI/CD 파이프라인을 구성해보자

• Tekton은 Kubernetes CR 기반의 빌딩 블록으로 쉽게 파이프라인을 구성할 수 있다는 장점
• 기존 Kubernetes 환경을 그대로 이용할 수 있다는 활용성

Jenkins vs Tekton

• 현재 가장 많이 사용 되는 Jenkins는 러닝 커브가 낮고 범용성이 높지만 플러그인 관리, 장애 대처, 자격 증명 등의 단점도 존재합니다.
• Tekton은 Kubernetes 환경에서 동작해서 Auto Scaling, Self-Healing, Serverless 등 서버 관리에 이점이 있지만 관련 정보가 적다는 단점이 있습니다.
• Kubernetes를 사용하고 있는 환경을 잘 이해하고 있으며 자신이 직접 Pipeline을 구축할 수 있는 사용자는 Tekton을, 오픈소스로 빠르게 CI/CD를 구축하고 싶은 사용자는 Jenkins를 사용하는 것이 적절합니다.
• https://tech.osci.kr/tekton으로-ci-cd-pipeline-구성하기feat-playce-kube/

ㅇㅎㅇㅎ 대충 k8s 잘알고 커스텀 구체적으로 해서 서버관리 필요하면 == 테크톤 쓸 수 있다~

근데 젠킨스는 유명해서 정보 많고 빠르게 cicd구축 가능이니까 젠킨스 더 많이 씀

(kustomize도 유명하지만 설정을 구체적으로 할 수 있는게 장점이자 단점이라 helm보다 덜 쓰는 그런 차이같은 느낌일까나?)

 

---

 

4. 깃 플로우…

브랜치 한개?? 그만큼 간단하게 구축했다는건가?

브랜치를 1개만 쓰는 스타트업의 CICD 프로세스

 

→ CICD가 단순히 jenkins로 배포를 자동화하는 게 전부라고 생각했다. 이 부분도 필요하지만 더 중요한 건 어떻게 소프트웨어를 합쳐서 배포할 지에 대한 전략이다.

그래서 trunk based 개발 방식을 확립하고 브랜치를 한 개만~

 

++ 갑자기 더 찾아본 깃 브랜치/머지 전략

Git Flow에서 트렁크 기반 개발으로 나아가기 - 맘시터 기술블로그

 

TBD = 단일 브랜치에서 직접 모든 작업을 하는 것

트렁크 기반 개발(Trunk-Based Development)

⇒ 당연히 뭐가 더 좋다는 서비스별로 적합한 게 다르다~

 

작년에 적어놓은…

 

깃헙플로우는 단순하다 feature랑 main 브랜치 두개로 이전버전이 더이상 수정될 일 없음(hotfix) 깃헙에서 제공하는 통합등을 이용해서 안전 브랜치 메인을 통합하는…

아틀라시안에서 소개한 세가지 전략
1.극단적인 전략 피하자 하나의 배포를 하기 위해서 5개의 브랜치 … 4번의 병합을 하고 4번의 리뷰 4번의 테스트 -> 개발 속도를 더디게 만듦.
극단적으로 심플한 하나의 브랜치 사용하는 경우도 극단적임.
2.가능하다면 브랜치 구조를 단순화 하자 그 상황에서 가장 단순화된 구조로
3.브랜치 생성 기준을 정하자 브랜치를 마구잡이로 생성하게 되면 안좋음 깃버킷팀에서는 이슈당 하나의 브랜치를 만드는 게 티켓이라는 개념을 도입해서

== 깃헙 플로우는 메인브랜치가 stable하다는 전제가 있어야 함 근데 그렇지 않게될 수도 있고
온브랜드 제품이라 릴리즈브랜치를 통해서 이전버전 관리할 필요가 있음

https://www.atlassian.com/ko/git/tutorials/using-branches/merge-strategy

 

 

5. k8s, helm operator

- k8s operator(전에도 찾아봤던것같은데 아직 잘 정립이 안되는군요)

• https://ccambo.tistory.com/entry/Kubernetes-Operator-Kubernetes의-Operator-나름대로-정리

- helm controller

• https://coffeewhale.com/kubernetes/gitops/helm/2020/05/13/helm-operator/

 

Operator란?

 

• Operator란 쿠버네티스 클러스터 위에서 동작하며 Custom Resource를 이용하여 쿠버네티스와 동일한 방법으로 리소스를 관리하는 소프트웨어
• 쿠버네티스의 controller manager의 control loop?
• → 쿠버네티스의 control loop은 지속적으로 current state와 desired state를 모니터링하며 새로운 리소스가 생성되어 desired state가 변경되었을 때 그것을 자동으로 감지하여 current state를 desired state와 sync되도록 동작합니다.
• 이런 control loop의 작업으로 인해 사용자가 새로운 리소스를 생성할 때 (예를 들어, kubectl apply -f new_pod.yaml) 그것이 쿠버네티스 클러스터에 반영이 됩니다. (실제로 Pod가 실행됨)
• Operator란 쿠버네티스의 기본적인 쿠버네티스 리소스 이외에 Custom Resource 또한 쿠버네티스의 control loop 정책을 따라 동작하도록 만들어주는 주체이고,
• 이러한 패턴을 따르는 것을 Operator 패턴이라고 부릅니다.
• 마치 custom controller manager 역할을 담당하는 것이죠.
• Operator 개발자가 Operator를 어떻게 개발하는가에 따라 새로운 Custom Resource가 생성될 때 동작하는 방법이 달라집니다.

 

Helm Operator

 

• Helm Operator란 Helm Chart를 Custom Resource처럼 관리할 수 있게 해주는 Operator.
• Custom Resource가 생성될 때 helm chart를 설치해주고 (helm install)
• 리소스가 삭제될 때, helm list에서 삭제 (helm delete)합니다.
• Helm Operator에서 이 Custom Resource를 HelmRelease라고 부릅니다.
• 사용자가 HelmRelease라는 Custom Resource를 생성하게 되면 Helm Operator가 자체적으로 control loop를 살펴보다 변경된 것을 감지하여 새로운 helm release를 배포해 줍니다.

 

• k8s operator vs helm
  1. 복잡한 애플리케이션 관리: Kubernetes 환경은 일반적으로 복잡한, 마이크로서비스 기반의 애플리케이션을 호스팅합니다. 이러한 애플리케이션을 관리하는 것은 배포, 확장, 업데이트 및 가용성 유지와 같은 작업들이 어려울 수 있습니다. Kubernetes Operator 및 Helm은 이러한 도전에 대한 해결책을 제공합니다.
  2. 운영 작업 자동화: Kubernetes Operator는 운영 작업을 자동화합니다. 이들은 자동화된 사이트 신뢰성 엔지니어처럼 작동하여 수동 개입 없이 애플리케이션을 관리하고 최적화합니다. 이러한 자동화는 애플리케이션의 효율성과 신뢰성을 유지하는 데 중요하며, 특히 대규모 환경에서 Kubernetes 문제 해결에 도움이 됩니다.
  3. 배포 및 구성 간소화: Helm은 Kubernetes 애플리케이션의 배포와 관리를 간소화합니다. 이는 응용 프로그램 및 리소스를 정의하는 표준화된 형식을 제공하여 다양한 환경에서 애플리케이션을 배포하고 구성하는 것을 더 쉽게 만듭니다.
  4. 신뢰성 및 일관성 향상: 두 도구 모두 애플리케이션 배포 및 관리의 신뢰성과 일관성을 향상시킵니다. Kubernetes Operator는 응용 프로그램이 의도된대로 실행되도록 보장하고, Helm은 다양한 환경에서 일관된 방식으로 애플리케이션을 배포합니다.
  5. 협업 및 GitOps 작업 모델 강화: 두 도구 모두 GitOps 관행을 지원합니다. 이것은 선언적 구성과 자동 배포를 가능하게 하여 GitOps를 실천하는 팀에 필수적입니다. 이는 팀 구성원 간의 협력을 향상시키고 배포 프로세스를 간소화합니다.

 

 

그래서 차이가 뭐라꼬

 

1. 범위 및 목적:
   • Kubernetes Operator: Kubernetes Operator는 복잡하고 상태를 유지해야 하는 애플리케이션의 관리를 자동화하고 간소화하는 도구입니다. 새로운 사용자 정의 리소스나 기존 리소스를 수정하여 Kubernetes API의 기능을 확장하는 사용자 지정 컨트롤러를 사용합니다.
   • Helm: Helm은 Kubernetes의 패키지 매니저로, 복잡한 Kubernetes 애플리케이션의 정의, 설치 및 업그레이드를 도와줍니다. Helm은 "차트"라는 개념을 도입하여 애플리케이션의 모든 필수 Kubernetes 리소스를 포함하는 패키지로 정의합니다.
2. 복잡성 및 사용자 정의:
   • Kubernetes Operator: Kubernetes Operator는 Kubernetes의 사용자 정의 리소스 및 컨트롤러와 같은 개념에 대한 심층적인 이해가 필요합니다. 그러나 이러한 복잡성은 사용자가 Helm보다 더 높은 수준의 사용자 정의 및 자동화를 달성할 수 있도록 해줍니다.
   • Helm: Helm은 Kubernetes의 복잡성을 추상화하여 사용자가 애플리케이션을 배포하고 관리하기 쉽도록 도와줍니다. 그러나 이러한 단순성은 Kubernetes Operator보다는 사용자 정의 가능성이 적을 수 있습니다.
3. 자동화 및 라이프사이클 관리:
   • Kubernetes Operator: Kubernetes Operator는 복잡한, 상태를 유지해야 하는 애플리케이션의 철저하고 자동화된 관리를 제공합니다. 백업, 업데이트, 스케일링과 같은 작업들을 자동화하여 애플리케이션의 라이프사이클을 관리합니다.
   • Helm: Helm은 배포 프로세스를 간소화하지만 Kubernetes Operator만큼의 자동화를 제공하지 않습니다. Helm은 애플리케이션 라이프사이클 관리에 대한 자동화를 제공하지 않으며, 사용자가 Helm 차트를 업데이트하고 관리해야 합니다.
4. GitOps 방법론 적합성:
   • Kubernetes Operator: Kubernetes Operator는 GitOps 방법론에 적합합니다. 사용자가 선언적 구성과 자동 조정을 사용하여 복잡한, 상태를 유지해야 하는 애플리케이션을 관리할 수 있습니다.
   • Helm: Helm도 GitOps 방법론과 호환됩니다. Helm 차트는 버전 관리되고 Git을 통해 배포될 수 있습니다. 그러나 Helm은 Kubernetes Operator만큼의 자동화를 제공하지 않을 수 있으므로 GitOps에서의 사용은 다소 제한될 수 있습니다.

• Kubernetes Operator Vs. Helm: What's the Difference?
• What are the differences between Helm and Operators?

 

차이 다시 톺아보기

Kubernetes Operator vs Helm: 11 Key Differences & Which One to Choose

 

 

6. 이제는 익숙하게 들리는 gitops

• https://coffeewhale.com/kubernetes/gitops/argocd/2020/02/10/gitops-argocd/