도커: 두 판 사이의 차이

큰숲백과, 나무를 보지 말고 큰 숲을 보라.
시각위키텍스트
(→‎기타: 재미있는 사실 하나)
잔글 (→‎기타)
221번째 줄: 221번째 줄:
== 기타 ==
== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
* Docker Engine과 안드로이드를 비롯한 많은 임베디드 리눅스 개발 환경이 chroot를 비롯하여 많은 도구들을 공유하기 때문에, '이론상으로는' AMD64 기반 혹은 ARM64 기반 고성능 임베디드 시스템을 커스텀 도커 이미지로 만들고 도커 허브에 올린 다음, 이미지만 받아서 바로 그걸 [[Secure Digital|microSD카드]] 같은 플래시 메모리 장치의 부트 로더 파티션 뒤에 리눅스 dd 명령어 등으로 그대로 박아 넣어 부팅하는 짓이 가능하긴 하다. 문제는 AMD64 임베디드 시스템이라면 모를까, ARM64의 경우 개발 환경 및 타겟 장치 구성이 너무 심하게 파편화되어 ARM64 이미지를 커스텀하기 힘들고, RISC-V나 구형 32bit ARM CPU 및 기타 임베디드 시스템용 CPU/MCU를 도커 측에서 지원하지 않아 저걸 실현 가능한 경우의 수가 매우 한정적이라는 것. 도커로 임베디드 시스템 개발 작업까지 커버하기엔 멀어도 한참 멀었다.
* Docker Engine과 안드로이드를 비롯한 많은 임베디드 리눅스 개발 환경이 chroot를 비롯하여 많은 도구들을 공유하기 때문에, '이론상으로는' AMD64 기반 혹은 ARM64 기반 고성능 임베디드 시스템을 커스텀 도커 이미지로 만들고 도커 허브에 올린 다음, 이미지만 받아서 바로 그걸 [[Secure Digital|microSD카드]] 같은 플래시 메모리 장치의 부트 로더 파티션 뒤에 리눅스 dd 명령어 등으로 그대로 박아 넣어 부팅하는 짓이 가능하긴 하다. 문제는 AMD64 임베디드 시스템이라면 모를까, ARM64의 경우 개발 환경 및 타겟 장치 구성이 너무 심하게 파편화되어 ARM64 이미지를 커스텀하기 힘들고, RISC-V나 구형 32bit ARM CPU 및 기타 임베디드 시스템용 CPU/MCU를 도커 측에서 지원하지 않아 저걸 실현 가능한 경우의 수가 매우 한정적이라는 것. 아무리 도커 같은 리눅스 컨테이너 엔진이라도 임베디드 시스템 개발 작업까지 커버하기엔 멀어도 한참 멀었다.


== 같이 보기 ==
== 같이 보기 ==

2025년 6월 7일 (토) 23:39 판

도커
Docker
원작자 솔로몬 하익스 (Solomon Hykes)
프로그래밍 언어 Go[1]
운영 체제 리눅스, 윈도우, macOS
플랫폼 현대의 리눅스 커널이 포함된 x86-64, ARM (실험적), 하이퍼-V 기능이 포함된 x86-64 윈도우
종류 운영 체제 수준 가상화
라이선스 아파치 라이선스 2.0
웹사이트 www.docker.com

도커(Docker)는 리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:

도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.[2]

도커는 리눅스에서 운영 체제 수준 가상화의 추상화 및 자동화 계층을 추가적으로 제공한다.[3] 도커는 cgroups와 커널 이름공간과 같은 리눅스 커널의 기능들과 OverayFS, aufs와 같은 유니언 가능 파일 시스템의 리소스 격리 기능을 사용하며,[4] 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 가상 머신을 시작하여 유지보수해야 하는 부담을 없애준다.[5]

리눅스 커널의 이름공간 지원은 대체적으로[6] 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 libvirt, LXC (리눅스 컨테이너), systemd-nspawn을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer 라이브러리를 포함하고 있다.[7][8][9]

개요

도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.[9]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 사내, 공용 클라우드, 개인 클라우드, 베어 메탈 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.[10]

도커는 고급 API를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.[11]

리눅스 커널이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.[10] 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 격리된 이름공간을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 libvirt, LXC (리눅스 컨테이너), 또는 systemd-nspawn을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.[9][12]

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 분산 시스템을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 Apache Cassandra, 몽고DB, Riak와 같은 시스템을 위한 PaaS 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.[13][14]

통합

도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

