[오픈소스] - 컨테이너와 도커

1. 가상화
   -> 하드웨어에 종속된 컴퓨터 리소스를 추상화
   -> 운영체제에서 제공하는 가상화란 ?
         - 각각의 응용프로그램이 각자의 cpu, 큰 virtual memory를 가지고 있는 것처럼 착각하도록 가상화를 제공
          (process, cpu scheduling, virtual memory, paging, swapping .. )
2. 서버 가상화
   (1) 서버 가상화 도입 배경 : 하드웨어 기술이 발전하며 서버의 성능이 획기적으로 향상
        -> 싱글코어 👉 멀티코어 => 하나의 os에서 여러 app 가능/ system 자원 또한 hw가 os에게 나눠서 줌
   (2) 서버 가상화의 장점
        - 높은 자원 활용률 : 하드웨어 자원의 효율적인 활용 (남은 서버 활용 -> 남은 서버 사용 중지해 냉각 및 유지관리 비용 절감)
        - 장애 고립 (isolation) : 특정 어플리케이션이나 os의 장애가 전체 시스템으로 전파되어 다른 업무에 영향을 미치는 것을 방지
        - 보안 강화 : 개별 사용자가 자신의 vm에만 접근할 수 있어, 전체 시스템에 대한 접근을 원천적으로 차단
        - 신속한 자원 제공 및 백업 : 설정이 완료된 vm에 대해서 필요 시에 스토리지에서 복사 및 이전함으로써 신속하 자원 제공 및 백업 가능
          -> vm migration : 로드 밸런싱 or 전력소모 👇
   (3) 가상 서버의 문제점
        - 성능 오버헤드 : 시스템 자원의 할당/사용을 위해 Hypervisor(guest os운영 및 관리하는 sw)를 거쳐야 하므로 Bare-metal 방식에 비해서 처리에 부가적인 시간 필요 (성능적인 오버헤드)
       - 자원 낭비 : Guest OS 실행을 위해 필요한 자원 필요
       - 거대한 이미지 사이즈 : vm 이미지에는 애플리케이션, 필수 라이브러리 또는 바이너리 및 guest os가 포함됨
         -> 이미지 사이즈가 커서 vm migration이 느림
      - 느린 시작 시간 : cpu, 메모리, 하드디스크 등의 하드웨어를 가상화하고 있어 guest os를 부팅해야 사용할 수 있음
   
   
3. 컨테이너
   (1) 컨테이너란 ? 
        -> 운영체제 수준의 가상화 
        -> 컨테이너는 프로세스 간 벽을 만들어 하나의 os커널 안에서 애플리케이션이 구동되는 환경을 격리할 수 있음
        -> 리눅스 커널의 네임스페이스와 컨트롤 그룹이라는 기술을 기반으로 함
   (2) 컨테이너의 장점
        - 인프라의 사용률 향상 : guest os 실행을 위한 자원 낭비가 없음. 일반적인 프로세스 실행과 거의 차이가 없음. 하나의 물리 서버에서 프로세스만큼이나 많이 실행 가능
       - 빠른 기동 시간 : 컨테이너는 app + 라이브러리 만 담고 있어 실행속도가 상대적으로 빠름
       - 불변 실행 환경 (Immutable Infrastucture) : 애플리케이션 실행에 필요한 소프트웨어를 컨테이너는 모두 포함 중. 컨테이너를 조합하여 시스템을 구성함으로써 특정 서버 환경에 대한 종속성을 배제할 수 있음. 개발환경과 운영 환경의 차이를 줄일 수 있음
   
   
4. Docker
   - 컨테이너 기반 가상화 도구
   - 2013년 Go(구글이 만든 거) 언어로 개발
   - 컨테이너 관련 기술의 사실상 표준
   - 애플리케이션 배포에 초점
5. Docker의 아키텍처
   - 클라이언트/서버 모델 
      -> Docker 데몬(server), Docker 클라이언트(client)
      -> 이미지, 컨테이너, 도커 레지스트리
   
   
6. Docker 데몬
   - 클라이언트에서 도커 커맨드를 전달받고 도커 오브젝트인 이미지, 컨테이너, 볼륨, 네트워크 등을 관리
   - 네트워크 너머에 있는 원격 클라이언트로부터 요청을 받는 것도 가능
   
   
7. Docker 클라이언트
   - 컨테이너 조작을 위한 CLI 클라이언트
   - 컨테이너, 이미지, 네트워크, 볼륨 등의 도커 오브젝트를 관리
   - 명령어를 통해 동작
   
   
8. Docker 이미지
   - 컨테이너를 기동하기 위한 실행파일과 설정 파일의 묶음
   - 컨테이너 실행 시 이미지에 담긴 미들웨어나 애플리케이션이 설정에 따라 기동
   - 하나의 이미지는 여러 Layer의 조합으로 이루어짐
   - 대부분의 이미지는 다른 이미지에 기반하여 만들어짐 (실제론 다른 이미지의 layer참조 -> Base Layer)    
   - 유니온 파일 시스템에 의존
   - 이미지를 만들 때는 기반 이미지와 설치 스크립트 등을 Dockerfile에 기재해 빌드
   
   
   
9. Docker 컨테이너
   - docker run 명령을 통해 이미지는 컨테이너로 변환되어 하나의 인스턴스가 됨
   - ip주소를 가지는 하나의 독립된 서버처럼 동작
   - 중지 컨테이너를 재기동할 경우 할당된 ip주소 유지 안 됨. (강제 고정 방법이 있긴 함 )
   - 컨테이너 생명 주기
      이미지 : 실행되기 전의 상태(컨테이너 전의 상태)
      실행 : 컨테이너 위에서 프로세스가 실행 중인 상태
      정지 : 프로세스의 종료코드, 로그가 보존된 채 정지한 상태
   
   
   
10. Docker 레지스트리
    - 컨테이너의 이미지가 보관되는 장소
    - 기본적으로 Docker 허브를 사용 (도커 허브에서 이미지 이름 찾아서 있으면 알아서 다운 받음)
    - 레지스트리 종류
       퍼블릭 레지스트리 : 누구나 이용 가능한 공개 레지스트리 (ex. Docker Hub)
       클라우드 레지스트리 : 퍼블릭 클라우드에서 제공하는 레지스트리 서비스 (ex. google container registry)
       비공개 레지스트리 : 회사나 팀 전용으로 레지스트리를 구축 및 운영 (ex. gitlab container registry)
    
    
    
11. 레지스트리와 쿠버네티스의 관계
    - 레지스트리는 개발한 컨테이너 이미지를 쿠버네티스에서 실행하기 위한 중간 창고와도 같은 존재
    
    
    
12. Docker 이미지와 컨테이너
    - 이미지는 운영체제와 소프트웨어를 담고 있는 컨테이너 실행 이전의 상태
    - 각 이미지는 '리포지토리 : 태그' 로 식별됨
    - 리포지터리에 올리고 받는 것은 이미지 (push/pull)
    - 컨테이너는 이미지를 실행한 상태
    - 이미지로 여러 개의 컨테이너를 만들 수 있음
    - 운영체제로 치면 이미지는 실행파일 컨테이너는 프로세스
    
    
    
13. 도커 기반 애플리케이션 개발의 라이프사이클 
    - 컨테이너 동작에 필요한 모든 내용을 코드로 작성 (Infrastucture as Code == IaC)
    - 변경 불가능한 인프라 환경에서 애플리케이션 개발, 테스트, 배포 가능