Docker Compose 작성 관련 토론및 취합

[MZC-CSC]

docker 기반 인프라 구축을 위한 docker-compose 작성이 필요한데 현재 docker 이미지 배포 및 docker 기반 사용 가이드가 없는 Framework 워크가 너무 많습니다.
각 Framework 리더 분들은 가급적 8월 첫째 주까지 docker 이미지와 docker 이미지 기반 사용 가이드를 작성해 주시기 바랍니다.

각 프레임워크의 메인테너분들은 최종 docker-compose.yaml 파일의 내용을 참고해서 잘 못되었거나 추가되어야 할 내용들을 알려 주시면 감사하겠습니다.

@seokho-son @yunkon-kim
현재는 main 브랜치에 V태그가 달릴 때에만 docker hub에 도커 이미지가 만들어지고 있는데 빠른 통합 개발을 위해 정식 Release가 아닌 테스트가 가능한 수준의 기능이 개발될 때마다 "dev"등의 태깅을 사용해서 Dev용 docker 이미지도 빠르게 배포되면 좋을 것 같습니다.
또는 테스트 가능한 수준의 기능이 추가될 때에도 버전을 올리거나 정책을 정하면 좋을 것 같습니다. (일부 Framework들은 빠른 주기로 docker 이미지가 배포되고 있음)

docker-compose 작성관련 자세한 내용은 Wiki 글을 참고하시기 바랍니다.
https://github.com/m-cmp/mc-admin-cli/wiki/Docker%E2%80%90Compose-%EC%9E%91%EC%84%B1-%EA%B4%80%EB%A0%A8

[seokho-son]

@MZC-CSC docker image 관련 이슈화 감사합니다.

테스트가 가능한 수준의 기능이 개발될 때마다 "dev"등의 태깅을 사용해서 Dev용 docker 이미지도 빠르게 배포되면 좋을 것 같습니다.

--> 관련하여, 프리릴리스의 배포 주기만 짧아지면 크게 문제 없다고 보시는지요? dev 단위(commit 단위로 이해)로 이미지를 생성하는 것은 특정 기능이 완료되어 있는지 아닌지 등을 일일이 상호 확인해야 할 가능성이 높아서, 기준점을 잡을 필요가 있는데, 이 기준점이 프리릴리스(각 메인테이너가 판단) 시점이 아닌가 합니다.

[dev4unet]

@seokho-son 개인적으로 말씀하신 것처럼 모든 commit마다 이미지 생성은 의미는 없어 보이며, 생각하시는 프리릴리스처럼 각 메인테이너 판단으로 특정 기능의 테스트가 가능한 시점에 배포되면 될 것 같습니다.

현재는 정식으로는 1년에 2회만 배포되고 있지만 spider나 tumblebug처럼 이 배포 주기가 짧다면 문제 없을 것 같은데...
대다수의 프레임워크들은 아직 docker 이미지를 배포하고 있지 않기도 하고 만약, 특정 기능이 테스트 가능한 수준이기는 하지만 아직 정식 테스트가 완료되지 않아서 정식 버전으로 배포하기 애매해서 부담이 된다면 dev나 pre 등으로 배포되는 형태를 취해도 좋지 않을까 싶습니다.

그렇게되면 일반인들은 안정적인 정식 버전만 내려 받거나 현재 진행 중인 버전을 빠르게 테스트하고 싶은 사람들은 dev(또는 Pre) 등의 버전으로 미리 받아 볼 수 있지 않을까? 싶습니다.

도커허브에 올라가는 이미지에 통합 Test가 완료되지 않은 이미지에 dev 등의 구분이 필요 없다면 현재 git action 정책을 그대로 사용해서 v로 시작하는 버전의 배포 주기를 짧게 가져가면 좋을 듯 싶으며, 그렇지 않고 안정화되지 않은 버전과 안정화 버전의 구분이 필요하다면 v로 시작하는 정식 버전 외의 pre나 dev 등의 단어를 포함하는 버전으로 배포하는 기능도 git action에 추가되면 좋을 것 같습니다.
그러면 dev나 Pre 등 최종 사용할 단어가 결정되면 메인테이너들이 테스트 가능하다고 판단되는 시점에 해당 태그로 태깅하면 자동으로 배포되는 형태를 취하면되지 않을까 싶습니다.

지금처럼 v0.2는 찍었으나 도커 이미지 배포를 하지 않은 프레임워크가 많듯이 이미 자동 배포 시점이 지난 경우를 대비해서 원할 때 Actions에서 수동으로 배포할 수 있는 기능도 있으면 좋을 것 같습니다.

[sykim-etri]

