[클라우드] 4. Container (Docker)

 

인프라 구조의 발전

 

가상 머신 사용의 문제점

• 가상 머신을 사용하면 가상 서버마다 필요한 소프트웨어 설치 필요
• 쉘 스크립트를 통한 설치 및 설정 자동화도 어렵고 안정성에 영향을 줌
• 위 문제를 해결하기 위해 “Immutable Infrastructure” 라는 패러다임 등장

기존 머신들을 쓸때 가상 머신들을 여러개 띄우지만 막상 CPU 사용량을 보면 되게 미미하다. 한쪽에서 과도하게 사용하여 다른 널널한 자원을 VM이 쓸수는 없을까? -> 이런 개념이 컨테이너로 만들어지는 이유

 

Immutable Infrastructure

• OS 커널과 서비스 환경을 분리해 커널의 수정 없이 서비스 환경의 교체 가능
• 서비스가 수정되면 이전 서비스 환경을 새로운 서비스 환경으로 교체

 

• “Immutable Infrastructure”의 장점
  • 편리한 관리: 서비스 운영환경을 이미지화 해 중앙에서 관리 가능
  • 확장: 이미지 하나로 다수의 서버 생성 가능
  • 테스트: 이미지를 이용해 같은 서비스 환경 구성 가능
  • 경량화: OS와 서비스 환경을 분리해 가볍고 어디서든 실행 가능

 

• Docker는 “Immutable Infrastructure” 관련 프로젝트 중 하나

 

컨테이너

• OS를 가상화해 여러 개의 고립된 리눅스 시스템을 실행하는 방법
  • “chroot”가 기원 (시스템을 보호하기 위해 특정 경로를 최상위 경로로 보이게 함)

OS를 가상화 -> 사실 리눅스 커널을 가상화한것
기존 가상 머신은 "하드웨어를 가상화 했다"라는 개념이면 컨테이너는 여러개의 고립된 리눅스 시스템으로 가상화한 것

 

• Guest OS가 필요 없이 Host OS의 자원을 공유하기 때문에 가상화의 오버헤드 적음
          • VM은 각각의 VM 마다 Guest OS를 설치해 오버헤드가 큼
          • Container는 Host OS의 커널 자원을 공유하고 유저 영역을 분리함
          • OS가 하나만 동작해 낮은 사양의 환경에서 적합

 

•  부팅 개념이 존재하지 않아 시작과 종료가 빠름
• 플랫폼 간 이동이 자유로움

Ubuntu, CentOs, RHEL => 기본적으로 리눅스 커널이라는 점이 동일하기에 이동이 자유로움

 

• 불필요한 것을 제거하고 목적에 맞는 환경 구성 가능
  • 예를 들어, 웹 서버 컨테이너에는 Apache, Httpd와 같은 필요한 것만 존재

리눅스 환경을 쓰면 뭔가를 설치하고 지웠는데도 남아있는 환경세팅들 즉, 가비지 처럼 남아있게 된다. 하지만 컨테이너는 필요한 파일들만 하나의 패키지로 만들어서 불필요한게 없다.

 

컨테이너의 장단점

• 장점
  • 개발에서 운영까지의 과정이 단축됨
         • 휴대성이 좋아 개발, 테스트 환경을 그대로 운영환경에 적용 가능
  • 빠른 시작과 종료
         • OS 입장에서는 단순한 프로세스 실행 및 종료
  • 오버헤드가 낮음
         • 가상화를 위해 하이퍼바이저가 필요하지 않음
  • 자원의 효율적 사용
         • 애플리케이션 동작에 필요한 자원으로만 구성
• 단점
  • Host OS에 종속적
         • 단일 하드웨어에 다양한 OS의 사용이 필요한 경우 VM을 사용해야 함  ex) 보안 연구 및 침투 테스트
  • 각 컨테이너에 독립된 커널 구성이 불가능함
         • 커널 자원을 공유하기 때문에 컨테이너가 사용하는 커널 환경은 동일

 

 

