[Docker] 1. history chroot container

happy_quokka·2023년 12월 11일
docker
0

Docker

목록 보기
1/7

chroot

  • change root directory
  • root dir.를 특정 디렉토리로 변경
  • UNIX command 및 system call(c언어 함수)로 존재

초기 chroot의 사용(SVr4)

  • system 설치 및 복구 등의 시스템 부팅 및 관련 과정에서 사용
  • 부수적으로 jail(가두는) 기능을 가지고 있다
    • FreeBSD의 경우 jail system call을 개발하기도 했다

작동 방법

  • / : root directory
  • chroot /mnt/chroot 명령어 : root directory가 /mnt/chroot로 변경
  • 이 기능을 통해 각자 private mount layout을 가질 수 있다

chroot의 부수적 기능

보안적 측면의 격리

  • chroot를 통해 기초적인 격리를 할 수 있다
  • sandbox의 개념 (격리된 공간의 타입 의미)
    • 보안적 측면, 특수한 목적을 위해 격리된 형태의 공간을 필요로 할 때 사용
    • 개념적인 부분으로 구현체는 아니다
    • 하지만 구현체 중에 sandbox라는 이름이 실제 존재 -> UNIX의 fifo named pipe가 fifo의 개념과 이름만 같다
  • chroot로 격리된 directory hierarchy를 통해 경로를 속일 수 있다
    • 동일한 프로그램을 쉽게 다른 환경으로 복제할 수 있다는 사실

Practice : chroot, filezilla

준비 작업

  1. ftp 서비스를 제공하는 vsftpd 설치
$ sudo apt -y install vsftpd
  1. 설치 후 서비스가 running 되었는지 확인하고 running이 아니라면 start
$ sudo systemctl is-active vsftpd

결과로 active가 안나오면
$ sudo systemctl start vsftpd
  1. ftp 클라이언트 프로그램인 filezilla 설치 후 실행
$ sudo apt -y install filezilla
$ filezilla

  1. filezilla로 접속 후 HOME directory 확인 (확인 후 접속 끊기)
  1. 설정 변경 (chroot 켜주기)
$ sudo vi etc/vsftpd.conf

해당파일에 아래의 내용 추가
chroot_local_user=YES
allow_writeable_chroot=YES
  1. 설정 저장 후 vsftpd 재시작
$ sudo systemctl restart vsftpd
$ sudo systemctl status vsftpd
  1. filezilla 재접속 후 HOME directory 확인

Isolation

격리의 필요성

  • 시스템 내에 존재하는 자원은 한정적
  • 한정적인 자원을 효율적으로 분배하면 시스템의 가용성을 올릴 수 있다

process의 scope

  • 현대적인 OS는 프로세스가 독립적인 공간을 가지게 해준다
  • 장점 : 프로세스는 고유한 공간을 받을 수 있다
  • 단점
    • 외부 통신을 위해서 IPC를 사용하여 I/O 비용 증가
    • 여러 프로세스가 협동해야하는 프로그램에서는 단점이 더 커진다 (DBMS, server system의 경우)

Isolation의 활용

1. 보안, 자원 관리적 측면

  • 특정 파일 경로의 접근을 제한 (특정 시스템 자원의 사용 제한)
  • 예를 들어 FTP 프로세스가 /home/ftp 디렉터리 이하에서는 이동할 수 있도록 하고 싶다 -> chroot
  • 호스팅 업체라면 고성능 컴퓨터 1대로 여러 사업자에게 DB나 웹 제공

2. 호환, 충돌 측면

  • 동일한 directory를 사용하는 프로세스는 독립된 실행을 어떻게?
  • 혹은 서로 다른 버전의 파일을 사용하는 프로세스가 있다면?
  • 이럴때 격리된 공간을 제공하면 문제가 해결된다

Name space

history

  • 분산 컴퓨팅 시스템으로서 local system, remote system을 hierarchical file system으로 표현
  • 특정 리소스의 사용은 계층화된 file name space를 가지는 것과 같다

Linux Namespace

  • Linux-specific 구현
    • isolated resource를 NS의 hierarchical file system 형태로 구현
  • 줄여서 NS로 표기하기도 한다

Linux Namespace

  • 7종류
    • mount : 디렉토리 관련
    • UTS* : unix time sharing, 유닉스 시분할 시스템
    • IPC : 장치 관련
    • network
    • PID
    • user
    • cgroup : 권한 관련
  • Linux Namespace 관리 명령어
    • unshare
    • lsns
    • nsenter

Practice : Namespace

  • NS의 기본 작동
  • unshare : 고유의 공간을 만들고 그 안에서 프로그램 실행
  • lsns : Namespace를 리스팅

unshare

  1. 프로세스 격리