@MZC-CSC
이슈 메인에 기재된 Wiki 주소에 오류가 있는 것으로 보입니다. 현재는 아래 링크로 들어가야 확인이 가능합니다.
https://github.com/m-cmp/mc-admin-cli/wiki/Docker%E2%80%90Compose-%EC%9E%91%EC%84%B1-%EA%B4%80%EB%A0%A8

[dev4unet]

@sykim-etri 혹시 지금도 그러나요? 링크 확인해 보니 알려주신 링크와 동일한 링크입니다.
초기에 링크가 편집 화면으로 이동 되어서 알려 주신 링크로 변경했었는데 동일 증상이 발생하면 화면 새로 고침이나 캐시를 날리셔야 할 것 같습니다.

[sykim-etri]

@dev4unet
이슈 내용을 edit 상태로 봤는데, 알려주신 내용과는 다른 링크로 기재되어 있는 것으로 보입니다.

[dev4unet]

@sykim-etri 위키 메인 페이지가 아니라 위키 내용의 링크였네요^^
제가 이슈 메인을 위키 메인으로 잘 못 봤습니다.^^

이슈 페이지 링크 수정했습니다. 감사합니다.

[dev4unet]

오픈소스 배포 주기에서 Dev는 잘 사용을 안하니 Alpha / Beta / RC / Nightly 등에서 Alpha 정도가 어떨까 싶어서 도커허브에 올라온 몇 몇 제품들의 태그를 살펴 보니 Nginx는 Mainline / Stable / Legacy 처럼 배포 주기에 따라 구분해서 배포하는 것 같고, 그 외에는 저희처럼 대부분 버전만 사용하는 것 같네요.
그나마 구분해서 올라오는 몇몇 제품들은 대부분 rc1 / rc2 처럼 RC(Release Candidates)를 주로 사용하는 것 같습니다.^^;;;

[seokho-son]

@dev4unet 제안 및 확인 감사합니다. 현재도 @yunkon-kim 께서 CB-TB 에 적용해주신 이미지 빌드 및 퍼블리시 WF action에 의해서 PR(커밋) 단위의 edge 버전 이미지가 퍼블리시 되는 것으로 알고 있습니다.
다만 이를 활용할지 여부는 상황에 따라서 다르며, 위에서 의견 드린대로 꼭 필요한 경우 진행하시면 되지 않을까 싶습니다. :)

우선은 각 서브시스템별 dockerfile 제공이 가장 시급하겠네요.
dev 버전에 대한 이미지 퍼블리시 관련 사항은 WF action 구성 설정에 따라서, 비교적 간단히 조정이 가능하니, 필요에 따라 조정해가면 어떨까 싶습니다.

[seokho-son]

FYI

• https://github.com/cloud-barista/cb-tumblebug/blob/main/.github/workflows/continuous-integration.yaml
• https://github.com/cloud-barista/cb-tumblebug/blob/main/.github/workflows/continuous-delivery.yaml

[dev4unet]

@seokho-son 제가 WF action을 잘 몰라서 tag가 붙은 버전만 배포되는 줄 알았었는데 지금 보니 PR때마다 edge 버전도 같이 배포되고 있었네요.^^
현재는 확인이 필요한 급한 작업들은 edge 버전으로 진행을 하되 PR기준으로 자동 배포되기에 테스트 안정성을 위해 보조적으로 메인테이너들이 연계 테스트 가능한 버전이라고 판단되는 경우에는 가급적 버전을 찍어서 배포하는 프리릴리스 주기를 빠르게 진행하면 좋을 것 같습니다.

우선은 의견 주신 것처럼 각 서브시스템들의 dockfile과 WF action 세팅이 빠르게 진행되면 큰 문제는 해결될 것 같습니다.

[seokho-son]

@MZC-CSC @dev4unet

CB-Tumblebug은 Dockerfile 구성 완료하였으며, Docker Compose 로 CB-Tumblebug 및 관련 컴포넌트 제공을 기본 구동 방식으로 처리하기로 하였습니다. (저장소 차원의 Docker Compose 지속 메인테이닝 예정)

https://github.com/cloud-barista/cb-tumblebug?tab=readme-ov-file#2-run-cb-tb-and-all-related-components 및 cloud-barista/cb-tumblebug#1669 를 참고하시면 되겠습니다.

[MZC-CSC]

현재 각 프레임워크의 구동이 힘든 관계로 각 프레임워크의 메인테너분들은 최종 docker-compose.yaml 파일의 내용을 참고해서 잘 못되었거나 추가되어야 할 내용들을 알려 주시면 감사하겠습니다.