리눅스 기반 컨테이너 격리 기술 (chroot, Namespace, cGroups, Union Filesystem)

 

 

 

 

사용환경

- Azure VM

- Ubuntu 22.04 / 30GM / vCPU 2

 

 

컨테이너 기반 기술

 

클라우드 시대, 특히 컨테이너 기반의 애플리케이션 운영에서는 "어디서나 똑같이 동작하는 가벼운 실행 환경"이 핵심이다.
하지만 ‘가볍다’는 말은 기술적으론 다음 두 가지를 의미한다:

• 운영체제를 통째로 복사하지 않는다. → 가상머신(VM)과의 가장 큰 차이
• 자원과 환경을 격리한다. → 여러 앱이 충돌 없이 같은 OS 위에서 돌아갈 수 있게 함

이걸 가능하게 해주는 리눅스 커널 기술이 바로 아래와 같다

 

1. chroot

2. Namespace

3. cGroups

4. Union filesystem

 

 

 

1. chroot

chroot : 리눅스에서 제공하는 파일 시스템 격리 기술

• 특정 디렉토리를 루트(/)로 간주하게 함
• 목적: 프로세스가 시스템의 나머지 영역에 접근 못 하도록 격리

실습 요점: bash 쉘을 /root/newroot를 루트 디렉토리처럼 인식하게 실행
→ chroot /root/newroot /bin/bash

 

 

1단계: chroot 설치 확인 및 기본 디렉토리 구조 만들기

# chroot 명령어 확인
chroot --version

# 격리 환경 디렉토리 생성
mkdir -p newroot/{bin,lib,lib64}

# 트리 구조 확인 도구 설치
apt update
apt install -y tree
tree newroot

 

 

2단계: 첫 시도 – 실패 (그리고 이유)

# 격리된 환경에서 bash 실행 시도
chroot newroot /bin/bash
# => 실패: No such file or directory

 

🧠 원인: 단순히 /bin/bash 실행파일만 있다고 되는 게 아님
bash는 실행될 때 필요한 동적 라이브러리들을 로딩해야 하기 때문

 

 

3단계: 의존 라이브러리 복사

# bash 실행파일 복사
cp /bin/bash newroot/bin/

# 어떤 라이브러리를 필요로 하는지 확인
ldd /bin/bash
  =>    linux-vdso.so.1 (0x00007ffd8957e000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007eab997ce000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eab99400000)
        /lib64/ld-linux-x86-64.so.2 (0x00007eab99969000)


# 라이브러리 디렉토리 생성
mkdir -p newroot/lib/x86_64-linux-gnu
mkdir -p newroot/lib64

# 필요한 라이브러리 복사
cp /lib/x86_64-linux-gnu/libtinfo.so.6 newroot/lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libc.so.6     newroot/lib/x86_64-linux-gnu/
cp /lib64/ld-linux-x86-64.so.2         newroot/lib64/

 

여기까지 하면, 최소한 bash가 실행될 수 있는 최소 실행 환경이 갖춰진다

아래는 트리 구조

root@master:~# tree
newroot
├── bin
│   └── bash
├── lib
│   └── x86_64-linux-gnu
│       ├── libc.so.6
│       └── libtinfo.so.6
└── lib64
    └── ld-linux-x86-64.so.2

 

 

 

4단계: chroot 재시도 – 성공

root@master:~# chroot newroot /bin/bash
bash-5.1#

 

위의 화면처럼 bash로 접속되면 chroot 정상 작동

 

bash-5.1# pwd
/
bash-5.1# ls
bash: ls: command not found

 

위치를 확인해보면 /, 루트에 위치함

/bin/bash/ 만 복사했기에 ls와 같은 명령어는 격리된 루트에서 실행되지 않는다

위와 같은 방법대로 참조한 라이브러리들을 복사하면 실행 가능하다

 

bash-5.1# exit
exit
root@master:~#

 

exit를 실행하면 원래 루트로 복귀

 

 

 

---

 

 

 

2. Namepace

Namespace : 프로세스와 자원을 격리

• 여러 종류가 있음: PID, UTS(hostname), NET, MNT, USER 등
• 목적: 하나의 리눅스 OS 안에서도 마치 여러 OS가 돌아가는 것처럼 격리

