클라우드 캔버스
도커 이미지 최적화
저희 팀은 기존에 turborepo + pnpm 환경을 쓰고 있었습니다.
그리고 주요 실행 프로그램들은 apps라는 폴더에 두었고 apps에서 공통으로 사용하는 모듈은 packages에 두었습니다.
README.md
├── apps(주요 프로그램)
│ ├── client
│ ├── hub
│ ├── nginx
│ └── server
├── config
│ ├── cz.js
│ ├── mysql
│ ├── prometheus
│ └── tsconfig.base.json
├── docker-composes
│ ├── cloud-canvas-back.yml
│ ├── cloud-canvas-front-hub.yml
│ ├── cloud-canvas-front.yml
│ ├── cloud-canvas-local-back.yml
│ ├── cloud-canvas-local-client.yml
│ ├── cloud-canvas-local-hub.yml
│ ├── cloud-canvas-local.yml
│ ├── database
│ └── monitoring
├── infra
│ ├── dev
│ ├── init.tf
│ ├── modules
│ ├── prod
│ └── variables.tf
├── package.json
├── packages(apps에서 공통으로 사용하는 모듈)
│ ├── cli
│ ├── cloud-graph
│ ├── ncloud-sdk
│ └── terraform
├── pnpm-lock.yaml
├── pnpm-workspace.yaml
├── scripts
│ └── verdaccio-publish
└── turbo.json
때문에, 도커 이미지를 만들기 위해서는 이러한 의존성을 잘 관리하는 것이 중요했습니다.
하지만 그룹 프로젝트에서 처음 도커 이미지 경량화를 시도하다가 엄청 낭패를 보았습니다.
3주차 당시에는 packages를 불러와서 빌드하는 경우가 없었습니다.
때문에 그것을 고려하지 않고 apps 내부만 신경써서 도커 이미지를 최적화 했습니다. 때문에 packages 모듈을 사용하고 있지 않았을 때는 해당 시스템이 정상적으로 동작했습니다.
문제는 이후에 packages를 사용했을 때부터 발생하게 돼서 도커 이미지가 만들어지지 않았습니다.
저희 팀은 그때 시간이 없어서 그 문제를 해결하지 못하고 COPY . . 을 활용해 임시 방편으로 도커 이미지를 만들었습니다.
그런 식으로 만들어진 도커 이미지는 2GB에 육박하게 되었고, NCP 컨테이너 레지스트리의 큰 비용 지출이 염려되는 상황이었습니다.
이번 주차에서는 pnpm + turborepo 환경에서 멀티 스테이징 빌드와 turbo prune 기능을 활용하여 도커 이미지를 최적화 할 수 있었습니다.
결론적으로 2GB → 240MB, 빌드 시간은 5분 → 30초로 줄일 수 있게 되었습니다.