HANU CICD Documentation

[robertchoi80]

HANU의 CI/CD pipeline 은 Taco 및 관련 인프라, application 등을 빌드, 배포, 테스트하는 일련의 단계들로 구성되어 있습니다.
SKT에서 개발한 tacoplay라는 ansible playbook을 사용해 taco cluster를 배포하고, 그 위에 logging/monitoring toolchain, openstack cloud platform을 비롯한 여러 application 등을 배포하고 검증하는 flow로 이루어져 있습니다.

Application 배포를 위해서 decapod라는 SKT의 배포 체계를 사용하게 되며, 각 application 별 배포 설정은 yaml 포맷의 manifest로 관리됩니다.
부가적으로 좀더 안정적인 배포를 위해, 배포시 필요한 container image 및 helm chart, 필요한 소스코드 등을 주기적으로 내부 repository로 sync하는 job들도 존재합니다.

모든 코드 수정은 pull request 형태로 제출되어, 기본적인 테스트를 거친 후 human review를 거쳐 main branch에 반영되며, 각각의 컴포넌트 별 테스트 외에 주기적으로 여러 컴포넌트들이 결합되어 수행되는 통합 테스트를 거치게 됩니다.

테스트는 job의 성격에 따라 jenkins job 또는 github action의 형태로 수행됩니다.

