Docker 컨테이너를 사용하는 경우
앞에서 학습한 대로 Docker에는 사용할 수 있는 몇 가지 기능이 있습니다. 여기서는 Docker가 개발 및 운영 팀에 제공하는 이점을 살펴보겠습니다. Docker가 가장 적합한 선택이 아닐 수도 있는 몇 가지 시나리오를 살펴보겠습니다.
이러한 측면은 Docker가 컨테이너화 전략에 적합한지 결정하는 데 도움이 됩니다.
앞에서 주문 추적 포털을 개발하고 게시할 때 팀이 직면한 많은 과제가 있다고 설명했습니다. 팀은 다음에 대한 솔루션을 찾고 있었습니다.
- 간편하게 호스팅 환경 관리
- 소프트웨어를 제공하는 방법의 연속성 보장
- 서버 하드웨어의 효율적인 사용 보장
- 애플리케이션의 이동성 허용
Docker는 이와 같은 과제의 해결 방법입니다. 지금까지 설명한 모든 이점을 살펴보겠습니다.
Docker 이점
Docker를 사용하면 컨테이너화가 제공하는 이점을 즉시 활용할 수 있습니다.
효율적인 하드웨어 사용
컨테이너는 VM(가상 머신)을 사용하지 않고 실행됩니다. 앞에서 학습한 대로 컨테이너는 파일 시스템, 네트워크 관리, 프로세스 예약 및 메모리 관리와 같은 기능의 호스트 커널을 사용합니다.
VM과 비교하여 VM 내에서 실행 중인 애플리케이션에 커널 기능을 제공하려면 VM에 OS가 설치되어 있어야 함을 알 수 있습니다. VM OS에는 디스크 공간, 메모리 및 CPU 시간도 필요합니다. VM 및 추가 OS 요구 사항을 제거하여 호스트에서 리소스를 해제하고 다른 컨테이너를 실행하는 데 사용할 수 있습니다.
컨테이너 격리
Docker 컨테이너는 서로 영향을 주지 않고 동일한 호스트에서 동시에 여러 컨테이너를 실행하기 위한 보안 기능을 제공합니다. 앞에서 살펴본 대로 컨테이너를 격리하거나 특정 컨테이너 사이에 데이터와 연결을 공유하도록 데이터 스토리지 및 네트워크 구성을 구성할 수 있습니다.
이 기능을 VM 사용에 비교해 보겠습니다.
VM 두 개를 실행하는 물리적 호스트가 있다고 가정합니다. 실행하려는 애플리케이션 세 개가 서로 격리되어 있습니다. 첫 번째 앱을 VM1에 배포하고 두 번째 앱을 VM2에 배포하여 두 개의 앱을 서로 분리하기로 결정합니다. 이제 세 번째 애플리케이션을 설치하도록 선택하는 경우 이 패턴을 계속하려면 다른 VM을 설치해야 합니다.
애플리케이션 이동성
컨테이너는 거의 모든 위치, 데스크톱, 물리적 서버, VM 및 클라우드에서 실행됩니다. 이 런타임 호환성 덕분에 서로 다른 환경 간에 컨테이너화된 애플리케이션을 쉽게 이동할 수 있습니다.
컨테이너는 간단하기 때문에 VM과 같이 느린 시작 또는 종료 시간 문제가 발생하지 않습니다. 이 측면에서 다시 배포와 원활하고 신속한 스케일 업 또는 스케일 다운 같은 다른 배포 시나리오가 생성됩니다.
애플리케이션 제공
Docker를 사용하면 컨테이너는 애플리케이션을 배포하는 데 사용하는 단위가 됩니다. 이 개념을 기반으로 개발자 및 운영 팀이 모두 사용하는 표준화된 컨테이너 형식이 제공됩니다. 개발자는 소프트웨어 개발에 집중하고 운영 팀은 소프트웨어 배포 및 관리에 집중할 수 있습니다.
개발 팀이 애플리케이션 빌드를 릴리스한 후 배포 시스템의 모든 단계에서 컨테이너를 사용할 수 있습니다. 컨테이너는 연속 통합에 적합한 후보이며 빌드에서 프로덕션까지 시간을 단축합니다.
호스팅 환경 관리
애플리케이션 환경은 컨테이너에 내부적으로 구성됩니다. 이 포함은 운영 팀이 애플리케이션 환경을 훨씬 더 밀접하게 관리하는 유연성을 제공합니다. 팀은 OS 업데이트를 모니터링하고, 보안 패치를 한 번 적용하고, 필요에 따라 업데이트된 컨테이너를 출시할 수 있습니다.
팀은 다른 컨테이너에 영향을 주지 않고 설치, 업데이트 및 제거할 애플리케이션을 관리할 수도 있습니다. 각 컨테이너는 격리되며 다른 컨테이너와 개별적으로 할당되는 리소스 제한이 적용됩니다.
클라우드 배포
Docker 컨테이너는 Azure 컨테이너화 서비스의 기본 컨테이너 아키텍처이며 다른 많은 클라우드 플랫폼에서도 지원됩니다.
예를 들어 Azure Container Instances, Azure App Service 및 Azure Kubernetes Services에 Docker 컨테이너를 배포할 수 있습니다. 이러한 각 옵션은 다양한 기능을 제공합니다.
예를 들어 Azure Container Instances를 사용하면 인프라를 관리하는 오버헤드 없이 애플리케이션 디자인 및 빌드에 집중할 수 있습니다. 오케스트레이션할 컨테이너가 많은 경우 Azure Kubernetes Service를 사용하면 대규모 컨테이너 배포를 쉽게 배포하고 관리할 수 있습니다.
Docker 컨테이너를 사용하지 않는 경우
Docker 컨테이너는 많은 이점을 제공하지만 컨테이너가 모든 요구 사항에 맞지 않을 수 있다는 점에 유의하세요. 몇 가지 측면을 고려해야 합니다.
보안 및 가상화
컨테이너는 격리 수준을 제공합니다. 그러나 컨테이너는 단일 호스트 OS 커널을 공유하며 이는 단일 공격 지점이 될 수 있습니다.
Windows 호스트는 하이퍼바이저 수준에서 컨테이너를 격리하기 위해 특별히 빌드된 VM을 사용할 수 있는 추가 격리 모델을 제공합니다. 이 모드를 Hyper-V 격리 모드라고 하며 컨테이너와 컨테이너 호스트 간에 또 다른 보안 계층을 추가합니다.
또한 모든 보안 측면을 고려하는지 확인하려면 스토리지 및 네트워크와 같은 측면도 고려해야 합니다. 예를 들어 모든 컨테이너는 기본적으로 브리지 네트워크를 사용하며 IP 주소를 통해 서로 액세스할 수 있습니다.
일부 애플리케이션은 컨테이너화를 활용합니다. 이 경우 VM을 사용하는 것이 더 적합할 수 있습니다.
서비스 모니터링
애플리케이션 및 컨테이너 관리는 기존 VM 배포보다 더 복잡합니다. 실행 중인 컨테이너의 상태를 알려 주는 로깅 기능이 있지만 컨테이너 내의 서비스에 대한 자세한 정보는 모니터링하기 어렵습니다.
예를 들어 Docker는 docker stats 명령을 제공합니다. 이 명령은 CPU 사용량 백분율, 메모리 사용량 백분율, 디스크에 쓴 I/O, 전송/수신된 네트워크 데이터 및 할당된 프로세스 ID와 같은 컨테이너 정보를 반환합니다. 이 정보는 즉각적인 데이터 스트림으로 유용하지만 데이터가 저장되지 않으므로 집계가 수행되지 않습니다. 특정 기간 동안 의미 있는 데이터 캡처를 위해 타사 소프트웨어를 설치해야 합니다.