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에서 수동으로 배포할 수 있는 기능도 있으면 좋을 것 같습니다.

[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 파일의 내용을 참고해서 잘 못되었거나 추가되어야 할 내용들을 알려 주시면 감사하겠습니다.

[hyeon-inno]

@MZC-CSC @seokho-son
mc-observability의 경우 기존에 구성되었던 형상에서 최상단의 manager module이 추가되고 해당 모듈을 기준으로 새로운 dockerfile이 생성될 예정입니다.
따라서 현재 릴리즈 된 버전으로 dockerfile 최신화를 진행할지, 신규 모듈이 포함된 프리 릴리즈 버전 tag 생성시 해당 버전으로 준비를 할지 제안주시면 감사하겠습니다.

[MZC-CSC]

@hyeon-inno
현재 ETRI Docker Hub에 Push된 mc-observability 도커 이미지가 없으며, manager module이 포함된 최종 형상의 배포가 오래 걸리지 않는다면, 최신 버전으로 ETRI Docker Hub에 먼저 Push 해주신 후 Push된 도커 이미지와 함께 추가로 필요한 다른 Docker 이미지들이 있다면 연계된 Docker 이미지 기반으로 구동하는 방법에 대해 알려주시면 좋을 것 같습니다.
현재는 제공된 docker-compose.yaml 파일을 기반으로 확인하려고 생각 중입니다.

[seokho-son]

@hyeon-inno (cc: @MZC-CSC @powerkimhub )

• 만약 현재 릴리스 버전으로 dockerfile을 생성/최신화 하신다는 말씀이, 현재 agent 코드에 대한 컨테이너 이미지를 생성하는 dockerfile을 의미하신 것이 맞다면,

제 생각에는

• 실제 구동 가능한 서버의 dockerfile 은 신규 모듈(서버)가 개발되면서 릴리스하시는 것이 좋을 것 같습니다.
• 다만, @MZC-CSC 에서는 전체 컴포넌트를 컨테이너로 구동하는 작업을 추진하셔야 하는 입장이라, 현재 o11y에서 임의의 dockerfile이라도 구성(agent에만 해당하는 코드라도)해주시고, 이를 컨테이너 이미지 허브에 push 할 수 있도록 ci/cd workflow 작업을 병행해주시면 좋을 것 같습니다.
  • 관련 이슈: Add Docker image build and push workflow mc-observability#20
  • 향후 정식 구동이되는 서버의 dockerfile이 릴리스 되면, 기존 의미없는 이미지는 교체될 것으로 보면 될 것 같습니다.
  • 혹시 현재 개발 버전상 임의의 dockerfile 추가에 공수가 크다면 알려주세요. 이 경우 조정이 필요할 것 같습니다.

@MZC-CSC 제가 유사한 의견을 드린 것이 맞나요?
@powerkimhub 상기 내용 확인과, 필요하다면 추가 가이드/조율 부탁드립니다.

[powerkimhub]

@MZC-CSC @hyeon-inno @seokho-son

[관련 제안]

• 현재 O11Y 배포는 M-CMP 통합 운영 입장에서는 큰 의미가 없습니다.
• @MZC-CSC 추진 중이신 작업에 큰 이슈가 없으시면,
  • O11Y 통합 파트는 유의미한 버전(API-Server-Agent)이 배포 때까지 연기해주시면 어떠신지요?
  • 관련 일정은 아래와 같고, v0.3.0 통합 일정에는 큰 이슈가 없을 걸로 예상됩니다.

[관련 O11Y 일정]

• 현재 Rest API를 이용해서 활용 가능한 예상 시점은 다음과 같습니다.
  • ~ 8/30(금): 활용 가능한 서버 초기 버전 공유
• 이후 타 FW과 엮이어 운영 가능 => Dockerfile 필요
• @hyeon-inno 다음 일정 제안 드립니다.
  • ~ 9/6(금,ASAP): 통합/설치/운영을 위한 Dockerfile 제공
    • Docker image build and push workflow 포함

---

[※ 참고: 관련 M-CMP 목표 일정]

    - O11Y 기능 pre-Release 9/20(금)
    - FW별 v0.2.x Pre-Release 10/17(목)
    - FW별 v0.3.0 Pre-Release 10/24(목)
    - M-CMP v0.3.0 Release: 10/31(목)