실습 요점: unshare --fork --pid --mount-proc /bin/sh
→ 이 쉘 안에선 내가 PID 1번 프로세스!

 

PID, UTS, NET Namepace 3가지 종류에 대해 실습 진행

 

 

 

PID Namespace

• 프로세스 ID (PID) 를 분리하여 관리한다
• 프로세스 ID 공간을 분리해서, 각 네임스페이스마다 PID 1번부터 독립적으로 시작할 수 있게 해준다.
• 즉, 하나의 시스템에서 서로 다른 PID를 가진 "작은 리눅스 환경"을 만들 수 있다.

# 현재 쉘의 PID 확인
echo $$

# 새로운 PID 네임스페이스 생성 + /proc 마운트
unshare --fork --pid --mount-proc=/proc /bin/sh

 

• unshare --fork --pid --mount-proc=/proc /bin/sh
• 이 명령어는 현재 쉘로부터 분리된 새로운 PID 네임스페이스를 만들고,
  그 안에서 별도로 /proc 파일시스템을 마운트한 상태로 새 쉘을 실행하는 것

옵션	의미
--pid	새로운 PID 네임스페이스 생성
--fork	자식 프로세스로 새로운 쉘을 실행 (현재 쉘은 그대로 유지)
--mount-proc=/proc	새로운 /proc 파일시스템 마운트 (PID 네임스페이스에 맞게)
/bin/sh	실행할 쉘 프로세스

 

 

 

실제로 실행해보면

root@master:~# echo $$
16818
root@master:~# unshare --fork --pid  --mount-proc=/proc /bin/sh
# ps
    PID TTY          TIME CMD
      1 pts/1    00:00:00 sh
      2 pts/1    00:00:00 ps

 

🎯 이게 핵심!
sh 프로세스가 PID 1번, ps는 2번이다.
마치 이 안에서 내가 "리눅스를 부팅해서 최초로 실행된 프로세스"처럼 보인다.
실제 시스템에선 이 프로세스가 PID 16818이었지만, 내부적으로는 완전히 다른 프로세스 ID 공간이 만들어진 것.

 

# exit
/bin/sh: 7: Cannot set tty process group (No such process)

 

마찬가지로 exit로 탈출 가능

 

 

 

 

 

 

 

UTS Namespace

호스트 이름(hostname) 과 도메인 이름을 격리하는 공간이다.
네임스페이스 안에서 시스템 이름을 바꿔도 다른 환경에선 영향을 받지 않는다.
즉, 하나의 리눅스에서 여러 개의 독립된 컴퓨터 이름을 가진 환경을 만들 수 있다.

 

해당 실습은 하나의 서버를 2개의 터미널(terminal1, 2) 로 띄우고 비교하며 진행한다

 

✅ 실습: 호스트 이름 격리 확인하기

# (두 개의 터미널 열기) 각각 terminal1, terminal2

# 각 터미널에서 현재 hostname 확인
uname -n
hostname
----
root@master:~# uname -n
master
root@master:~# hostname
master

 

→ 두 터미널 모두 같은 이름 출력됨 

 

 

✅ 이제 terminal1에서 새로운 UTS 네임스페이스 시작

unshare -u /bin/bash
hostname happy.life.com
-----
root@master:~# unshare -u /bin/bash
root@master:~# hostname happy.life.com
root@master:~# hostname
happy.life.com
root@master:~# uname -n
happy.life.com

 

→ 이 셸 내부에서는 hostname이 happy.life.com으로 바뀜.

 

🔎 결과 비교: 진짜 격리되었을까?

# terminal1 (새 네임스페이스 안)
hostname       # → happy.life.com
uname -n       # → happy.life.com

# terminal2 (기존 시스템 환경)
hostname       # → master
uname -n       # → master

 

같은 가상 머신에서 서로 다른 호스트네임을 출력하는 것을 확인할 수 있다

 

📂 내부 구조 확인 – /proc을 통해 네임스페이스 ID 비교