$ unshare -pf --mount-proc /bin/bash
$ ps
$ exit
  • unshare로 격리된 프로세스를 만드는데 그 프로세스 이름은 bash
  • option
    • -p, --pid : pid 격리
    • -f, --fork : 자식 프로세스를 만들어서 실행
    • --mount-proc : proc 파일을 고유의 공간으로 가져온다 -> proc은 process control block(PCB) 가지고 있는데 이를 고유하게
  1. network 격리

listen하고 있는 것 확인
$ ss -nltp

5000번 포트를 listen
$ nc -l 5000 >nc_host_output.txt & 
4036은 host

$ ss -nltp

-n : network 격리
$ unshare -n /bin/bash

$ ps

$ ss -nlt
확이해보면 5000번 포트가 안나온다

$ nx -l 5000 >nc_ns_output.txt &
다시 점유할 수 있다

$ ss -nlt

lsns

  • unshare가 실행되는 터미널을 그대로 두고 터미널 하나 더 실행
$ lsns
시스템의 namespace가 쭉 나온다
  • unshare -pf --mount-proc /bin/bash 명령으로 NS를 만들면 --fork때문에 자식 프로세스 bash가 실행된다 -> NPROCS의 수가 1개에서 2개로 증가

container

cgroup (control group)

  • process container 였는데 cgroup으로 rename
  • group별로 가상화된 공간을 만들고 자원을 제약할 수 있게 되었다
  • 마치 물리적으로 다른 host처럼 인식
  • docker, hadoop, systemd 등의 많은 프로젝트들이 cgroup을 사용

docker

  • container runtime 기술
  • container를 세련된 방식으로 구현한 제품의 일종
  • 격리된 자원의 묶음(image)과 런타임으로 구성
    • 기본적으로 C/S 구조(client/server)를 가지므로 daemon(백그라운드에서 돌면서 여러 작업을 하는 프로그램)이 작동된다
  • host OS 위에서 작동하는 격리된 프로세스의 일종이므로 virtual machine과 달리 memory, file system의 I/O에서 발생하는 크리티컬한 overhead가 없다
    • 이 특징이 docker의 가장 큰 장점
    • host os의 튜닝이나 성능 향상은 docker에게도 향상을 가져다 주기 때문
  • 단점(보안, 안정성 측면)
    • daemon으로 작동하면서 child process로 수직 관리 : daemon이 문제가 생기면 아래의 모든 container가 죽을 수 있다
    • 관리자 권한 사용

container(docker) vs Hypervisor(virtual machine)

podman

  • alternative of linux container
  • docker가 가장 많이 쓰이고 있지만 단점과 상용화 문제로 인해 대안 요구
  • podman은 redhat에서 지원
  • daemon, admin account 사용하지 않는다
  • systemd unit support -> 서비스와 시킬 수 있다, 중앙 집중화가 잘 된다

future of container(20~21년 기준)

  • docker : 입지 불안, 구조적, 기술적 문제가 있지만 여전히 매력적인 기술
  • container 기술의 복잡성 증가

Virtualization

Virtual machine

  • virtual machine도 isolation의 일종
  • full virtualization(hypervisor) 사용
    • 소프트웨어로 가상화된 하드웨어를 구현
    • 완전히 격리된 공간 제공
    • 보안, 호환성 문제를 거의 대부분 해결
  • 단점
    • 낮은 성능! (절반 이하ㅠ)
    • 독점적인 자원 점유
    • host-guest간의 자원 교환의 어려움 및 비효율

H/W, OS, Application/VM/Hypervisor

  • os가 관리하는 h/w를 접근하는 방식 차이 : 직접 접근 vs 간접 접근
  • vm을 사용하면 오버헤드가 커지는 단점

sandbox

  • 격리된 모래 장난을 위한 공간의 개념 차용
  • 임시로 쓸수 있는 공간을 만들어 주는 것
  • 구현 : 다양한 방법 (vm, container, chroot)
  • 목적 : 테스트 유닛으로서 격리된 공간, 보안 공간, 복제된 서비스 공간..
  • sandbox를 더 경량화할 수 없을까? -> container
  • 단지 격리가 목적이라면 굳이 vm를 쓸 필요가 없다
    • lightweight container로 공유하는 부분은 공유하고 공유하지 않는 부분만 분리해서 만들자
  • 버전 충돌 문제 등의 여러 문제를 해결한다

summary

  • chroot는 root dir.를 변경
  • isolation할 수 있는 자원은 여러 종류, 즉 선택적이다
    • 이를 편리하게 해주는 것이 container
    • container는 기존의 namespace, cgroup, chroot 등을 결합한 기술
  • docker, podman 등은 container 구현체
    • container의 가장 큰 장점은 성능과 배포
    • vm 특히 full virtualization은 성능 문제가 심각
profile
happy_quokka
다음 포스트

[Docker] 2. 설치

0개의 댓글