Docker

[도커 알아가기] 1. 컨테이너 기술

begong 2025. 1. 16. 02:50
반응형

관련 글 목록

1. 컨테이너 기술

2. 도커와 Docker engine

3. 도커 네트워크

4. 도커 포트포워딩 시 서버 폭파 문제해결

주제 선정 이유

  • 프로젝트에서 CI/CD를 편하게 하기 위해 도커를 사용중입니다.
  • Mediasoup 라이브러리는 접속자 한명 당 두개의 포트가 필요합니다.
  • 현재는 도커 bridge모드를 사용하여 포트 매핑을 통해 컨테이너와 네트워크 연결하고 있습니다.
  • 많은 사용자 접속을 위해, 많은 포트를 매핑 시 CPU 사용량 때문에 서버가 터지는 문제 발생하였습니다.
  • 도커 네트워크 모드 변경을 통하여 위의 문제를 해결할 수 있다고 합니다. (브릿지모드 → 호스트 모드)
  • 별다른 공부 없이 네트워크 연결 방식 변경으로 해결하기보다는 도커의 작동원리, 컨셉들을 잘 이해하여 왜? 어째서? 이런 문제가 생겼는지, 이 방법이 왜 문제를 해결하는 방법인지 학습하고 정리해보려고 합니다.

컨테이너란?

  • 코드와 모든 종속성을 패키지화하여 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행될 수 있도록 하는 표준 소프트웨어 단위

컨테이너 기술의 등장배경

  • 2000년대 초반까지만 하더라도 기업들은 애플리케이션들을 각각 별도의 서버에서 실행하고 있었음
    ⇒ 서버가 유휴 상태에 있는 시간이 많고, 자원을 비효율적으로 사용
    ⇒ VM을 사용하여 물리적 서버를 가상화하여 하나의 서버에 여러개의 어플리케이션을 실행하게 됨
  • VM은 하나 당 하나의 OS를 요구하기 떄문에 성능적으로 뛰어나지 않았음
  • 더욱 빠르고, 가벼운 가상화 기술이 요구되어 컨테이너 기술이 등장

컨테이너 기술의 역사

1980년 초반 ~ 2000년 초반 초기 가상화 기술

  • Chroot(1982년)
    • 초기 리눅스 시스템에서 사용된 파일 시스템 격리 기술
    • 프로세스를 특정 디렉토리 트리 안에서만 동작하도로 강제하여 프로세스 격리를 제공 ⇒ 컨테이너화의 가장 초기 형태
    • 완벽한 격리를 제공하지 않았고, 보안적인 결함이 있었음
  • Linux vServer(2001년)
    • Linux 커널에서 운영 체제 수준의 가상화
    • CPU 시간, 메모리, 네트워크 주소 등의 리소스를 안전하게 분할 할 수 있었음

2000년대 후반 - LXC

  • LXC (Linux Containers) (2008년)
    • 리눅스 커널의 네임스페이스(Namespace)와 컨트롤 그룹(Cgroups) 기능을 활용하여 격리된 환경을 제공하는 리눅스 기반의 컨테이너화 기술
    • 운영체제 수준의 가상화를 제공
    • 여러 컨테이너가 동일한 리눅스 커널을 공유하면서도 독립적으로 동작
    • 현재 컨테이너화 기술에 매우 큰 영향을 미침

도커의 등장 (2013년)

  • 기존의 컨테이너화 기술(LXC등)을 기반으로, 애플리케이션 배포와 관리를 위한 간편한 툴을 제공하는 방식으로 등장
  • 간단하고 직관적인 도커 명령어를 통해 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있었음.
  • Docker Swarm과 같은 오케스트레이션 도구를 통해 컨테이너의 관리 및 배포를 간소화.
  • Kubernetes와 같은 도구와의 통합을 통해 대규모 시스템에서 컨테이너를 효율적으로 관리 및 자동화

컨테이너의 실행방식

  • 구조
    • Host Operating System : 컨테이너가 실행되는 실제 물리적인 서버의 운영 체제
    • 컨테이너 엔진 (예 : Docker) : 컨테이너를 생성하고 실행하는 소프트웨어
    • 컨테이너
  • 어플리케이션 계층의 추상화
  • 호스트 운영체제에서 실행됨 ⇒ 운영 체제의 커널을 공유
  • 운영체제의 커널을 공유하지만 애플리케이션의 독립된 실행환경을 제공

