1. Welcome to Docker

 

리눅스 컨테이너 기술은 프로세스를 독립적으로 실행하는 기술 중 하나입니다. 컨테이너는 운영 체제 수준에서 가상화를 제공하며, 각 컨테이너는 자체 파일 시스템, 네트워크 및 프로세스 공간을 가질 수 있습니다. 이것은 컨테이너 안에서 실행되는 프로세스가 호스트 시스템에서 실행되는 다른 프로세스와 격리되어 있음을 의미합니다. 따라서 리눅스 컨테이너를 사용하면 애플리케이션을 패키지화하고 실행할 때 각 애플리케이션을 독립적인 단위로 분리할 수 있습니다. 이는 애플리케이션 간의 충돌을 방지하고, 리소스 사용을 효율적으로 관리하며, 배포와 확장을 단순화하는 데 도움이 됩니다.

리눅스 컨테이너는 호스트 시스템의 리눅스 커널을 공유합니다. 이것이 컨테이너 기술의 중요한 특징 중 하나입니다. 각 컨테이너는 독립적인 파일 시스템과 프로세스 공간을 가지지만, 호스트 시스템의 커널은 모든 컨테이너에서 공유됩니다. 이것은 컨테이너가 가볍고 빠르게 생성되고 실행될 수 있도록 도와줍니다. 또한, 리눅스 커널의 기능을 효율적으로 활용하여 컨테이너 간의 격리와 자원 관리를 제공할 수 있습니다.

컨테이너 내에서 실행되는 프로세스와 호스트 시스템에서 직접 실행되는 프로세스 모두 동일한 리눅스 커널을 공유합니다. 이는 컨테이너 기술의 핵심 개념 중 하나이며, 가상화된 환경 내에서 실행되는 프로세스는 호스트 시스템과 동일한 커널을 사용하여 작동합니다.

컨테이너 기술은 가상화 기술과 달리, 하이퍼바이저를 통해 호스트 시스템과 별도의 커널을 사용하지 않습니다. 대신, 리눅스 커널 기능 중 하나인 네임스페이스와 컨트롤 그룹(cgroups)을 이용하여 프로세스의 격리와 자원 관리를 달성합니다. 이로 인해 컨테이너 간에 리소스를 효율적으로 공유하고, 빠르게 생성 및 시작할 수 있습니다.

호스트 시스템에서 직접 실행되는 프로세스와 컨테이너 내에서 실행되는 프로세스 간에는 몇 가지 차이점이 있습니다. 주요 장점은 다음과 같습니다:
1. 직접 하드웨어 액세스: 호스트 시스템에서 실행되는 프로세스는 하드웨어에 직접 액세스할 수 있습니다. 이는 예를 들어, 컨테이너를 사용하지 않고 직접 실행되는 프로세스가 네트워크 장치 또는 GPU와 같은 하드웨어 자원에 더욱 쉽게 접근할 수 있음을 의미합니다.
2. 더 높은 성능: 컨테이너는 추가적인 추상화 계층을 가지고 있기 때문에 약간의 오버헤드가 발생할 수 있습니다. 따라서 성능에 민감한 작업을 수행하는 경우, 직접 실행되는 프로세스가 더 높은 성능을 제공할 수 있습니다.
3. 더 높은 자유도: 컨테이너는 호스트 시스템의 제약 사항 내에서만 작동합니다. 반면에 호스트 시스템에서 직접 실행되는 프로세스는 운영 체제 레벨의 제약을 거의 경험하지 않습니다. 이는 특정 운영 체제 기능을 이용할 수 있는 유연성을 제공합니다.
4. 보안: 일부 응용 프로그램은 보안 또는 규정 준수 요구 사항을 충족하기 위해 컨테이너 환경보다 더 엄격한 환경에서 실행해야 할 수도 있습니다. 호스트 시스템에서 직접 실행되는 프로세스는 더 높은 보안 수준을 유지할 수 있습니다.

요약하자면, 컨테이너는 확장성과 효율성을 제공하며, 빠른 배포 및 확장을 가능하게 합니다. 하지만 성능, 자유도 및 보안과 같은 특정 요구 사항에 따라 직접 실행되는 프로세스가 더 적합할 수 있습니다.

호스트 시스템에서 직접 실행되는 프로세스에는 컨테이너와 비교하여 몇 가지 단점이 있을 수 있습니다:
1. 환경 격리 부족: 컨테이너는 운영 체제 수준에서 격리를 제공하여 각각의 프로세스가 독립적으로 실행될 수 있습니다. 그러나 호스트 시스템에서 직접 실행되는 프로세스는 이러한 격리를 제공하지 않습니다. 따라서 프로세스 간의 상호작용이 더욱 긴밀할 수 있으며, 하나의 프로세스의 오작동이 다른 프로세스에 영향을 줄 수 있습니다.
2. 자원 관리의 어려움: 컨테이너는 자원 관리를 효율적으로 수행하기 위해 컨트롤 그룹(cgroups)과 같은 리눅스 기능을 사용합니다. 이를 통해 각 컨테이너에 할당된 자원을 제한하고 관리할 수 있습니다. 그러나 호스트 시스템에서 직접 실행되는 프로세스는 이러한 자원 제한 기능을 활용하기 어려울 수 있으며, 자원의 과다 사용이 발생할 수 있습니다.
3. 배포와 관리의 어려움: 컨테이너는 패키지화된 형태로 애플리케이션을 쉽게 배포하고 관리할 수 있습니다. 그러나 호스트 시스템에서 직접 실행되는 프로세스의 경우, 애플리케이션의 배포 및 관리 작업이 더 복잡해질 수 있습니다. 이는 응용 프로그램의 종속성 관리, 구성 변경, 버전 관리 등을 포함할 수 있습니다.
4. 이식성 문제: 호스트 시스템에서 직접 실행되는 프로세스는 호스트 운영 체제에 종속적일 수 있습니다. 따라서 이식성이 떨어질 수 있으며, 다른 환경에서 동일한 방식으로 실행하기 어려울 수 있습니다.

이러한 단점들은 상황에 따라 다를 수 있으며, 컨테이너와 직접 실행되는 프로세스를 적절히 선택하는 것은 애플리케이션의 요구 사항과 환경에 따라 다를 수 있습니다.

 

 

이 장에서 다루는 내용은 다음과 같습니다.

• Docker가 무엇인지
• 예시: "Hello, World"
  
• 컨테이너 소개
  
• Docker가 대부분의 사람들이 용인하는 소프트웨어 문제를 어떻게 해결하는지
  
• Docker를 언제, 어디서, 왜 사용해야 하는지

