[Docker] 중간고사 정리(1)

 

 

 

 

 

https://www.docker.com

 

 

 

Chap1. Overview 

- 수천 수만대의 컴퓨터들이 웹을 기반으로 서비스 ex) 구글, MS / Datacenter programming 기술의 개발 철학과 배경들 – Agile, DevOps, CI/CD – Continuous Integration and Delivery, Microservice and Serverless 

 

- IP Address - 컴퓨터 기기에 주어지는 주소, internet protocol address 

- Port number - 한 컴퓨터 내에서도 프로그램마다 주소가 붙음 / 프로그램이 OS에 구멍을 뚫는 것 ex) 웹은 80번 포트 사용

 

- Domain name - 사람이 이해하기 쉬운 영어 이름 / 뒤에 있는 (com) 도메인이 더 넓은 개념

Ex) https://www.domain-name.com                 

- https:// - protocol, www – sub-domain, com – top-level domain

- DNS – Domain name system - 영어 단어를 기계가 이해하는 IP 주소로 바꿈 // domain <-> IP address by DNS server

- DHCP – Dynamic Host Configuration Protocol - IP 주소는 부족 -> 통신 시에만 임시로 IP 주소를 빌려주는 기법이 DHCP

- HTTP - HTTP 클라이언트가 서버에게 request를 보내고 response를 받는다. 이처럼 0과 1을 주고 받는 소프트웨어, HTTP

 

 

 

 

 

Chap2. Cloud Computing and Infrastructure 

- 구글 서버들이 동작하는 물리적인 컴퓨터들의 위치 - 어딘가 분명 컴퓨터, 디스크, 네트워크 존재 but 사용자는 몰라도 됨

- 필요할 때, 필요한 만큼의 CPU 디스크 네트워크 사용하고, 필요 없어지면 반납한다. Ex) 구글 코어 500만개, 네이버 40만개

- ex) 네이버 각 - 네이버 본사에서 개발된 SW가 춘천에서 돌아간다.

 

* Cloud Computing? 필요할 때 필요한 만큼, 거의 무한한 자원(CPU, 디스크, 네트워크)을 바로 요청 가능, 사용자는 구체적인,  물리적인 인프라 몰라도 OK - 돈 내고 빌려서 사용 / 하드웨어 인프라와 소프트웨어, 어플리케이션까지 모두 제공 가능

* 내가 직접 인프라를 구축하는 것 대비 갖는 장점
1. 사용자의 요구를 충족하는, 거의 무한에 가까운 자원 
2. Up-front commitment 제거 – 컴퓨터 대당 빌려서, 다 사용하지 않더라도 돈을 내야 했다. 이러한 희생을 제거할 수 있다. 
3. 필요할 때 늘리고 줄이면, 내가 직접 컴퓨터를 사는 것보다 효율적으로 사용 가능 // 

+ 클라우드 컴퓨팅을 도입한다고 절대로 저렴한 것 X / 잘게 쪼개고, 모니터링하고, 개발자가 이에 맞게 소프트웨어를 잘 짜는게 중요 / 늘리고 줄이는 것 중요 / 그렇게 했을 경우 싸다

 

* Cloud computing 도입하기 좋은 Use Cases 

1. 시간에 따라 수요가 변하여 예측이 어려운 경우 2. 컴퓨터 한 대가 1000 시간 돌릴 걸, 1000 대에서 1시간 돌도록 배치 처리 ex) 머신러닝, 과학 시뮬레이션 + 시각적 렌더링 (애니메이션)

 

* 클라우드 컴퓨팅의 5가지 특징 

- On Demand - 필요할 때, 필요한 만큼 사용하며, 이 작업에 대해서 사람의 개입을 최소화하여 자동화 된 interface 사용

- 네트워크로 장치들이 연결되어 있다 / 어딘가에는 물리적인 리소스들이 쌓여 있다 -> 필요할 때 가상의 리소스들이 할당됨

- 서비스가 중단되지 않도록, 빠르게 리소스 제공 가능 (rapid elasticity) 

