프로젝트 넷이 비슷한 이미지를 쓰고 있어서 하나로 합칠지를 고민하게 됐다. 각각 따로 빌드하니 같은 것을 매번 네 번씩 만들고 있었다.
Table of contents
Open Table of contents
무엇이 같고 다른지
항목별로 표를 만들어 넷을 나란히 놓고 런타임 판과 확장 모듈 넷과 이미지 크기를 함께 봤다.
거의 모든 항목이 같았고 런타임 판 하나와 확장 모듈 하나만 갈렸다. 다른 것이 둘뿐이라는 사실이 공통 층으로 묶을 수 있다는 근거가 됐다.
공통 층과 얹는 층
공통 부분을 기반 이미지로 한 번 만들고 각 프로젝트는 거기에 자기 것만 얹게 했으며 추가 모듈이 필요한 프로젝트만 그 한 줄을 더 쓴다.
FROM our-base:8.2
RUN pecl install imagick && docker-php-ext-enable imagick
COPY . /app공통 층이 캐시되면서 빌드 시간이 줄었다. 층을 나눌 때 자주 바뀌는 것을 위에 두는 것이 중요했는데 코드가 맨 위라 코드만 바뀌면 그 층만 다시 만들어진다.
억지로 합치지 않은 것
한 프로젝트는 런타임 판이 낮았는데 올릴 수 없는 이유가 따로 있었다. 옛 라이브러리가 새 판에서 동작하지 않았고 교체 예정이지만 아직 안 된 상태였다.
그래서 기반 이미지를 런타임 판별로 만들고 그 프로젝트만 낮은 판을 쓰게 했다. 판이 다른 것을 하나로 만들려면 한쪽이 안 되거나 이미지가 커지므로 억지로 합치지 않았다.
한 이미지에 앱 넷을 다 넣고 실행할 때 고르는 방법도 검토했지만 하지 않았다. 하나를 고쳐도 넷이 다 다시 빌드되고 배포되며 안 쓰는 앱까지 들어가 이미지가 커지고 한 앱의 의존성 문제가 넷에 영향을 준다. 기반만 공유하고 앱은 나눴다.
기반 갱신 절차
기반을 공유하게 되니 그것을 고칠 때 넷 전부에 영향이 갔다. 새 태그로 만들어 한 프로젝트에서 먼저 써 보고 문제가 없으면 나머지를 바꾸며 옛 태그는 한 달 남기는 순서를 정했다.
여기서 핵심은 최신 태그를 안 쓰고 날짜 태그를 쓴 것인데 최신 태그를 쓰면 언제 무엇이 바뀌는지 알 수 없기 때문이다. 이미지에 라벨을 붙여 무엇이 들어 있는지 보이게 하고 각 앱이 어느 기반을 쓰는지도 조회할 수 있게 했다.
공유가 만든 값
기반에 보안 문제가 나오면 기반을 다시 빌드하고 넷을 다시 빌드해 배포하는 흐름이 필요했고 그것을 자동으로 돌게 했다. 기반이 바뀌면 나머지가 따라 빌드된다.
전에는 각자 빌드하다가 하나를 빠뜨린 적이 있었는데 기반을 공유하고 나서는 한 번에 됐다. 저장 용량도 줄었고 기반이 이미 있으면 앱 층만 받으므로 배포가 빨라진 것도 따라왔다. 처음에는 빌드 시간만 생각했는데 실제로 가장 큰 값은 갱신이 한 번에 된다는 것이었다.
정리
- 비슷한 이미지가 여럿이면 무엇이 같고 다른지 표로 본다
- 공통 층을 만들고 각자 필요한 것만 얹는다
- 판이 다른 것은 억지로 하나로 만들지 않는다
- 한 이미지에 여러 앱을 넣지 않는다
- 기반을 바꿀 때 한 곳에서 먼저 써 본다
- 최신 태그 대신 날짜 태그를 쓴다
- 이미지에 라벨을 붙여 무엇이 들어 있는지 보이게 한다
- 공유하면 보안 갱신이 한 번에 된다