최선의 관행은 제품이나 시스템에 선택적으로 투자하여 미래에 더 나은 결과를 가져올 수 있는 것을 말합니다. 최선의 관행은 보안을 강화하고, 충돌을 방지하며, 서비스 가능성을 개선하거나, 수명을 연장합니다. 최선의 관행은 종종 옹호가 필요한데, 이는 즉각적인 비용을 정당화하기 어려울 수 있기 때문입니다. 이는 시스템이나 제품의 미래가 불확실할 때 특히 그렇습니다. Docker는 소프트웨어 패키징, 배포, 사용에 대한 최선의 관행을 저렴하고 합리적인 기본값으로 채택하게 만드는 도구입니다. 이는 프로세스 컨테이너에 대한 완전한 비전을 제공하고, 이를 구축하고 작업하는 간단한 도구를 제공함으로써 이루어집니다. 동적 스케일링 요구 사항이 있는 서비스 소프트웨어를 운영하는 팀에 속해 있다면, Docker를 사용하여 소프트웨어를 배포하면 고객에 미치는 영향을 줄일 수 있습니다. 컨테이너는 가상 머신보다 더 빨리 시작되며, 더 적은 자원을 소비합니다.

 

지속적인 통합(Continuous Integration)과 지속적인 배포(Continuous Deployment) 기술을 사용하는 팀들은 Docker를 사용함으로써 더 표현력 있는 파이프라인을 구축하고 더 견고한 기능 테스트 환경을 만들 수 있습니다. 테스트되는 컨테이너는  프로덕션으로 이동할 동일한 소프트웨어를 보유합니다. 결과적으로 프로덕션 변경에 대한 높은 신뢰도, 더 엄격한  프로덕션 변경 통제, 그리고 더 빠른 반복이 가능해집니다. 

팀이 로컬 개발 환경을 모델링하기 위해 Docker를 사용한다면, 팀원 온보딩 시간을 줄이고 작업을 늦추는 일관성 없는 문제를 해결할 수 있습니다. 그러한 환경은 소프트웨어와 함께 버전 관리되며 소프트웨어 요구 사항이 변경됨에 따라 업데이트될 수 있습니다.

팀원 온보딩(Onboarding)은 새로운 팀원이 조직의 문화, 필요한 기술, 프로세스 등을 이해하고 팀의 일원으로서 효과적으로 기능할 수 있도록 지원하는 과정을 말합니다. 이 과정은 새로운 팀원이 업무에 필요한 정보를 얻고, 동료들과의 관계를 형성하며, 조직 내에서의 역할을 명확히 하는 데 도움을 줍니다. 온보딩 과정은 새로운 직원이 빠르게 적응하고, 생산성을 높이며, 장기적으로 회사에 긍정적인 영향을 미칠 수 있도록 설계되어야 합니다. 이 과정은 단순히 초기 교육만을 의미하는 것이 아니라, 새로운 팀원이 조직의 일원으로 완전히 통합될 때까지 지속되는 포괄적인 접근 방식을 포함합니다.

 

소프트웨어 작성자는 보통 자신의 소프트웨어를 합리적인 디폴트 값과 필요한 의존성으로 해당 소프트웨어를 설치하고 구성하는 방법을 알고 있습니다. 소프트웨어를 작성하는 경우, Docker를 사용하여 그 소프트웨어를 배포하면 사용자가 설치하고 실행하기가 더 쉬워집니다. 사용자는 포함된 디폴트 구성과 도움이 되는 자료를 활용할 수 있습니다. Docker를 사용하면, 제품 "설치 가이드"를 단일 명령어와 단일 이동식 의존성으로 줄일 수 있습니다.

소프트웨어 작성자가 의존성, 설치, 포장을 이해하는 반면, 시스템 관리자는 소프트웨어가 실행될 시스템을 이해합니다. Docker는 컨테이너에서 소프트웨어를 실행하기 위한 표현력 있는 언어를 제공합니다. 이 언어는 시스템 관리자가 환경 특정 구성을 주입하고 시스템 자원에 대한 접근을 엄격하게 제어할 수 있게 합니다. 동일한 언어는 내장된 패키지 관리, 도구, 배포 인프라와 결합하여, 배포를 선언적이고, 반복 가능하며, 신뢰할 수 있게 만듭니다. 이는 일회용 시스템 패러다임, 영구 상태 분리, 그리고 시스템 관리자가 더 높은 가치 활동에 집중할 수 있게 도와주는 다른 최선의 관행을 촉진합니다.

2013년 3월에 출시된 Docker는 운영 체제와 함께 작동하여 소프트웨어를 패키지하고, 배송하며, 실행합니다. Docker를 시간을 절약하고 핵심 역량에 집중할 수 있게 해주는 소프트웨어 물류 제공자로 생각할 수 있습니다. Docker는 웹 서버, 데이터베이스, 메일 서버와 같은 네트워크 애플리케이션은 물론, 텍스트 에디터, 컴파일러, 네트워크 분석 도구 및 스크립트와 같은 터미널 애플리케이션과 함께 사용할 수 있으며, 일부 경우에는 웹 브라우저와 생산성 소프트웨어와 같은 GUI 애플리케이션을 실행하는 데도 사용됩니다.

Docker는 대부분의 시스템에서 리눅스 소프트웨어를 실행합니다. Docker for Mac과 Docker for Windows는 일반적인 가상 머신(VM) 기술과 통합하여 Windows 및 macOS와의 이식성을 생성합니다. 그러나 Docker는 현대의 Windows 서버 기계에서 네이티브 Windows 애플리케이션을 실행할 수 있습니다.

Docker는 프로그래밍 언어가 아니며 소프트웨어를 구축하기 위한 프레임워크도 아닙니다. Docker는 설치, 제거, 업그레이드, 배포, 신뢰 및 소프트웨어 실행과 같은 일반적인 문제를 해결하는 데 도움이 되는 도구입니다. 이는 오픈 소스 리눅스 소프트웨어로, 누구나 기여할 수 있으며 다양한 관점으로부터 혜택을 받았다는 의미입니다. 회사가 오픈 소스 프로젝트의 개발을 후원하는 것은 일반적인 일입니다. 이 경우, Docker Inc.가 주요 후원자입니다. Docker Inc.에 대해 더 알아보려면 https://docker.com/company/에서 확인할 수 있습니다.

 

1.1 Docker란 무엇인가?

이 책을 집어 들었다면, 아마도 Docker에 대해 이미 들어보셨을 겁니다. Docker는 프로그램을 구축, 배포, 실행하기 위한 오픈 소스 프로젝트입니다. 이는 커맨드라인 프로그램, 백그라운드 프로세스, 그리고 소프트웨어 문제를 해결하고 소프트웨어를 설치, 실행, 출판, 제거하는 경험을 단순화하는 물류적 접근을 제공하는 일련의 원격 서비스입니다. Docker는 컨테이너라고 불리는 운영 체제 기술을 사용하여 이를 달성합니다.

 

 

 

1.1.1 "Hello, World"