+ 100개의 기능을 하나의 실행 파일에 다 때려 박으면 X, 하나를 100개의 실행 파일로 쪼개어 돌리는 거야

- 100개의 기능 중, 하나의 기능만 두 배로 키울 필요가 생겼어 -> 모니터링을 하다가, 필요한 애들만 더 키우는 것

 

*** 클라우드 컴퓨팅 3가지 모델 – Service models 

(1) SaaS – Software as a Service - 개발자가 아니라, 일반 유저가 필요할 때 필요한 만큼 쓰는 경우 ex) 유튜브, Gmail, Dropbox

- 어딘가에 있는 서버에 접속해서 서비스 활용 / 엔드 유저가 필요할 때 쓰는 경우 (돈을 내거나 or 광고를 보고)

(2) PaaS – Platform as a Service - CPU DISK 메모리 위에 기업 별 소프트웨어 도구 or 라이브러리 등 개발 도구와 환경도 활용 

Ex) Google App Engine, Google Cloud Platform 

(3) IaaS – Infrastructure as a Service – Amazon EC2(elastic compute cloud), Amazon S3, Window Azure - CPU DISK 메모리 - CPU or Storage 빌려주는 것, 이때 우리가 빌리는 것은 가상의 기계 – 그 아래의 진짜 machine에는 관심 X

 

* Cloud computing – Deployment models 4가지 

1. Private cloud - 같은 소유주 안에서, 조직 내부 구성원들에게 제공 / 사내에서 관리하는 cloud, 대기업 한정 

2. Community cloud - 같은 목적으로 모여서 함께 인프라를 공유. ex) 수학 물리 연구자들 (순수과학, 비영리단체)

3. Public cloud – 제 3자 아마존, 구글과 같이, 사용자가 남의 회사의 자원을 빌려 사용하고, 대가를 지불

4. Hybrid cloud – private에서 특정 상황에 부분적으로 public cloud 도입하는 것, 민감한 데이터가 넘어간다면? 보안문제 O

+ data lock-in - 이후 업체를 변형하기 어렵다

 

 

 

 

 

Chap3. Infrastructure & Virtualization 

- On-premise - 자체적으로 데이터 센터 서버를 운영하는 것, private cloud computing 의미 

- ex) 삼성 내부의 cloud - 수면 아래의 부담에 의해서 도입하지 않는 경우가 많음 (하드웨어, 개발 인력 필요 등) 

- public cloud 도입 시 돈을 지불해야 하지만, 밑단은 몰라도 된다는 이점이 있다. 

 

* On-premise vs Cloud Server -> *** Pet model vs Cattle model

1. Pet model - 본인이 직접 구축한 서버에 독특한 이름 부여 -> 서버가 유니크 하길 바람 -> 개발 시 문제 발생 가능

2. Cattle model - 서버 간 차이점 X (유니크 이름 X) 기능과 숫자를 주는 방식으로, 모든 서버는 동일한 취급 – 필요 시 replace

+ 더 밑바닥까지 내려가고 싶다면 SaaS는 더 내려갈 수 X, 미들웨어 OS까지 모두 control 할 수 있다는 장점 ex) 구글, 아마존

 

- Infrastructure – Hardware & Network, OS, Middleware 

- Server – Central Processing Unit (CPU), Memory – 주기억장치 메모리, Storage – 보조기억장치 디스크

+ 서버와 클라이언트가 HTTP로 통신하니까, 웹이라는 이름이 주로 붙는 것 / 무조건 서버가 웹을 갔다 오는 건 X

 

* Web Server - HTTP 기반의 통신이 목적 / request 받음 + 로직 서버 + DB서버 (Store, process & deliver) 

- 가장 기본적인 것은 HTML 파일을 주고 받는다.

* Database Server - 대규모 데이터를 관리하는 전용 소프트웨어 DBMS / SQL - structured query language - 엑셀 차트로 만들 수 있는 데이터들 ex) 경희대 학적부, 회계 -> SQL server

+ 최근의 데이터는 구조화되지 X, 이미지, 비디오, 블로그 게시글 등 비정형 데이터를 다루는 NoSQL server 

 

