[GCP] Foundations - 컨테이너 및 Kubernetes 소개

Container

• 자체 물리적인 컴퓨터에 애플리케이션을 실행. 확장성을 위해 컴퓨터를 추가하면 리소스 낭비가 심함.
• 가상화를 통해 여러 가상 서버와 운영체제를 동일한 물리적 컴퓨터에서 실행
  • 하이퍼바이저는 기본 하드웨어로 운영체제의 종속성을 깨뜨리고 여러 가상 머신이 동일한 하드웨어를 공유하도록 허용하는 소프트웨어 레이어
  • KVM은 잘 알려진 하이퍼바이저
  • 가상화를 사용하여 새 서버를 빠르게 배포 가능

• 하지만 애플리케이션과 모든 종속 항목, 운영체제는 여전히 하나로 묶여 있으며 한 하이퍼바이저 제품에서 다른 하이퍼바이저 제품으로 VM을 이동하기가 쉽지 않음 (단일 VM 내 여러 App)
  • 운영체제 부팅에 시간이 듦
  • 서로 격리되지 않음
    • 특정 애플리케이션이 리소스를 많이 사용하면 다른 애플리케이션에서 필요한 리소스를 사용하지 못함
    • 한 애플리케이션의 종속 항목을 업그레이드하면 다른 애플리케이션 작동이 멈출 수 있음
    • 문제 방지를 위해서는 통합 테스트 등이 필요함 (개발 속도 둔화)

• 각 애플리케이션에 대해 전용 가상 머신을 실행
  
  • 각 애플리케이션은 자체 종속 항목을 유지하고 한 애플리케이션이 다른 애플리케이션의 성능에 영향을 미치지 않도록 커널이 격리 (Kernel 2개)
  • 수백 또는 수천 개의 애플리케이션으로 확장하면 VM 중복 및 낭비가 일어남
    • VM은 운영체제 전체가 부팅되어야 하는 만큼 상대적으로 시작이 느림

• 애플리케이션과 종속 항목 수준에서 추상화를 구현
  • 사용자 공간은 커널 위에 상주하는 모든 코드이며 애플리케이션과 그 종속 항목이 여기에 포함
  • 컨테이너는 애플리케이션 코드 실행을 위해 격리된 사용자 공간
    • 컨테이너는 예약되거나 기반 시스템에 긴밀하게 패킹될 수 있어 아주 효율적
    • 애플리케이션을 구성하는 프로세스만 시작하고 중단하며 각 애플리케이션에 대해 VM 전체를 부팅하고 운영체제를 초기화하지 않기 때문에 컨테이너를 빠르게 생성하고 종료할 수 있음
  • 컨테이너는 가볍고 독립형이며 리소스 효율성이 높고 이동성까지 갖춘 실행 가능한 패키지
  • 컨테이너를 사용하면 애플리케이션 런타임 시스템 도구, 시스템 라이브러리, 기타 설정 등 소프트웨어 종속 항목에 대한 걱정 없이 최종 코드를 VM에서 실행할 수 있음
  • 컨테이너는 동일하게 어디서나 실행됨
  • 프로덕션 이미지를 토대로 컨테이너를 점진적으로 변경하면 단일 파일 사본으로 아주 빠르게 배포할 수 있음
    • 개발 프로세스가 빨라짐
  • 컨테이너를 사용하면 마이크로서비스 설계 패턴 즉, 세분화되고 느슨하게 결합된 구성요소를 활용하여 애플리케이션을 더 쉽게 빌드할 수 있음
    • 애플리케이션 전체에 영향을 미치지 않으면서 애플리케이션의 구성요소를 확장하고 업그레이드

 

Container and Container Image

• 이미지 = 애플리케이션과 애플리케이션의 종속 항목
• 컨테이너 = 이미지의 실행중인 인스턴스
• Containers use a varied set of Linux technologies
  • Porcesses
  • Linux namespaces
  • cgroups
  • Union file systems

 

Continers are structured in layers

• Dockerfile을 실행하면 아래에서부터 위로 Layer가 만들어진다.
• Dockerfile을 쓸 때는 레이어의 변경 가능성이 작은 것부터 큰 것 순으로 구성해야 한다.
• 제공 및 실행하려는 컨테이너에서 애플리케이션을 빌드하는 방식이 권장되지 않는다. 빌드 도구는 배포된 컨테이너에서는 기껏해야 혼잡성에 불과하지만 최악의 경우 추가로 공격에 노출되는 영역이 되기 때문이다.
• 지금은 다단계 빌드 프로세스를 활용하여 애플리케이션이 패키징되는데 이 프로세스에서는 한 개의 컨테이너가 최종 실행 가능한 이미지를 빌드하고 별개의 컨테이너가 애플리케이션을 실행하는 데 필요한 요소만 수신한다. 
  • 이미지에서 새 컨테이너를 실행하면 컨테이너 런타임은 기본 레이어 상단에 쓰기 가능한 새 레이어를 추가한다. 흔히 이 레이어를 컨테이너 레이어라고 한다.
    • 모든 변경사항 즉, 새 파일 쓰기, 기존 파일 수정, 파일 삭제 등은 이렇게 쓰기 가능한 얇은 컨테이너 레이어에 작성된다.
    • 레이어는 임시적이라서 컨테이너가 삭제되면 쓰기 가능한 레이어의 콘텐츠가 영원히 사라진다.
  • 컨테이너의 이러한 특징이 애플리케이션 설계에서 지니는 의미는 데이터를 영구적으로 저장하고 싶은 경우 실행 중인 컨테이너 이미지가 아닌 다른 곳에 저장해야 한다는 것이다.
    • 각 컨테이너는 쓰기 가능한 컨테이너 레이어를 보유하고 있고 모든 변경사항이 이 레이어에 저장된다. 따라서 여러 컨테이너가 동일한 기본 이미지에 대한 액세스를 공유하는 동시에 자체적인 데이터 상태를 지닐 수 있다.

•  컨테이너를 빌드하면 컨테이너는 이미지 전체를 복사하는 대신 차이만으로 레이어를 생성한다.
  • 컨테이너를 실행하면 컨테이너 런타임은 필요한 레이어를 가져온다.
  • 업데이트 시에는 차이만 복사하면 된다.
    • 이런 방식은 새 가상 머신을 실행하는 경우보다 훨씬 빠르다.
    • 공개적으로 사용 가능한 오픈소스 컨테이너 이미지를 자체 이미지의 기반으로 사용하거나 수정하지 않은 채 사용하는 경우는 흔하다.
• Nginx 웹 서버는 컨테이너 패키징에 자주 사용된다.

• Google은 gcr.io라는 Container Registry를 유지관리한다.
  • 다른 공개 저장소로는 Docker Hub Registry, GitLab 등이 있다. 

 

Cloud Build로 작업하기

• 1) 필요한 API 설정 여부 확인
• 2) Dockerfile과 Cloud Build로 컨테이너 빌드
• 3) 빌드 구성 파일과 Cloud Build로 컨테이너 빌드
• 4) 테스트