도커 (Docker)

• 컨테이너 관리, 생성, 실행, 배포를 위한 오픈소스 엔진
  • 2013년 Docker, Inc가 프로젝트를 처음 발표
  • Go 언어로 작성
  • 개발을 위한 효율성 증가
       • 개발 환경 구축시간 단축, 분리된 공간으로 실험환경 구성 가능
  • Linux Container, Control Group, Namespace, AUFS 등의 기술을 사용

도커의 장점

• 애플리케이션의 빠른 배포
  • 컨테이너 형식이 표준화됨, 개발자와 관리자의 업무를 분리
         • 개발자는 컨테이너 내부만, 관리자는 컨테이너 관리만
  • 애플리케이션에 대한 이해도를 높여 줌, 개발 테스트 및 수정이 빠름

 

• 설치 및 확장이 쉽고, 휴대성이 좋음
  • Docker는 어디서든 동작 가능, 실험환경이 실제 동작하는 환경으로 이동 가능
  • 컨테이너 규모 확장 및 축소가 쉽고 빠름, 컨테이너 실행/종료가 빠름

 

•  오버헤드가 낮음
  • 하이퍼바이저가 필요 없음, 서버 자원을 더 효과적으로 사용 가능
  • 장비 및 라이센스에 소비되는 비용 감소

 

• 관리가 쉬움
  • 수정된 부분만 소규모로 적용

 

도커 vs 가상머신

 

• Docker vs. KVM: 부팅 시간 및 메모리 사용량

• Docker vs. KVM: 재부팅 시간 및 메모리 사용량

 

• Docker vs. KVM: CPU 및 IO 성능 비교

 

도커의 구성요소

• Server (Docker Daemon): 컨테이너를 관리하고 실행
• Client: 사용자의 인터페이스 제공
• Registry: Image 저장소
• Image: 라이브러리, 실행 파일, 소스 코드 등이 패키지화 된 것
• Container: 하나 이상의 Image가 동작하는 것

• Server (Docker Daemon)
    • Host에서 컨테이너를 관리하고 실행하는 데몬
    • 사용자와 Docker Client를 통해 연결됨
• Docker Client
    • Docker와 사용자 간 인터페이스 제공
    • 사용자 명령을 받아 Docker Daemon으로 전달 (소켓 통신사용)

 

• Docker Registry: Image가 저장된 장소
      • Private 또는 public registry가 존재
      • Docker Hub는 Docker, Inc에서 제공하는 public registry
           • Docker hub는 GitHub 같은 기능을 제공
           • Docker Hub에 있는 다른 사용자의 Image도 사용 가능

 

• Image
    • Container를 만들기 위한 자원
        • 실행파일, 라이브러리, 애플리케이션 등
    • Union 파일 시스템 사용
        • 여러 파일 시스템을 통합해 하나로 만듦
    • Public 또는 private registry에 저장
    • 다른 사용자가 만든 것도 사용 가능

 

• Container
    • Image를 실행한 상태
        • 독립된 애플리케이션 플랫폼
        • 하나 또는 그 이상의 Image로 구성
        • 애플리케이션 실행을 위한 모든 것을 포함

 

 

 

Union Filesystem

• 여러 filesystem을 통합해 하나의 filesystem으로 보이게 하는 기술
  • 수정된 layer만 새로 빌드 후 교체하는 경량화된 방식
• Layer (filesystem을 나눈 단위)
  • Read-Only Layer (Container를 제외한 나머지)
        • Boot filesystem (bootfs): Kernel
        • Base Image: alpine, ubuntu, centos, busybox, etc.
        • Image: application, code, etc.
  • Read-Write Layer (항상 최상위 Layer에 위치)
        • Container: 수정 가능한 layer
• Copy-on-Write
  • Image 내용을 수정할 땐 Container로 수정할 파일을 복사한 후에 내용 수정
  • 현재 상태를 저장할 땐 Container를 Image로 만듦
        • 만들어진 Image는 Registry에 저장
        • Container가 Image로 만들어 지면 새로운 Container를 위에 생성함

 