• Jenkins job 형태로 수행되는 프로젝트의 경우, 최상위 디렉토리의 Jenkinsfile이라는 파일에 의해 job이 정의되며, (Eg, https://github.com/openinfradev/tacoplay/blob/main/Jenkinsfile)
• github action의 경우 '.github/workflows' 라는 파일에 job 내용이 정의됩니다. (Eg, https://github.com/openinfradev/kustomize-helm-transformer/blob/main/.github/workflows/run-kustomize.yml)

현재 개발 또는 동작 중인 주요 job들은 다음과 같으며, 여기 있는 job들의 경우 대부분 jenkins job 형태로 수행됩니다.

• deploy-taco: tacoplay playbook을 사용하여 taco cluster 배포
• deploy-apps: decapod toolset 을 사용하여 taco 클러스터 위에 application 배포 (openstack, LMA 등)
• build-decapod-yaml: (common한 내용을 담고 있는) base yaml과 각 site yaml를 조합하여 app 배포를 위한 실제 manifest 생성
• sync_artifacts: upstream의 artifacts들을 내부 repo로 주기적으로 sync
  • kubespray: kubernetes 배포를 위해 tacoplay에서 내부적으로 참조하는 playbook
  • container images
  • helm charts
• promote (release): 검증 완료 후 주기적으로 version release

[estherk0]

• 작성하신 리스트에 있는 job들이 jenkins job으로 명시되어야 할 것 같습니다.
• .github/workflows의 예시로 kustomize-helm-plugin workflow 등의 링크를 첨부하는 것도 좋을 것 같습니다.

[bluejayA]

decapod-yaml에 넣는 것도 가능은 하겠네요.

개인적으로는,
앞으로 누구든지 필요하면 추가 app에 대한 site-yaml을 넣을 수 있다고 생각하면 별도로 가져가는 것이 더 좋지 않을까 하고,
퍼블릭, 프라이빗 모두 같은 구조로 (hanu-site-yaml, taco-site-yaml (가칭)) 유지하는 것도 일관성이 있을 것 같고.

[robertchoi80]

네, 말씀하신 부분 생각을 해봤는데, 추가 app에 대한 manifest를 추가하려면 decapod-(base)-yaml 과 site-yaml 쪽을 모두 추가해야 합니다. 또는 사용자들이 이미 base 쪽에 있는 lma나 openstack 등을 유사한 구조로 사용하되 환경 종속적인 설정 부분만 고쳐서 쓴다고 하면 site-yaml 쪽만 수정해서 쓸수 있을 듯 하구요. 사실 후자는 좀 희박해보이고 전자 쪽이 그나마 use-case 가 많을 듯 한데, @jabbukka 님 의견은 어떠신가요? 그런 case를 대비한다면 manifest 작성 관련하여 documentation이 잘 되어있어야겠네요

[bluejayA]

그렇네요. 신규 APP 추가는 두 개를 모두 해야 하네요. 기존 openstack도 site 변경으로만 안되고 base를 수정해야 하는 케이스들도 경우에 따라 많이 필요할 수도 있고.

사실 site-yaml에 대한 추가나 수정은, 이미 base 있는 상태일테니 상대적으로 변경사항에 대한 검증이 유연할 수 있지 않을까 합니다 (태일님이 말한것 중 후자). 저희가 이미 수정이 가능한 부분들을 제약하고 있다고 봐야 하니. (맞죠?)

대신에 base에 대한 수정이나 추가는, 좀 더 확실한 리뷰나 검증이 이루어질 수 있도록 (site-effect가 상당히 생길수 있으므로) ci pipeline이나 리뷰 프로세스가 잘 만들어져 있어야 하고.

base 와 site가 서로 연결되는 부분임에 틀림없으나, separation of concern 차원에서 repo가 분리되어 있는게 좋을수도 있다는 생각은 합니다.
(말씀하신대로 처음 사용하시는 혹은 기여하고자 하시는 분들이 이해 가능토록, documentation이 잘 되어 있어야 하겠네요. Site 변경시 자동으로 base와 합쳐서 output을 내주는 프로세스도 잘 자동화가 되어 있어야 하고, 문제 발생시 로그등도 잘 보면서 trouble shooting이 쉽도록 해줘야 할 것도 같고)

다른 분들 의견도 들어보면 좋을 듯 한데

[estherk0]

• 말씀하신대로 decapod-yaml과 site-yaml의 관계에 대한 documentation이 잘 되어야할 것 같습니다.

• 이전에 잠깐 논의했던 것 같은데 아래와 같은 multi base로 구조를 변경한다면 각 조직의 니즈에 맞는 app 추가 구성 문제는 풀 수 있을 것 같습니다.
  decapod-yaml(default source) + custom-yaml(additional source) + site-yaml => output

• decapod-yaml 안에 jenkins cicd에 대한 site만 example로 넣는 건 어떨까요? 현재는 decapod-yaml에는 ci가 구성되어 있지 않지만, CI Pipeline 구축 시에 site도 필요하게 됩니다.

[robertchoi80]

방금 말씀하신 두번째 포인트로 가게 된다면, custom-yaml 부분은 어차피 hanu github 상에 커밋하는 것이 아니라 각자의 개인 repo 또는 로컬 환경에서 작업을 하게 될 가능성이 높겠네요. 그렇게 되면 site-yaml 부분도 마찬가지가 될 테고.. 이 방향에 따라 repository 구조 설계가 달라질 수 있을 것 같습니다.

[bluejayA]

그러면 @robertchoi80님, 우선 1월2일 이후에 팀 내 논의 시간을 가지고 정리해서, 문서 올리는 것으로 진행하시는거죠?

[robertchoi80]

논의 후 정리된 사항 업로드합니다.

Taco site 외에 일반 사용자들의 site-yaml 관리는 어떻게 할것인가?

• hanu-site-yaml (private), decapod-site-yaml (public-사용자용 sample이며 사용자가 fork해서 사용) 으로 이원화하여 관리
  • decapod-base-yaml PR을 올릴때 decapod-site-yaml PR 통과 버전을 올려야하도록 안내 필요
• 사용자가 새로운 app을 추가할 경우, site 외에 base도 추가되어야 하는데, 어떤 구조로??
  • (에스더님 의견) base + custom base + hanu-site-yaml 구조로 하고, 사용자의 site-yaml은 위의 안처럼 이원화 관리
  • 결론: 당분간 custom base는 생각하지 않고, 일반 사용자가 base를 fork해서 자신만의 app 추가해서 쓰거나 또는 site-yaml 쪽에 넣는 방법 등 단순한 구조로 가고, custom-base는 차후에 필요시 다시 고려