# terminal1
ls -l /proc/$$/ns/uts
# → uts:[4026532377]
---
root@master:~# uname -n
happy.life.com
root@master:~# ls -l /proc/$$/ns/uts
lrwxrwxrwx 1 root root 0 Jun 18 12:10 /proc/17039/ns/uts -> 'uts:[4026532377]'


# terminal2
ls -l /proc/$$/ns/uts
# → uts:[4026531838]
---
root@master:~# uname -n
master
root@master:~# ls -l /proc/$$/ns/uts
lrwxrwxrwx 1 root root 0 Jun 18 12:10 /proc/17024/ns/uts -> 'uts:[4026531838]'

 

uts:[숫자] 값이 다르다 → 서로 다른 UTS 네임스페이스에 있다는 증거

 

 

 

 

 

NET Namespace

 

NET 네임스페이스는 리눅스에서 네트워크 자원을 격리하는 핵심 기술로, 다음과 같은 특징을 가진다:

• 각 네임스페이스마다 고유한 인터페이스와 IP 구성을 갖는다
  → 서로 다른 컨테이너는 독립된 네트워크 공간에서 동작한다
• 동일한 포트를 동시에 바인딩해도 충돌이 없다
  → 각 네임스페이스 안에서 포트가 독립적으로 관리되기 때문
• 라우팅 테이블, 방화벽 규칙(iptables), 네트워크 장치 등도 완전히 분리된다
  → 하나의 시스템이 여러 네트워크를 동시에 갖는 것처럼 구성 가능

실습 목표

• 새로운 네트워크 네임스페이스(guestnet)를 만들고
• 기본 네임스페이스(default)와 veth 페어 인터페이스로 연결
• 각 인터페이스에 IP를 할당한 뒤, 서로 ping 통신이 가능한지 확인해본다

 

아래 참고하면 좋은 내용들

https://devocean.sk.com/blog/techBoardDetail.do?ID=163803

10분만에 이해하는 컨테이너 네트워크

 

https://80000coding.oopy.io/a6a43912-cd6e-485e-9031-fbc3969aa335

리눅스 네트워크 네임스페이스 살펴보기

 

https://malwareanalysis.tistory.com/249

쿠버네티스 네트워크 스터디 1주차 2편: 네트워크 네임스페이스

 

 

 

 

 

✅ Step 1. 네임스페이스 생성 및 loopback 활성화

# 새로운 NET 네임스페이스 guestnet 생성
ip netns add guestnet

# 내부 loopback 인터페이스 활성화
ip netns exec guestnet ip link
ip netns exec guestnet ip link set lo up

 

root@master:~# ip netns exec guestnet ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
root@master:~# ip netns exec guestnet ip link set lo up
root@master:~# ip netns exec guestnet ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

 

lo: <LOOPBACK> => lo: <LOOPBACK,UP,LOWER_UP>

lo는 기본적으로 down 상태이므로 수동으로 올려줘야 함

 

 

✅ Step 2. veth 페어 인터페이스 생성 및 분리

 

인터페이스	네임스페이스
host	default
guest	guestnet

 

# veth 페어 생성: host <-> guest
ip link add host type veth peer name guest

# guest 인터페이스를 guestnet 네임스페이스로 이동
ip link set guest netns guestnet

# 확인
ip link                                # guest 사라짐 → 이동됨
ip netns exec guestnet ip link         # guest 등장

 

 

 

실행 결과

root@master:~# ip link add host type veth peer name guest
root@master:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:22:48:05:3f:0d brd ff:ff:ff:ff:ff:ff
3: enP61412s1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:22:48:05:3f:0d brd ff:ff:ff:ff:ff:ff
    altname enP61412p0s2
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 1a:58:0f:2f:2a:b0 brd ff:ff:ff:ff:ff:ff
29: veth97b1361@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 6a:00:54:d9:dc:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
30: veth2729f05@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 8e:bf:84:65:34:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
33: veth3dc75bf@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 86:79:fa:e7:a4:2c brd ff:ff:ff:ff:ff:ff link-netnsid 2
34: guest@host: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether f6:87:fa:a4:91:bb brd ff:ff:ff:ff:ff:ff
35: host@guest: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 26:4c:e4:cd:ee:c3 brd ff:ff:ff:ff:ff:ff

 