이 주제는 구체적인 예시를 통해 배우기가 더 쉽습니다. 전통을 따라, "Hello, World"를 사용할 것입니다. 시작하기 전에, 시스템에 맞는 Docker를 다운로드하고 설치하세요. 모든 가능한 시스템에 대한 자세한 설치 지침은 https://docs.docker.com/install/에서 최신으로 유지됩니다. Docker가 설치되었고 인터넷 연결이 활성화되면, 명령 프롬프트로 이동하여 다음을 입력하세요:

docker run dockerinaction/hello_world

이렇게 하면 Docker가 활성화되어 다양한 구성 요소를 다운로드하기 시작하고 결국 "hello world"를 출력합니다. 다시 실행하면, "hello world"만 출력됩니다. 이 예시에서는 여러 가지 일이 일어나고 있으며, 명령 자체에는 몇 가지 구분되는 부분이 있습니다.

먼저, docker run 명령을 사용합니다. 이는 Docker에게 컨테이너 안에서 프로그램을 설치하고 실행하는 시퀀스(그림 1.1에 표시됨)를 시작하고 싶다는 것을 알립니다.

그림 1.1 docker run 실행 후 발생하는 것들

 

두 번째 부분은 Docker가 컨테이너에서 실행하길 원하는 프로그램을 명시합니다. 이 예시에서, 그 프로그램은 dockerinaction/hello_world입니다. 이것을 이미지(또는 저장소) 이름이라고 합니다. 지금 당장은, 이미지 이름을 설치하거나 실행하고자 하는 프로그램의 이름으로 생각하면 됩니다. 이미지 자체는 파일과 메타데이터의 집합입니다. 이 메타데이터에는 실행할 특정 프로그램과 기타 관련 구성 세부 정보가 포함됩니다.

참고: 이 저장소와 여러 다른 저장소는 이 책의 예시를 지원하기 위해 특별히 만들어졌습니다. 2부의 끝까지, 이러한 오픈 소스 예시들을 검토하는 데에 익숙해질 수 있어야 합니다.

이 명령을 처음 실행할 때, Docker는 dockerinaction/hello_world 이미지가 이미 다운로드되었는지를 파악해야 합니다. 만약 그것을 컴퓨터에서 찾을 수 없다면(Docker를 처음 사용하는 경우일 수 있음), Docker는 Docker Hub에 요청을 합니다. Docker Hub는 Docker Inc.에 의해 제공되는 공개 레지스트리입니다. Docker Hub는 로컬 호스트 컴퓨터에서 실행 중인 Docker에게 이미지(dockerinaction/hello_world)가 어디에서 찾을 수 있는지를 알려주고, Docker는 다운로드를 시작합니다.

 

이미지가 설치되면, Docker는 새로운 컨테이너를 생성하고 단일 명령을 실행합니다. 이 경우, 명령은 간단합니다:

echo "hello world"

 

echo 커맨드가 터미널에 "hello world"를 출력한 후, 프로그램은 종료되고 컨테이너는 정지 상태로 표시됩니다. 컨테이너의 실행 상태가 컨테이너 내부에서 실행 중인 단일 프로그램의 상태와 직접 연결되어 있다는 것을 이해하는 것이 중요합니다. 프로그램이 실행 중이면 컨테이너도 실행 중입니다. 프로그램이 중지되면 컨테이너도 중지됩니다. 컨테이너를 다시 시작하면 프로그램이 다시 실행됩니다.

명령어를 두 번째로 주면, Docker는 docker-inaction/hello_world가 설치되었는지 다시 확인할 것입니다. 이번에는 로컬 호스트 컴퓨터에서 이미지를 찾아 다른 컨테이너를 생성하고 즉시 실행할 수 있습니다. 중요한 세부사항을 강조하고 싶습니다. docker run을 두 번째로 사용할 때, 같은 저장소에서 두 번째 컨테이너를 생성합니다(그림 1.2가 이를 보여줍니다). 이는 docker run을 반복적으로 사용하고 많은 컨테이너를 생성하면, 생성한 컨테이너의 목록을 얻고 어느 시점에서는 그것들을 파괴할 필요가 있다는 것을 의미합니다. 컨테이너를 다루는 것은 그것들을 생성하는 것만큼이나 간단하며, 두 주제 모두 2장에서 다룹니다.

 

그림 1.2 두 번째로 docker run을 실행합니다. 이미지가 이미 설치되어 있기 때문에, Docker는 새 컨테이너를 즉시 시작할 수 있습니다.

 

축하합니다! 이제 공식적으로 Docker 사용자가 되셨습니다. Docker 사용은 바로 이렇게 쉽습니다. 하지만 실행하려는 애플리케이션에 대한 이해를 시험할 수 있습니다. 컨테이너에서 웹 애플리케이션을 실행한다고 생각해 보세요. TCP 포트 80에서 들어오는 네트워크 통신을 기다리는 장기 실행 애플리케이션이라는 것을 모른다면, 해당 컨테이너를 시작하기 위해 어떤 Docker 명령어를 사용해야 할지 정확히 모를 수 있습니다. 이러한 유형의 문제점들은 사람들이 컨테이너로 이전하면서 마주치게 됩니다.

이 책은 귀하의 특정 애플리케이션의 필요성에 대해 말할 수는 없지만, 공통 사용 사례를 식별하고 가장 관련성 높은 Docker 사용 패턴을 가르치는 데 도움을 줍니다. 1부의 끝까지, Docker를 사용한 컨테이너에 대한 강력한 이해를 갖게 될 것입니다.

 

1.1.2 컨테이너

역사적으로 UNIX 스타일 운영 시스템은 jail이라는 용어를 사용하여, 특정 프로그램이 접근할 수 있는 자원의 범위를 제한하는 수정된 런타임 환경을 설명하는 데 사용했습니다. Jail 기능은 1979년으로 거슬러 올라가며 이후로 계속 발전해왔습니다. 2005년, 선 마이크로시스템즈(Sun Microsystems)의 Solaris 10과 Solaris 컨테이너의 출시로, 이러한 런타임 환경에 대한 용어가 컨테이너로 선호되기 시작했습니다. 목표는 파일 시스템 범위를 제한하는 것에서 명시적으로 허용된 경우를 제외하고 모든 자원으로부터 프로세스를 격리하는 것으로 확장되었습니다.

컨테이너를 사용하는 것은 오랫동안 최선의 관행이었습니다. 하지만 수동으로 컨테이너를 구축하는 것은 도전적이며 잘못하기 쉽습니다. 이러한 도전은 일부 사람들에게는 컨테이너를 사용하기 어렵게 만들었습니다. 다른 사람들은 잘못 구성된 컨테이너를 사용하며 잘못된 보안 감각에 안주합니다. 이는 해결을 요구하는 문제였으며, Docker가 도움을 줍니다. Docker로 실행되는 모든 소프트웨어는 컨테이너 내에서 실행됩니다. Docker는 기존의 컨테이너 엔진을 사용하여 최선의 관행에 따라 일관되게 구축된 컨테이너를 제공합니다. 이는 모든 사용자에게 강화된 보안을 제공합니다.

