0부터 시작하는 Docker 공부 - 컨테이너 기술 & Architecture life cycle

1. 컨테이너 기술

• OCI ( OPEN CONTAINER Initiative ) : 컨테이너 표준 기술. cgroup & namespace & chroot 에 대한 표준 제정

  

  • chroot : root 디렉터리를 변경해주는 것, 컨테이너 생성시 별도의 프로세스가 실행되며, 계정이 root 로 바뀐다. 즉, 일반 사용자가 컨테이너 내부로 들어갔을 경우 super user 인 root 로 작업할 수 있도록 해준다
  • namespace : 각각의 컨테이너 별로 작업 공간을 제공하고, 각 컨테이너 별로 서로 간에 영향을 끼치지 않도록 격리시켜 구획을 나눈다

    • linux namespace : 프로세스 별로 격리시켜 독립된 작업 공간 제공, 만약, httpd:ftp:nfs 프로세스로 구분을 한다면 두 개의 httpd 는 존재할 수 없다. 이미 하나의 httpd 가 설치되있기에 추가 설치가 불가능 하다
    • Docker namespace : 컨테이너 별로 격리시켜 독립된 작업 공간 제공, 컨테이너 ID 별로 구분하기에 각 컨테이너가 동일한 httpd 를 실행할 수 도 있다
    • K8s namespace : 각 사용자 별로 격리시켜 별도의 독립된 작업 공간 제공

  • cgroup : namespace 를 통해 구획이 나뉜 각 컨테이너 별로 별도의 자원 사용량을 제공하는 것 ( cpu , ram )

• CRI ( Container Runtime Interface ) : Kubelet 이 컨테이너를 제어할 수 있도록 해주는 인터페이스

• 쿠버네티스 : 컨테이너 오케스트레이션 툴, 일반적으로 오케스트레이션은 컨테이너 클러스터 환경에서 이루어지게 한다

  • 쿠버네티스는 컨테이너나 서비스를 직접 만드는 도구는 아니다. 쿠버네티스는 컨테이너 / 네트워크 / 볼륨 등을 관리 ( 오케스트레이션 ) 하는 도구이다. 실제 컨테이너를 만드는 역활은 runtime 이 수행하게 된다. 이 runtime 으로 docker ( containerd ) , cri-o , podman , rocket 등등을 사용할 수 있고, 쿠버네티스는 모든 런타임과 통신이 가능하다. 이로인해 사실상 컨테이너 오케스트레이션의 표준으로 불린다

2. 배포와 프로비저닝

• 애플리케이션은 배포 , 시스템 ( 서버, 네트워크, 볼륨 ) 은 프로비저닝 한다

• 배포와 프로비저닝은 일반적으로 여러 컨테이너, 서버, 네트워크, 볼륨 등을 연계하여 구성 해야 하는 복잡한 과정이다. 하나의 작업을 수동으로 한 뒤, 이를 묶는 작업은 복잡하므로, IaC ( Infrastructure as Code - 코드형 인프라 ) 을 도입하여 yml 과 같은 파일 형태로 작성한 뒤, 이를 활용하여 환경을 구성하는 형식으로 변화하고 있다

  • Docker-Compose.yml : 컨테이너 환경 구성
  • cloudformation : aws 에서 서버 인프라 환경 구성
  • heat : openstack 에서 서버 인프라 환경 구성
  • terraform

3. Docker 의 Architecture life cycle

1. 도커 클라이언트에서 명령 입력
2. 명령은 api 를 통해서 도커 서버 ( dockerd 프로세스로 작동하며 이를 도커 데몬이라고 함 ) 에 전달
3. 도커 데몬 ( 컨테이너 엔진 ) 을 통해 명령 실행. 도커 데몬은 실제 작업을 하는 것이 아닌, 밑에 containerd 에 전달한다
4. containerd 에서 컨테이너 관리, 컨테이너의 시작 등 실제 작업을 한다
5. containerd 는 작업을 위한 자식 프로세스인 containerd shim 을 생성한다
6. containerd shim 은 runc 를 호출한다. 이 runc 는 컨테이너 생성을 위한 namespace, cgroup, 구동 까지 해준다. 작업이 끝나면 runc 는 종료된다. 이 runc 는 containerd shim 과 통신을 한다

• 컨테이너의 모든 통신은 shim 을 통해 이루어지게 되고, 해당 내용은 shim 에서 containerd 와 통신을 통해 관리된다. shim 은 컨테이너의 입출력, 로그를 containerd 에게 전달한다

4. 컨테이너와 이미지

• 컨테이너는 이미지로부터 배포된다. 이미지는 iso 파일과 같이 정적인 파일이다. 따라서, 추가 작성된 내용은 기본적으로 저장되지 않는다. 이를 해결하기 위해서는 별도의 볼륨을 사용 해야 한다

볼륨의 종류

1. nfs ( binding ) : Host 의 특정 디렉터리와 컨테이너의 특정 디렉터리를 mount ( /root/test:/var/www/html )
2. iscsi ( volume ) : 별도의 볼륨을 생성하고, 해당 볼륨을 컨테이너의 특정 디스크로 활용하는 방법 ( testvolume:/root - /root 는 /dev/sda3 와 같이 특정 파티션이 된다 )
3. tmpfs : Disk / Storage 의 특정 공간을 사용하는 것이 아니라, 메모리를 사용하는 방법으로, 속도가 빠른 대신 영구 보관은 불가능 하다

이미지의 저장 장소

• public registry : docker hub 로, 불특정 다수가 접속할 수 있는 공간
• private registry : 특정 사용자나 그룹 사용자가 접속할 수 있는 공간
• local registry : 도커 데몬이 동작하는 사용자 컴퓨터

컨테이너 생성 과정

1. 명령 실행시 local registry 에서 이미지 검색
2. 이미지가 없으면, 자동으로 public registry 에 연결, pull 명령 전달
3. public registry 에서 필요한 공식 이미지를 검색
4. 해당 공식 이미지를 local registry 에 pull 을 통해 가져온다
5. 가져온 이미지를 통해 컨테이너 생성

5. 컨테이너의 종류

os 컨테이너

• ex) centos, fedora, ubuntu ...

애플리케이션 컨테이너

• ex) httpd, node, python ...