쿠버네티스를 위한 파일 시스템 – UFS ( Union File System )
유튜브 동영상 보기
Container 파일시스템
발표 슬라이드의 내용을 각각 살펴 보겠습니다.
Container Image 구조
컨테이너 이미지는 결국 여러 개의 layer가 쌓여서 만들어진 것입니다.
Layer가 쌓여서 만들어진 컨테이너 이미지에 추가로 layer를 쌓을 수 있습니다.
예를들면 미들웨어가 설치되어 있는 CentOS 이미지가 필요하다고 하면 CentOS 이미지에 OS 설치 없이 미들웨어 Layer만 쌓으면 되는 것이죠.
쌓인 이미지는 DVD와 같이 읽기 전용입니다. 이제 소프트웨어를 설치하는 것 아니라, 컨테이너 이미지를 배포만 하면 되는 것입니다.
컨테이너(Container) 이미지 구조 예시
컨테이너 이미지란 각 작업들을 레이어로 만들고, 이 레이어들을 쌓아서 사용하게 됩니다.
베이스 이미지로 OS만 포함되어 있는 이미지가 있다고 가정을 합니다.
아파치 웹서버를 설치해서 OS 베이스 이미지에 웹서버만 위에 얹어서 설치하면 됩니다.
가상화 서버처럼 OS부터 다시 설치할 필요가 없다는 장점이 있죠. Layer를 공유하기 때문입니다.
그렇게 웹서버 설치가 된 베이스 이미지는 다른 사람들이 사용을 하더라도 모두 같은 상태를 유지합니다.
만약 누군가 여기다가 어플리케이션도 추가를 하고 싶다면 웹서버가 설치되어 있는 이미지에 어플리케이션만 추가 설치하면 됩니다
아까와 마찬가지로 Layer를 공유하기 때문에 OS나 웹서버를 설치할 필요가 없습니다.
이렇게 제작된 이미지들은 Containerhub 라고 불리우는 레지스트리에 저장하여 공유할 수 있습니다.
컨테이너 파일 시스템 상세 구조
컨테이너 이미지를 만들 때 Containerfile이란 메타 정보에 명령어를 기술합니다.
이런 명령어 하나 하나가 실제로는 컨테이너 이미지의 레이어가 되는 것이고, 명령어가 얼마나 많은 크기의 파일을 생성하느냐에 따라 레이어의 크기가 결정됩니다.
어떤 명령을 실행했는지에 대한 Layer 정보는 Containerhub나 레지스트리 관리 도구에서도 확인할 수 있습니다.
컨테이너 파일 시스템 – 컨테이너 이미지에 대한 레이어 정보
컨테이너를 보관하는 레지스트리에서는 누군가 악의적인 마음을 품고 바이러스를 이미지에 추가시켜서
업로드 해놓았을 수도 있으니 컨테이너 이미지에 대한 CVE(Common Vulnerabilities and Exposures) 보안도 제공하고 있습니다.
그래서 안심할 수 있는 공개 레지스트리를 사용해야 합니다. Containerhub나 레드햇에서 제공하는 quay.io, Amazon의 Public ECR등이 있습니다.
References & Related Links
- 컨테이너기술의 장점 – http://www.opennaru.com/openshift/container/benefits-of-container/
- 컨테이너기술과 가상화 기술 비교 – http://www.opennaru.com/cloud/virtualization-vs-container/
- 물리서버 , 가상화 , 컨테이너기술 진화의 역사 – http://www.opennaru.com/cloud/physical-server-virtualization-container/
경쟁력 있는 쿠버네티스 플랫폼 선택 – Red Hat OpenShift
/in Kubernetes, Red Hat/by 오픈마루 마케팅1클라우드 네이티브 환경에서 HCI가 아닌 Baremetal 시대로 전환하는 이유
/in Container, Kubernetes/by 오픈마루 마케팅1CentOS 지원 종료 – 새로운 OS선택이 아닌 컨테이너로의 전환
/in Container, Kubernetes/by 오픈마루 마케팅0