클라우드 파운드리 Diego 프로젝트는 도커를 클라우드 파운드리 PaaS에 통합한다.[33]

레드햇의 오픈시프트 PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.[34]

Apprenda PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.[35]

역사

솔로몬 하익스는 프랑스에서 PaaS 기업인 닷클라우드 안에 내부 프로젝트로서 도커를 시작했다.[36]

도커는 2013년 3월 오픈 소스로 출시되었다.[11]

사용법

CLI를 통한 이용

GUI를 통한 이용

도커 데스크탑

도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

IDE/텍스트 편집기를 통한 이용

비주얼 스튜디오 코드에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. docker exec -it <container> bash 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

portainer 사용

도구

Docker Compose

Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.[37] YAML 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

Docker Swarm

Docker Swarm은 도커 컨테이너의 네이티브 클러스터링 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.[38]

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.[39]

비슷한 소프트웨어로는 kubernetes(쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

기타

  • 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 젠킨스 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
  • Docker Engine과 안드로이드를 비롯한 많은 임베디드 리눅스 개발 환경이 chroot를 비롯하여 많은 도구들을 공유하기 때문에, '이론상으로는' AMD64 기반 혹은 ARM64 기반 고성능 임베디드 시스템을 커스텀 도커 이미지로 만들고 도커 허브에 올린 다음, 이미지만 받아서 바로 그걸 microSD카드 같은 플래시 메모리 장치의 부트 로더 파티션 뒤에 리눅스 dd 명령어 등으로 그대로 박아 넣어 부팅하는 짓이 가능하긴 하다. 문제는 AMD64 임베디드 시스템이라면 모를까, ARM64의 경우 개발 환경 및 타겟 장치 구성이 너무 심하게 파편화되어 ARM64 이미지를 커스텀하기 힘들고, RISC-V나 구형 32bit ARM CPU 및 기타 임베디드 시스템용 CPU/MCU를 도커 측에서 지원하지 않아 저걸 실현 가능한 경우의 수가 매우 한정적이라는 것. 아무리 도커 같은 리눅스 컨테이너 엔진이라도 임베디드 시스템 개발 작업까지 커버하기엔 멀어도 한참 멀었다.

같이 보기

외부 링크

각주

  1. ↑ “Docker source code”. 《docs.docker.com》. Docker, Inc. 2015년 10월 12일. 2015년 10월 24일에 확인함. 
  2. ↑ https://www.docker.com/what-docker
  3. ↑ O'Gara, Maureen (2013년 7월 26일). “Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud”. SYS-CON Media. 2019년 9월 13일에 원본 문서에서 보존된 문서. 2013년 8월 9일에 확인함. 
  4. ↑ “docker/docker”. 《GitHub》. 2015년 12월 29일에 확인함. 
  5. ↑ “Docker Documentation: Kernel Requirements”. 《docker.readthedocs.org》. 2014년 1월 4일. 2014년 8월 21일에 원본 문서에서 보존된 문서. 2014년 8월 20일에 확인함. 
  6. ↑ Dan Walsh. “Yet Another Reason Containers Don't Contain: Kernel Keyrings”. 《projectatomic.io》. 2015년 4월 13일에 원본 문서에서 보존된 문서. 2015년 4월 13일에 확인함. 
  7. ↑ Steven J. Vaughan-Nichols (2014년 6월 11일). “Docker libcontainer unifies Linux container powers”. ZDNet. 2014년 7월 30일에 확인함. 
  8. ↑ “libcontainer - reference implementation for containers”. 《github.com》. 2014년 7월 30일에 확인함. 
  9. ↑ 9.0 9.1 9.2 “Docker 0.9: Introducing execution drivers and libcontainer”. 《docker.com》. 2014년 3월 10일. 2015년 2월 21일에 원본 문서에서 보존된 문서. 2015년 1월 20일에 확인함. 
  10. ↑ 10.0 10.1 Noyes, Katherine (2013년 8월 1일). “Docker: A 'Shipping Container' for Linux Code”. Linux.com. 2013년 8월 8일에 원본 문서에서 보존된 문서. 2013년 8월 9일에 확인함. 
  11. ↑ 11.0 11.1 Avram, Abel (2013년 3월 27일). “Docker: Automated and Consistent Software Deployments”. InfoQ. 2013년 8월 9일에 확인함. 
  12. ↑ Swan, Chris (2014년 3월 13일). “Docker drops LXC as default execution environment”. InfoQ. 2015년 1월 20일에 확인함. 
  13. ↑ Hall, Adron (2013년 7월 31일). “OSCON : Conversations, Deployments, Architecture, Docker and the Future?”. CloudAve. 2019년 3월 27일에 원본 문서에서 보존된 문서. 2013년 8월 9일에 확인함. 
  14. ↑ Reeder, Travis (2014년 4월 22일). “How Docker Helped Us Achieve the (Near) Impossible”. Iron.io. 2014년 8월 8일에 원본 문서에서 보존된 문서. 2014년 7월 25일에 확인함. 
  15. ↑ “Amazon EC2 - Docker Documentation”. 《docs.docker.com》. 2014년 10월 18일에 원본 문서에서 보존된 문서. 2014년 10월 18일에 확인함. 
  16. ↑ /. “ansible/library/cloud/docker”. GitHub. 2013년 12월 27일에 원본 문서에서 보존된 문서. 2014년 1월 20일에 확인함. 
  17. ↑ “CFEngine”. CFEngine. 2014년 6월 13일에 원본 문서에서 보존된 문서. 2014년 6월 6일에 확인함. 
  18. ↑ “thoward/docker-cookbook”. GitHub. 2014년 1월 20일에 확인함. 
  19. ↑ “Containers on Google Cloud Platform”. Google Inc. 
  20. ↑ “Bluemix Launches IBM Containers Beta Based on Docker”. IBM. 2014년 12월 4일. 2015년 4월 28일에 원본 문서에서 보존된 문서. 2015년 4월 20일에 확인함. 
  21. ↑ “Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery”. PRWeb. 2014년 12월 3일에 확인함. 
  22. ↑ “georgebashi/jenkins-docker-plugin”. GitHub. 2017년 1월 9일에 확인함. 
  23. ↑ Surana, Ramit (2015년 9월 16일). “Containerizing Docker on Kubernetes”. 《LinkedIn》. 2015년 11월 2일에 확인함. 
  24. ↑ “The Docker Virtual Machine Extension for Linux on Azure”. Microsoft. 2015년 6월 29일. 2016년 3월 17일에 원본 문서에서 보존된 문서. 2015년 8월 11일에 확인함. 
  25. ↑ Stefano Maffulli (2013년 6월 7일). “OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog”. Openstack.org. 2013년 12월 29일에 원본 문서에서 보존된 문서. 2014년 1월 20일에 확인함. 
  26. ↑ “OpenSVC Docker”. OpenSVC. 2014년 5월 31일에 원본 문서에서 보존된 문서. 2014년 5월 29일에 확인함. 
  27. ↑ Native, Cloud. “Oracle Container Cloud Service Explained By Oracle.com”. 
  28. ↑ Gareth Rushgrove. “garethr/docker”. Puppet Forge. 2014년 1월 20일에 확인함. 
  29. ↑ “saltstack/dockerio”. 2014년 2월 3일에 원본 문서에서 보존된 문서. 2014년 1월 20일에 확인함. 
  30. ↑ “philspitler/vagrant-docker”. GitHub. 2013년 8월 9일에 원본 문서에서 보존된 문서. 2014년 1월 20일에 확인함. 
  31. ↑ http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)
  32. ↑ http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers
  33. ↑ Whelan, Phil (2014년 9월 3일). “Cloud Foundry: Diego Explained By Onsi Fakhouri”. ActiveState. 2015년 4월 20일에 확인함. Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego. 
  34. ↑ Jackson, Joab (2014년 4월 16일). “Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker”. Computerworld, Inc. 2014년 5월 29일에 확인함. Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin. 
  35. ↑ Verge, Jason (2015년 4월 28일). “PaaS and Docker Containers Work Together in Latest Apprenda Release”. Data Center Knowledge. 2015년 12월 6일에 확인함. The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS. 
  36. ↑ “One home for all your apps”. 《dotcloud.com》. 2014년 5월 17일에 원본 문서에서 보존된 문서. 2014년 5월 8일에 확인함. 
  37. ↑ “Overview of Docker Compose”. 2017년 7월 6일에 확인함. 
  38. ↑ “8 Container Orchestration Tools to Know”. 2017년 4월 12일. 2017년 7월 6일에 확인함. 
  39. ↑ “Docker Swarm”. 2017년 7월 6일에 확인함. 
이 문서의 출처는 위키백과의 도커 문서입니다.
원본 주소 "https://bigforest.a2hosted.com/w/index.php?title=도커&oldid=89370"