Docker를 사용함으로써, 사용자는 훨씬 낮은 비용으로 컨테이너를 얻을 수 있습니다. 1.1.1 섹션의 예시를 실행하는 것은 컨테이너를 사용하며, 특별한 지식을 요구하지 않습니다. Docker와 그 컨테이너 엔진이 개선됨에 따라, 최신이자 가장 훌륭한 격리 기능을 얻게 됩니다. 강력한 컨테이너를 구축하는 빠르게 발전하고 기술적으로 복잡한 세계를 따라잡는 대신, 대부분을 Docker가 처리하도록 할 수 있습니다.

 

 

1.1.3 컨테이너는 가상화가 아니다

클라우드 네이티브 시대에 사람들은 일반적으로 단일 프로세스를 배포한다는 것이 네트워크에 연결된 가상 머신을 생성하는 것을 의미하는 배포 단위로 가상 머신을 생각합니다. 가상 머신은 가상 하드웨어(운영 체제 및 기타 프로그램을 설치할 수 있는 하드웨어)를 제공합니다. 가상 머신을 생성하는 데는 오랜 시간(종종 몇 분)이 걸리며 사용하고자 하는 소프트웨어 외에도 전체 운영 체제를 실행하기 때문에 상당한 리소스 오버헤드가 필요합니다. 가상 머신은 모든 것이 실행되고 난 후 최적의 성능을 발휘할 수 있지만, 시작 지연은 즉각적 또는 반응형 배포 시나리오에 적합하지 않게 만듭니다.

가상 머신과 달리, Docker 컨테이너는 하드웨어 가상화를 사용하지 않습니다. Docker 컨테이너 내부에서 실행되는 프로그램은 호스트의 리눅스 커널과 직접 인터페이스합니다. 많은 프로그램들이 불필요한 운영 체제를 실행하거나 전체 부팅 시퀀스의 지연을 겪지 않고도 격리 상태에서 실행될 수 있습니다. 이는 중요한 차이점입니다. Docker는 하드웨어 가상화 기술이 아닙니다. 대신, 운영 체제 커널에 이미 내장된 컨테이너 기술을 사용할 수 있게 도와줍니다.

가상 머신은 운영 체제를 실행할 수 있도록 하드웨어 추상화를 제공합니다. 컨테이너는 운영 체제의 기능입니다. 따라서 현대적인 리눅스 커널을 실행하는 머신에서는 항상 Docker를 가상 머신 안에서 실행할 수 있습니다. Docker for Mac과 Windows 사용자, 그리고 거의 모든 클라우드 컴퓨팅 사용자는 가상 머신 안에서 Docker를 실행할 것입니다. 따라서 이들은 실제로 서로 보완적인 기술입니다.

 

 

1.1.4 격리를 위해 컨테이너에서 소프트웨어 실행

컨테이너와 격리 기능은 수십 년 동안 존재해 왔습니다. Docker는 리눅스 네임스페이스와 cgroups를 사용하는데, 이는 2007년부터 리눅스의 일부였습니다. Docker는 컨테이너 기술을 제공하지 않지만, 컨테이너 기술을 사용하기 더 간단하게 만듭니다. 시스템에서 컨테이너가 어떤 모습인지 이해하기 위해, 먼저 기본선을 설정해 보겠습니다. 그림 1.3은 단순화된 컴퓨터 시스템 아키텍처에서 실행되는 기본 예시를 보여줍니다.

 

그림 1.3 커맨드 라인에서 시작된 두 프로그램을 실행하는 기본 컴퓨터 스택

 

커맨드 라인 인터페이스(CLI)는 운영 체제 위에서 실행되는 다른 프로그램들처럼 User space 메모리에서 실행되는 것으로 불립니다. 이상적으로, 사용자 공간에서 실행되는 프로그램은 커널 공간 메모리를 수정할 수 없습니다. 넓게 말하자면, 운영 체제는 모든 사용자 프로그램과 컴퓨터가 실행되고 있는 하드웨어 사이의 인터페이스입니다.

※ Process Virtual Address Space

그림 1.4에서 볼 수 있듯이, Docker를 실행한다는 것은 User space에서 두 프로그램을 실행하는 것을 의미합니다. 첫 번째는 Docker 엔진입니다. 제대로 설치되었다면, 이 프로세스는 항상 실행되어야 합니다. 두 번째는 Docker CLI입니다. 이는 사용자가 상호작용하는 Docker 프로그램입니다. 소프트웨어를 시작, 중지 또는 설치하고 싶다면, Docker 프로그램을 사용하여 명령을 내릴 것입니다.

Docker 데몬(Docker daemon)은 Docker 엔진(Docker Engine)의 일부입니다. Docker 데몬은 백그라운드에서 실행되는 서비스로서, Docker CLI(명령줄 인터페이스) 또는 다른 Docker 클라이언트와의 통신을 관리하고, 이미지를 관리하며, 컨테이너의 실행과 같은 Docker 명령을 처리합니다. Docker 엔진은 Docker 데몬, Docker CLI, 그리고 Docker REST API를 포함하는 더 넓은 아키텍처를 말합니다. Docker 데몬은 주로 Docker 컨테이너를 생성, 실행, 모니터링 및 관리하는 핵심적인 역할을 수행합니다.

 

그림 1.4 기본 리눅스 컴퓨터 시스템에서 세 개의 컨테이너를 실행하는 Docker

그림 1.4는 또한 세 개의 실행 중인 컨테이너를 보여줍니다. 각각은 Docker 엔진의 자식 프로세스로 실행되며, 컨테이너로 감싸져 있고, 대리 프로세스[Docker 엔진의 자식 프로세스]는 User Space의 자체 메모리 하위 공간에서 실행됩니다. 컨테이너 안에서 실행되는 프로그램은 컨테이너에 의해 정의된 범위 내에서만 자신의 메모리와 자원에 접근할 수 있습니다.

Docker는 10가지 주요 시스템 기능을 사용하여 컨테이너를 구축합니다. 이 책의 1부는 Docker 명령어를 사용하여 이러한 기능이 어떻게 수정될 수 있는지를 보여줌으로써, 포함된 소프트웨어의 필요성을 충족시키고 컨테이너가 실행될 환경에 맞게 조정할 수 있습니다.

10가지 주요 시스템 기능:

• PID namespace — Process identifiers and capabilities
• UTS namespace — Host and domain name
• MNT namespace — Filesystem access and structure
• IPC namespace — Process communication over shared memory
• NET namespace — Network access and structure
• USR namespace — User names and identifiers
• chroot syscall — Controls the location of the filesystem root
• cgroups—Resource protection
• CAP drop — Operating system feature restrictions
• Security modules — Mandatory access controls

Docker는 런타임에 컨테이너를 구축하기 위해 이러한 기술을 사용하지만, 컨테이너를 패키지하고 배포하기 위해 또 다른 기술 세트를 사용합니다.

 