34: guest@host:...

35: host@guest:...

이렇게 host <-> guest 간의 veth 페어 생성 확인

 

root@master:~# ip link set guest netns guestnet
root@master:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:22:48:05:3f:0d brd ff:ff:ff:ff:ff:ff
3: enP61412s1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:22:48:05:3f:0d brd ff:ff:ff:ff:ff:ff
    altname enP61412p0s2
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 1a:58:0f:2f:2a:b0 brd ff:ff:ff:ff:ff:ff
29: veth97b1361@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 6a:00:54:d9:dc:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
30: veth2729f05@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 8e:bf:84:65:34:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
33: veth3dc75bf@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 86:79:fa:e7:a4:2c brd ff:ff:ff:ff:ff:ff link-netnsid 2
35: host@if34: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 26:4c:e4:cd:ee:c3 brd ff:ff:ff:ff:ff:ff link-netns guestnet

 

guest를 새로 생성한 guestnet으로 이동시켰더니

• 위에는 있었던 34: guest@host:... 가 사라짐 => 기본 네임스페이스(default)에서는 guest 인터페이스가 사라진다
• guestnet 네임스페이스 내부로 들어가서 확인하면, 그 안에 guest 인터페이스가 생긴다.
• default 쪽에 남은 host 인터페이스는 이렇게 바뀐다:
  • 35: host@guest:... => 35: host@if34:... 
  • 여기서 if34는 guest 인터페이스가 이전에 쓰던 인터페이스 인덱스를 의미한다.
  • host는 여전히 guest와 연결되어 있지만, 이제 그 연결 상대는 guestnet이라는 다른 네임스페이스 안에 존재하는 것이다.

 

 

 

 

✅ Step 3. 각 인터페이스에 IP 주소 할당

 

host(veth) IP (2.2.2.1/24) 할당

# default 네임스페이스 (host)
ip link set host up
ip address add 2.2.2.1/24 dev host
---
root@master:~# ip link set host up
root@master:~# ip address add 2.2.2.1/24 dev host
root@master:~# ip address show dev host
35: host@if34: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether 26:4c:e4:cd:ee:c3 brd ff:ff:ff:ff:ff:ff link-netns guestnet
    inet 2.2.2.1/24 scope global host
       valid_lft forever preferred_lft forever

 

 

 

guest (veth) IP (2.2.2.2/24) 할당

# guestnet 네임스페이스 (guest)
ip netns exec guestnet ip link set guest up
ip netns exec guestnet ip address add 2.2.2.2/24 dev guest
---
root@master:~# ip netns exec guestnet ip link set guest up
root@master:~# ip netns exec guestnet ip address add 2.2.2.2/24 dev guest
root@master:~# ip netns exec guestnet ip address show dev guest
34: guest@if35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f6:87:fa:a4:91:bb brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 2.2.2.2/24 scope global guest
       valid_lft forever preferred_lft forever
    inet6 fe80::f487:faff:fea4:91bb/64 scope link
       valid_lft forever preferred_lft forever

 

 

여기까지 진행한다면 아래와 같은 구조를 갖게 된다

[ default namespace ]                    [ guestnet namespace ]
-----------------------                  -----------------------
|                     |                  |                     |
|     host (veth)     | <==============> |    guest (veth)     |
|   IP: 2.2.2.1/24    |    veth pair     |  IP: 2.2.2.2/24     |
|                     |                  |                     |
-----------------------                  -----------------------

 

 

✅ Step 4. 네임스페이스 간 통신 테스트

# default → guestnet
ping 2.2.2.2

# guestnet → default
ip netns exec guestnet ping 2.2.2.1

 

root@master:~# ping 2.2.2.2
PING 2.2.2.2 (2.2.2.2) 56(84) bytes of data.
64 bytes from 2.2.2.2: icmp_seq=1 ttl=64 time=0.112 ms
64 bytes from 2.2.2.2: icmp_seq=2 ttl=64 time=0.057 ms
64 bytes from 2.2.2.2: icmp_seq=3 ttl=64 time=0.102 ms
64 bytes from 2.2.2.2: icmp_seq=4 ttl=64 time=0.066 ms
64 bytes from 2.2.2.2: icmp_seq=5 ttl=64 time=0.058 ms
--- 2.2.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4131ms
rtt min/avg/max/mdev = 0.057/0.079/0.112/0.023 ms


