2021 08 15

2021-08-15¶

도커¶

왜 컨테이너를 학습해야 하는가? - 애플리케이션 배포 환경을 서버에 직접 설치하여 구성하면 snowflake server 이슈 발생 - snowflake server: 한번 설치한 서버에 계속해서 설정을 변경하고 패치를 적용하는 것 - 이렇게 설정된 서버 다시 똑같이 설정하는 거 진짜 너무 어려움 - 누락된 설정/패치에 의해 장애 발생 다수 - 이를 극복하고자 script를 활용한 자동화 방식, OS 가상화 방식등으로 서버 관리

기존의 OS 가상화 방식 - 하이퍼바이저를 활용해 여러개의 OS를 하나의 호스트에서 사용하는 방식 - 하이퍼바이저: 호스트 컴퓨터에서 다수의 OS를 실행하기 위한 논리적 플랫폼 - 각종 시스템 자원 가상화 + 독립된 공간 생성하는 것이 하이퍼바이저를 거침 - 일반 Host에 비해 성능 손실 발생 - 가상머신은 GuestOS를 사용하기 위한 "라이브러리, 커널" 등을 모두 포함해야 함 - 가상머신을 배포하기 위한 이미지로 만드는 것은 크기가 너무 컸어! - 특정 환경에 종속되지 않은 상태로 어플리케이션을 띄우는 것이 목표야 - "어플리케이션"을 띄울라하는데 "OS"를 띄우는 건 좀 에바야 - 격리된 CPU, 메모리, 디스크, NW를 가진 공간을 만들고, 이 공간에서 프로세스를 실행해서 유저에게 서비스할 것! - chroot로 특정 자원만 사용하도록 제한 - chroot: Change Root Directory = 현재 실행중인 프로세스와 자녀 프로세스의 루트 디렉토리 변경하는 작업 - cgroup을 활용해 자원의 사용량을 제한 - cgroup: Control Group = 단일 또는 태스크 단위의 프로세스 그룹에 대한 자원 할당을 제어하는 커널 모듈 - namespace로 특정 유저만 자원 보도록 제한 - namespace: 프로세스를 실행할 때 시스템의 리소스를 분리해서 실행할 수 있도록 도와주는 기능 - 한 덩어리의 데이터에 이름을 붙혀 충돌 가능성 줄이고, 쉽게 참조하는 개념 - PID namespace - Network namespace - UID namespace - Mount namespace - UTS namespace - IPC namespace - overlay network등 네트워크 가상화 기술 활용 - overlay network: 물리 네트워크 위에 성립되는 가상의 컴퓨터 네트워크 - union file system으로 이식성, 비용절감 - ufs: 여러개의 파일 시스템을 라나의 파일 시스템에 마운트하는 기능 (나중에 마운트된 파일로 덮어쓰기) - 컨테이너에 필요한 커널은 호스트의 커널을 공유하여 사용하자! - 컨테이너 안에는 어플리케이션 구동에 "필요한 라이브러리와 실행파일"만 놔두자!

도커 - 컨테이너는 호스트 시스템의 커널을 사용 - 컨테이너는 이미지에 따라 실행되는 환경(파일 시스템)이 달라짐 - chroot를 활용하여 프로세스를 루트 파일 시스템으로 강제 인식시켜 프로세스 실행함 - 컨테이너도 결국 프로세스 - 도커 데몬의 역할 - 컨테이너 이미지 빌드, 관리, 공유, 실행 - 컨테이너 인스턴스 관리 - 모든 컨테이너를 자식 프로세스로 소유

도커 이미지 - 이미지: 파일들의 집합 - 컨테이너: 이미지들의 집합 위에서 실행된 특별한 프로세스 - 도커 이미지: [저장소이름]/[이미지이름]:[태그] - 도커는 여러 레이어를 합쳐 Union 파일 시스템을 이룸

도커 네트워크 - veth interface - 랜카드에 연결된 실제 네트워크 인터페이스 X - 가상으로 생성한 네트워크 인터페이스 O - 패킷 전달받으면 자신에게 연결된 다른 네트워크 인터페이스로 패킷 보내야해서 항상 pair로 생성할 것 - NET namespace - 리눅스 격리 기술인 namespace 중 네트워크와 관련된 부분 - 네트워크 인터페이스를 각각 다른 namespace에 할당함으로써, 서로가 서로를 모르게끔 설정할 수 있음 - 도커 네트워크 구조 1. 컨테이너는 namespace로 격리, 통신을 위한 네트워크 인터페이스(eth0)를 할당받음 2. host의 veth interface가 생성되고 컨테이너 내의 eth0와 연결 3. host의 veth interface는 docker0라는 다른 veth interface와 연결
- docker-compose로 띄우면 다른 네트워크 대역을 가짐 - docker-compose로 컨테이너 띄우면 compose로 묶은 범위에 맞춰 브릿지 하나 더 생성함 - 서로 경유하는 브릿지가 다르기에 docker-compose로 띄운 컨테이너와 일반 컨테이너 통신 X

도커 볼륨 - 도커 이미지로 컨테이너 생성 -> 이미지는 "읽기 전용" - 컨테이너 데이터를 영속적인 데이터로 활용하기 위한 방법 == 볼륨을 활용하자! - -v 옵션을 통해 호스트 디렉터리를 컨테이너 디렉터리에 마운트 - 컨테이너의 해당경로에 파일이 있다면 호스트의 볼륨으로 덮어씌워짐 - 컨테이너가 아닌 외부에 데이터를 저장하고, 컨테이너는 그 데이터로 동작하도록 설계하자! - "컨테이너 자체는 상태가 읎고! 상태 결정하는 데이터는 외부로 부터 제공받도록 구성하자!"