"도커 (소프트웨어)"의 두 판 사이의 차이
leejia1222 (토론 | 기여) |
잔글 |
||
(사용자 3명의 중간 판 13개는 보이지 않습니다) | |||
15번째 줄: | 15번째 줄: | ||
* '''도커 레지스트리'''(Docker Registry) : 도커의 이미지 저장소이다. 도커 클라이언트는 레지스트리에 연결하여 사용하기 위해 이미지를 다운로드하거나 생성한 이미지를 업로드한다. 레지스트리는 공개계정과 비공개계정으로 나뉜다. 주요 공용 레지스트리는 도커 허브와 도커 클라우드가 있다. 도커 허브는 도커가 이미지를 찾는 기본 레지스트리이다.<ref> 도커(소프트웨어) 위키디피아 -https://en.wikipedia.org/wiki/Docker_(software)</ref> | * '''도커 레지스트리'''(Docker Registry) : 도커의 이미지 저장소이다. 도커 클라이언트는 레지스트리에 연결하여 사용하기 위해 이미지를 다운로드하거나 생성한 이미지를 업로드한다. 레지스트리는 공개계정과 비공개계정으로 나뉜다. 주요 공용 레지스트리는 도커 허브와 도커 클라우드가 있다. 도커 허브는 도커가 이미지를 찾는 기본 레지스트리이다.<ref> 도커(소프트웨어) 위키디피아 -https://en.wikipedia.org/wiki/Docker_(software)</ref> | ||
− | * '''도커 컴포즈'''(Docker Compose): 컴포즈의 사전적 의미는 | + | * '''도커 컴포즈'''(Docker Compose): 컴포즈의 사전적 의미는 ‘짓다’, ‘조립하다’이다. 도커 컴포즈는 여러 개의 컨테이너를 짓고 조립하는 데 유용하다. 여러 컨테이너에 대한 옵션을 docker-compose.yml이라는 명령어로 파일로 작성하면, docker-compose up이라는 한 번의 명령어로 서비스를 시작할 수 있다. 도커 컴포즈는 도커파일로 응용프로그램 환경을 정의한다. 프로그램을 구성하는 서비스를 도커-컴포즈.yml에 정의해서 한꺼번에 실행 가능하도록 한다.도커-컴포즈up 명령어로 컴포즈를 실행해 앱을 시작한다. 서비스에서는 실행하려는 컨테이너들을 정의하면 된다. 도커 컴포즈에서는 서비스 항목에 프로그램 구성에 필요한 컨테이너들을 여러 개 정의할 수 있다. 또한, 서비스 안에 각 컨테이너 항목에서는 도커 이미지를 실행할 때 쓰던 커맨드라인에 쓰던 여러 옵션(ex. ports)들을 적어둘 수 있다.<ref>Roseline Song, 〈[https://roseline124.github.io/kuberdocker/2019/07/24/docker-study06.html 도커 컴포즈(Docker Compose)]〉, 《깃허브 블로그》, 2019-07-14</ref> |
− | * '''도커 스웜'''(Docker Swarm): 도커가 공식적으로 만든 오케스트레이션(orchestraion) 툴 이다. 오케스트레이션 툴이란 여러 호스트 서버의 컨테이너들을 배포 및 관리를 위한 툴이다. 도커 스웜을 쉽게 말하면 [[쿠버네티스]](Kubernetes)를 대신할 도커에서 만든 컨테이너 관리를 위한 툴이다. 오케스트레이션 툴은 컨테이너 배포뿐만 아니라 다양한 기능을 포함한다. 컨테이너를 자동 배치하고 복제하며 컨테이너 그룹에 대한 [[부하]]를 분산시켜준다. 때문에 [[ | + | * '''도커 스웜'''(Docker Swarm): 도커가 공식적으로 만든 오케스트레이션(orchestraion) 툴 이다. 오케스트레이션 툴이란 여러 호스트 서버의 컨테이너들을 배포 및 관리를 위한 툴이다. 도커 스웜을 쉽게 말하면 [[쿠버네티스]](Kubernetes)를 대신할 도커에서 만든 컨테이너 관리를 위한 툴이다. 오케스트레이션 툴은 컨테이너 배포뿐만 아니라 다양한 기능을 포함한다. 컨테이너를 자동 배치하고 복제하며 컨테이너 그룹에 대한 [[부하]]를 분산시켜준다. 때문에 [[장애복구]]가 가능하다. 도커를 사용하는 컴퓨터 클러스터를 외부서비스 노출해주며 컨테이너 추가 또는 제거를 이용한 확장 및 축소가 가능하다. 컨테이너 서비스 간의 인터페이스를 통한 연결 및 네트워크 포트 노출을 제어한다. 도커 스윔은 여러 개의 도커 호스트를 함께 클러스터링하여 단일 가상 도커 호스트 생성하며 호스트 프로그램에 에이전트만 설치하면 간단하게 작동하고 설정이 쉽고 에이전트를 외부에 설치하지 않는다.<ref> Hong Log, 〈[https://honggg0801.tistory.com/22 Docker Swarm이란]〉, 《티스토리》, 2019-02-19</ref> |
===기능=== | ===기능=== | ||
58번째 줄: | 58번째 줄: | ||
* '''net_cls''' : 네트워크 제어 | * '''net_cls''' : 네트워크 제어 | ||
* '''blkio''' : 블록 디바이스 입출력량 제어<ref name="출처"></ref> | * '''blkio''' : 블록 디바이스 입출력량 제어<ref name="출처"></ref> | ||
+ | |||
+ | ===네트워크=== | ||
+ | 도커의 컨테이너는 서버의 물리 NIC와 별도로 각 컨테이너마다 가상 NIC가 할당되어 있다. 또한 이러한 가상 NIC는 도커0이라는 가상 브릿지에 접속하여 컨테이너끼리 통신한다. 도커0은 도커 데몬을 기동한 후에 생성되며, 172.17.42.1 주소가 할당된다. 도커에서 컨테이너를 구동하면 컨테이너에 172.17.0.0/16 subnet mask를 가진 프라이빗 IP 주소가 eth0에 자동으로 할당된다. eth0에는 호스트OS에 생성된 가상 NIC(vethxxx)가 페어로 할당된다. veth는 OSI 7계층 레이어 2의 가상 네트워크 인터페이스로서 페어된 NIC끼리 터널링 통신을 수행한다. 가상 NIC(vethxxx)는 컨테이너에서 eth0으로 인식된다. 도커 컨테이너는 이러한 네트워크 구성을 기본으로 다음과 같이 네트워크 통신을 수행한다. | ||
+ | |||
+ | ; 도커 컨테이너 간의 통신 | ||
+ | 동일한 호스트 상의 도커 컨테이너는 구동 시 프라이빗 주소가 자동으로 할당되므로 컨테이너끼리 통신하기 위하여 '링크 기능'을 사용한다. 컨테이너를 구동할 때, 통신하려는 컨테이너 이름을 지정하여 링크하면 해당 정보가 /etc/host에 환경변수로 저장되어 직접 통신할 수 있다. 단, 링크 기능을 사용한 통신은 동일 호스트, 즉 가상 브릿지 도커0에 접속한 컨테이너끼리만 가능하다. 멀티 호스트 환경에서는 링크 기능을 이용한 통신이 불가능하므로 주의해야 한다. 또한 보안 요구 사항에 따라 컨테이너 간 통신을 차단하도록 설정할 수 있다. | ||
+ | |||
+ | ; 도커 컨테이너와 외부 네트워크 통신 | ||
+ | 도커 컨테이너가 외부 네트워크와 통신할 때에는 가상 브릿지 도커0와 호스트OS의 물리 NIC에서 패킷을 전송해야 한다. 이 때, 도커에서는 NAPT 기능을 사용하여 접속한다. NAPT(Network Address Port Translation)란 하나의 IP 주소를 여러 컴퓨터에서 공유하는 기술로서 IP 주소와 포트 번호를 변환하는 기능이다. TCP 및 UDP 포트 번호까지 동적으로 변환하기 때문에 여러 머신에서 한 글로벌 IP 주소로 접속할 수 있다. 이 기능은 컨테이너를 구동할 때, 내부에서 사용하고 있는 포트를 가상 브릿지 도커0에서 개방할 때 사용된다. 예를 들어 컨테이너 구동 시, 컨테이너 내의 웹 서버(http 데몬)가 사용하는 80번 포트를 호스트OS의 8080번 포트로 전송하도록 설정하였을 때, 외부 네트워크에서 호스트OS의 8080번 포트에 액세스하면 컨테이너 내의 80번 포트로 연결되는 구조이다.<ref>miiingo, 〈[https://miiingo.tistory.com/88 (Docker) 완벽한 IT 인프라 구축을 위한 Docker: 제2장 컨테이너 가상화 기술과 Docker]〉, 《티스토리》, 2018-01-30</ref> | ||
===도커 파일=== | ===도커 파일=== | ||
72번째 줄: | 81번째 줄: | ||
[[파일:가상머신과 도커 비교.png|썸네일|500 픽셀|가상머신과 비교]] | [[파일:가상머신과 도커 비교.png|썸네일|500 픽셀|가상머신과 비교]] | ||
− | 도커는 | + | 도커는 [[가상머신]]에 비해 매우 가볍고 빠르다. 그 이유는 [[리눅스]]의 [[커널]]을 이용하기 때문이고, 하나의 [[서버]]나 [[가상머신]]이 여러 [[컨테이너]]들을 동시에 [[조작]]할 수 있기 때문이다. 대신에 도커는 [[파일]]의 상태를 정밀하게 알기는 어렵고 자유롭게 사용하기에는 제약이 많다. 하지만 실제 사용해보면 도커의 장점이 훨씬 부각 된다. 그 이유는 가볍고 빠른 것도 있지만 어느 [[환경]]이나 동일하게 [[작용]]하기 때문이다. 여기서 동일하게 동작한다는 건 완전 밑단까지 같이 동작한다는 이야기가 아니라 사용하는 입장에서 동등하게 사용할 수 있다는 뜻이다. 우측 그림에서도 나오듯이, 기존의 가상머신의 경우에는 [[호스트]] 운영체제 위에 새로운 게스트 운영체제를 설치를 했다. 그러다 보니 [[운영체제]] 위에 운영체제가 있는 모양이고 이는 필연적으로 [[속도]] 저하로 이어진다. 하지만 도커는 운영체제 위에 운영체제를 설치하는 것이 아니라 현재 운영체제에 없는 것만 추가적으로 받아온다. |
가령 현재 호스트 운영체제가 A인데 게스트 운영체제를 B로 사용한다고 가정한다. 가상머신은 A위에 B를 설치하게 된다. 근데 도커는 A에 없는 부분만, 즉 B와 A가 공유하는 부분은 빼고 나머지만 재 설치한다. 이게 가능한 이유는 맥과 리눅스는 모두 유닉스와 같은 운영체제이기 때문이다. 그래서 윈도우에서 사용하는 도커는 리눅스 자체를 가상머신 마냥 올리기 때문에 성능이 좋지 않다. 그렇다고 윈도우에서 의미가 없는 건 아니고 윈도우에서도 리눅스와 똑같은 환경으로 사용할 수 있다는 장점이 있다. 그래서 오히려 윈도우에서 코딩할수록 도커를 사용하는 것이 좋다. 하지만 도커를 사용한다는 의미는 단순히 테스팅을 한다는 의미가 아니다. 오히려 테스팅을 할 거면 가상머신이 훨씬 낫다. 도커는 배포를 위해서 사용하는 것이므로 테스트를 하기에 적합하지는 않다.<ref> 카망, 〈[https://kamang-it.tistory.com/entry/DockerDocker%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EB%8F%84%EC%BB%A4%EC%9D%98-%EA%B8%B0%EC%B4%88%EC%99%80-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%84%A4%EC%B9%98%ED%95%98%EA%B3%A0-%EC%82%AC%EC%9A%A91 (Docker)Docker는 무엇인가? 도커의 기초와 이미지 설치하고 사용(1)]〉, 《티스토리》, 2019-04-14</ref> | 가령 현재 호스트 운영체제가 A인데 게스트 운영체제를 B로 사용한다고 가정한다. 가상머신은 A위에 B를 설치하게 된다. 근데 도커는 A에 없는 부분만, 즉 B와 A가 공유하는 부분은 빼고 나머지만 재 설치한다. 이게 가능한 이유는 맥과 리눅스는 모두 유닉스와 같은 운영체제이기 때문이다. 그래서 윈도우에서 사용하는 도커는 리눅스 자체를 가상머신 마냥 올리기 때문에 성능이 좋지 않다. 그렇다고 윈도우에서 의미가 없는 건 아니고 윈도우에서도 리눅스와 똑같은 환경으로 사용할 수 있다는 장점이 있다. 그래서 오히려 윈도우에서 코딩할수록 도커를 사용하는 것이 좋다. 하지만 도커를 사용한다는 의미는 단순히 테스팅을 한다는 의미가 아니다. 오히려 테스팅을 할 거면 가상머신이 훨씬 낫다. 도커는 배포를 위해서 사용하는 것이므로 테스트를 하기에 적합하지는 않다.<ref> 카망, 〈[https://kamang-it.tistory.com/entry/DockerDocker%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EB%8F%84%EC%BB%A4%EC%9D%98-%EA%B8%B0%EC%B4%88%EC%99%80-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%84%A4%EC%B9%98%ED%95%98%EA%B3%A0-%EC%82%AC%EC%9A%A91 (Docker)Docker는 무엇인가? 도커의 기초와 이미지 설치하고 사용(1)]〉, 《티스토리》, 2019-04-14</ref> | ||
82번째 줄: | 91번째 줄: | ||
〈[http://www.itworld.co.kr/news/135282#csidx559b9938b74390bb2540ab8506e03e7 쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해]〉 , 《아이티 월드》, 2019-10-31</ref> | 〈[http://www.itworld.co.kr/news/135282#csidx559b9938b74390bb2540ab8506e03e7 쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해]〉 , 《아이티 월드》, 2019-10-31</ref> | ||
− | 쿠버네티스의 장점은 무중단(Fault tolerance-FT) 서비스를 제공하는 것이다. 때때로 기업의 서비스를 이용하는 사용자들은 개선을 위해 임시점검 중이라는 안내문을 보게 된다. 기업에서는 서버 업데이트를 위해서 사용자들이 잠든 새벽 시간을 활용하거나 긴급 점검의 형태로 서비스를 일시 중단해왔지만, 쿠버네티스는 점진적 업데이트를 제공하기 때문에 서비스를 중단하지 않고도 프로그램을 업데이트할 수 있다. 또한, 쿠버네티스는 자가 회복(Self Healing) 기능이 있기 때문에 특정 컨테이너에 갑작스러운 장애가 발생하더라도 곧바로 복제 컨테이너를 생성해서 서비스를 유지할 수 있다. 또 한 가지는, 다른 소프트웨어와 호환성이 가능하다. 만약 고객이 A사의 클라우드를 사용하다가 다른 회사의 클라우드로 환경을 이전하고 싶을 때, 서로 다른 업체의 클라우드 제품 간에 호환 문제가 발생하여 이전하기 어려운 상황을 벤더 락인(Vendor Lock In)이라고 한다. 쿠버네티스는 도커 컨테이너를 기반으로 하는 오픈소스이기 때문에 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경들을 이전할 수 있다.<ref> Jo Youngho , 〈[https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 컨테이너와 쿠버네티스를 쉽게 이해하기]〉, 《IBM Developer》, 2019-02-01</ref> | + | 쿠버네티스의 장점은 무중단(Fault tolerance-FT) 서비스를 제공하는 것이다. 때때로 기업의 서비스를 이용하는 사용자들은 개선을 위해 임시점검 중이라는 안내문을 보게 된다. 기업에서는 서버 업데이트를 위해서 사용자들이 잠든 새벽 시간을 활용하거나 긴급 점검의 형태로 서비스를 일시 중단해왔지만, 쿠버네티스는 점진적 업데이트를 제공하기 때문에 서비스를 중단하지 않고도 프로그램을 업데이트할 수 있다. 또한, 쿠버네티스는 자가 회복(Self Healing) 기능이 있기 때문에 특정 컨테이너에 갑작스러운 장애가 발생하더라도 곧바로 복제 컨테이너를 생성해서 서비스를 유지할 수 있다. 또 한 가지는, 다른 소프트웨어와 호환성이 가능하다. 만약 고객이 A사의 클라우드를 사용하다가 다른 회사의 클라우드로 환경을 이전하고 싶을 때, 서로 다른 업체의 클라우드 제품 간에 호환 문제가 발생하여 이전하기 어려운 상황을 벤더 락인(Vendor Lock In)이라고 한다. 쿠버네티스는 도커 컨테이너를 기반으로 하는 오픈소스이기 때문에 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경들을 이전할 수 있다.<ref>Jo Youngho, 〈[https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 컨테이너와 쿠버네티스를 쉽게 이해하기]〉, 《IBM Developer》, 2019-02-01</ref> |
==활용== | ==활용== | ||
128번째 줄: | 137번째 줄: | ||
* Daegwon Nacyot Kim, 〈[https://www.44bits.io/ko/post/easy-deploy-with-docker 도커(Docker) 입문편 컨테이너 기초부터 서버 배포까지]〉, 《44비츠》, 2020-03-22 | * Daegwon Nacyot Kim, 〈[https://www.44bits.io/ko/post/easy-deploy-with-docker 도커(Docker) 입문편 컨테이너 기초부터 서버 배포까지]〉, 《44비츠》, 2020-03-22 | ||
* raccoony, 〈[https://www.44bits.io/ko/post/why-should-i-use-docker-container#%EC%84%9C%EB%B2%84%EB%A5%BC-%EC%BD%94%EB%93%9C%EB%A1%9C%EA%B5%AC%EC%84%B1%ED%95%98%EA%B3%A0%EA%B4%80%EB%A6%AC%ED%95%98%EB%8A%94-%EB%8B%A4%EC%96%91%ED%95%9C-%EB%B0%A9%EB%B2%95\ 왜 굳이 도커(컨테이너)를 써야 하나요?눈송이 서버의 한계를 넘어 컨테이너를 사용해야 하는 이유]〉, 《44비츠》, 2019-01-14 | * raccoony, 〈[https://www.44bits.io/ko/post/why-should-i-use-docker-container#%EC%84%9C%EB%B2%84%EB%A5%BC-%EC%BD%94%EB%93%9C%EB%A1%9C%EA%B5%AC%EC%84%B1%ED%95%98%EA%B3%A0%EA%B4%80%EB%A6%AC%ED%95%98%EB%8A%94-%EB%8B%A4%EC%96%91%ED%95%9C-%EB%B0%A9%EB%B2%95\ 왜 굳이 도커(컨테이너)를 써야 하나요?눈송이 서버의 한계를 넘어 컨테이너를 사용해야 하는 이유]〉, 《44비츠》, 2019-01-14 | ||
− | * Jo Youngho , 〈[https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 컨테이너와 쿠버네티스를 쉽게 이해하기]〉, 《IBM Developer》, 2019-02-01 | + | * Jo Youngho, 〈[https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 컨테이너와 쿠버네티스를 쉽게 이해하기]〉, 《IBM Developer》, 2019-02-01 |
* Hong Log, 〈[https://honggg0801.tistory.com/22 Docker Swarm이란]〉, 《티스토리》, 2019-02-19 | * Hong Log, 〈[https://honggg0801.tistory.com/22 Docker Swarm이란]〉, 《티스토리》, 2019-02-19 | ||
* 카망, 〈[https://kamang-it.tistory.com/entry/DockerDocker%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EB%8F%84%EC%BB%A4%EC%9D%98-%EA%B8%B0%EC%B4%88%EC%99%80-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%84%A4%EC%B9%98%ED%95%98%EA%B3%A0-%EC%82%AC%EC%9A%A91 (Docker)Docker는 무엇인가? 도커의 기초와 이미지 설치하고 사용(1)]〉, 《티스토리》, 2019-04-14</ref> | * 카망, 〈[https://kamang-it.tistory.com/entry/DockerDocker%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EB%8F%84%EC%BB%A4%EC%9D%98-%EA%B8%B0%EC%B4%88%EC%99%80-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%84%A4%EC%B9%98%ED%95%98%EA%B3%A0-%EC%82%AC%EC%9A%A91 (Docker)Docker는 무엇인가? 도커의 기초와 이미지 설치하고 사용(1)]〉, 《티스토리》, 2019-04-14</ref> | ||
* Roseline Song, 〈[https://roseline124.github.io/kuberdocker/2019/07/24/docker-study06.html 도커 컴포즈(Docker Compose)]〉, 《깃허브 블로그》, 2019-07-14 | * Roseline Song, 〈[https://roseline124.github.io/kuberdocker/2019/07/24/docker-study06.html 도커 컴포즈(Docker Compose)]〉, 《깃허브 블로그》, 2019-07-14 | ||
− | * 도커(소프트위어) 위키디피아 -https://en.wikipedia.org/wiki/Docker_(software) | + | * 도커(소프트위어) 위키디피아 -https://en.wikipedia.org/wiki/Docker_(software) |
*〈[http://www.itworld.co.kr/news/135282#csidx559b9938b74390bb2540ab8506e03e7 쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해]〉 , 《아이티 월드》, 2019-10-31 | *〈[http://www.itworld.co.kr/news/135282#csidx559b9938b74390bb2540ab8506e03e7 쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해]〉 , 《아이티 월드》, 2019-10-31 | ||
* 김지성, 〈[http://blog.naver.com/ji_sung31/222030918443 (컨테이너 기술) IT에서 컨테이너란 어떤기술인가요? #클라우드 #맥도날드]〉, 《네이버 블로그》, 2020-07-14 | * 김지성, 〈[http://blog.naver.com/ji_sung31/222030918443 (컨테이너 기술) IT에서 컨테이너란 어떤기술인가요? #클라우드 #맥도날드]〉, 《네이버 블로그》, 2020-07-14 | ||
+ | *〈[https://www.youtube.com/watch?v=VANyEAfqO3k&t=1s 취약한 DOCKER REGISTRY 찾는 법]〉 , 《유튜브》, 2023-01-06 | ||
− | ==같이 보기== | + | == 같이 보기 == |
+ | * [[도커]] | ||
+ | * [[소프트웨어]] | ||
+ | * [[가상화]] | ||
+ | * [[가상머신]] | ||
* [[컨테이너]] | * [[컨테이너]] | ||
− | |||
* [[리눅스]] | * [[리눅스]] | ||
+ | * [[커널]] | ||
+ | * [[장애 (정보통신)|장애]] | ||
+ | * [[장애복구]] | ||
− | {{ | + | {{소프트웨어|검토 필요}} |
2023년 2월 14일 (화) 11:08 기준 최신판
도커(Docker)는 컨테이너(container) 기반의 오픈소스 가상화 플랫폼이다. 미국의 도커(Doker) 사에서 오픈소스 소프트웨어로 개발을 진행하고 있다. 리눅스 컨테이너 관리 도구인 도커는 컨테이너에 할당된 디스크 이미지를 간편하게 관리할 수 있는 점이 특징이다. 이미 애플리케이션이 설치된 이미지를 내려받아 이용할 수도 있고 자신이 새로운 이미지를 만들어 공개할 수도 있다.
목차
개요[편집]
도커는 2013년에 등장한 오픈소스 컨테이너 기반 가상화 도구이다. 도커는 항만(부두) 노동자라는 의미를 가지고 있다. 프로그래밍 콘퍼런스 파이콘 US 2013 에서 솔로몬 하이크(Solomon Hykes)가 리눅스의 컨테이너 기술을 사용한 도커를 처음 발표했다. 현재 도커는 고(GO) 언어로 개발되고 있으며, 2014년에 1.0 버전을 발표한 이후, 2020년 현재 최신 버전은 19.03.8이다. 도커는 리눅스 상에서 컨테이너 방식으로 프로세스를 격리해서 실행하고 관리할 수 있도록 도와주며, 계층화된 파일 시스템에 기반해 효율적으로 이미지 프로세스 실행 환경을 구축할 수 있도록 해준다. 도커를 사용하면 이미지를 기반으로 컨테이너를 실행할 수 있으며, 다시 특정 컨테이너의 상태를 변경해 이미지로 만들 수 있다. 이렇게 만들어진 이미지는 파일로 보관하거나 원격 저장소를 사용해 쉽게 공유할 수 있어 도커만 설치되어 있다면 필요할 때 언제 어디서나 컨테이너로 실행하는 것이 가능하다.[1] 도커는 복잡한 리눅스 응용 프로그램들을 하나의 컨테이너로 묶어서 실행할 수 있다. 그 이유는 개발 테스트 및 서비스 환경을 하나로 통일하여 효율적으로 관리할 수 있기 때문이다. 이로 인해 많은 사람에게 주목을 받기 시작했다. 파일을 이미지 파일로 변환하여 공유하고 리눅스 커널에서 제공하는 컨테이너 기술을 활용하여 전세 계 사람들과 공유도 가능하다. 깃허브(Github)와 비슷한 방식의 도커허브(Hub)를 제공한다.
특징[편집]
구성요소[편집]
- 소프트웨어 : 부두 노동자의 데몬이라고 하는 도커드(dockerd)는 도커 컨테이너 및 핸들 컨테이너 객체를 관리하는 지속적인 과정이다. 데몬은 도커엔진 API를 통해 전송된 명령을 받는다. 도커 클라이언트 프로그램은 사용자가 도커 데몬과 상호 작용할 수 있는 명령 인터페이스를 제공한다.
- 도커 객체: 도커에서 응용프로그램을 모은는 데 사용되는 방식이다. 도커 객체의 주요 클래스는 이미지, 컨테이너 및 서비스를 제공한다. 컨테이너는 응용 프로그램을 실행하는 표준화 된 캡슐화 된 환경이다. 컨테이너는 부두 노동자의 CLI 또는 API를 사용하여 관리된다. 도커 이미지는 컨테이너를 빌드하는 데 사용되는 읽기 전용 템플릿이다. 이미지는 응용 프로그램을 저장하고 배송하는 데 사용된다. 도커 서비스를 사용하면 컨테이너를 여러 도커 데몬으로 확장 할 수 있고, 그 결과 도커 API를 통해 통신하는 협력 데몬세트를 스윔이라고 한다.
- 도커 레지스트리(Docker Registry) : 도커의 이미지 저장소이다. 도커 클라이언트는 레지스트리에 연결하여 사용하기 위해 이미지를 다운로드하거나 생성한 이미지를 업로드한다. 레지스트리는 공개계정과 비공개계정으로 나뉜다. 주요 공용 레지스트리는 도커 허브와 도커 클라우드가 있다. 도커 허브는 도커가 이미지를 찾는 기본 레지스트리이다.[2]
- 도커 컴포즈(Docker Compose): 컴포즈의 사전적 의미는 ‘짓다’, ‘조립하다’이다. 도커 컴포즈는 여러 개의 컨테이너를 짓고 조립하는 데 유용하다. 여러 컨테이너에 대한 옵션을 docker-compose.yml이라는 명령어로 파일로 작성하면, docker-compose up이라는 한 번의 명령어로 서비스를 시작할 수 있다. 도커 컴포즈는 도커파일로 응용프로그램 환경을 정의한다. 프로그램을 구성하는 서비스를 도커-컴포즈.yml에 정의해서 한꺼번에 실행 가능하도록 한다.도커-컴포즈up 명령어로 컴포즈를 실행해 앱을 시작한다. 서비스에서는 실행하려는 컨테이너들을 정의하면 된다. 도커 컴포즈에서는 서비스 항목에 프로그램 구성에 필요한 컨테이너들을 여러 개 정의할 수 있다. 또한, 서비스 안에 각 컨테이너 항목에서는 도커 이미지를 실행할 때 쓰던 커맨드라인에 쓰던 여러 옵션(ex. ports)들을 적어둘 수 있다.[3]
- 도커 스웜(Docker Swarm): 도커가 공식적으로 만든 오케스트레이션(orchestraion) 툴 이다. 오케스트레이션 툴이란 여러 호스트 서버의 컨테이너들을 배포 및 관리를 위한 툴이다. 도커 스웜을 쉽게 말하면 쿠버네티스(Kubernetes)를 대신할 도커에서 만든 컨테이너 관리를 위한 툴이다. 오케스트레이션 툴은 컨테이너 배포뿐만 아니라 다양한 기능을 포함한다. 컨테이너를 자동 배치하고 복제하며 컨테이너 그룹에 대한 부하를 분산시켜준다. 때문에 장애복구가 가능하다. 도커를 사용하는 컴퓨터 클러스터를 외부서비스 노출해주며 컨테이너 추가 또는 제거를 이용한 확장 및 축소가 가능하다. 컨테이너 서비스 간의 인터페이스를 통한 연결 및 네트워크 포트 노출을 제어한다. 도커 스윔은 여러 개의 도커 호스트를 함께 클러스터링하여 단일 가상 도커 호스트 생성하며 호스트 프로그램에 에이전트만 설치하면 간단하게 작동하고 설정이 쉽고 에이전트를 외부에 설치하지 않는다.[4]
기능[편집]
이미지 생성[편집]
도커에서는 이미지를 생성하는 기능을 빌드(Build)라고 한다. 도커는 응용 프로그램과 실행에 필요한 라이브러리, 미들웨어, 운영체제, 네트워크 설정 등 필요한 모든 파일을 모아서 도커 이미지 파일로 만든다. 도커 이미지는 명령어를 이용해 수동으로 만들 수도 있지만, 자동으로 이미지를 빌드하여 배포하는 지속적 배포 결합 환경에서는 도커 설정 파일을 이용해 자동으로 만들 수 있다. 보통 이미지에는 하나의 응용 프로그램만 넣고 여러 컨테이너를 조합해서 서비스를 구축하는 방법을 사용한다. 또한 이미지 여러 개를 같이 사용할 수 있다. 예를 들면 센트오에스(CentOS) 리눅스 이미지와 엔진엑스(Nginx) 웹 서버 이미지를 겹쳐서 새로운 이미지를 만들 수 있다.
이미지 공유[편집]
도커에서는 이미지를 공유하는 기능을 쉽(Ship)이라고 한다. 도커 이미지를 업로드해서 공유하는 저장소를 도커 레지스트리(Docker Registry)라고 한다. 대표적으로는 도커의 공식 레지스트리인 도커허브(Docker Hub) 가 있다. 도커 허브에서는 업체에서 제공하는 공식 이미지를 받을 수 있다. 우분투나 센트오에스 같은 운영체제 이미지, 마이에스큐엘(MySQL), 레디스, 엔진엑스와 같은 미들웨어와 플랫폼 이미지도 제공한다. 이런 베이스 이미지를 활용하면 환경을 빠르고 안전하게, 그리고 자동으로 구축할 수 있다. 또 자신이 만든 응용 프로그램을 이미지로 만들어서 업로드하고 공유할 수 있다. 깃허브와 같은 형상 관리도구와 연동해서 도커파일을 관리하고 도커 이미지를 자동으로 빌드해서 도커 허브로 배포하는 것도 가능하다. 퍼블릭 클라우드에서는 비공개 레지스트리와 지속적 배포를 쉽게 구성할 수 있는 기술을 제공한다. 이에는 아마존 컨테이너나 구글의 클라우드 플랫폼이 포함된다. 사실 도커 이미지는 보안에 취약하다. 이미지 공유 기술을 악용하여 보안상 위협이 되는 프로그램을 심기도한다. 이를 방지하기 위해서 컨테이너를 스캔하고 정책에 위배되는 이미지는 배포를 허용하지 않는다.
컨테이너 동작[편집]
도커에서는 컨테이너를 생성하여 동작하는 것을 런(Run)이라고 한다. 도커는 도커 이미지를 가지고 컨테이너를 생성하여 동작한다. 하나의 이미지를 가지고 다수의 컨테이너를 만들기도 한다. 이렇게 만든 컨테이너들을 관리하기 위한 여러 명령을 사용한다. 실제 업무에서는 보통 한 대의 호스트에 모든 컨테이너를 동작시키는 것이 아니라 여러 호스트로 된 분산 환경으로 작동된다. 분산 환경에서 여러 노드의 컨테이너를 관리하기 위해 쿠버네티스(Kubernetes)와 같은 컨테이너 오케스트레이션 툴(Container Orchestration Tool)을 주로 사용한다. 오케스트레이션이란 컨테이너 배포, 장애 복구, 로드 밸런싱 등 여러 기능을 자동으로 처리해주는 것을 말한다. 음악회의 오케스트라를 보면 지휘자의 신호에 맞게 음악을 연주한다. 이처럼 컨테이너 동작 시에 자동화 프로그램을 이용하여 컨테이너의 데이터를 관리한다.[5]
리눅스 컨테이너[편집]
도커는 리눅스의 컨테이너 방식을 사용하여 프로그램이 작동한다. 컨테이너 방식은 가상머신의 발달로 등장하게 되었다. 컴퓨터 첫 등장 이후 컴퓨터 성능이 급격히 발전하면서 일반 PC에서도 흔히 사용하게 되었다. 이러한 기술의 발달로 서버의 성능이 향상하게 되었다. 하지만 그만큼 서버에 남아있는 공간도 많고 서버가 일을 하지 않으니 문제가 되고 IT 기술이 보편화 되면서 서버도 많아졌다. 그렇기 때문에 컴퓨터에 컴퓨터를 만들어 작동하기 위한 가상머신이 나오게 되었고 서버 자체를 가상머신을 통해서 작동하는 기술이 발달했다. 이는 서버의 빈공간을 가상머신으로 이용하여 서버의 효율을 극대화할 수 있다. 가상머신에 각종 서버 프로그램, 데이터베이스를 설치하여 소프트웨어 응용 프로그램이나 웹사이트를 실행하고, 미리 구축한 가상머신 이미지를 여러 서버에 복사하여 실행하면 이미지 하나로 서버를 계속 만들 수 있다. 하지만 가상머신은 이미지 안에 OS가 포함되기 때문에 이미지 용량이 커지게 되어 문제가 발생한다. 컴퓨터 자체를 전부 사용하다 보니 각종 성능에 손실이 발생하게 되었다. 호스트와 커널을 공유하는 반가상화 기술이 등장 했지만 배포하고 관리하는데 기능이 부족했다. 이를 개선하기 위해 리눅스 컨테이너가 나오게 되었다.[6]
컨테이너 박스는 흔히 선박을 통하여 물건을 수출할 때 많이 사용한다. 도커의 로고를 보면 알 수 있듯이, 컨테이너는 이동하는 물건을 하나의 공간에 담고 목적지까지 안전하게 보낼 수 있다. 컨테이너 없이 물건을 하나하나 쌓아서 보관하다보면 없어지는 경우도 생기고 물건이 충격을 받는다면 부러지거나 변형이 생기기 마련이다. 이처럼 리눅스에서도 파일 전송 및 변경 시 파일 안에 있는 데이터가 아무런 보호없이 간다면 충분히 변조 및 데이터 패킷이 변형될 수있다. 그렇기에 가상의 컨테이너 만들어 사용하면 보관하기에도 편하고 같은 목적지를 가는 물건일 경우 더욱 안전하게 갈 수 있다. 다운받은 프로그램이 같다 해도 서로 다른 환경의 응용체제에서 사용하면 조금은 다르게 작동된다. 이는 서버마다 운영기록이 다르기 때문인데 어디에서도 프로그램을 실행하더라도 100프로 실행할 수 있는 기법이 필요하다. 이를위해 복잡한 IT 환경을 통합하여 포장하는 기술이 컨테이너 기술이다. 언제 어디서든 프로그램을 실행 할 때 본래의 의도와 맞게 변형이나 문제없이 프로그램이 실행된다.[7] 리눅스 컨테이너에서는 대표적인 2가지 명령어 네임스페이스(NameSpace)와 씨그룹스(Cgroups)가 있다. 컨테이너는 가상의 독립된 환경을 만들기 위해 리눅스 커널의 네임스페이스 기능을 사용한다. 쉽게 얘기하면 리눅스 객체에 이름표를 붙여 같은 이름표가 붙여진 것들만 묶어 관리한다. 이를 다른 말로 격리(isolated)시킨다는 의미가 있는데 이는 다른 네임스페이스에서는 접근할 수 없다는걸 의미한다.
- 네임스페이스
- PID : 각 프로세스에 할당된 고유한 아이디인 PID 를 기준으로 다른 프로세스를 격리한다. 네임스페이스가 다르면 접근할 수 없다.
- 네트워크: 네트워크 자원(IP 주소, 포트 번호, 라우팅 테이블 등)을 네임스페이스마다 독립적으로 가져간다.
- UID : 사용자 아이디와 그룹 아이디를 네임스페이스별로 구분한다. 따라서 컨테이너에서는 루트 권한을 가지고 있더라도 호스트의 관리 권한을 가질 수 없도록 격리가 가능하다.
- 마운트(mount): 리눅스에서 파일을 인식하기 위해 마운트가 필요하다. 파일 시스템 등 마운트된 파일을 네임스페이스별로 격리한다.
- UTS : 호스트 명이나 도메인명을 네임스페이스별로 독자적으로 설정이 가능하다.
- IPC : 프로세스 간 통신에 필요한 공유 메모리, 세마포어(Semaphore), 메시지 큐(Message Queue) 등을 독자적으로 사용한다.
리눅스에서 프로그램은 프로세스로 실행되고, 프로세스는 하나 이상의 쓰레드로(Tread) 이루어져 있다. 씨그룹스는 프로세스와 쓰레드를 그룹화해서 관리하는 기술이다. 호스트 OS의 자원을 그룹별로 할당하거나 제한을 둘 수 있다. 즉 컨테이너에서 사용하는 리소스를 제한함으로써 하나의 컨테이너가 자원을 모두 사용해 다른 컨테이너가 영향을 받지 않게 된다. 또한 그룹에 계층 구조를 적용할 수 있어 체계적인 자원관리가 가능하다.
- 씨그룹스
- CPU : CPU 사용량 제한
- cpuacct : CPU 사용량 통계 정보 제공
- cpuset : CPU나 메모리 배치 제어
- 메모리 : 메모리나 스왑(Swap) 사용량 제한
- 디바이스 : 디바이스에 대한 접근 제어
- 프리저(freezer) : 그룹 내 프로세스 정지 및 재개
- net_cls : 네트워크 제어
- blkio : 블록 디바이스 입출력량 제어[5]
네트워크[편집]
도커의 컨테이너는 서버의 물리 NIC와 별도로 각 컨테이너마다 가상 NIC가 할당되어 있다. 또한 이러한 가상 NIC는 도커0이라는 가상 브릿지에 접속하여 컨테이너끼리 통신한다. 도커0은 도커 데몬을 기동한 후에 생성되며, 172.17.42.1 주소가 할당된다. 도커에서 컨테이너를 구동하면 컨테이너에 172.17.0.0/16 subnet mask를 가진 프라이빗 IP 주소가 eth0에 자동으로 할당된다. eth0에는 호스트OS에 생성된 가상 NIC(vethxxx)가 페어로 할당된다. veth는 OSI 7계층 레이어 2의 가상 네트워크 인터페이스로서 페어된 NIC끼리 터널링 통신을 수행한다. 가상 NIC(vethxxx)는 컨테이너에서 eth0으로 인식된다. 도커 컨테이너는 이러한 네트워크 구성을 기본으로 다음과 같이 네트워크 통신을 수행한다.
- 도커 컨테이너 간의 통신
동일한 호스트 상의 도커 컨테이너는 구동 시 프라이빗 주소가 자동으로 할당되므로 컨테이너끼리 통신하기 위하여 '링크 기능'을 사용한다. 컨테이너를 구동할 때, 통신하려는 컨테이너 이름을 지정하여 링크하면 해당 정보가 /etc/host에 환경변수로 저장되어 직접 통신할 수 있다. 단, 링크 기능을 사용한 통신은 동일 호스트, 즉 가상 브릿지 도커0에 접속한 컨테이너끼리만 가능하다. 멀티 호스트 환경에서는 링크 기능을 이용한 통신이 불가능하므로 주의해야 한다. 또한 보안 요구 사항에 따라 컨테이너 간 통신을 차단하도록 설정할 수 있다.
- 도커 컨테이너와 외부 네트워크 통신
도커 컨테이너가 외부 네트워크와 통신할 때에는 가상 브릿지 도커0와 호스트OS의 물리 NIC에서 패킷을 전송해야 한다. 이 때, 도커에서는 NAPT 기능을 사용하여 접속한다. NAPT(Network Address Port Translation)란 하나의 IP 주소를 여러 컴퓨터에서 공유하는 기술로서 IP 주소와 포트 번호를 변환하는 기능이다. TCP 및 UDP 포트 번호까지 동적으로 변환하기 때문에 여러 머신에서 한 글로벌 IP 주소로 접속할 수 있다. 이 기능은 컨테이너를 구동할 때, 내부에서 사용하고 있는 포트를 가상 브릿지 도커0에서 개방할 때 사용된다. 예를 들어 컨테이너 구동 시, 컨테이너 내의 웹 서버(http 데몬)가 사용하는 80번 포트를 호스트OS의 8080번 포트로 전송하도록 설정하였을 때, 외부 네트워크에서 호스트OS의 8080번 포트에 액세스하면 컨테이너 내의 80번 포트로 연결되는 구조이다.[8]
도커 파일[편집]
도커에서 사용하는 도커 파일(Docker File)은 서버 운영 기록을 코드화한 것이다. 도커 파일로 도커 이미지를 만들 수 있다. 도커 파일이 서버 운영 기록이라면, 도커 이미지는 운영 기록을 실행한 시점이라고 한다. 이미지와 컨테이너는 도커를 이해하는 데 있어 가장 중요한 개념이다. 이미지는 가상머신에서 사용하는 이미지와 비슷한 역할을 한다. 한마디로 정의해보자면 이미지는 어떤 응용 프로그램을 실행하기 위한 환경이라고 할 수 있다. 그리고 이 환경은 파일들의 집합이다. 도커에서는 응용 프로그램을 실행하기 위한 파일들을 모아놓고, 다수의 프로그램과 함께 이미지로 만들 수 있다. 그리고 이 이미지를 기반으로 해당 소스를 바로 배포할 수 있다. 또한 이미지는 컨테이너 실행에 필요한 파일과 설정값 등을 포함하고 있는 것으로 상태 값을 가지지 않고 변하지 않는다. 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장된다. 같은 이미지에서 여러 개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 바뀌거나 컨테이너가 삭제되더라도 이미지는 변하지 않고 그대로 남아있게 된다.
예를 들어 사용자가 1년 전 서버에 서버 A를 구성했고, 오늘 서버 B를 구성한다면, 두 서버에 대해 이미지는 설치된 시점으로부터 1년의 차이가 발생하게 된다. 하지만 도커에서는 도커 파일로 이미지를 만들어 두면, 서버가 구성되는 시점으로부터 이미지를 만든 시점으로 고정된다. 이 이미지를 사용해 1년 전 A 서버에 컨테이너를 배포하고, 오늘 B 서버에 컨테이너를 배포한다고 해도, 두 컨테이너 모두 이미지가 설치된 시점은 같다. 도커는 특히 분산 환경을 쉽게 구축할 수 있는 클라우드 서비스와 호환성이 좋다. 그래서 주요 클라우드 사업자들은 모두 컨테이너 실행 환경을 쉽게 관리할 수 있는 서비스를 제공한다.[9] 도커 파일 작동 과정은 다음과 같다.
도커 파일 생성 → 도커 파일을 통한 도커 이미지 생성 → 완성된 이미지 저장소에 업로드 → 각 섭버에서 이미지를 다운받아 사용
도커 이미지는 해당 프로그램을 실행하는데 모든 정보를 담고 있다. 예를 들어 우분투 이미지는 우분투를 실행하기 위한 모든 파일을 가지고 있고 마이에스큐엘 이미지는 데비안(Debian)을 기반으로 마이에스큐엘을 실행하는데 필요한 파일과 실행 명령어, 포트 정보 등을 가지고 있다. 말 그대로 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 더 이상 의존성 파일을 확인 하지않고 다른 파일을 설치할 필요가 없다. 만약 새로운 서버가 추가되면 미리 만들어 놓은 이미지를 다운받고 컨테이너를 생성만 하면 된다. 한 서버에 여러 개의 컨테이너를 실행할 수 있고, 수십, 수백, 수천 대의 서버도 문제가 없다. 도커 이미지는 도커 허브에 등록하거나 도커 리지스트리 저장소를 직접 만들어 관리할 수 있다. 현재 공개된 도커 이미지는 50만 개가 넘고 도커 허브의 이미지 다운로드 수는 수십억 회에 이른다. [10]
비교[편집]
가상머신[편집]
도커는 가상머신에 비해 매우 가볍고 빠르다. 그 이유는 리눅스의 커널을 이용하기 때문이고, 하나의 서버나 가상머신이 여러 컨테이너들을 동시에 조작할 수 있기 때문이다. 대신에 도커는 파일의 상태를 정밀하게 알기는 어렵고 자유롭게 사용하기에는 제약이 많다. 하지만 실제 사용해보면 도커의 장점이 훨씬 부각 된다. 그 이유는 가볍고 빠른 것도 있지만 어느 환경이나 동일하게 작용하기 때문이다. 여기서 동일하게 동작한다는 건 완전 밑단까지 같이 동작한다는 이야기가 아니라 사용하는 입장에서 동등하게 사용할 수 있다는 뜻이다. 우측 그림에서도 나오듯이, 기존의 가상머신의 경우에는 호스트 운영체제 위에 새로운 게스트 운영체제를 설치를 했다. 그러다 보니 운영체제 위에 운영체제가 있는 모양이고 이는 필연적으로 속도 저하로 이어진다. 하지만 도커는 운영체제 위에 운영체제를 설치하는 것이 아니라 현재 운영체제에 없는 것만 추가적으로 받아온다.
가령 현재 호스트 운영체제가 A인데 게스트 운영체제를 B로 사용한다고 가정한다. 가상머신은 A위에 B를 설치하게 된다. 근데 도커는 A에 없는 부분만, 즉 B와 A가 공유하는 부분은 빼고 나머지만 재 설치한다. 이게 가능한 이유는 맥과 리눅스는 모두 유닉스와 같은 운영체제이기 때문이다. 그래서 윈도우에서 사용하는 도커는 리눅스 자체를 가상머신 마냥 올리기 때문에 성능이 좋지 않다. 그렇다고 윈도우에서 의미가 없는 건 아니고 윈도우에서도 리눅스와 똑같은 환경으로 사용할 수 있다는 장점이 있다. 그래서 오히려 윈도우에서 코딩할수록 도커를 사용하는 것이 좋다. 하지만 도커를 사용한다는 의미는 단순히 테스팅을 한다는 의미가 아니다. 오히려 테스팅을 할 거면 가상머신이 훨씬 낫다. 도커는 배포를 위해서 사용하는 것이므로 테스트를 하기에 적합하지는 않다.[11]
쿠버네티스[편집]
쿠버네티스(Kubernetes)란 컨테이너 오케스트레이션의 종류로 사람들이 많이 도커와 쿠버네티스를 많이 헷갈려하고 있다. 오케스트레이션이란 컨테이너를 스케줄링/클러스터링/서비스 디스커버리/로깅 및 모니터링하는 것이다. 컨테이너는 원래 프로세스나 프로그램을 서로서로 시스템으로부터 격리하기 위해 만들어졌다. 그래서 개별 컨테이너를 생성하고 배치하기는 쉽다. 하지만 여러 컨테이너, 데이터베이스와 웹 프론트엔드, 연상을 위한 백엔드 등 여러 컨테이너를 모아 하나의 단위로 관리할 수 있는 커다란 애플리케이션으로 만들고자 한다면 문제가 달라진다. 더구나 이들 컨테이너 각각을 독립적으로 배치하고 연결하고 관리하고 확장할 수 있어야 한다면 모든 구성요소를 전체로 기능하도록 조직할 방법이 필요하다. 이 작업이 바로 쿠버네티스가하는 일이다. 만약 컨테이너가 크루즈선의 승객이라면, 쿠버네티스는 크루즈선의 선장인셈이다.
구글이 시작한 프로젝트를 기반으로 하는 쿠버네티스는 여러 컨테이너 애플리케이션을 여러 대의 호스트에 배치하고 관리하는 작업을 자동화하는 방법을 제공한다. 각각의 컨테이너를 직접 하나씩 관리하지 않아도 되며 개발자는 여러 컨테이너에 걸친 애플리케이션의 배치도를 작성하는데, 여기에는 각 컨테이너가 네트워킹과 스토리지를 사용하는 방식 등의 세부 정보가 담겨 있다. 쿠버네티스는 런타임에서 나머지 부분을 처리한다. 또한 기밀이나 앱 환경 구성 같은 성가신 세부 관리도 맡는다. 소수의 사용자를 위한 비교적 단순한 컨테이너 앱은 보통 오케스트레이션이 필요 없다. 하지만 만약 프로그램의 기능과 사용자 수가 사소한 수준 이상이라면, 오케스트레이션 시스템을 사용하지 않고 직접 해결하기 어려워진다. 복잡한 프로그램, 두 개 이상의 컨테이너가 관련되는 프로그램이라면 오케스트레이션을 사용하는 것이 좋을 것이다. 하지만 사용자 수가 많지 않고 크기도 보통인 앱이라면 쿠버네티스보다는 도커 스웜 모드 같은 좀 더 최소화된 솔루션을 사용하는 것이 좋다. 그리고 쿠버네티스를 비롯한 오케스트레이션 툴은 조건이 바뀔 때마다 코딩으로 대응하지 않고, 원하는 시스템 상태를 서술하는 방식으로 워크로드와 컨테이너 간의 균형을 맞출 수 있다.[12]
쿠버네티스의 장점은 무중단(Fault tolerance-FT) 서비스를 제공하는 것이다. 때때로 기업의 서비스를 이용하는 사용자들은 개선을 위해 임시점검 중이라는 안내문을 보게 된다. 기업에서는 서버 업데이트를 위해서 사용자들이 잠든 새벽 시간을 활용하거나 긴급 점검의 형태로 서비스를 일시 중단해왔지만, 쿠버네티스는 점진적 업데이트를 제공하기 때문에 서비스를 중단하지 않고도 프로그램을 업데이트할 수 있다. 또한, 쿠버네티스는 자가 회복(Self Healing) 기능이 있기 때문에 특정 컨테이너에 갑작스러운 장애가 발생하더라도 곧바로 복제 컨테이너를 생성해서 서비스를 유지할 수 있다. 또 한 가지는, 다른 소프트웨어와 호환성이 가능하다. 만약 고객이 A사의 클라우드를 사용하다가 다른 회사의 클라우드로 환경을 이전하고 싶을 때, 서로 다른 업체의 클라우드 제품 간에 호환 문제가 발생하여 이전하기 어려운 상황을 벤더 락인(Vendor Lock In)이라고 한다. 쿠버네티스는 도커 컨테이너를 기반으로 하는 오픈소스이기 때문에 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경들을 이전할 수 있다.[13]
활용[편집]
도커의 운영체제는 다음을 포함한 다양한 인프라구조 도구들에 통합되어 어디서든지 사용할 수 있다. 이에는 오라클 컨테이너 클라우드, 아마존 웹 서비스(AWS), 구글 클라우드 플랫폼, 우분투, 센트오에스, 맥, IBM 블루믹스, 페도라, 쿠버네티스, VM웨어 v스피어(VMware vSphere) 등을 포함한다.
설치방법[편집]
도커는 리눅스 컨테이너 기술이므로 맥이나 윈도우에 설치할 경우 가상머신에 또한 설치가 된다. 리눅스에 도커를 설치하는 방법은 자동 설치 스크립트를 이용하는 것이 가장 쉽다. 다음 명령어를 입력하면 root 권한을 요구하고 잠시 기다리면 설치가 완료된다. 설치가 안된다면 리눅스 커널 버전이 3.10.x 이상인지 확인해야 된다. 우분투 14.04 이상을 사용하면 큰 문제가 없고 커널의 버전이 낮을 경우 제대로 동작하지 않거나 문제가 발생할 수 있기에 반드시 업데이틀 해주어야 한다. 밑의 내용처럼 리눅스 명령어 창에 도커를 설치하고 버전 정보를 확인하여 서버와 클라이언트가 나온다면 설치가 잘 이루어진 것이다.
curl -fsSL (https://get.docker.com/) | sudo sh //도커 설치 docker version //도커정보 확인 ~$ docker version Client: Version: 17.09.0-ce API version: 1.32 Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:42:18 2017 OS/Arch: linux/amd64 Server: Version: 17.09.0-ce API version: 1.32 (minimum version 1.12) Go version: go1.8.3 Git commit: afdb6d4 Built: Tue Sep 26 22:40:56 2017 OS/Arch: linux/amd64 Experimental: false
컨테이너에서 사용하는 기본적인 명령어는 다음과 같다.
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...] //도커 실행 docker ps [OPTIONS] //컨테이너 목록 확인 docker stop [OPTIONS] CONTAINER [CONTAINER...] //컨테이너 중지 docker rm [OPTIONS] CONTAINER [CONTAINER...] //컨테이너 제거 docker images [OPTIONS] [REPOSITORY[:TAG]] //컨테이너 이미지 확인 docker pull//이미지 다운 docker rmi// 이미지 제거
윈도에서는 윈도우 버전에 의해 두 가지 버전으로 나뉘게 된다. 먼저 윈도우 버전이 윈도우7 이상이여야 하고 컴퓨터 하드웨어가 가상화(Virtualization)를 지원해야 한다. 윈도우 8, 윈도우 10은 작업관리자 "성능" 탭에서 "가상화:사용"이라고 표시되면 도커를 사용할 수 있다. 구글에 docker.com을 검색하고 도커 공식 사이트에 접속하여 회원가입을 하면 한 달간 무료체험버전 다운이 가능하다. 윈도우, 맥, 리눅스에서 전부 사용 가능하다.[14]
각주[편집]
- ↑ Daegwon Nacyot Kim, 〈도커(Docker) 입문편 컨테이너 기초부터 서버 배포까지〉, 《44비츠》, 2020-03-22
- ↑ 도커(소프트웨어) 위키디피아 -https://en.wikipedia.org/wiki/Docker_(software)
- ↑ Roseline Song, 〈도커 컴포즈(Docker Compose)〉, 《깃허브 블로그》, 2019-07-14
- ↑ Hong Log, 〈Docker Swarm이란〉, 《티스토리》, 2019-02-19
- ↑ 5.0 5.1 에릭 한, 〈도커 Docker 기초 확실히 다지기〉, 《GitHub》, 2018-11-16
- ↑ pyrasis, 〈도커 무작정 따라하기: 도커가 처음인 사람도 60분이면 웹 서버를 올릴 수 있습니다!〉, 《슬라이드쉐어》, 2015-02-14
- ↑ 김지성, 〈(컨테이너 기술) IT에서 컨테이너란 어떤기술인가요? #클라우드 #맥도날드〉, 2020-07-14
- ↑ miiingo, 〈(Docker) 완벽한 IT 인프라 구축을 위한 Docker: 제2장 컨테이너 가상화 기술과 Docker〉, 《티스토리》, 2018-01-30
- ↑ raccoony, 〈왜 굳이 도커(컨테이너)를 써야 하나요?눈송이 서버의 한계를 넘어 컨테이너를 사용해야 하는 이유〉, 《44비츠》, 2019-01-14
- ↑ subicura, 〈초보를 위한 도커 안내서 - 도커란 무엇인가?〉, 《서비큐라 블로그》, 2017-01-19
- ↑ 카망, 〈(Docker)Docker는 무엇인가? 도커의 기초와 이미지 설치하고 사용(1)〉, 《티스토리》, 2019-04-14
- ↑ 〈쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해〉 , 《아이티 월드》, 2019-10-31
- ↑ Jo Youngho, 〈컨테이너와 쿠버네티스를 쉽게 이해하기〉, 《IBM Developer》, 2019-02-01
- ↑ subicura, 〈초보를 위한 도커 안내서 - 설치하고 컨테이너 실행하기〉, 《서비큐라 블로그》, 2017-01-19
참고자료[편집]
- pyrasis, 〈도커 무작정 따라하기: 도커가 처음인 사람도 60분이면 웹 서버를 올릴 수 있습니다!〉, 《슬라이드쉐어》, 2015-02-14
- subicura, 〈초보를 위한 도커 안내서 - 도커란 무엇인가?〉, 《서비큐라 블로그》, 2017-01-19
- subicura, 〈초보를 위한 도커 안내서 - 설치하고 컨테이너 실행하기〉, 《서비큐라 블로그》, 2017-01-19
- 에릭 한, 〈도커 Docker 기초 확실히 다지기〉, 《GitHub》, 2018-11-16
- Daegwon Nacyot Kim, 〈도커(Docker) 입문편 컨테이너 기초부터 서버 배포까지〉, 《44비츠》, 2020-03-22
- raccoony, 〈왜 굳이 도커(컨테이너)를 써야 하나요?눈송이 서버의 한계를 넘어 컨테이너를 사용해야 하는 이유〉, 《44비츠》, 2019-01-14
- Jo Youngho, 〈컨테이너와 쿠버네티스를 쉽게 이해하기〉, 《IBM Developer》, 2019-02-01
- Hong Log, 〈Docker Swarm이란〉, 《티스토리》, 2019-02-19
- 카망, 〈(Docker)Docker는 무엇인가? 도커의 기초와 이미지 설치하고 사용(1)〉, 《티스토리》, 2019-04-14</ref>
- Roseline Song, 〈도커 컴포즈(Docker Compose)〉, 《깃허브 블로그》, 2019-07-14
- 도커(소프트위어) 위키디피아 -https://en.wikipedia.org/wiki/Docker_(software)
- 〈쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해〉 , 《아이티 월드》, 2019-10-31
- 김지성, 〈(컨테이너 기술) IT에서 컨테이너란 어떤기술인가요? #클라우드 #맥도날드〉, 《네이버 블로그》, 2020-07-14
- 〈취약한 DOCKER REGISTRY 찾는 법〉 , 《유튜브》, 2023-01-06
같이 보기[편집]