root@master:~# ip netns exec guestnet ping 2.2.2.1
PING 2.2.2.1 (2.2.2.1) 56(84) bytes of data.
64 bytes from 2.2.2.1: icmp_seq=1 ttl=64 time=0.063 ms
64 bytes from 2.2.2.1: icmp_seq=2 ttl=64 time=0.078 ms
64 bytes from 2.2.2.1: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 2.2.2.1: icmp_seq=4 ttl=64 time=0.081 ms
64 bytes from 2.2.2.1: icmp_seq=5 ttl=64 time=0.061 ms
--- 2.2.2.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4133ms
rtt min/avg/max/mdev = 0.061/0.069/0.081/0.008 ms

 

 

✅ 결과: 서로 다른 네임스페이스에 있으면서도 veth로 연결되었기 때문에 통신 가능!

 

 

 

 

 

---

 

 

 

 

3. cGropus

 

cgroups: 자원(CPU, 메모리 등)을 제한하고 할당

• 리눅스 커널이 제공하는 기능으로, 특정 프로세스(또는 그룹)가 CPU, 메모리, 네트워크, 디스크 등을 얼마나 사용할지 제한하거나 모니터링할 수 있다.
• 목적: 어떤 컨테이너가 자원을 독식하지 못하게 막음.
• 서버 자원을 누가 얼마나 쓸 수 있는지 정해주는 관리자 도구로, CPU 사용률, 메모리 제한 등을 설정 가능

 

구조는 어떻게 생겼나?

• /sys/fs/cgroup 아래에 폴더처럼 계층 구조로 구성되어 있다
• 이 폴더 구조 안의 설정 파일들을 수정해서 자원을 제어함
• 부모 그룹이 설정한 자원 제한을 자식 그룹이 물려받을 수 있음 (상속 구조)

 

cGroup을 제어하는 방법

 

1. 직접 파일 수정 (VFS 방식)

1. 디렉토리 만들고, 설정 파일 편집
2. 예: echo "50000 100000" > cpu.max

2. 도구 사용

• Ubuntu: cgroup-bin
• RHEL: libcgroup
• → 명령어 기반으로 자원 할당 및 그룹 구성 가능

실습은 직접 파일 수정하여 진행

 

 

 

 

✅ Step 1. CPU를 무한히 사용하는 프로그램 만들기

 

# 업데이트
apt update
apt install -y gcc

 

# vim으로 a.c 파일 생성 및 아래 코드 추가
vi a.c

# C 코드 작성 (a.c)
void main() {
  for(;;);
}

 

# 컴파일 후 실행 (백그라운드로)
gcc a.c
./a.out &

 

 

 

a.c 컴파일 후 a.out 이라는 파일 생성된다

이 파일을 실행시키고 다른 터미널에서 top으로 CPU 사용량을 체크해보면  a.out이 100%를 차지하는 것을 확인할 수 있다

 

 

 

✅ Step 2. cGroup 디렉토리 생성 및 진입

 

sudo mkdir /sys/fs/cgroup/mygroup
cd /sys/fs/cgroup/mygroup

 

mygroup, 이 디렉토리는 우리가 관리할 "자원 그룹"이라고 보면 된다
이 안에 설정 파일을 넣어서 제한 조건을 직접 걸 수 있다

 

 

 

 

 

부모 그룹이 설정한 자원 제한을 자식 그룹이 물려받을 수 있음 (상속 구조)

➡️ 생성된 mygroup에 들어가보면 빈 디렉토리가 아닌 많은 파일들이 존재하는데 이는 /sys/fs/cgroup 의 파일들을 상속받았기 떄문이다

cgroup아래에 있는 디렉토리들의 파일들까지 다 가져오기 때문에 cgroup 보다 파일들이 좀 더 많아보인다

 

 

 

 

✅ Step 3. CPU 사용량 제한 설정

# CPU 제한 설정: 100ms 주기 중 50ms만 실행 가능 (즉, 50% 제한)
echo "50000 100000" | sudo tee cpu.max

 

 