1.1.5 컨테이너 배송[Shipping]

Docker 컨테이너를 물리적인 배송 컨테이너로 생각할 수 있습니다. 이는 애플리케이션과 그 모든 의존성들(실행 중인 운영 체제 커널을 제외한)을 저장하고 실행하는 상자입니다. 크레인, 트럭, 기차, 배가 배송 컨테이너를 쉽게 다룰 수 있듯이, Docker도 컨테이너를 쉽게 실행, 복사, 분배할 수 있습니다. Docker는 소프트웨어를 패키지하고 배포하는 방법을 포함함으로써 전통적인 컨테이너 비유를 완성합니다. 배송 컨테이너 역할을 하는 구성 요소를 이미지라고 합니다.

1.1.1절의 예시에서는 dockerinaction/hello_world라는 이름의 이미지를 사용했습니다. 그 이미지는 작은 실행 가능한 리눅스 프로그램이 담긴 단일 파일을 포함합니다. 보다 일반적으로, Docker 이미지는 컨테이너 내에서 실행되는 프로그램에게 제공되어야 하는 모든 파일들의 번들된 스냅샷입니다. 원하는 만큼 많은 컨테이너를 이미지로부터 생성할 수 있습니다. 하지만 그렇게 할 때, 같은 이미지에서 시작된 컨테이너들은 파일 시스템에 대한 변경사항을 공유하지 않습니다. Docker를 사용하여 소프트웨어를 배포할 때, 이러한 이미지를 배포하고, 수신 컴퓨터는 그것들로부터 컨테이너를 생성합니다. 이미지는 Docker 생태계에서 배송 가능한 단위입니다.

Docker는 Docker 이미지를 분배하는 것을 간소화하는 일련의 인프라 구성 요소를 제공합니다. 이러한 구성 요소는 레지스트리와 인덱스입니다. Docker Inc., 다른 호스팅 회사들 또는 자체 레지스트리와 인덱스에서 제공하는 공개적으로 이용 가능한 인프라를 사용할 수 있습니다.

 

 

1.2 Docker가 해결하는 문제는 무엇인가?

소프트웨어 사용은 복잡합니다. 설치하기 전에 사용 중인 운영 체제, 소프트웨어가 요구하는 자원, 이미 설치된 다른 소프트웨어, 그리고 의존하는 다른 소프트웨어 등을 고려해야 합니다. 설치 위치를 결정해야 합니다. 그 다음에는 설치 방법을 알아야 합니다. 설치 과정이 오늘날 얼마나 극적으로 다양한지는 놀랍습니다. 고려해야 할 사항 목록은 길고 냉혹합니다. 소프트웨어 설치는 최선의 경우에도 일관성이 없고 너무 복잡합니다. 시간이 지남에 따라 여러 대의 기계가 일관된 소프트웨어 세트를 사용하도록 하고 싶다면 문제는 더욱 악화됩니다.

APT, Homebrew, YUM, npm과 같은 패키지 관리자들이 이를 관리하려고 시도하지만, 그 중 소수만이 어느 정도의 격리를 제공합니다. 대부분의 컴퓨터에는 한 개 이상의 애플리케이션이 설치되어 실행되고 있습니다. 그리고 대부분의 애플리케이션은 다른 소프트웨어에 대한 의존성을 가지고 있습니다. 사용하고자 하는 애플리케이션이 잘 어울리지 않을 때는 어떻게 될까요? 재앙입니다! 애플리케이션이 의존성을 공유할 때 상황은 더 복잡해집니다:

• 어떤 애플리케이션이 업그레이드된 의존성을 필요로 하는데 다른 애플리케이션은 필요로 하지 않는다면 어떻게 될까요?
• 애플리케이션을 제거할 때 정말로 사라지나요?
  
• 오래된 의존성을 제거할 수 있나요?
  
• 이제 제거하고 싶은 소프트웨어를 설치하기 위해 해야 했던 모든 변경 사항을 기억할 수 있나요?
  

사실, 사용하는 소프트웨어가 많을수록 관리하기가 더 어려워집니다. 애플리케이션을 설치하고 실행하는 데 필요한 시간과 에너지를 들일 수 있다 하더라도, 보안에 대해 얼마나 확신할 수 있을까요? 오픈 소스와 폐쇄 소스 프로그램은 지속적으로 보안 업데이트를 제공하며, 모든 문제를 인지하는 것은 종종 불가능합니다. 실행하는 소프트웨어가 많을수록 공격에 취약할 위험이 커집니다.

심지어 엔터프라이즈급 서비스 소프트웨어도 의존성과 함께 배포되어야 합니다. 그러한 프로젝트들은 수백, 아니 수천 개의 파일과 다른 프로그램과 함께 배송되어 기계에 배포되는 것이 일반적입니다. 각각은 충돌, 취약성 또는 라이센싱 책임에 대한 새로운 기회를 만듭니다.

 

이 모든 문제는 주의 깊은 회계, 자원 관리, 물류를 통해 해결될 수 있지만, 그것들은 다루기에 지루하고 불쾌한 일들입니다. 설치, 업그레이드, 또는 배포하려는 소프트웨어를 사용하는 데 시간을 더 잘 사용할 수 있을 것입니다. Docker를 만든 사람들은 그 점을 인식했고, 그들의 노력 덕분에, 거의 아무런 노력 없이도 문제의 해결책을 순식간에 훑어볼 수 있습니다.

오늘날 대부분의 이 문제들이 수용 가능해 보일 수 있습니다. 아마도 그것들이 당신에게 사소해 보이는 것은 그것들에 익숙해져 있기 때문일 것입니다. Docker가 이러한 문제들을 접근 가능하게 만드는 방법을 읽은 후, 당신의 의견이 변화하는 것을 느낄 수 있을 것입니다.

 

1.2.1 조직화하기

Docker 없이는 컴퓨터가 잡동사니 서랍처럼 보일 수 있습니다. 애플리케이션들은 온갖 종류의 의존성을 가집니다. 일부 애플리케이션들은 사운드, 네트워킹, 그래픽 등과 같은 일반적인 기능을 위해 특정 시스템 라이브러리에 의존합니다. 다른 애플리케이션들은 그들이 작성된 언어의 표준 라이브러리에 의존합니다. 일부는 자바 프로그램이 자바 가상 머신에 의존하는 방식이나, 웹 애플리케이션이 데이터베이스에 의존하는 방식과 같이 다른 애플리케이션에 의존합니다. 실행 중인 프로그램이 네트워크 연결이나 파일과 같은 희귀 자원에 대한 독점적 접근을 요구하는 것은 일반적입니다.

오늘날, Docker 없이는 애플리케이션들이 파일 시스템 전체에 퍼져 있어 복잡한 상호작용의 무질서한 웹을 만들어냅니다. 그림 1.5는 Docker 없이 예시 애플리케이션이 예시 라이브러리에 어떻게 의존하는지를 보여줍니다.

