컨테이너 아키텍처와 OCI

#개발자의도구들 #컨테이너아키텍처

​

AI스쿨 msa기반 java 백엔드 코스 중에 공부한 내용을 작성하였습니다

\* 현재 Spring x 프로젝트를 진행하고 있습니다. 전체 목차를 보시려면 여기를 눌러주세요.

\* Devops stack: 여기

\* 리눅스 기본기: 여기

그림으로 시작하기

이번 글에 다룰 내용은 컨테이너 아키텍처입니다. 본격적으로 설명에 들어가기 앞서서 컨테이너 그림을 먼저 볼까요?

​

그와 동시에 컨테이너의 속성을 뽑아내어 봅시다.

                                    1. 표준규격을 따른다.

2. 외부로 부터 보호된 격리된 공간이다.

3. 무언가를 담는 전용공간이다.

대강 이정도로 뽑아내어 보았습니다. 놀랍게도 저 그림을 통해 컨테이너 아키텍처의 모든 속성을 뽑아낼 수 있었습니다. 컨테이너 안의 내용물만 실제 물건에서 어플리케이션으로 갈아 끼우면 됩니다.

컨테이너 아키텍처

컨테이너 아키텍처는 어플리케이션을 위한 맞춤형 공간을 제공합니다.

아주 간단한 예로 우리가 만든 Spring Boot Server를 컨테이너로 담는다고 가정해 봅시다. 우리는 Spring Boot를 컨테이너에 돌리기 위해서 우리가 만든 코드 파일과, JVM만 있으면 됩니다. 이 두개만 잇으면 언제 어디서든 우리의 서버가 실행될 수 있습니다.

​

가상 머신과 달리 Container는 최소한의 자원만을 사용하는 맞춤형 어플리케이션 공간이라고 보시면 됩니다.

                                    👉 실제로 크게 용량 차이는 없어서, 어플리케이션을 추상화 하는 것에 의의가 있습니다.

OCI

🚀 추상화로서의 컨테이너

특정 프로그램에 필요한 모든 설정을 컨테이너 이미지을 만들때 넣어주기 때문에 사용자가 해당 프로그램을 바로 사용할 수 있는 장점이 존재합니다.

​

👉 앱 추상화, 배포의 편리성

                                    📌 리눅스 환경에서 컨테이너의 필요성

초기 컨테이너는 리눅스 공유 라이브러리 버전 문제를 해결하기 위해 사용되었다.
리눅스는 공유 라이브러리 버전이 전역에 설정되는데, 이로인해 사용되는 어플리케이션 마다
별도로 버전을 설정할 수 없게 된다.

 반면 컨테이너는 이미지 파일 내부에 라이브러리 버전을 넣어줄 수 있기 때문에
서로 다른 어플리케이션 구동에 유리했다.

​

👉 Open Container Initiative

OCI는 컨테이너를 정의하는 표준 규격 파일입니다. Docker와 같은 컨테이너 런처 프로그램은 이 OCI 파일을 읽어들여 컨테이너를 실행합니다.

​

OCI 파일에는 다음과 같은 데이터를 포함합니다.

실제 저자가 Dockerhub에 올린 OCI 파일

위 OCI 파일은 직접 제작한 Spring Boot Server를 올려둔 파일입니다. 앞서 언급한대로 컨테이너는 프로그램 실행에 필요한 모든 것들을 저장할 수 있습니다. 단순 JVM, 서버 파일(JAR) 뿐 아니라, 해당 서버를 실행시키데 필요한 설정 및 명령어 역시 포함할 수 있습니다.

OCI Layer

위에서 보시다싶이 이미지는 여러 Layer를 이루며 하나의 파일로 합쳐집니다. 즉 실제 실행 환경에서는 해당 레이어를 하나씩 읽어들이며 컨테이너를 구축하게 됩니다.

​

이미지를 레이어로 두면 다음과 같은 🚀 이점이 있습니다.

• 변경된 레이어만 업데이트 및 다운로드 가능
• 빠른 업데이트 및 배포
• 병렬 다운로드
• 여러 레이어를 개별적으로 동시에 다운 가능
• 캐싱 효율성
• 자주 사용되는 레이어를 캐싱하여 재사용할 수 있음
• 내용 기반 주소지정
• 이미지의 무결성을 보장하며, 중복 데이터를 방지, 빠른 검증 효율적 전송이 가능

​

​

각 레이어를 레고 블럭이라 생각해보면, 이점을 직관적으로 파악할 수 있습니다. 내가 사용하는 레고 블럭은 다른 레고 시리즈에도 포함될 수 있습니다.

​

즉 우리는 OCI를 만들때 이미 만들어진 이미지를 사용한다는 것을 의미합니다.

​

​

👷‍♂️Layer Structure

​

기본적으로 OCI 파일은 Containerfile을 읽어들이며 생성됩니다.

​

Docker는 이미지를 빌드할 때 이 파일을 읽어들여 OCI 파일을 만드는데 다음과 같은 절차를 따릅니다.

​

1. Build 이전 상태를 상태 기록(snapshot)
2. Build 이후 상태와 이전 상태를 비교
3. Disk가 변경되는(크기가 줄어들거나, 늘어나는) 곳을 이미지로 생성

​

예를 들어 Dockerfile에 COPY와 같은 명령어가 있다면 이는 이미지 레이어로 추가 될 수 잇습니다.

이미지 레이어를 확대해서 보면, COPY와 같은 부분에 메모리가 추가된다는 것을 알 수 있습니다. 이는 제가 build한 JAR 파일을 컨테이너가 실행환경에 복사하도록 하는 명령어이기 때문에 레이어로 추가된 것을 볼 수 있습니다.

​

                                    🤔 0B부분은 왜 레이어로 추가가 되었는가?

 빌드 과정을 전부 복원 가능하게 기록해 둔 것으로 파일 변화 없이 기록만 남겨둔 것

추가로 기록할 내용

                                    👉 컨테이너는 기본적으로 실행환경과 OS를 공유한다. 이에 따라 커널 버전이 다르면 사용할 수 없음

👉 컨테이너의 경량성을 주목하지만, 실제로는 별차이가 업다고한다. 실제 OS가 먹는 리소스가 1이라면
서버는 99를 먹기 때문이다.

👉 컨테이너 프로세스 트리는 독립적이지 않다. 도커에 컨테이너를 실행했다면 main host의 프로세스는
도커 프로세스이다. OS 분리가 아니라 권한을 나눠 공유하지 않는 것 뿐이다.
=> host는 모두 볼 수 있음

​