설정 항목	의미
50000	사용할 수 있는 시간 (microsecond 단위, 50ms)
100000	전체 주기 (100ms) → 따라서 50% 사용 제한

 

 

 

 

 

✅ Step 4. 프로세스를 cGroup에 등록

# a.out의 PID를 해당 그룹에 등록
echo $(pgrep a.out) | sudo tee cgroup.procs

 

이 순간부터 해당 프로세스는 cpu.max에서 정의한 제약 조건의 적용을 받는다

 

 

실행 결과

root@master:/sys/fs/cgroup/mygroup# echo "50000 100000" | sudo tee cpu.max
50000 100000
root@master:/sys/fs/cgroup/mygroup# echo $(pgrep a.out) | sudo tee cgroup.procs
17453

 

 

이전에 100%로 사용되던 CPU 사용량이 50%로 제한된 것을 확인할 수 있다

 

 

 

✅ cgroup 설정을 기본값(제한 없음)으로 되돌리는 방법

 

기본값으로 되돌리기

# 무제한으로 설정
echo "max 100000" | sudo tee cpu.max

 

 

그룹 해제 (프로세스를 그룹에서 빼내기)

# 해당 PID를 다른 그룹(cgroup.procs)으로 이동
# 예: root 디폴트 그룹으로 이동
echo <PID> | sudo tee /sys/fs/cgroup/cgroup.procs

 

 

cgroup 디렉토리 삭제 (주의 필요)

cd /sys/fs/cgroup
sudo rmdir mygroup

 

 

 

 

 

 

---

 

 

 

 

4. Union Filesystem

Union Filesystem: 레이어로 쌓아 효율적 이미지 구성

• 이미지들을 레이어로 관리 → 중복 저장 없음
• 대표적으로 AUFS, OverlayFS 사용

실습 요점: overlayfs를 직접 mount 해서 여러 이미지 레이어 결합하는 방식 확인

 

 

실습 목표

• OverlayFS로 다중 이미지 레이어를 병합해서 가상의 통합 디렉토리를 만들고,
• 그 안에서 파일 삭제/추가가 어떻게 동작하는지를 확인한다.

 

 

✅ Step 1.  실습 환경 구성

# 실습 디렉토리 생성
mkdir overlayfs && cd overlayfs
mkdir container image1 image2 work merge

# 각각의 레이어에 파일 생성
touch image1/{a,b} image2/c
---
├── container
├── image1
│   ├── a
│   └── b
├── image2
│   └── c
├── merge
└── work

 

 

디렉토리	용도
image1, image2	읽기 전용 이미지 계층 (lower)
container	쓰기 가능한 upper layer
work	OverlayFS 동작을 위한 워크 디렉토리
merge	우리가 접근할 통합 디렉토리 (mount point)

 

 

✅ Step 2.  OverlayFS 마운트

mount -t overlay overlay \
-o lowerdir=image2:image1,upperdir=container,workdir=work \
merge

 

🔍 설명:

• lowerdir = image2:image1 → 이미지1 위에 이미지2가 얹힌 구조
• upperdir = container → 쓰기 레이어. 변경은 여기에 저장
• workdir = work → 내부적으로 OverlayFS가 사용하는 임시 저장소
• 결과적으로 merge 디렉토리를 보면, 3개 레이어가 합쳐진 하나의 파일시스템처럼 보임

Filesystem	1K-blocks	Used	Available	Use%	Mounted on
overlay	30298176	2998448	27283344	10%	/root/overlayfs/merge

 

 

 

✅ Step 3.  결과 확인

tree
├── container
├── image1
│   ├── a
│   └── b
├── image2
│   └── c
├── merge
│   ├── a
│   ├── b
│   └── c
└── work
    └── work

 

➡️ merge에는 a, b, c가 모두 보임 → 레이어 병합 성공

 

 

 

 

✅ Step 4.  파일 삭제 및 추가 실습

rm merge/a
touch merge/d
tree . -I work
---
├── container
│   ├── a
│   └── d
├── image1
│   ├── a
│   └── b
├── image2
│   └── c
└── merge
    ├── b
    ├── c
    └── d