도커에는 '이미지(Image)' 라는 개념이 있습니다. 이미지라고 사진같은 개념은 아닙니다.

도커에서 이미지는 컨테이너 실행에 필요한 모든 파일과 설정 값 등을 포함한 것으로 상태값을 가지지 않고 변하지 않는 것입니다.

• 이미지는 특정 프로그램을 실행하기 위한 파일과 설정값을 지니고 있는 것.
• 의존성 파일을 컴파일하거나 설치가 필요 없다.
• 이미지를 다운로드 받고 실행하면 컨테이너를 실행 가능.

컨테이너 : 이미지를 실행한 상태

https://tech.ktcloud.com/73

가상머신 기반 가상화 기술

Virtual machines

• 저수준 하드웨어장치(CPU, Disk, Network)를 가상화하는 기술
• 하이퍼바이저 위에 하나의 머신들이 가상화돼서 동작한다.
• 머신 단위로 할당이 되기 때문에 각각 OS도 설치해야 앱 구동 가능

장점

• 다양한 운영체제 실행 가능
• 물리머신 대비 동일한 자원을 더 효율적으로 사용
• 물리머신 대비 빠른 서버 프로비저닝

단점

app을 구동하기 위해 굳이 OS가 다 올라와야 한다.

하이퍼바이저

• 하이퍼바이저 = 가상머신 모니터 = VMM
• 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼(platform)을 말한다.
• CPU와 메모리 스토리지 등의 하드웨어 자원들을 애뮬레이션해서
  결과적으로 한 대의 서버에 독립된 여러 머신 환경을 구성하는것과 같은 가상화를 제공한다.

하이퍼바이저의 두가지 타입

• TYPE1 - 하드웨어에 하이퍼바이저가 설치되고 그 위에 Guest OS들이 설치가 된 구조 (서버, 워크스테이션 클라우드 환경에서 많이 사용)
• TYPE2 - Host OS 위에 하이퍼바이저 위에 Guest OS들이 동작 (주로 데스크탑, 노트북 환경에서 많이 사용)

컨테이너 기반 가상화 기술

컨테이너

• app구동에 필요한 모든 종속성을 포함한 sw패키지를 운영체제 위에서 가상화
• 하드웨어 위에 Host OS 위에 컨테이너를 구동하기 위한 컨테이너 엔진( =도커) 위에 컨테이너
• 컨테이너를 어느 환경에나 배포 가능하다.
• OS를 부팅하거나 라이브러리를 로드할 필요가 없다.
• 가상환경을 더 효율적이고 경량으로 생성 가능하다.
• 수초 이내의 빠른 시작시간
• 하나의 호스트에 더 많은 app 실행 가능
• 운영적인 측면에서 보면 OS 업데이트나 패치등 Host를 공유하기 때문에 유지관리를 하는데 있어서 오버헤드가 감소한다.
• 단점으로는 컨테이너가 정의된 운영체제의 종속성
• ** 운영체제를 공유하고 커널을 공유하는 형태이기 때문에 안전하게 isolation을 했지만
  클라우드 vendors와 같이 다중고객 멀티 테넌트 환경에서는 리스크를 갖고 있는 구조이기 때문에 이를 개선하기 위한 다른 방식의 라이트웨이트 가상화를 구현해서 사용하기도 합니다.

주요 기술 변화 - 인프라 환경/ 컴퓨팅 환경/ 서버 관리 측면/ 장애 대응 측면

인프라 환경

온프레미스 → 클라우드

온프레미스

• 서버를 구매하고 설치, 관리 하는 업무를 직접 진행한다.
• 서버를 실제 할당받기 위해 긴 시간 소요

클라우드

• 컴퓨팅 자원을 필요한만큼 할당 받고, 사용한 만큼 비용 지불
• 인프라 자원을 간단하고 즉각적으로 할당 받을 수 있다.
• 클라우드 벤더사에서 제공하는 API/SDK 를 이용해 모든 자원을 자동화 하여 프로비저닝 할 수 있다.
  ( ex 테라폼으로 필요한 자원의 명세를 기술하면 인프라가 자동으로 생성된다.)
• 국방,금융 분야같은 안정성이나 보안을 중요시하는 분야에서도 클라우드 사용 추세

컴퓨팅 환경

가상머신 → 컨테이너(도커)

가상머신

• 하드웨어를 가상화하는 기술을 기반으로 가상머신을 만들어내고, 그 기반 위에 OS와 애플리케이션 구동
• 가상머신 단위로 확장 (스케일업, 스케일 아웃)

컨테이너

• 컨테이너는 운영체제 기반 가상화 기술. 컨테이너 패키지 단위로 가상화 한다.
• 컨테이너 단위로 확장
• 빠른 확장성을 갖고있다.
• 기존 : 컴퓨터 켜서 -운영체제 구동 - app실행
  컨테이너 환경 : app실행
  (컴퓨터는 켤 필요 없고 운영체제는 이미 구동되어 있는 상태여서)
• 리눅스 기반의 기술로 자원을 격리시켜 가는 방식으로 실행
  (같은 운영체제 위에서 여러 app이 구동되어도, 각 app간 아이솔레이션이 잘 이루어지는 환경)

서버 관리 측면

쉘 스크립트 → 자동화 도구

쉘 스크립트

• 커스텀 쉘 스크립트
• 담당자가 부재시에는 대응 어렵다.
• 스크립트 자체 오류 존재 가능

자동화 도구

• 필요한 부분에는 쉘 스크립트 사용
• 쉘 스크립트를 한 단계 추상화된 형태로 자원을 기술하는 도구를 사용하여 관리 (ex Ansible)
• Ansible 멱등성 : 동일한 인프라 설정을 반복적으로 실행해도, 항상 동일한 형상을 유지하도록 내부적으로 관리가 된다는 장점이 있다.

장애 대응 측면

리눅스 명령어 이해 → 리눅스 이해

기존

장애가 발생한 서버에 직접 접속해서, 리눅스 명령어로 복구/분석 했다.

최근

• 중앙 집중화된 로깅/ 모니터링 할 수 있는 환경을 구축/운영
• 수집된 데이터를 기반으로 장애를 판단.

컨테이너 개념

app 구동하려면 코드 , 종속성, 런타임(실행환경)이 필요하다.

이걸 하나의 패키지로 묶는다.
→ 이 패키지를 다양한 환경에 배포 진행.

도커는 기존에 Paas에서 지원을 하고있던 환경에 로컬환경도 포함된다.

• 로컬에서 개발자가 직접 아티팩트 만들고 테스트와 개발을 진행 가능
• 컨테이너 런타임이 동작하는 호스트 환경에 구애받지 않고 동일한 패키지가 실행된다.

컨테이너 장점

민첩성

• 개발자가 app을 운영 환경에 배포될 코드를 직접 빌드하고 배포를 진행 해 볼수 있다. (더 빠른 배포 가능)

이식성

• OS 플랫폼 간, 클라우드 간 이식가능하다.
• 설치된 OS나 클라우드 종류에 관계없이 동일한 컨테이너 실행 가능
• 개발시스템에서 프로덕션 환경까지 일관된 형식 사용

신속한 확장성

• 같은 인프라에 더 많은 컨테이너 자원 사용 가능
• app만 app단위로 스케일링을 진행할 수 있다.

https://www.slideshare.net/awskorea/aws-container-service-getting-started-with-kubernetes-on-aws