그림 1.5 Dependency relationships of example programs

 

반대로, 1.1.1 섹션의 예시에서는 필요한 소프트웨어를 자동으로 설치했고, 동일한 소프트웨어를 단일 명령으로 신뢰할 수 있게 제거할 수 있습니다. Docker는 모든 것을 컨테이너와 이미지로 격리함으로써 조직적으로 유지합니다.

그림 1.6은 이러한 동일한 애플리케이션들과 그들의 의존성이 컨테이너 내부에서 실행되는 모습을 보여줍니다. 연결이 끊어지고 각 애플리케이션이 깔끔하게 포함되어 있어 시스템을 이해하는 것이 접근 가능한 작업이 됩니다. 처음에는 이것이 gcc와 같은 공통 의존성의 중복 복사본을 생성함으로써 저장 공간 오버헤드를 도입하는 것처럼 보일 수 있습니다. 3장에서는 Docker 패키징 시스템이 일반적으로 저장 공간 오버헤드를 줄이는 방법을 설명합니다.

 

그림 1.6 의존성의 복사본을 가진 컨테이너 내에서 실행되는 예시 프로그램들

 

1.2.2 이식성 향상

소프트웨어 문제 중 하나는 애플리케이션의 의존성이 일반적으로 특정 운영 체제를 포함한다는 것입니다. 운영 체제 간의 이식성은 소프트웨어 사용자들에게 주요한 문제입니다. Linux 소프트웨어와 macOS 간의 호환성은 가능할 수 있지만, 그러한 소프트웨어를 Windows에서 사용하는 것은 더 어려울 수 있습니다. 이는 전체 소프트웨어의 이식된 버전을 구축하는 것을 필요로 할 수 있습니다. 심지어 이것은 Windows에 적합한 대체 의존성이 존재하는 경우에만 가능합니다. 이는 애플리케이션의 유지 관리자들에게 큰 노력을 의미하며, 종종 생략됩니다. 사용자들에게 불행하게도, 막대한 양의 강력한 소프트웨어가 그들의 시스템에서 사용하기에 너무 어렵거나 불가능합니다.

현재 Docker는 Linux에서 네이티브로 실행되며 macOS와 Windows 환경을 위한 단일 가상 머신을 제공합니다. Linux로의 이러한 집중은 Docker 컨테이너 내에서 실행되는 소프트웨어가 일관된 의존성 집합에 대해 단 한 번만 작성될 필요가 있음을 의미합니다. 여러분은 방금 "잠깐만요. Docker가 가상 머신보다 낫다고 말씀하셨잖아요."라고 생각했을 수 있습니다. 그것은 맞지만, 가상 머신과 Docker는 보완적인 기술입니다. 단일 프로그램을 포함하기 위해 가상 머신을 사용하는 것은 낭비입니다. 특히 여러 가상 머신을 동일한 컴퓨터에서 실행할 때 더욱 그렇습니다. macOS와 Windows에서 Docker는 모든 컨테이너를 실행하기 위해 단일, 작은 가상 머신을 사용합니다. 이 접근 방식을 취함으로써, 가상 머신을 실행하는 오버헤드는 고정되어 있지만, 컨테이너의 수는 확장될 수 있습니다.

이 새로운 이식성은 사용자에게 몇 가지 방법으로 도움을 줍니다. 첫째, 이전에 접근할 수 없었던 전체 소프트웨어 세계를 열어줍니다. 둘째, 이제 동일한 소프트웨어—정확히 동일한 소프트웨어—를 어떤 시스템에서든 실행할 수 있게 되었습니다. 이는 여러분의 데스크톱, 개발 환경, 회사의 서버, 회사의 클라우드가 모두 동일한 프로그램을 실행할 수 있음을 의미합니다. 일관된 환경을 실행하는 것은 중요합니다. 이는 새로운 기술을 채택하는 데 따른 학습 곡선을 최소화하는 데 도움이 됩니다. 소프트웨어 개발자들이 자신의 프로그램을 실행할 시스템을 더 잘 이해할 수 있게 도와줍니다. 예상치 못한 일이 줄어듭니다. 셋째, 소프트웨어 유지 관리자가 단일 플랫폼과 하나의 의존성 세트를 위해 프로그램을 작성하는 데 집중할 수 있게 되면, 그것은 그들에게 엄청난 시간 절약이며 그들의 고객에게 큰 승리입니다.

Docker나 가상 머신 없이는, 흔히 개별 프로그램 수준에서 공통 도구를 기반으로 하는 소프트웨어에 의해 이식성이 달성됩니다. 예를 들어, Java는 프로그래머들이 여러 운영 체제에서 대체로 작동하는 단일 프로그램을 작성할 수 있게 해주는데, 이는 프로그램이 자바 가상 머신(JVM)이라는 프로그램에 의존하기 때문입니다. 이는 소프트웨어를 작성하는 동안 적절한 접근 방식이지만, 우리가 사용하는 대부분의 소프트웨어는 다른 회사의 다른 사람들에 의해 작성되었습니다. 예를 들어, Java나 비슷하게 이식 가능한 언어로 작성되지 않은 인기 있는 웹 서버를 사용하고 싶다면, 저자들이 우리를 위해 그것을 다시 작성하는 데 시간을 할애할 것이라고 생각하기 어렵습니다. 이 단점 외에도, 언어 인터프리터와 소프트웨어 라이브러리는 의존성 문제를 만드는 바로 그 요소들입니다. Docker는 작성된 언어, 설계된 운영 체제, 또는 실행 중인 환경의 상태에 관계없이 모든 프로그램의 이식성을 향상시킵니다.

 

1.2.3 컴퓨터 보호

지금까지 언급한 대부분은 소프트웨어를 다루는 관점에서의 문제들과 컨테이너 외부에서 이를 다루는 이점에 대한 것이었습니다. 하지만 컨테이너는 컨테이너 내부에서 실행되는 소프트웨어로부터 우리를 보호하기도 합니다. 프로그램이 잘못 동작하거나 보안 위험을 제시하는 다양한 방법이 있습니다:

• 프로그램이 공격자에 의해 특별히 작성될 수 있습니다.
• 선의의 개발자가 해로운 버그를 가진 프로그램을 작성할 수 있습니다.
  
• 프로그램이 입력 처리의 버그를 통해 공격자의 지시를 실수로 수행할 수 있습니다.
  

어떤 방식으로든, 소프트웨어를 실행하는 것은 컴퓨터의 보안을 위험에 빠뜨립니다. 소프트웨어를 실행하는 것이 컴퓨터를 가진 전체 목적이기 때문에, 실질적인 위험 완화를 적용하는 것이 현명합니다.