가상머신의 실행 방식

  • 구조
    • 호스트 OS(그림에서는 없음) : 실제 물리적인 서버의 운영체제
    • Hypervisor : 여러개의 가상 머신을 관리하는 소프트웨어
      • Type1 : 호스트 OS 없이 하드웨어에서 직접 실행
      • Type2 : 호스트 OS 위에서 실행
        • 위의 그림은 Type1 hypervisor에 대한 그림
    • Guest OS : 가상 머신 내에서 실행되는 독립적인 운영 체제.
  • 하드웨어의 추상화
  • 각 가상 머신은 독립된 운영체제를 실행하는 가상화된 컴퓨터

가상머신과 컨테이너의 비교

  • 가상머신
    • 장점 : 완전한 격리, 하나의 물리적 서버에서 다양한 OS 실행가능, 완전한 OS사용으로 다양한 요구사항의 애플리케이션 실행 가능
    • 단점 : OS를 여러개 실행하는 것이므로 자원 소모가 큼, 배포 및 관리가 어려움
  • 컨테이너
    • 장점 : 운영체제를 포함하지 않으므로 자원소모가 적고 빠름. 편리한 배포 및 높은 이식성, 자원 효율성이 뛰어남.
    • 단점 : vm에 비해 상대적으로 낮은 격리 수준 제공, 호스트 OS의 커널을 공유하기 떄문에 보안적 위험 존재

컨테이너의 실행방식

  • 호스트 OS의 커널을 공유하면서 격리된 환경에서 애플리케이션을 실행
  • 호스트 OS의 커널을 공유하면서도 자원은 독립적으로 격리 ⇒ 애플리케이션의 실행 환경이 다른 컨테이너와 충돌하지 않음

컨테이너화의 핵심기술

  • 네임스페이스
    • 컨테이너를 실행하는 동안, 각각의 컨테이너가 독립적인 리소스를 가지도록 도와주는 리눅스 커널의 기능
    • 컨테이너 간 격리를 담당하며 각 컨테이너가 자신만의 파일 시스템, 프로세스 ID, 네트워크 공간 등을 가진 것처럼 보이게 만듬
  • 컨트롤 그룹
    • 컨테이너가 사용할 수 있는 자원의 양을 제한하고 관리하는 리눅스 커널 기능
    • CPU, 메모리, 디스크 I/O 등의 자원 사용을 제한하여, 한 컨테이너가 과도한 자원을 사용하지 않도록 함

컨테이너 실행 흐름

  1. 이미지 생성
    • 컨테이너 이미지 : 애플리케이션 실행에 필요한 모든 파일, 라이브러리, 실행 환경 등을 포함하고 있는 읽기 전용 템플릿
    • 애플리 케이션 코드와 그에 필요한 라이브러리 및 종속성, 설정 파일, 네트워크 설정 등이 포함.
    • 이미지는 읽기전용. 실제 컨테이너가 실행될 때, 해당 이미지를 기반으로 읽기/쓰기 가능한 레이어가 추가됨.
  2. 컨테이너 실행
    • 컨테이너 엔진이 이미지를 읽고 새로운 컨테이너를 생성. 이 때 새로운 파일 시스템 레이어가 추가됨 (쓰기 가능)
    • 컨테이너가 실행되면, 네임스페이스를 사용하여 컨테이너가 독립적인 환경에서 실행되도록 격리됨.
    • 컨트롤 그룹이 컨테이너가 사용하는 자원을 제한하고 다른 컨테이너에 영향을 주지 않도록 보장
  3. 애플리케이션 실행
    • 컨테이너 내에서 애플리케이션이 실행
    • 애플리케이션은 호스트 OS와 커널을 공유하면서도, 독립적인 파일 시스템과 네트워크 환경에서 실행됨.
  4. 컨테이너 종료 및 삭제
    • 컨테이너 엔진을 통해 컨테이너를 종료 또는 삭제.
    • 컨테이너를 삭제하면 해당 컨테이너의 쓰기 가능한 레이어도 함께 삭제됨.

참고문서

What is a Container? | Docker

리눅스 컨테이너(Linux Containers, LXC)에 대해서 알아보자

https://inside.nhn.com/tech/205#:~:text=컨테이너는 특정 애플리케이션을,실행하는 기술을 말합니다.

반응형