Need to check Dockerfile, DockerCompose, CI, CD from its experts

[seokho-son]

최근 docker의 buildx 툴킷을 활용하여, 빌드 속도 향상과 여러 측면에서의
Dockerfile, DockerCompose, CI, CD 개선이 진행되었음.

• Speed up docker build time by using go build cache #1732
• Enhance workflow for ci cd container image #1733 Clean up files #1734

결과적으로 빌드 성능이 상당히 개선된 것으로 보이며,
오류 등의 특이사항도 없는 것으로 보임.

그러나, PR 리뷰 절차가 진행되지 않았으므로,
전문가이신 ~ @yunkon-kim 님의 추가 확인을 거치고자 함.

[yunkon-kim]

@seokho-son 올려주신 PR을 보니 컨테이너 이미지 빌드 시간이 대폭 개선된 것 같습니다 :-)

빠르게 살펴보면서 파악한 의견을 남겨드립니다. 상황에 맞게 반영하시거나, 이슈 발생 시 대응해주시면 될 것 같습니다.

1. 상대 경로로 인한 이슈 (기여자별 환경 상이)

cb-tumblebug/Dockerfile

Lines 13 to 16 in da7bbfe

	COPY go.mod go.sum go.work go.work.sum ./
	RUN --mount=type=cache,target=/go/pkg/mod \
	--mount=type=cache,target=/root/.cache/go-build \
	go mod download

cb-tumblebug/Dockerfile

Lines 25 to 27 in da7bbfe

	RUN --mount=type=cache,target=/go/pkg/mod \
	--mount=type=cache,target=/root/.cache/go-build \
	go build -ldflags '-w -s' -tags cb-tumblebug -v -o src/cb-tumblebug src/main.go

• A from @seokho-son : target=/root/.cache/go-build 는 container 내부 주소라서, 사용자가 특별히 다른 종류의 container를 사용하는 것이 아니라면, 문제가 없을 것 같습니다. :)

• A from @seokho-son : target=/go/pkg/mod 도 컨테이너 내부에서의 일반적인 경로라서, 특별히 문제 없을 것 같습니다.

• A from @yunkon-kim:
  아.. 그렇네요. 그렇다면 Dependency를 지정해서 캐시하는 방식이 아닌 빌드 과정의 이미지를 캐시하는 방식이겠네요. 이 경우에 캐시된 이미지로 인해 정상적으로 이미지가 빌드되지 않았던 경험이 있습니다. 재현이 어려운 케이스이니 현황만 공유드리겠습니다.

cb-tumblebug/docker-compose.yaml

Lines 145 to 150 in da7bbfe

	cb-mapui:
	image: cloudbaristaorg/cb-mapui:0.9.2
	container_name: cb-mapui
	build:
	context: ../cb-mapui
	dockerfile: Dockerfile

• A from @seokho-son : CB-Tumblebug을 가이드에 따라 내려 받고 시작했다면, CB-MapUI도 해당 상대 경로에 있을 것이라고 판단하였습니다. 다만, 사용자가 특별한 위치에 해당 저장소를 두었다면, 자체적으로 경로를 수정하는 것이 바람직해보입니다. CB-Tumblebug, CB-MapUI 모두 자체적으로 build 를 하는 수준의 개발자에게만 해당하므로, 해당 설정 정도는 변경할 수 있을 것으로 기대하였습니다. :)

• A from @yunkon-kim:
  기여자가 compose를 수정 및 활용하는 것은 가급적 피하고자 하셨던것 같아 코멘트 남겨본 사항입니다. 앞으로는 기여자의 수정 및 활용도 고려하면 되겠죠?

2. CI, CD 워크플로우 관련 확인 필요

캐시 적용 및 컨테이너 이미지 빌드를 위해서는 CI와 CD 워크플로우 간에 일관성을 맞출 필요가 있어 보입니다.

그 동안, docker/setup-buildx-action에도 변화가 있었던 것 같고요. 캐시와 관련하여 동작이 되고 있으나, 아래 컴포넌트들이 쓰임새에 맞게 적용되고 있는지에 대한 의문점이 있습니다.

export cache에 대해서 다음과 같이 안내되고 있으나,

By default, the docker-container driver will be used to be able to build multi-platform images and export cache using a BuildKit container. - https://github.com/docker/setup-buildx-action?tab=readme-ov-file#about

moby/buildkit에서는 현재 GitHub Actions cache가 experimental 상태 입니다.

GitHub Actions cache (experimental) https://github.com/moby/buildkit?tab=readme-ov-file#github-actions-cache-experimental

buildkit과 actions/cache@v4간에도 캐시하는 대상의 차이가 있어 보입니다. 자세한 사항은 추가로 분석 후, 개선하는 쪽이 좋을 것 같습니다.

• A from @seokho-son : 감사합니다. CI/CD 관련해서는 일단 제 선에서 대략 수정을 해두었지만 저도 아직 확신은 없습니다. 그냥 생각하기에는 github에서 구동되는 ci/cd는 매번 새로 구성될 수 있으니, 빌드 캐시가 의미가 있을까? 라는 생각도 듭니다. 멀티 빌드의 경우에는 멀티간 캐시가 의미가 있을 것 같긴하네요.. ^^

• A from @yunkon-kim:
  넵, 이 부분은 차후에 파악하여 적용하면 될 것 같습니다.

[seokho-son]

@yunkon-kim 감사합니다! 항목별로 답변이 있어서, 답변에 기존 코멘트를 수정활용하였습니다.

[yunkon-kim]

@seokho-son 마찬가지로 수정을 통해 답글 남겨놓았습니다 ^^

[seokho-son]

A from @yunkon-kim:
기여자가 compose를 수정 및 활용하는 것은 가급적 피하고자 하셨던것 같아 코멘트 남겨본 사항입니다. 앞으로는 기여자의 수정 및 활용도 고려하면 되겠죠?

네넵! 일단 저만해도 개발을 위해 build할때는 cb-tumblebug/docker-compose.yaml 를 주로 활용하게 되네요 ^^;;
git ignore가 우리가 원하는 형태로 잘 컨트롤되면 좋을텐데 좀 아쉽습니다.

docker-compose-custom.yaml (.env 활용) 도 향후에 유용하게 될 것 같은데, 일단, docker-compose.yaml 를 중심적으로 정형화(개선 등)을 해보고, 안정화되면 docker-compose-custom.yaml 의 개선도 고려해보면 좋을 것 같습니다.