물리적인 감옥처럼, 컨테이너 내부의 것은 또한 내부의 것들에만 접근할 수 있습니다. 이 규칙에는 예외가 있지만, 사용자에 의해 명시적으로 생성된 경우에만 해당합니다. 컨테이너는 프로그램이 다른 실행 중인 프로그램, 접근할 수 있는 데이터 및 시스템 자원에 미칠 수 있는 영향 범위를 제한합니다. 그림 1.7은 컨테이너 바깥과 안에서 소프트웨어를 실행하는 것의 차이를 보여줍니다.

이것이 당신이나 당신의 비즈니스에 의미하는 바는 특정 애플리케이션을 실행하는 것과 관련된 모든 보안 위협의 범위가 애플리케이션 자체의 범위로 제한된다는 것입니다. 강력한 애플리케이션 컨테이너를 만드는 것은 복잡하며 어떤 심층 방어 전략의 중요한 구성요소입니다. 이는 너무 흔하게 생략되거나 미온적인 방식으로 구현됩니다.

 

그림 1.7 왼쪽: 민감한 자원에 직접 접근하는 악성 프로그램. 오른쪽: 컨테이너 내부의 악성 프로그램.

 

1.3 Docker가 중요한 이유는?

Docker는 추상화를 제공합니다. 추상화를 통해 복잡한 것들을 단순화된 용어로 다룰 수 있습니다. 따라서 Docker의 경우, 애플리케이션 설치와 관련된 모든 복잡성과 특수성에 초점을 맞추는 대신, 우리가 설치하고 싶은 소프트웨어가 무엇인지만 고려하면 됩니다.

배에 화물 컨테이너를 싣는 크레인처럼, Docker로 어떤 소프트웨어든 설치하는 과정은 다른 것과 동일합니다. 화물 컨테이너 안의 물건의 모양이나 크기는 달라질 수 있지만, 크레인이 컨테이너를 드는 방식은 항상 같습니다. 모든 도구는 어떤 화물 컨테이너에도 재사용 가능합니다.

이는 애플리케이션 제거에도 마찬가지입니다. 소프트웨어를 제거하고 싶을 때, 단순히 Docker에게 어떤 소프트웨어를 제거할지 알려주면 됩니다. 모든 것이 Docker에 의해 포함되고 계산되었기 때문에 남아있는 잔여물은 없을 것입니다. 컴퓨터는 소프트웨어를 설치하기 전처럼 깨끗할 것입니다.

컨테이너 추상화와 Docker가 컨테이너 작업을 위해 제공하는 도구는 시스템 관리와 소프트웨어 개발 풍경을 변화시켰습니다. Docker는 컨테이너를 모두에게 사용할 수 있게 만들기 때문에 중요합니다. 이를 사용하면 시간, 돈, 에너지를 절약할 수 있습니다.

Docker가 중요한 두 번째 이유는 소프트웨어 커뮤니티에서 컨테이너와 Docker를 채택하려는 중대한 움직임이 있기 때문입니다. 이 움직임은 아마존, 마이크로소프트, 구글과 같은 회사들이 모두 그 개발에 기여하고 자신들의 클라우드 제안에 채택하기 위해 함께 작업할 정도로 강력합니다. 이러한 경쟁 회사들이 자체 솔루션을 개발하고 출시하는 대신 오픈 소스 프로젝트를 지원하기 위해 함께 모인 것입니다.

Docker가 중요한 세 번째 이유는 컴퓨터에 대해 앱 스토어가 모바일 장치에 했던 것을 달성했기 때문입니다. 소프트웨어 설치, 분할, 제거를 간단하게 만들었습니다. 더 나아가, Docker는 이를 크로스 플랫폼 및 오픈 방식으로 수행합니다. 모든 주요 스마트폰이 같은 앱 스토어를 공유한다고 상상해 보십시오. 그것은 꽤 큰 일일 것입니다. 이 기술이 자리 잡음으로써, 운영 체제 간의 경계가 마침내 흐려지기 시작하고, 제3자 제공 업체의 영향이 운영 체제 선택에 덜 중요해질 수 있습니다.

넷째, 우리는 드디어 운영 체제의 보다 고급 격리 기능의 더 나은 채택을 보기 시작했습니다. 이는 사소해 보일 수 있지만, 많은 사람들이 운영 체제 수준에서 격리를 통해 컴퓨터의 보안을 강화하려고 노력하고 있습니다. 그들의 노력이 대규모 채택을 보기까지 오랜 시간이 걸린 것은 안타까운 일입니다. 컨테이너는 수십 년 동안 한 형태나 다른 형태로 존재해 왔습니다. Docker가 이러한 기능을 복잡성 없이 활용할 수 있게 해주는 것은 대단한 일입니다.

 

1.4 Docker를 언제 어디서 사용해야 할까요?

Docker는 집이나 직장에서 대부분의 컴퓨터에서 사용할 수 있습니다. 실제로, 이를 얼마나 멀리 가져가야 할까요?

Docker는 거의 어디서나 실행될 수 있지만, 그렇다고 해서 모든 곳에서 실행하고 싶다는 의미는 아닙니다. 예를 들어, 현재 Docker는 리눅스 운영 체제에서 실행될 수 있는 애플리케이션, 또는 Windows Server에서 Windows 애플리케이션만 실행할 수 있습니다. 만약 당신이 데스크탑에서 macOS 또는 Windows 네이티브 애플리케이션을 실행하고 싶다면, 아직 Docker로는 할 수 없습니다.

리눅스 서버나 데스크탑에서 일반적으로 실행되는 소프트웨어로 대화를 좁혀서, 거의 모든 애플리케이션을 컨테이너 안에서 실행하는 것에 대해 탄탄한 근거를 제시할 수 있습니다. 이에는 웹 서버, 메일 서버, 데이터베이스, 프록시 등의 서버 애플리케이션뿐만 아니라, 웹 브라우저, 워드 프로세서, 이메일 클라이언트 또는 다른 도구와 같은 데스크탑 소프트웨어도 포함됩니다. 심지어 신뢰할 수 있는 프로그램도 사용자가 제공한 데이터나 네트워크 데이터와 상호작용할 경우 인터넷에서 다운로드한 프로그램만큼 위험합니다. 이러한 것들을 컨테이너 내에서, 그리고 권한이 줄어든 사용자로 실행하면 시스템을 공격으로부터 보호하는 데 도움이 될 것입니다.

심층적인 방어의 추가 이점을 넘어, Docker를 일상적인 작업에 사용하는 것은 컴퓨터를 깨끗하게 유지하는 데 도움이 됩니다. 깨끗한 컴퓨터를 유지하는 것은 공유 자원 문제에 부딪히는 것을 방지하고 소프트웨어 설치 및 제거를 용이하게 합니다. 같은 설치, 제거, 배포의 용이성은 컴퓨터 집단의 관리를 단순화하고 회사들이 유지 관리에 대해 생각하는 방식을 근본적으로 바꿀 수 있습니다.