* OS – Linux - 개발, 운영 목적의 서버 모두 리눅스 사용, 실습에서 CLI 명령어 많이 씀

- 운영체제의 핵심이 커널 - 서버 관련 소프트웨어들이 리눅스 커널 위에서 돌아간다.

* Middleware – 엔드 유저 어플리케이션과 OS 사이의 미들웨어 -> 라이브러리, 프레임워크 등 OS 보완하는 것이 미들웨어

 

* Deploying at Scale - 필요할 때 필요한 만큼 가짜 CPU, DISK, 네트워크를 사용할 것 / 그 위에 초 단위로 필요한 것을 올림

- 어딘가에는 분명 physical 존재 -> 직접 인프라 짜는 상황에서 치뤄야 하는 대가가 곧 클라우드 컴퓨팅의 장점

- 시간이 오래 걸림 (부품 주문, 건물 등 부동산 계약, 설치 등등) 리눅스를 이해하는 사람이 필요함, 기술 별로 전문가 필요

 

* IaC – Infrastructure as Code – 마이크로 서비스를 한 글자로 말하세요! -> IaC 

- 프로그래밍을 하지 않는데, 프로그래밍 하듯이 파일 안에 문서로 작성 / 개발자가 본인이 필요한 환경을 코드로 기술하면, 데이터센터가 주어진 환경을 자동화된 형태로 제공 / ex) 나는 이런 CPU 몇 개, OS, DB, 라이브러리, 네트워크 스킴, 연결 등 작성 / 프로그래밍 하듯이 타이핑하여, 명세서를 쓰는 것

Ex) 도커에게 실행 요청하면, 작성된 방식으로 구성해서 / 네가 확인해봐 or 쿠버네티스 - 내가 알아서 해 -> 10개 중 하나 죽으면,얘가 알아서 하나 더 올림 – 인간의 개입을 줄이는 것 (자동화)

 

- 인프라를 virtual하게 필요할 때 필요한 만큼 띄우는 것, Physical은 몰라도 되도록 / 어떠한 환경이든 동일한 결과를 나오게 함

* Infrastructure as Code is an approach to managing IT infrastructure for the age of cloud, microservices and continuous delivery. 

- 클라우드 위에 마이크로서비스를 돌린다. 한 CPU에서는 굉장히 작은 것을 돌리는 것 / 인간이 개입하지 않는 CI/CD 자동화 

- git-hub에서 가져와 / 인프라로 돌려 / 테스트 코드 돌려 / 결과 확인 / 배포 -> 개발팀 서버에서 운영팀 서버로 copy해 / 검증팀으로 옮겨서 코드 돌려 / continuous delivery / integration Ex) 젠킨스

 

* Infrastructure as Code의 장점

- 신속하고 간편하게 필요할 때 필요한 만큼 요청하고, 가져올 수 있다 / 환경과 하드웨어에 독립적으로, 일관성 유지 가능

- 위험성 감소 / SW 개발 효율 증가 / 비용 절감 (마이크로 서비스화 하지 않은 상황에서 올리면 해당 X)

 

*** Mutable Infrastructure vs Immutable Infrastructure

(1) Mutable Infrastructure – 하나만 바꾸면 되지, 뭐하러 다 바꿔 

- 하나의 application 안에 여러 service가 존재 – 각 서비스 별 버전을 다양하게 유지 -> 트랙킹, 유지 보수가 매우 어렵다.

 

(2) Immutable Infrastructure

- 현 시점에서 실행되는 것은 버전은 딱 하나 - 과도기 상태는 있을 수 있지만, 큰 그림으로는 버전을 하나만 유지하자!

- immutable 해야, 필요할 때 늘이고 줄이는 것이 가능함 * 매우 중요한 규칙

* 가장 중요한 장점은 관리 측면 – 인스턴스 별 변화를 트랙킹 할 필요 없다 / 한 번에 하나의 이미지(버전)만 유지하니까

