Docker 교과서

Why?

도커에 대한 좀 더 이해를 통해 image 최적화를 하여 좀 더 빠를 scale out을 하고싶어서 현재 mlops image가 크다보니 scale out되는데 시간이 꽤 걸리는 부분이 있음.

 

개념 정리

 

컨테이너란?

 - 가상 리소스를 들고있는 독립적인 환경을 가지는 상자( 호스트명 ip 주소, 디스크)

 - 독립적인 환경은 가지지만 컨테이너가 실행되는 컴퓨터의 리소스는 공유한다. 가상머신과 달리 운영체제를 전부 포함하지 않기 때문에 가상머신 대비 가볍다.

 - 종료된 컨테이너도 명시적으로 삭제하지 않는 한 그대로 남아 있다. 컨테이너의 파일 시스템도 그대로 남아있다.

 

네트워크

 - 컨테이너는 기본적으로 외부 환경에 노출되지 않는다. 각 컨테이너는 고유의 ip를 갖지만, 이 ip주소는 도커가 관리하는 내부 가상 네트워크의 주소지 호스타가 연결된 물리 네트워크에 연결된 것이 아니다.

- 포트를 공개한다는 것은 도커가 호스트 포트를 주시하다가 해당 포트로 들어오는 트래픽을 컨테이너로 전달해 주는 것이다.

 

실행

 - 도커 엔진 : 도커의 관리 기능을 맡는 컴포넌트, 로컬 이미지 캐시를 담당하므로 새로운 이미지가 필요하면 이미지를 내려 받으며, 기존 이미지가 있다면 전에 내려받은 이미지를 사용한다.

 - 도커 엔진은 도커 api를 통해 맡은 기능을 수행한다. 도커 cli는 도커 api의 클라이언트다.

 - 도커 엔진은 containerd라는 컴포넌트를 통해 컨테이너를 실제로 관리하는데, cotainerd는 호스트 운영체제가 제공하는 기능을 통해 가상환경을 만든다.

 

이미지와 레이어

 - 이미지는 논리적으로는 하나의 대상이다.

 - 하지만 내려받는 과정을 보면 단일 파일을 받는게 아니라 레이어 형태로 받게 된다.

 - base image는 최소한의 운영체제 layer를 포함한다.

 - 하나의 Image layer가 공유되기 때문에 docker는 image layer를 읽기전용으로 만들어둔다.

 - 도커는 캐시에 일치하는 레이어가 있는지 확인하기 위해 해시값을 사용한다. 해시값은 dockerfile 스크립트의 인스트럭션과 인스트럭션에 의해 복사되는 파일의 내용으로부터 계산되는데 일치하지않으면 캐시 미스가 발생한다.

 - 때문에 자주 변경되지않는 인스트럭션을 앞으로 오게 배치하여야 한다.

 - cmd 인스트럭션은 스크립트 마지막에 위치할 필요가 없다. 이 인스트럭션은 from 뒤라면 어디에 배치해도 무방한다. 또한 수정할 일이 잘 없을 것이므로 초반부에 배치하면 된다.

 - 이미지 최적화 첫번째로 각 인스트럭션은 layer를 가지며 data를 지운다해도 다음 layer에 가려져서 보이지 않을 뿐 삭제된게 아니다.

 - 때문에 전체 copy가 아닌 필요한 dir만 copy를 반드시 진행해야 한다.

 - 기반 이미지의 크기는 디스크 용량이나 네트워크 전송 시간뿐만 아니라 애플리케이션 보안과도 관계가 깊다. 너무 많은 도구는 컨테이너에서는 보안상의 허점이 될 수 있다. 예를 들어 curl이 설치돼 있다면, 애플리케이션 컨테이너에 침입한 공격자가 curl을 사용해 악의적인 소프트웨어를 컨터이너로 내려받거나 데이터를 전송할 수 도 있다.

 - 도구의 동작 원리와 기능을 이해해야 레이어 크기를 적절히 제어할 수 있다.

 - 멀티 스테이지 빌드를 통해 스테이지를 나누어 최종적으로 빌드되는 이미지에는 명시적으로 복사해 온 파일만이 포함되기 때문에 최적화가 가능하다.

 

빌드

 - 각 빌드 단계는 독립적으로 실행되지만 앞선 단계에서 만들어진 디렉터리나 파일을 복사할 수 있다. run 인스트럭션은 빌드 중에 컨테이너 안에서 명령을 실행한 다음 그 결과를 이미지 레이어에 저장하는 기능을 한다.

 - 멀티 스테이지 빌드를 통해 의존 모듈 로딩을 최적화 할 수 있다.

 

 

최적화 과정

최적화전 image 크기

inkyu                                                                       latset                            b89111c6d57c   6 minutes ago    24.6GB

 

최적화 진행이 완료되었다..

 

 image size는 줄이고 싶었지만 ML INFERENCE에 쓰이는 패키지가 너무 많았다 패키지 경량화를 해야하지만 해당 건은 백엔드에서 단독으로 할 수 없으므로 우선 docker layer cache를 통한 deploy 최적화를 우선으로 하게 되었다. layer hash값이 바뀌지않도록 안되어있던 versioning을 명확하게 하고 자주 변경되지 않은 layer를 위아래로 나누어서 base image로 뺄 수 있는 것들을 분리해줬다. base image만 17GB package를 푸니까 ㄷㄷ, 이후 메인 코드에 필요해 package가 7gb로 결국 매번 build time에 image하고 배포 되는 이미지는 7gb이므로 10~12분 걸리는 scale out시간이 4~5분으로 단축되게 되었다. 추후에는 좀 더 image 경량화 에 좀 더 힘써봐야 될 것 같다.