가장 중요한 것은 때때로 컨테이너가 부적절할 수 있다는 것을 기억하는 것입니다. 기계에 대한 전체 접근 권한을 가지고 실행해야 하는 프로그램의 보안에 컨테이너가 큰 도움이 되지 않을 수 있습니다. 이 글을 쓰는 시점에서, 그렇게 하는 것은 가능하지만 복잡합니다. 컨테이너는 보안 문제에 대한 전체적인 해결책이 아니지만, 많은 유형의 공격을 방지하는 데 사용될 수 있습니다. 신뢰할 수 없는 소스에서 소프트웨어를 사용해서는 안 됩니다. 이는 특히 해당 소프트웨어가 관리자 권한을 요구하는 경우 더욱 그렇습니다. 고객이 제공한 컨테이너를 공동된 환경에서 무분별하게 실행하는 것은 나쁜 아이디어입니다.

 

 

1.5 더 큰 생태계에서의 Docker

오늘날 더 큰 컨테이너 생태계는 새로운 또는 더 높은 수준의 문제를 해결하는 도구들로 풍부합니다. 그러한 문제들에는 컨테이너 오케스트레이션, 고가용성 클러스터링, 마이크로서비스 생명주기 관리, 그리고 가시성이 포함됩니다. 키워드 연관성에 의존하지 않고 그 시장을 탐색하는 것은 까다로울 수 있습니다. Docker와 그 제품들이 어떻게 함께 작동하는지 이해하는 것은 더욱 까다롭습니다.

그러한 제품들은 플러그인 형태로 Docker와 함께 작동하거나 특정 더 높은 수준의 기능을 제공하고 Docker에 의존합니다. 일부 도구들은 Docker의 하위 구성 요소를 사용합니다. 이 하위 구성 요소들은 runc, libcontainerd, notary와 같은 독립적인 프로젝트입니다.

Kubernetes는 Docker 자체를 제외하고 생태계에서 가장 주목할만한 프로젝트입니다. Kubernetes는 클러스터 환경에서 컨테이너로 서비스를 오케스트레이션하기 위한 확장 가능한 플랫폼을 제공합니다. 그것은 일종의 "데이터센터 운영 체제"로 성장하고 있습니다. 리눅스 커널처럼, 클라우드 제공자와 플랫폼 회사들은 Kubernetes를 패키징하고 있습니다. Kubernetes는 Docker와 같은 컨테이너 엔진에 의존하기 때문에, 노트북에서 빌드한 컨테이너와 이미지는 Kubernetes에서 실행될 것입니다.

도구를 선택할 때 여러 가지 상충되는 점들을 고려해야 합니다. Kubernetes는 그 확장성에서 힘을 얻지만, 그것은 학습 곡선과 지속적인 지원 노력의 대가로 옵니다. 오늘날 Kubernetes 클러스터를 구축, 사용자 정의 또는 확장하는 것은 전일제 직업입니다. 하지만 기존의 Kubernetes 클러스터를 사용하여 애플리케이션을 배포하는 것은 최소한의 연구로 직관적입니다. Kubernetes를 살펴보는 대부분의 독자들은 자신만의 것을 구축하기 전에 주요 공공 클라우드 제공업체에서 관리하는 서비스를 채택하는 것을 고려해야 합니다. 이 책은 Docker만을 사용하여 더 높은 수준의 문제에 대한 해결책을 중점적으로 다루고 가르칩니다. 문제가 무엇인지, 그리고 하나의 도구로 어떻게 해결할 수 있는지 이해하면, 더 복잡한 도구를 선택하는 데 있어 더 성공할 가능성이 높습니다.

 

 

1.6 Docker 명령줄 도움말 받기

이 책의 나머지 부분에서 docker 명령줄 프로그램을 사용할 것입니다. 시작하기 위해, docker 프로그램 자체에서 명령어에 대한 정보를 얻는 방법을 보여드리고자 합니다. 이를 통해, 컴퓨터에 설치된 Docker의 정확한 버전을 어떻게 사용하는지 이해할 수 있을 것입니다. 터미널이나 명령 프롬프트를 열고 다음 명령어를 실행하세요:

docker help

docker help를 실행하면 docker 명령줄 프로그램을 사용하기 위한 기본 문법과 프로그램 버전의 전체 명령어 리스트에 대한 정보가 표시됩니다. 한번 시도해보고 당신이 할 수 있는 모든 멋진 것들을 감상해 보세요.

docker help는 사용할 수 있는 명령어에 대한 고급 정보만 제공합니다. 특정 명령어에 대한 자세한 정보를 얻으려면, 명령어를 <COMMAND> 인수에 포함시키세요. 예를 들어, 컨테이너 내부의 위치에서 호스트 기계의 위치로 파일을 복사하는 방법을 알아보려면 다음 명령어를 입력할 수 있습니다:

docker help cp

이 명령어는 docker cp의 사용 패턴, 명령어가 수행하는 일의 일반적인 설명, 그리고 그 인수의 자세한 분석을 표시할 것입니다. 도움이 필요할 때 어떻게 찾아야 하는지 이제 알게 되었으니, 이 책의 나머지 부분에서 소개된 명령어를 다루는 것이 즐거울 것이라고 확신합니다.

요약
이 장은 Docker와 시스템 관리자, 개발자, 그리고 다른 소프트웨어 사용자가 해결하는 문제에 대한 간략한 소개였습니다. 이 장에서 배운 내용은 다음과 같습니다:

• Docker는 공통 소프트웨어 문제를 해결하기 위한 물류적(logistical) 접근을 취하며, 소프트웨어를 설치, 실행, 출판, 제거하는 경험을 단순화합니다. 이는 명령줄 프로그램, 엔진 백그라운드 프로세스, 그리고 원격 서비스 세트입니다. Docker Inc.가 제공하는 커뮤니티 도구와 통합되어 있습니다.
• 컨테이너 추상화는 그 물류적 접근의 핵심입니다.
  
• 소프트웨어 대신 컨테이너를 다루면 일관된 인터페이스를 생성하고 더 정교한 도구 개발을 가능하게 합니다.
  
• 컨테이너는 컨테이너 외부의 것과 상호작용할 수 없고 공유 의존성이 형성될 수 없기 때문에 컴퓨터를 깔끔하게 유지하는 데 도움이 됩니다.
  
• Docker가 Linux, macOS, Windows에서 사용 가능하고 지원되므로, Docker 이미지에 패키징된 대부분의 소프트웨어는 어떤 컴퓨터에서든 사용할 수 있습니다.
  
• Docker는 컨테이너 기술을 제공하지 않지만, 컨테이너 소프트웨어와 직접 작업하는 복잡성을 숨기고 최선의 관행을 합리적인 기본 설정으로 전환합니다.
  
• Docker는 더 큰 컨테이너 생태계와 함께 작동합니다; 그 생태계는 새롭고 더 높은 수준의 문제를 해결하는 풍부한 도구들로 가득 차 있습니다.
  
• 명령어에 도움이 필요할 때는 항상 docker help 하위 명령어를 참조할 수 있습니다.