06-Docker Overview
🐬 Previous Studies
- What is Docker?
- Use cases of Docker
- Solomon
- Immutable Infrastructure with Docker
- Why is Docker popular?
- Image
- Container
➡ Container SW 중 하나인 도커를 만든 사람은 Solomon이며, 도커파일을 사용함으로써 ubuntu OS를 가져오고, 운영체제에 SW를 설치하고, 파이썬을 설치하고, 환경설정 하는 것은 "자신이 동작하고자 하는 어플리케이션 하단에 있는 인프라를 Immutable하게 코드로 실행함"
➡ 도커가 유명한 이유는 2013년에 나온 이후로 수많은 컨테이너 기술등 중에서 가장 대중적인 오픈소스이며, 가벼운 측면과 더불어 Linux, Windows를 포함한 다양한 운영체제를 지원하여 수많은 OS 위에 도커들이 설치됨 + intell CPU, Arm CPU와 같이 서로 다른 하드웨어 플랫폼에서도 도커가 실행되므로 portability(휴대성) 측면에서 다양한 플랫폼들이 일관됨
🙂 따라서, 도커를 기반으로 해서 SW개발,운영,관리하는 사람은 하단에 있는 인프라 및 하드웨어에 대해서는 인지하지 않아도 동일한 결과가 나올 것이라는 기대가 있음, Infrastructure as os컨셉은 도커파일을 통해서 필요한 운영체제, SW, 라이브러리, 기타 configration을 만들수 있고, 이것을 Build 명령어를 통해 이미지를 만들 수 있음
🙂 즉, 다른사람이 만든 이미지(Ubuntu, Hello world, python)를 Registry에서 가져와서 사용해 이미지를 만들었고, 이미지를 필요할 때, 필요량만큼 실행하는 것이 Container라고 함
🔹 Docker Editions (1)
➡ Community Edition (CE)
individual developers & small teams
: 오픈소스로 사용되고 있어 수많은 사람들이 사용해보고, 버그를 잡고, 기여하는 개념임
ex. 오픈소스, developer, user group, free와 같은 개발자 커뮤니티
➡ Enterprise Edition (EE)
enterprise developers & IT teams
: 돈을 지불하고 사용
ex. 회사에서 상용화를 목적으로 서비스를 만들고 이를 build하고, 실제로 여러 CPU와 디스크 위에서 실행할 때, 안정적으로 실행되게 함 (사람이 부가가치를 창출하는데, 집중해야 함으로 자동화 시스템으로 풍부하게 해주는 것을 의미함)
🔹 Docker Editions (2)
: 도커엔진이 enterprise가 된다면, 엔진 뿐만 아니라 다양한 솔루션을 제공함으로 수많은 이미지들이 나올 것이고, 버전이 달라질 것이며, 이를 기반으로 컨테이너 앱들이 만들어지고, 또 버전이 달라지며, 보안에 대한 문제들이 나타날 것임
: 도커엔진 enterprise는 도커엔진 외에 수많은 SW들이 만들어지고, 버전관리가 되며 running, 관리, 보안관리 등을 자동화 하는 부분들이 포함됨
🙂 따라서, '도커파일'이라는 Infrastructure as Code로 필요한 인프라를 정의하였고, 여기에 자신의 어플리케이션을 넣을 수 있으며, 이를 build해서 이미지를 만들고 이를 running하면 컨테이너가 됨
🙂 running 할때에, 수천~수만개의 CPU에 흩어질 수 있는 distributing(배포)을 할 수 있는데, 결국 이러한 작업을 도커엔진 SW 하는 일임
🙂 엔진은 통상 SW의 핵심이 되면, 컨테이너가 잘 실행되는지를 확인하는 다양한 기능들을 수행함
🙂 즉, 도커엔진이 우리가 만든 도커파일에서 이미지로 만든 컨테이너들을 실행 & 관리하는 가장 중요한 SW임 (전반적으로 많이 사용되는 SW)
🔹 Docker Editions (3)
🔹 Docker Daemon (SW)
: CLI or 다른 Daemon이 도커API를 통해서 전달될 것에 대해 본인에게 어떤 요청을 하는지를 계속 듣고 있음
ex. 이미지, 컨테이너, 네트워크 & 볼륨을 다루는 작업을 함
: 같은 컴퓨터 안에 Daemon, CLI를 연결할 것이고, CLI를 통해 다른 컴퓨터에 있는 도커 Daemon을 접촉하기도 함
🙂 위의 둘은 떨어질 수도 있고, Daemon끼리 통신도 가능함
🔹 Docker Client
: 도커 Daemon에 접촉하는 SW 도커 클라이언트는 CLI(검정화면에서 명령어를 타이핑 하는 것)를 도커엔진에게 요청함
: 클라이언트 서버 아키텍쳐와 비슷함
: 도커 클라이언트는 도커엔진에게 본인이 필요한 기술들을 요청함
ex. registr에서 이미지를 가져오세요~
: 도커 command가 하나하나의 명령이 도커API 매핑이 됨
: 도커 클라이언트는 본인 host에 있는 도커 Daemon 외에 다른 host에 있는 Daemon을 접촉하는 것도 가능함
🔹 Docker Architecture
➡ 도커 Daemon, 클라이언트, registry, 이미지, 컨테이너의 관계를 설명하는 그림은 다음과 같음
: 왼쪽) 클라이언트가 있음
-도커파일에서 이미지를 만드는 도커 bulid
-만들어진 이미지를 어딘가로부터 registry에서 가져오는 도커 full
-이미지를 다시 실행해서 컨테이너를 실행하는 run
🙂 즉, 왼쪽) 클라이언트, 우측) registry, 중간) 도커Daemon(클라이언트의 명령을 받음)이 있으며, 도커 Daemon은 중간에서 registry를 통해 이미지를 가져오며, 클라이언트에 요청하여 이미지를 컨테이너로 실행함
🔹 Docker Registry
: Registry는 이미 만들어진 도커의 이미지를 저장하는 곳
➡ 2가지의 개념
(1) Public registry
: 누구에게나 공개함 & 누가나 사용가능
ex. 대학이 자체적으로 registry를 가지고 있는게 아닌, 외부의 registry를 사용함
(2) Private registry
: 다른사람은 볼 수 없고, 기관만 사용가능
ex. A대학만 볼 수 있음
🙇 밖에 두고 registry를 사용하고 싶다면? 구글 or 아마존을 활용하기
ex. 구글) 텐서플로우와 같은 특화된 이미지가 존재
🙂 SW를 개발 할때, 제3자가 만든 소스코드를 가져오는데 (구글 or 아마존이 만든 이미지를 가져옴) 좋은점은 엔진박스 단체가 도커에 가장 최적화된 이미지를 제공하고 있으므로, 추가적으로 올리기만 하면 됨
🙂 프로그래밍은 라이브러리, 소스코드 뿐만 아니라, Infrastructure as Code에 의해서 이미 다른 사람이 만든것을 가져옴으로 자신이 원하는 서비스를 도입할 수 있고, 안정적이며, 시행착오도 줄일 수 있음
🔹 Docker Ecosystem
: Developoer machine은 개발자 컴퓨터로, 개발자는 소스코드를 만들고 코드와 이미지를 클라이언트들에게 전달함
: External code repositories) 소스코드를 저장해서 필요한 사람에게 배포하는 소스코드에 대한 부분임
: Images repositories) registry에 대한 부분임
🙂 즉, Developoer 컴퓨터에서 코드나 도커파일과 같은 소스코드는 소스코드 매니저(github)로 가고 그곳에서 만들어진 이미지는 registry로 갈 것임
🙂 따라서,
(1) develpment environment : 개발자가 만든 소스코드와 이미지가 있으면, 개발자가 만든 결과물이 생김
(2) production environment : sw를 필요한 만큼의 cpu와 디스크들을 흩어서 실행함
➡ 도커host 위에서 만든 이미지와 소스코드들이 동작할 것임
: 수천~수만대를 관리하기 위해서, orchestrator(ex.쿠버)가 중간 이후로 등장함
🔹 Docker Ecosystem : Development
: Developoer machine 안에는 physical한 부분들이 있음
: 하드웨어 위에 host가 있고, 그 위에 추가되는 라이브러리들이 있으며, 그 위에 도커 Daemon이 있어서 컨테이너들이 떠 있는데, 이것을 개발환경으로 제어하고 있고, build해서 컨테이너를 띄움
: 개발자 컴퓨터에서 도커파일을 통해서 도커이미지를 만들고, 컨테이너를 띄우기도함
: 본인이 만든 SW들이 Developoer machine에서 만들어질 것임
: 본인이 만든 SW코드와 Infrastructure as Code 실행을 위한 도커파일은 도커명령이 아님
: git push는 소스코드와 도커파일을 서버에 올리는 작업을 함
🙂 따라서, github는 외부에 있는 것을 사용하는 것이고, public(돈 지불x) or private(돈 지불o)을 사용
🙂 개발자 컴퓨터에서 내가 만든 코드와 도커파일은 소스코드 매니저에게 들어가는 것이고, 그렇지 않으면, 이미지 쪽으로 가게됨
🙂 코드와 도커파일을 가지고 build해서 이미지를 만들었다면, 이미지를 registry에 올리는 것은 "도커 push"임
🙂 Images repositories는 (c)에 있는 도커허브를 registry에 사용할 수 있고, (d) 회사 안에 있거나 구글, 마이크로소프트, 에이저 등을 사용할 수도 있음
🙂 private, pubilc, 도커허브에 이미지가 등록될 것이고, registry에는 만든 이미지 외에도, 다른사람이 만들어 놓은 것도 많을 것임
🙂 이것을 가지고 재사용도 가능하며, 소스코드 레벨로 다른사람과 공유 or 전문시스템에 올려놓은 것이 있고, 이미지는 registry에 올렸으며, operation(작업)하는 쪽에서 만든 이미지를 가지고 실행할 것임
🙂 수행할 도커 host하고, 하드웨어 위-OS 위-라이브러리 위에 도커 Daemon이 있으면, 이미지를 가져와서 컨테이너들을 띄울 것임 (한 대의 도커 Daemon 위에 여러개의 컨테이너를 띄울 수 있음)
🙂 orchestrator : 수 많은 도커머신들을 지휘하는 것이며, 업그레이드도 가능(ex.쿠버네티스)
🎯 중요!!
: virture machine 기법을 사용하면, 코어를 사용해야 하기 때문에 코어 개수보다 많은 virture machine을 띄울 수밖에 없음
ex. hard core와 cpu4개인 경우)
virture machine을 띄울때 virture machine 하나당 single core을 주려고 한다면, host에서 사용할 코어가 1개 있으니 남아있는 3개에 한개씩 줄때, 최대 virture machine 개수는 3개임
➡ but, 컨테이너는 달라!
: 컨테이너는 cpu가 견딜 수 있고, 요구하는 부하가 현재 남은영역으로 동작이 가능하다면, cpu의 개수와 상관없이 컨테이너는 견딜 수 있음
🔹 Docker underlying technologies
(1) Namespaces
: c++, 파이썬과 같은 프로그래밍 언어에서도 여러사람들이 각각 만들어 놓은 class 라이브러리들을 한 프로그램에서 사용할 때, 서로간의 이름이 충돌되는 것을 방지하는 것임
: 한대의 컴퓨터를 마치 컨테이너들은 혼자 사용하는 것처럼 보이게 하는 virtureazaion 컨셉임
: 컨테이너 기술은 os 버전의 virtureazaion을 하기 위해서 각 컨테이너들에게 고립된 (서로 침범하지 않는) 고유의 영역들을 만들어줌
: 그래서 virture machine은 아니지만, 컨테이너가 개발하는 입장에서 virture machine 처럼 보이지만(컨테이너가 독립적인 것처럼 보임), 이런 기술들이 도커에 있으므로 컨테이너에 virture machine이 있는 것처럼 편하게 사용 가능
*아래의 표 : 컨테이너마다 독립적으로 만들어줌
(2) Control Groups (cgroups)
: resource를 관리함
: 하나의 하드웨어를 여러개의 컨테이너를 공유하는 것이므로, 도커 아래-도커 안에서는 각 메모리를 어느정도 사용할 것인지, 서로 나눌 수 있음
: 컴퓨터 자원을 virture machine처럼 할당 할 수 있음
: 컨트롤 그룹 개념도 도커엔진에 포함됨