Like cattle model – physical 서버와 무관하게 표준화되어 동일한, 획일적인 체계 -> 이것이 docker의 concept

+ 도커 맥 사이에 아주 작은 리눅스가 올라감 / 사실상 리눅스 기반에서 올라가게 만들어졌으며, 맥OS 위에 작은 리눅스 깔고 도커 올라가게 하는 것 / 즉 도커가 조그마한 리눅스를 설치한다. 

 

 

 

 

 

Chap4. Virtualization & Container Technology

- 가상화 - 물리적인 하드웨어 위에서 돌아가는 가상의 CPU DISK 네트워크 (주로 CPU 가상화) 

- 가상화를 통해 하나의 물리적인 하드웨어 위에 논리적으로 여러 개의 컴퓨터들이 돌아갈 수 있다. (여러 OS 띄우기 가능)

- 하드웨어와 host OS 위에 hypervisor -> 이 위에 VMWare, parallels 등등 여러 virtual machines 띄울 수 있다. 

- 각 VM들 위에 app이 돌아가기 위한 (사용자의 요청을 처리하기 위한), Guest OS가 host OS와 독립적으로 필요하다. 

 

* hypervisor 장점 – 1. 한 대의 컴퓨터 위에 여러 대의 논리적인 컴퓨터를 띄워, 남는 리소스를 빌려줄 수 있다. 2. physical한 기기가 아니라, 필요할 때 필요한 만큼, 당장 빌려서 사용 가능 

* hypervisor, Virtual machine 단점 – machine을 virtual화 하는 것 -> OS Full copy -> 오버헤드, 느리고 무거움

- CPU 코어가 N개라면, 숙명적으로 host OS가 돌아가는 코어 하나 배제해야 함 -> 최대 N-1개 사용 가능 

-> 내가 돌리고 싶은건 프로그램인데, 굳이 머신까지 띄워야 하는가?

-> 프로그램의 실행에 focus -> host OS의 능력을 재사용하면 guest OS가 없어도 되거나, 얇아도 된다

 

*** Linux over linux problem - virtualization tax

- 빌려 쓰는 경우 큰 문제 X / but private cloud 우리 회사에서 데이터센터 구축 시 문제 발생 / 대부분 회사는 공인 OS 통일

- Apple은 Public cloud X / 아이폰, 맥을 위한 제공할 애플 서비스, 인프라를 우리 회사 내부 고객이 사용 / private cloud team

- 리눅스 오버 리눅스 문제 by apple -> NASA openstack은 VM을 만드는 것을 기반으로 함, 그 부하가 30%에 이른다.

 

-> but 우리는 필요할 때 필요한 만큼 컴퓨팅 자원이 필요한 것 (virtual machine이 아니라 컨테이너 기법으로 전환) 

- 도커 이전의 리눅스 컨테이너 (전통적인 기술) / 서버 - 새로운 유저에게 계정을 열어줘 (물리적인 공간을 만들어줘)

- 어딘지는 모르겠지만, 필요할 때 필요한 만큼 실행파일을 동작시키고, 필요 없어지면 프로그램을 깔끔하게 삭제

 

* Container vs Virtual Machine 

- 도커는 컨테이너를 실어 나르는 역할 / 컨테이너 = 실행 파일 + 필요한 라이브러리 – abstraction at the app layer 

- 필요할 때 필요한 만큼 설치하고, 깨끗하게 지우자 (오래된 리눅스 컨테이너 기법)

* 컨테이너의 장점 - 게스트 OS로 full OS가 올라타야 하니까 무거웠음 / 컨테이너는 수MB (매우 가볍고, 빠르게 돌릴 수 있음) 

- 코어를 독립적으로 요구하지 않아 요구하는 공간이 VM보다 작고, 따라서 VM보다 더 많은 application을 돌릴 수 있다.

- 컨테이너가 VM보다 메모리도 더 적게 사용 / 각 컨테이너들은 하나의 host os 공유하게 된다.

* Challenges of Container - 수십만 수백만 코어가 있다고 가정하고, 서버 프로그램을 짜는 것 - CNCF (cloud native)