Image 수정 및 업데이트

• 기본 이미지에서 수정된 부분만 업데이트

 

 

도커의 동작 방식

• Image 생성, 저장, 검색, 실행

 

 

Dockerfile

• Dockerfile
  • Docker image를 자동으로 만들기 위해 명령어를 모아둔 문서
       • 사용자가 image 생성을 위한 명령어를 순차적으로 작성
       • Docker client의 터미널에 “docker build” 명령을 입력해 image 생성

 

 

도커의 네트워킹

• Docker 컨테이너가 외부로 통신하기 위한 구조
  • Default gateway로 Linux bridge인 docker0를 만듦
       • 외부 네트워크와 교환하는 패킷에 NAT 작업 수행
       • 컨테이너 간 네트워크 연결
  • 각 컨테이너에 격리된 네트워크 공간을 만들고 컨테이너의 eth0에 static IP 할당
  • 컨테이너 내부의 eth0와 docker0로 연결된 veth 인터페이스를 연결해 외부와 통신

 

 

도커가 사용하는 기술

• Docker가 컨테이너를 관리하기 위해 사용하는 기술
      • Libcontainer, LXC, cgroups, namespaces, etc.

 

Linux Container (LXC)

 

• 컨테이너 life-cycle 관리 기술
    • 과거에는 “chroot” 명령어로 컨테이너를 생성함
        • 직접 하위 경로에 실행 파일과 공유 라이브러리를 설치해야 함
        • 완벽한 가상화 환경이 아니기에 제약 사항이 많음
        • 설정이 복잡함
• LXC
     • 초기 Docker에서 사용된 Linux용 컨테이너 관리 기술
     • Namespaces, cgroups를 사용해 컨테이너를 생성 및 관리
• Libcontainer
     • Linux 플랫폼에 의존적인 LXC를 대체하기 위해 Docker에서 만든 컨테이너 관련 기술
         • Host OS 의존성을 제거해 다양한 플랫폼 지원
     • Go 언어로 구현

 

Control Groups (cgroups)

    • 컨테이너의 컴퓨팅 자원을 제어하는 기술
    • 프로세스 집단의 자원 관리 기능
         • CPU, memory, disk I/O, network, etc.
    • 2006년 Google에서 개발 시작
         • 초기 이름은 “process container”였으나 2007년 “control groups”로 변경
• 기능
   • Resource limitation: 설정한 메모리 이상 사용하지 못하도록 보호
   • Prioritization: 그룹에 따라 CPU 사용량 또는 디스크 I/O 분배
   • Accounting: 자원 사용량 측정
   • Control: 사용 중단, 체크 포인트 설정, 재시작 등

 

Namespaces

    • 컨테이너를 만들기 위한 프로세스 가상화 기술
    • 하이퍼바이저를 사용하지 않고 격리된 공간을 제공
• 구현 기술
    • clone() – 새로운 프로세스와 새로운 namespace 생성
    • unshare() – 존재하는 프로세스에 새로운 namespace 생성
    • setns() – 존재하는 namespace에 합류

• Namespace 종류
    • Mount namespace
         • 파일 시스템 추상화를 위해 사용
         • Container 사용자에게는 VM과 같이 새로운 파일 시스템을 보여줌
    • UTS namespace
         • User name과 domain name을 기반으로 초기화 및 설정 스크립트 작성 가능
   • PID namespace
         • PID 재사용 가능
         • Container는 자신의 PID 1을 가짐
   • Network namespace
         • Container를 host 같이 다룰 수 있음
         • Network interface, routing table, IPv4/6 network stack, firewall, port number, etc.
   • IPC namespace
         • 공유 메모리, 큐, 세마포어의 IPC 자원 분리
   • User namespace
         • User와 group ID 공간을 격리
         • Namespace 외부에 있는 user나 group이 내부의 공간을 보거나 건드릴 수 없음