시작하면서
과제에 best practices for writing Dockerfiles 를 꼭 읽어보라는 내용이 있습니다.
지금까지 42의 성향을 볼 때 이런 문항을 무시하고 넘어갔다가 평가에서 혼나는 경우가 많아 정리하고 가려고 합니다.
물론 그것만이 아니더라도 Dockerfile을 만드는데, 올바른 방법에 대해서 아는 것은 필요하다고 생각합니다.
각 명령은 하나의 계층을 생성합니다.
이것은 이미지 layer부분에서 설명했 듯 도커파일의 한 명령은 하나의 layer를 생성합니다. 따라서, 필요한 경우에 명령을 사용하고 layer의 의미가 있을 때 사용하는 것이 좋습니다.
컨테이너 계층
이미지를 실행하고 컨테이너를 생성할 때 컨테이너 계층이라고도 하는 쓰기 가능한 새 계층을 기본 계층 위에 추가합니다. 새 파일 쓰기, 기존 파일 수정 및 파일 삭제와 같은 실행 중인 컨테이너의 모든 변경 내용은 이 쓰기 가능한 컨테이너 계층에 기록됩니다.
일반 지침 및 권장 사항
Create ephemeral containers (임시 컨테이너 만들기)
새 파일 작성, 기존 파일 수정 및 파일 삭제와 같이 실행 중인 컨테이너에 대한 모든 변경 사항은 이 쓰기 가능한 컨테이너 계층에 기록됩니다.
당신의 Dockerfile에 정의된 이미지는 가능한 한 일시적인 컨테이너를 생성해야 합니다.
여기서 일시적이라는 것은 컨테이너를 중지하고 삭제한 다음, 절대 필요한 최소한의 설정과 구성으로 다시 빌드하고 교체할 수 있는 것입니다.
도커파일의 이미지의 layer형태를 활용해서 최소한의 변경으로 교체가 가능하게 하라는 의미로 해석했다.
build context 이해
이 링크를 참고하라고 권유합니다. 따라서 링크를 따라가 정리하겠습니다.
이건 다른 게시물로 정리해두겠습니다.
다단계 빌드(Multi-stage builds)를 사용하세요
이 방법은 layer수 최소화하기와 연관이 있습니다.
다음 글을 참고해서 다른 게시물로 정리해두겠습니다.
다단계 빌드를 사용 하면 중간 레이어 및 파일 수를 줄이려고 노력하지 않고도 최종 이미지의 크기를 크게 줄일 수 있습니다. 빌드 프로세스의 마지막 단계에서 이미지가 빌드되기 때문에 빌드 캐시를 활용하여 이미지 레이어를 최소화할 수 있습니다 .
예를 들어 빌드에 여러 레이어가 포함되어 있고 빌드 캐시를 재사용할 수 있는지 확인하려는 경우 덜 자주 변경되는 레이어부터 더 자주 변경되는 레이어로 순서를 지정할 수 있습니다. 다음 목록은 명령 순서의 예입니다.
- 애플리케이션 구축에 필요한 도구 설치
- 라이브러리 종속성 설치 또는 업데이트
- 애플리케이션 생성
불필요한 패키지를 설치하지 마세요
불필요한 패키지를 설치하지 않으면 이미지의 복잡성이 감소하고, 종속성이 감소하며, 파일 크기가 감소하며, 빌드 시간이 단축됩니다.
애플리케이션 분리
각 컨테이너에는 하나의 주제만 있어야 합니다. 애플리케이션을 여러 컨테이너로 분리하면 수평 확장 및 컨테이너 재사용이 더 쉬워집니다.
예를 들어, 웹 애플리케이션은 분리된 방식으로 웹 애플리케이션, 데이터베이스 및 메모리 내 캐시를 관리하기 위해 각각 고유한 이미지가 있는 세 개의 개별 컨테이너로 구성될 수 있습니다.
컨테이너를 하나의 프로세스로 제한하는 방법은 좋은 방법이긴 하지만 어렵기도 하고, 빠르지도 않습니다.
다중 행 인수 정렬
RUN apt-get update && apt-get install -y \
bzr \
cvs \
git \
mercurial \
subversion \
&& rm -rf /var/lib/apt/lists/* \ 를 추가하는 것을 더 권장합니다.빌드 캐시 활용
이미지를 작성할 때 도커는 도커 파일의 지시사항을 단계별로 수행하여 지정된 순서대로 각각 실행합니다.
각 명령을 검사할 때 Docker는 캐시에서 중복 이미지를 새로 만드는 대신 재사용할 수 있는 기존 이미지를 찾습니다.
캐시를 전혀 사용하지 않으려면 docker build 의 --no-cache=true 옵션을 사용하면 됩니다.
Docker가 캐시를 사용하도록 허용하는 경우 일치하는 이미지를 찾을 수 있는 경우와 찾을 수 없는 경우를 이해하는 것이 중요합니다. 도커가 따르는 기본 규칙을 보고 이해합시다.
도커의 캐시관련 기본규칙
- 캐시에 이미 있는 상위 이미지부터 시작하여 다음 명령을 해당 기본 이미지에서 파생된 모든 하위 이미지와 비교하여 이들 중 하나가 정확히 동일한 명령을 사용하여 작성되었는지 확인합니다. 아니라면 캐시는 무효화됩니다.
- 대부분의 경우 도커파일을 특정 하위 이미지 하나만 보면 되지만, 여러개를 보는 경우도 있습니다.
ADD와COPYinstructions은checksum을 사용하기 때문에, 내용지 조금이라도 바뀌는 경우 캐시는 무효가 됩니다.
ADD와COPY를 제외한다면 캐시확인을 위해 컨테이너 내부 파일을 확인하지 않습니다.
- 예를 들어, 다음을 처리할 때
RUN apt-get -y update내부에서 실제 업데이트가 있는지 확인하는게 아니라 문자열이 같은지를 확인합니다.
도커파일 내부 명령에 대한 지침
여기에는 FROM 등 모든 도커파일에서 지시어에 대한 지침이 있으니 지시어를 사용하다가 모르겠는 경우 다시 찾아보는 걸로하자.
이걸 다 정리하다가는 인셉션만 두달하겠다..
[42 inception 과제 개념정리1]
Uploaded by N2T
'42Seoul > Inception' 카테고리의 다른 글
| Build context [42 inception 과제 개념 심화2] (0) | 2023.06.24 |
|---|---|
| Multi-stage builds [42 inception 과제 개념 심화 1] (0) | 2023.06.24 |
| 컨테이너 빌드에 대한 권장사항 [PID 1] [42 inception 과제 개념11] (0) | 2023.06.24 |
| Docker Volume이란? [42 inception 과제 개념 10] (0) | 2023.06.24 |
| Dockerfiles이란? [42 inception 과제 개념 9] (0) | 2023.06.24 |