Containers from Scratch: A Deep Dive into Single-Host Container Networking
Learn How Single-Host Container Networking Works at the Underlying Layer
This article was orginally published on zawzaw.blog.
ဒီဆောင်းပါးမှာ Container တွေ အောက်ခြေမှာ ဘယ်လိုအလုပ်လုပ်လဲ၊ Container တွေ တခုနဲ့တခု Network Layer မှာ ဘယ်လိုဆက်သွယ်လဲဆိုတာ အခြေခံသဘောတရားတွေကို လက်တွေ့ကျကျ လေ့လာရမှာ ဖြစ်ပါတယ်။ လက်တွေ့စမ်းကြည့်လို့လည်း ရနိုင်ပါတယ်။ Linux မှာ အလွယ်တကူရတဲ့ Command-line Tools နဲ့ စမ်းသပ်ထားပါတယ်။ ဒီဆောင်းပါကို ဖက်ပြီး စမ်းကြည့်ပြီးရင်တော့ Docker ရဲ့ Bridge Networking ကို ကောင်းကောင်းနားလည်သွားပါလိမ့်မယ်။
Summary: Key Points
ခေတ်သစ် Containerization နည်းပညာရဲ့ အခြေခံအုတ်မြစ်ဖြစ်သော Linux Namespaces အကြောင်း။
Linux Namespaces ဘယ်လိုအလုပ်လုပ်ပြီး Container တွေ Host Machine ကနေ ဘယ်လို သီးခြားခွဲထုတ်ပြီး တည်ဆောက်လို့ရသလဲ။
Virtual Ethernet (VETH) နှင့် Bridge Networking ဘယ်လို အလုပ်လုပ်သလဲ။
Containers နှင့် Container Networking ရဲ့ အခြေခံအဆင့် (low level) တွင် မည်သို့အလုပ်လုပ်သလဲဆိုတာ ဒီဆောင်းပါးမှာ အဓိကလေ့လာရမှာ ဖြစ်ပါတယ်။
Prerequisities
Linux Host (e.g., Ubuntu, Fedora, etc..)
Linux Namespaces
Command-Line Tools
chroot,unshare,ip
Setup Project Structure
ပထမဦးဆုံးအနေနဲ့ Container တွေ ဘယ်လိုအလုပ်လုပ်လဲ ဆိုတာကို နားလည်နိုင်ဖို့အတွက် chroot နှင့် unshare CLI tools များကို အသုံးပြုပြီး Container များကို အစကနေ တည်ဆောက်ပြီး run ကြည့်ပါမယ်။
Project Structure သည် အောက်ပါအတိုင်း ဖြစ်ပါလိမ့်မယ်။
/home/zawzaw/containers
├── alpine-linux
│ ├── bin
│ ├── dev
│ ├── etc
│ ├── home
│ ├── lib
│ ├── media
│ ├── mnt
│ ├── opt
│ ├── proc
│ ├── root
│ ├── run
│ ├── sbin
│ ├── srv
│ ├── sys
│ ├── tmp
│ ├── usr
│ └── var
└── tiny-linux
├── bin
├── dev
├── proc
├── sbin
├── sys
└── usr
Containers လို့ အမည်ပေးထားတဲ့ Project directory တစ်ခုဆောက်လိုက်ပါမယ်။ အဲဒီနောက် Alpine Linux Root Filesystem image ကို အဲဒီ directory ထဲကို ထည့်လိုက်မှာ ဖြစ်ပါတယ်။
$ mkdir -p containers/alpine-linux
ဒီဆောင်းပါးမှာ Alpine Linux Mini root filesystem ကို အသုံးပြုမှာ ဖြစ်ပါတယ်။ Alpine Linux ရဲ့ Official website ဖြစ်တဲ့ https://alpinelinux.org/downloads သို့သွားရောက်ပြီး Alpine Linux Mini root filesystem ကို download လုပ်လိုက်ပါ။ Alpine Linux က Container များနှင့် Minimal chroots များမှာ အသုံးပြုဖို့အတွက် Alpine Mini root filesystem ကို ထောက်ပံ့ပေးထးပါတယ်။ aarch64, armv7, riscv64, x86, x86_64 စသည်ဖြင့် မတူညီသော System architectures များကို ထောက်ပံ့ပေးပါတယ်။
(သို့မဟုတ်)
curl command line tool ဖြင့် download လုပ်နိုင်ပါတယ်။ ဥပမာ - x86_64 architecture အတွက်။
$ curl -LO https://dl-cdn.alpinelinux.org/alpine/v3.21/releases/x86_64/alpine-minirootfs-3.21.3-x86_64.tar.gz
Download လုပ်ထားသော Alpine Linux Mini rootfs file ကို containers/alpine-linux directory အောက်သို့ထည့်ပြီးနောက် mini rootfs tar file ကို ဖြည်ပါ။
$ cp alpine-minirootfs-3.21.3-x86_64.tar.gz ~/containers/alpine-linux
$ cd ~/containers/alpine-linux
$ tar -xzvf alpine-minirootfs-3.21.3-x86_64.tar.gz
ဖြည်ပြီးရင်တော့ alpine-minirootfs-3.21.3-x86_64.tar.gz tar file ကို ဖျတ်လိုက်လို့ ရပါပြီ။
$ rm alpine-minirootfs-3.20.2-x86_64.tar.gz
Project တည်ဆောက်ပုံက အောက်ပါပုံစံအတိုင်း ဖြစ်ပါလိမ့်မယ်။
/home/zawzaw/containers
├── alpine-linux
│ ├── bin
│ ├── dev
│ ├── etc
│ ├── home
│ ├── lib
│ ├── media
│ ├── mnt
│ ├── opt
│ ├── proc
│ ├── root
│ ├── run
│ ├── sbin
│ ├── srv
│ ├── sys
│ ├── tmp
│ ├── usr
│ └── var
Running Containers from Scratch
Introduction to Chroot
/ (Host Root Filesystem)
├── bin
├── dev
├── etc
├── home
│ └── zawzaw/
│ └── containers/
│ ├── alpine-linux/
│ │ ├── bin
│ │ ├── dev
│ │ ├── etc
│ │ ├── home
│ │ ├── lib
│ │ ├── proc
│ │ ├── sbin
│ │ └── var
│ └── tiny-linux/
│ ├── bin
│ ├── dev
│ ├── init.sh
│ ├── linuxrc -> bin/busybox
│ ├── proc
│ ├── sbin
│ ├── sys
│ ├── sbin
│ └── usr
├── proc
├── sbin
├── sys
├── usr
└── var
Change Root (chroot) က Unix နဲ့ Linux မှာ အလွယ်တကူ အသုံးပြုနိုင်တယ်။ Container တခုကို Host OS ကနေ ဘယ်လိုခွဲထုတ်ပြီး တည်ဆောက်တာမလဲဆိုတာ မလေ့လာခင် chroot ကို အရင်လေ့လာကြည့်ပါမယ်။
chroot က Container တွေရဲ့ အခြေခံသဘောတရားတခုလို့လည်း ဆိုနိုင်တယ်။ သမိုင်းကြောင်းအရ မူရင်း chroot system call က ၁၉၇၉ ခုနှစ်မှာ ထွက်ရှိခဲ့တဲ့ Unix Seventh Edition (Version 7) မှာ စတင်မိတ်ဆက်ခဲ့တာ ဖြစ်ပါတယ်။ Linux system တခုမှာ အဓိက Root filesystem တခုရှိပြီး၊ လက်ရှိအလုပ်လုပ်နေတဲ့ process နဲ့ သူ့ရဲ့ child process တွေအတွက် Root directory ကို ပြောင်းလဲပေးတဲ့ လုပ်ဆောင်ချက်တစ်မျိုး ဖြစ်ပါတယ်။ အဲဒီသီးခြား Root filesystem ထဲမှာ ကိုယ်စမ်းသပ်ချင်တာတွေ လုပ်ဆောင်လို့ရနိုင်တယ်။
ဒါပေမယ့် chroot client tool က Linux kernel ကနေ ထောက်ပံ့တဲ့ chroot(2) system call ကို ခေါ်ယူပြီး အသုံးပြုတာ ဖြစ်ပါတယ်။ ဒါကြောင့် chroot က နောက်ဘက်က Linux kernel ရဲ့ ထောက်ပံ့မှုပေါ်မှာ မူတည်ပါတယ်။
chroot ကို ဘယ်နေရာတွေမှာ သုံးနိုင်မလဲ ဆိုရင်
Sandboxing: Program တစ်ခုကို သတ်မှတ်ထားတဲ့ environment မှာပဲ အလုပ်လုပ်စေပြီး System တစ်ခုလုံးကို ထိခိုက်မှုမရှိအောင် ကာကွယ်ပေးပါတယ်။
Recovery and Testing: System တစ်ခု ပျက်သွားတဲ့အခါ ပြန်လည်ပြင်ဆင်ဖို့ ဒါမှမဟုတ် Software အသစ်တွေ စမ်းသပ်ဖို့အတွက် လိုအပ်တဲ့ environment တစ်ခုကို ဖန်တီးပေးပါတယ်။
Using the chroot User-space Tool
chroot client tool ကို စပြီး စမ်းသုံးကြည့်ပါမယ်။ အပေါ်မှာပြောခဲ့သလိုပဲ chroot က User-space tool ဖြစ်ပြီး၊ သူက chroot(2) system call ကို ခေါ်ယူပြီး အသုံးပြုတာဖြစ်ပါတယ်။
အပေါ်ဆုံးအဆင့်မှာ ဆောက်ထားတဲ့ ${HOME}/containers/alpine-linux အောက်ကို သွားပြီး chroot command ကို စသုံးပါမယ်။
$ cd $HOME/containers/alpine-linux
$ sudo chroot . /bin/sh
အဒီနောက် Linux commands တွေနဲ့ စပြီးစမ်းသပ်ကြည့်နိုင်ပါတယ်။
/ # ls -l
total 0
drwxr-xr-x 1 1000 1000 858 Jul 22 14:34 bin
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 dev
drwxr-xr-x 1 1000 1000 540 Jul 22 14:34 etc
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 home
drwxr-xr-x 1 1000 1000 272 Jul 22 14:34 lib
drwxr-xr-x 1 1000 1000 28 Jul 22 14:34 media
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 mnt
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 opt
dr-xr-xr-x 1 1000 1000 0 Jul 22 14:34 proc
drwx------ 1 1000 1000 24 Jul 30 04:26 root
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 run
drwxr-xr-x 1 1000 1000 790 Jul 22 14:34 sbin
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 srv
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 sys
drwxr-xr-x 1 1000 1000 0 Jul 22 14:34 tmp
drwxr-xr-x 1 1000 1000 40 Jul 22 14:34 usr
drwxr-xr-x 1 1000 1000 86 Jul 22 14:34 var
/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.21.3
PRETTY_NAME="Alpine Linux v3.21"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
The /proc Virutal Filesystem
ပြီးတဲ့နောက် proc Virtual filesystem ကို ကိုယ့်ရဲ့ chroot environment ထဲမှာ Mount လုပ်ဖို့ လိုအပ်ပါလိမ့်မယ်။ ဒီ command က chroot environment မှာ proc Virtual filesystem ကို /proc directory ထဲကို Mount လုပ်လိုက်တာ ဖြစ်ပါတယ်။
$ mount -t proc proc /proc
ဒီနေရာမှာ proc Virtual filesystem ဆိုတာ ဘယ်လိုမျိူးလဲ။ ဘာကြောင့် Mount လုပ်ဖို့ လိုအပ်တာလဲလို့ မေးစရာရှိပါတယ်။
Linux မှာ proc က Virtual Filesystem (VFS) တနည်းအားဖြင့် Special filesystem တခုဖြစ်ပါတယ်။ proc က Linux kernel ရဲ့ နောက်ဘက်ကနေ ထောက်ပံ့ပေးထားတဲ့ VFS တခုဖြစ်ပြီး Hardware(System) နဲ့ Process အချက်လက်တွေကို In-Memory သိမ်းတာ ဖြစ်ပါတယ်။ ဒီနေရာမှာ ရှင်းရှင်းလင်းလင်းသိရမှာက /proc အောက်က files တော့ Linux kernel ကနေ Boot တတ်လာချိန်မှာ Dynamically တည်ဆောက်ပေးတာ ဖြစ်ပြီး၊ Disk ပေါ်မှာ တကယ်သိမ်းတာ မဟုတ်ဘဲ In-Memory ပဲ သိမ်းထားဖြစ်ပါတယ်။
ဥပမာ
cat /proc/versionက လက်ရှိ Linux kernel version ကို စစ်ကြည့်ဖို့သုံးနိုင်တယ်။cat /proc/cpuinfoက လက်ရှိ Linux system ရဲ့ CPU နဲ့ ပတ်သက်တဲ့ အသေးစိတ်အချက်လက်ကို အသေးစိတ် ကြည့်နိုင်တယ်။
ဒါကြောင့် chroot environment ထဲမှာ process နဲ့ ပတ်သက်တဲ့ အသေးစိတ်အချက်လက်ကို သိနိုင်ဖို့၊ သုံးနိုင်ဖို့ proc Virtual Filesystem ကို မဖြစ်နေ Mount လုပ်ဖို့လိုအပ်တာ ဖြစ်ပါတယ်။ အဲဒီလို Mount မလုပ်ရင် chroot environment ထဲမှာ ps လိုမျိုး command က ကောင်းကောင်း အလုပ်မလုပ်နိုင်ပါဘူး။
ဥပမာ
$ ps aux
# Error: Could not read /proc/stat
ဘာကြောင့်လဲဆိုတော့ ps က client tool ဖြစ်ပြီး တကယ့်လုပ်ဆောင်ချက်က နောက်ဘက်က /proc ကနေ ထောက်ပံ့ပေးတာကြောင့် ဖြစ်ပါတယ်။
အပေါ်က mount -t proc proc /proc ကို ကိုယ့်ရဲ့ chroot environment ထဲမှာ Run ပြီးရင်တော့ အောက်က Linux system နဲ့ process နဲ့ ပတ်သက်တဲ့ commands တွေကို စမ်းကြည့်နိုင်တယ်။
cat /proc/cpuinfops auxip addr
/ # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
stepping : 12
microcode : 0xfc
cpu MHz : 2900.231
cache size : 8192 KB
...
/ # ps aux
PID USER TIME COMMAND
1 root 0:05 /usr/lib/systemd/systemd --switched-root --system --deserialize=51 rhgb
2 root 0:00 [kthreadd]
3 root 0:00 [pool_workqueue_]
4 root 0:00 [kworker/R-rcu_g]
5 root 0:00 [kworker/R-sync_]
6 root 0:00 [kworker/R-slub_]
7 root 0:00 [kworker/R-netns]
9 root 0:00 [kworker/0:0H-ev]
12 root 0:00 [kworker/R-mm_pe]
14 root 0:00 [rcu_tasks_kthre]
15 root 0:00 [rcu_tasks_rude_]
16 root 0:00 [rcu_tasks_trace]
17 root 0:16 [ksoftirqd/0]
18 root 0:10 [rcu_preempt]
19 root 0:00 [rcu_exp_par_gp_]
20 root 0:00 [rcu_exp_gp_kthr]
...
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether fa:8b:5b:09:59:51 brd ff:ff:ff:ff:ff:ff
inet 192.168.55.129/24 brd 192.168.55.255 scope global dynamic noprefixroute wlo1
valid_lft 75600sec preferred_lft 75600sec
inet6 fe80::fa24:a316:4e60:c881/64 scope link noprefixroute
valid_lft forever preferred_lft forever
...
ဒီနေရာမှာ သတိထားမိပါလိမ့်မယ်။ chroot environment ထဲမှာ Host OS ရဲ့ Process / Network နဲ့ ပတ်သက်တာတွေအားလုံးကို မြင်နေရတာကို တွေ့ရပါလိမ့်မယ်။ နောက်အပိုင်းမှာ ဘယ်လို Isolate လုပ်လို့ရမလဲဆိုတာ အသေးစိတ်လေ့လာကြည့်ပါမယ်။
Isolating from the Host Machine
Linux Namespaces
Linux Namespaces က Linux kernel ရဲ့ feature တခုဖြစ်ပြီး ခေတ်သစ် Containerization နည်းပညာရဲ့ အခြေခံအုတ်မြစ်တခုလည်း ဖြစ်ပါတယ်။
အဓိက သဘောတရားကတော့ Process အစု၀ေးတခုအတွက် မတူညီတဲ့ System resources တွေကို Host Machine ကနေ သီးခြားခွဲထုတ်ပြီး Virtualize လုပ်တောကို လုပ်ဆောင်ပေးတယ်။ Namespaces ကို ၂၀၀၂ ခုနှစ် Linux kernel version 2.4.19 တည်းက စတင်သုံးခဲ့ပါတယ်။
System resources ဆိုတဲ့နေရာမှာ အောက်ပါအရာတွေပါ၀င်ပါတယ်
PID (Process ID)
Mount
UTS (UNIX Timesharing System)
IPC (Inter-process Communication)
Network
User
Control Groups (CGroups)
Documentation: https://man7.org/linux/man-pages/man7/namespaces.7.html
| Namespace | Manual Page | Isolates |
| PID (Process ID) | pid_namespaces | Isolates process IDs. |
| Mount | mount_namespaces | Isolates the set of mounted filesystems. |
| UTS (UNIX Timesharing System) | uts_namespaces | Isolates hostname and DNS name. |
| IPC (Inter-process Communication) | ipc_namespaces | Isolates IPC resources, such as message queue and shared memory. |
| Network | network_namespaces | Isolates network interfaces, IP addresses, routing tables, and port numbers. |
| User | user_namespaces | Isolates user and group IDs. |
| CGroup | cgroup_namespaces | Isolates the view of Control Groups (CGroups). |
ဥပမာ - Linux Host Machine တခုပေါ်မှာ Container တခု လည်ပတ်နေတယ် ဆိုပါစို့။
Container မှာ သီးခြားကိုယ်ပိုင် Root Filesystem ရှိနိုင်တယ်။ အကြောင်းက သူက Host Machine ကနေ Mount Namespaces ကို ခွဲထုတ်လိုက်လို့ ဖြစ်ပါတယ်။
Container မှာ သီးခြားကိုယ်ပိုင် Hostname ရှိနိုင်တယ်။ အကြောင်းက သူက Host Machine ကနေ UTS Namespaces ကို ခွဲထုတ်လိုက်လို့ ဖြစ်ပါတယ်။
Container မှာ သီးခြားကိုယ်ပိုင် PIDs များ ရှိနိုင်ပါတယ်။ အကြောင်းကတော့ သူမှာ Host Machine ကနေ PID (Process ID) Namespaces ကို ခွဲထုတ်လိုက်လို့ ဖြစ်ပါတယ်။
Using the unshare User-space Tool
Linux Namespaces က Linux kernel ကနေ နောက်ဘက်ကနေ ထောက်ပံ့ပေးသူဖြစ်ပြီး သူနဲ့ ဆက်သွယ်ဆောင်ရွတ်ဖို့က unshare client tool ကို သုံးနိုင်ပါတယ်။
unshare က Client tool ဖြစ်ပြီး Linux Namespaces က Backend service လို့ မြင်လို့ရပါတယ်။ ushare CLI tool က unshare(2) system call ကို ခေါ်ပြီး Namespace အသစ်တခု ဆောက်တာ သို့မဟုတ် ရှိထားပြီးသား Namespace တခုကိုရွေ့တာ စသဖြင့် လုပ်ဆောင်နိုင်ပါတယ်။
အပေါ်က Linux Namespaces အပိုင်းမှာ ပြောခဲ့သလိုပဲ unshare CLI tool အောက်ပါ Namespaces တွေကို တည်ဆောက်နိုင်ပါတယ်။
--mount: Create a new mount namespace.--uts: Create a new UTS namespace (isolates hostname and domain name).--ipc: Create a new IPC namespace.--net: Create a new network namespace.--pid: Create a new PID namespace.--user: Create a new user namespace.--cgroup: Create a new cgroup namespace.--fork: Fork a new process to run the command (required for PID namespaces).
စပြီး သုံးကြည့်ပါမယ်။ အပေါ်ဦးဆုံးအပိုင်းမှာ ဆောက်ခဲ့တဲ့ containers/alpine-linux အောက်ကို သွားပြီး unshare ကို Run ပါမယ်။ ဒီ command က PID / Mount / Network Namespaces တွေကို unshare ကို သုံးပြီး Host Machine ကနေ သီးခြားခွဲထုတ်လိုက်တာ ဖြစ်ပါတယ်။
$ cd containers/alpine-linux
$ sudo unshare --pid --mount --net -f chroot alpine-linux /bin/sh
/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.21.3
PRETTY_NAME="Alpine Linux v3.21"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
Change Root (chroot) အပိုင်းမှာ ပြောခဲ့သလိုပဲ System နဲ့ Process အချက်လက်ကို ရယူနိုင်ဖို့ /proc ကို Mount လုပ်ပေးဖို့ လိုအပ်ပါတယ်။
$ mount -t proc proc /proc
ပြီးတဲနောက်တော့ Chroot Container ထဲမှာ လက်ရှိလည်ပတ်နေတဲ့ Process ID (PID) နဲ့ Network interfaces တွေကို စစ်ကြည့်ပါမယ်။
/ # ps aux
PID USER TIME COMMAND
1 root 0:00 /bin/sh
5 root 0:00 ps aux
/ # ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
ဒီနေရာမှာ သတိထားမိပါလိမ့်မယ်။ PID နဲ့ Network interfaces တွေက Host Machine ကနေ ခွဲထုတ်လိုက်ပြီး သီးခြားစီဖြစ်နေတာကို တွေ့ရပါလိမ့်မယ်။ နောက်အပိုင်းမှာ Network Layer မှာ Container တွေ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာ ဆက်လက်လေ့လာရမှာ ဖြစ်ပါတယ်။
Configuring Container Networks from Scratch
Alpine Linux Container IP address:
172.19.35.3Tiny Linux Container IP address:
172.19.35.2
ဒီအပိုင်းမှာ Container နှစ်လုံးအတွက် အစကနေ VETH (Virtual Ethernet) နဲ့ Bridge Network တခု တည်ဆောက်ပြီး ဘယ်လိုအလုပ်လုပ်သလဲ လေ့လာရမှာ ဖြစ်ပါတယ်။ Virtual Ethernet (VETH) နဲ့ Bridge Networking က Linux Virtual Networking ရဲ့ အဓိကအစိတ်ပိုင်းတွေ ဖြစ်ပြီး Container နဲ့ Host Machine သို့မဟုတ် Container ကနေ Container ဆက်သွယ်ဖို့ အသုံးပြုပါတယ်။ Container Networking နည်းပညာဘက်မှာ အလွန်အသုံးများပါတယ်။
Virtual Ethernet (VETH)
Virtual Ethernet (VETH) ဆိုတာ ပိုက် (pipe) တစ်ခုလိုမျိုး လုပ်ဆောင်တဲ့ Virtual network interfaces နှစ်ခုတွဲ ဖြစ်ပါတယ်။ အဲဒီ Interface နှစ်ခုထဲက တစ်ခုကနေ ပို့လိုက်တဲ့ အချက်အလက် (packets) တွေဟာ ကျန်တစ်ခုကနေ လက်ခံရရှိမှာ ဖြစ်ပါတယ်။ VETH ကို ပုံမှန်အားဖြင့် Network namespaces များကို Host machine သို့မဟုတ် အခြား Network namespaces များနှင့် ချိတ်ဆက်ရန် အသုံးပြုပါတယ်။
VETH တွဲတစ်ခုမှာ Interfaces နှစ်ခု ပါဝင်ပါတယ်။
တစ်ခုက Host machine ရဲ့ Network namespace ထဲမှာ ရှိပြီး
ကျန်တစ်ခုက Container ရဲ့ Network namespace ထဲမှာ ရှိပါတယ်။
Interface တစ်ခုကနေ ပို့လိုက်တဲ့ packets တွေကို အခြား Interface ကနေ လက်ခံရရှိပါတယ်။ ဒါကြောင့် Container နဲ့ Host ဒါမှမဟုတ် အခြား Container တွေကြားမှာ အချင်းချင်း ချိတ်ဆက်ပြောဆိုနိုင်တာ ဖြစ်ပါတယ်။
Bridge Networking
Bridge Network ဆိုတာ Virtual network switch တစ်ခုဖြစ်ပြီး Network interfaces များစွာကို တစ်ခုနဲ့တစ်ခု ချိတ်ဆက်ပေးပါတယ်။ ဒါ့ကြောင့် Container တွေကို အချင်းချင်း ဆက်သွယ်နိုင်အောင် လုပ်ဆောင်ပေးပါတယ်။
Bridge တစ်ခုဟာ Layer 2 device တစ်ခုလိုမျိုး လုပ်ဆောင်ပြီး ချိတ်ဆက်ထားတဲ့ Interfaces တွေကြားမှာ Ethernet frames တွေကို လက်ဆင့်ကမ်းပို့ဆောင်ပေးပါတယ်။
Containers တွေ ဒါမှမဟုတ် Virtual Machines (VMs) တွေကို VETH pairs ကနေတဆင့် bridge နဲ့ ချိတ်ဆက်ပါတယ်။
Step (1): Setting up VETH Network for Container (A) — Alpine Linux Container
ဒီအပိုင်းမှာ Alpine Linux Container ပေါ်တွင် VETH ကွန်ရက်ကို ဘယ်လိုတည်ဆောက်မလဲဆိုတာ ဖော်ပြသွားပါမယ်။
အပေါ်မှာ စမ်းခဲ့တဲ့နည်းလမ်းအတိုင်းပါပဲ unshare နှင့် chroot Command-line tool များကို အသုံးပြုပြီး သီးခြားခွဲထားသော PID (Process ID)၊ Mount နှင့် Network namespaces များပါရှိတဲ့ Alpine Linux Container တခုကို တည်ဆောက်မှာ ဖြစ်ပါတယ်။
$ cd ${HOME}/containers/alpine-linux
$ sudo unshare --pid --mount --net \
-f chroot . \
env -i \
HOME=/root \
HOSTNAME=alpine-linux \
/bin/sh
$ mount -t proc proc /proc
ထို့နောက် ကိုယ့်ရဲ့ Host Linux machine မှာ Container PID ကို ရယူပါ။ ဒီမှာတော့ ကျွန်တော့်ရဲ့ Alpine Linux Container PID သည် 25473 ဖြစ်ပါတယ်။
ဒီနေရာမှာ PID က စမ်းတဲ့သူပေါ်မှာ မူတည်ပြီး အပြောင်းလဲ ရှိနိုင်ပါတယ်။
[zawzaw@fedora-linux:~]$ ps -C sh
PID TTY TIME CMD
25473 pts/6 00:00:00 sh
ပြီးရင်တော့ export command ဖြင့် ALPINE_CONTAINER_PID environment variable ကို သတ်မှတ်လိုက်ပါ။ VETH Network ကို တည်ဆောက်တဲ့အခါ ဒီ PID ကို လိုအပ်ပါတယ်။
[zawzaw@fedora-linux:~]$ export ALPINE_CONTAINER_PID=25473
Host Linux machine မှာ ip command-line tool ဖြင့် veth0, veth1 ဟုခေါ်သော VETH network pair တစ်ခုကို တည်ဆောက်လိုက်ပါမယ်။
ဒီနေရာမှာ သေချာနားလည်ရမှာက veth0 က Host machine မှာ ရှိမှာဖြစ်ပြီး၊ veth1 က Alpine Linux Container ဘက်မှာ ရှိမှာဖြစ်ပါတယ်။
[zawzaw@fedora-linux:~]$ sudo ip link add veth0 type veth peer name veth1
[zawzaw@fedora-linux:~]$ sudo ip link set veth1 netns "${ALPINE_CONTAINER_PID}"
[zawzaw@fedora-linux:~]$ sudo ip link set dev veth0 up
Alpine Linux Container ပေါ်တွင် veth1 Network interface ရဲ့ IP address ကို 172.19.35.3 လို့ သတ်မှတ်လိုက်ပါမယ်။
/ # ip addr add dev veth1 172.19.35.3/24
/ # ip link set lo up
/ # ip link set veth1 up
Host Linux machine ပေါ်တွင် Network interfaces များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။
[zawzaw@fedora-linux:~]$ ip addr show veth0
11: veth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether c6:23:c1:27:62:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::c423:c1ff:fe27:62a8/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Alpine Linux Container ပေါ်တွင် Network interfaces နှင့် IP addresses များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
10: veth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 1e:c9:8c:80:fd:9a brd ff:ff:ff:ff:ff:ff
inet 172.19.35.3/24 scope global veth1
valid_lft forever preferred_lft forever
inet6 fe80::1cc9:8cff:fe80:fd9a/64 scope link
valid_lft forever preferred_lft forever
အခုအခြေနေမှာ veth0, veth1 VETH interfaces များ အလုပ်လုပ်နေပြီး ၎င်းတို့ရဲ့ IP address တွေကို 172.19.35.3 လို့ သတ်မှတ်ထားတာကို တွေ့ရပါလိမ့်မယ်။
Step (2): Setting up VETH Network for Container (B) — Tiny Linux Container
ဒီအပိုင်းမှာ အပေါ်ကဆင့်တွေအတိုင်းပဲ အတူတူပဲ ဖြစ်ပါတယ်။ နောက်ထပ် Container တလုံး တည်ဆောက်မှာ ဖြစ်ပါတယ်။ Container (B) အတွက် Linux kernel source code နဲ့ Busybox တို့ကို အသုံးပြုပြီး ကိုယ်တိုင် Compile လုပ်ထားတဲ့ Tiny Linux root filesystem image ကို အသုံးပြုပါမယ်။ Building a minimal Linux system from Scratch and Booting in QEMU Emulator မှာ အသေးစိတ် လေ့လာနိုင်ပါတယ်။
အောက်ပါ Tiny Linux root filesystem image ကို ဒေါင်းလုဒ်ဆွဲပြီး ~/containers/ project directory ထဲသို့ ထည့်လိုက်ပါ။
Download Link: Tiny Linux Root Filesystem Image
[zawzaw@fedora-linux:~/containers/tiny-linux]$ tree
.
├── bin
├── dev
├── linuxrc -> bin/busybox
├── proc
├── sbin
├── sys
└── usr
ဒီအပိုင်းမှာတော့ Tiny Linux Container ပေါ်မှာ VETH Network ကို တည်ဆောက်ပါမယ်။ ပထမအတိုင်းပဲ unshare နဲ့ chroot Command-line tool တွေကို အသုံးပြုပြီး Container (B)—Tiny Linux ကို PID (Process ID)၊ Mount နဲ့ Network namespaces တွေ သီးခြားခွဲထုတ်ပြီး တည်ဆောက်လိုက်ပါမယ်။
$ cd ${HOME}/containers/tiny-linux
$ sudo unshare --pid --mount --net \
-f chroot . \
env -i \
HOME=/root \
HOSTNAME=tiny-linux \
/bin/sh
$ mount -t proc proc /proc
ပြီးရင် ကိုယ့်ရဲ့ Host Linux machine ကနေ Container PID ကို ရယူလိုက်ပါ။ ဒီနေရာမှာတော့ Tiny Linux Container PID က 29999 ဖြစ်ပါတယ်။
ဒီနေရာမှာ PID က စမ်းတဲ့သူပေါ်မှာ မူတည်ပြီး အပြောင်းလဲရှိနိုင်ပါတယ်။
[zawzaw@fedora-linux:~]$ ps -C sh
PID TTY TIME CMD
25473 pts/6 00:00:00 sh
29999 pts/9 00:00:00 sh
ထို့နောက် export command နဲ့ TINY_CONTAINER_PID environment variable ကို သတ်မှတ်လိုက်ပါမယ်။ ဒီ PID ကို VETH pair တည်ဆောက်တဲ့နေရာမှာ ပြန်သုံးမှာ ဖြစ်ပါတယ်။
[zawzaw@fedora-linux:~]$ export TINY_CONTAINER_PID=29999
Host Linux machine ပေါ်မှာ ip command-line tool နဲ့ veth2, veth3 ဆိုတဲ့ VETH network pair တစ်ခုကို တည်ဆောက်လိုက်ပါမယ်။
ဒီနေရာမှာ သေချာနားလည်ရမှာကတော့ veth2 က Host machine ဘက်မှာ ရှိမှာဖြစ်ပြီး၊ veth3 က Tiny Linux Container ဘက်မှာ ရှိမှာဖြစ်ပါတယ်။
[zawzaw@fedora-linux:~]$ sudo ip link add veth2 type veth peer name veth3
[zawzaw@fedora-linux:~]$ sudo ip link set veth3 netns "${TINY_CONTAINER_PID}"
[zawzaw@fedora-linux:~]$ sudo ip link set dev veth2 up
Tiny Linux Container ပေါ်တွင် veth3 Network interface ရဲ့ IP address ကို 172.19.35.2 လို့ သတ်မှတ်လိုက်ပါမယ်။
/ # ip addr add dev veth3 172.19.35.2/24
/ # ip link set lo up
/ # ip link set veth3 up
Host Linux machine ပေါ်တွင် Network interfaces များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။
[zawzaw@fedora-linux:~]$ ip addr show veth2
13: veth2@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 06:97:e6:1f:d4:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::497:e6ff:fe1f:d4b3/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Alpine Linux Container ပေါ်တွင် Network interfaces နှင့် IP addresses များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
12: veth3@if13: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
link/ether 72:37:8b:a8:26:7e brd ff:ff:ff:ff:ff:ff
inet 172.19.35.2/24 scope global veth3
valid_lft forever preferred_lft forever
inet6 fe80::7037:8bff:fea8:267e/64 scope link
valid_lft forever preferred_lft forever
အခုဆိုရင် veth2, veth3 ဆိုတဲ့ VETH network interfaces တွေ အလုပ်လုပ်နေပြီး IP Address ကို 172.19.35.2 လို့ သတ်မှတ်ထားတာကို တွေ့ရပါလိမ့်မယ်။
ဒါပေမယ့် အခုချိန်မှာ Container A နဲ့ B က အချင်းချင်း ဆက်သွယ်လို့ရသေးမှာ မဟုတ်ပါဘူး။ ဒါကို ping command နဲ့ စမ်းသပ်ကြည့်နိုင်ပါတယ်။
Container (A)—Alpine Linux IP Address:
172.19.35.3Container (B)—Tiny Linux IP address:
172.19.35.2
ဥပမာအားဖြင့် Tiny Linux Container ကနေ Alpine Linux (172.19.35.3) ကို ping လုပ်ကြည့်ပါ။ အလုပ်လုပ်မှာမဟုတ်ပါဘူး။ ဘာကြောင့်လဲဆိုတော့ ကျွန်တော်တို့ Bridge network ကို ထပ်ပြီးတည်ဆောက်ဖို့ လိုအပ်နေလို့ပါပဲ။
/ # ping -c 5 172.19.35.3
PING 172.19.35.3 (172.19.35.3): 56 data bytes
--- 172.19.35.3 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
နောက်တစ်ပိုင်းမှာတော့ Container နှစ်ခုကြားမှာ Network packets တွေကို ပို့ဆောင်ဖို့အတွက် Bridge network တစ်ခုကို ဘယ်လိုတည်ဆောက်ရမလဲဆိုတာကို လေ့လာရမှာ ဖြစ်ပါတယ်။
Step (3): Setting Up Bridge Network
အခုဆိုရင် ကျွန်တော်တို့မှာ Alpine Linux နဲ့ Tiny Linux ဆိုတဲ့ Container နှစ်ခုရှိနေပြီး၊ သူတို့ဟာ သီးခြားစီဖြစ်နေတဲ့ PID, Mount နဲ့ Network Linux namespaces တွေထဲမှာ အလုပ်လုပ်နေကြပါတယ်။ သူတို့မှာ Virtual Ethernet (VETH) pair ကိုလည်း တူညီတဲ့ Network Linux namespace ထဲမှာ ရှိပါတယ်။
ဒီအပိုင်းမှာတော့ Container နှစ်ခု ကြားက Network packets တွေကို လက်ဆင့်ကမ်းပို့ဆောင်ဖို့အတွက် Bridge network တစ်ခုကို ဆက်လက်တည်ဆောက်သွားပါမယ်။
Host Linux machine ပေါ်တွင် br0 လို့ခေါ်တဲ့ Bridge network တစ်ခုကို တည်ဆောက်လိုက်ပြီး၊ br0 Bridge network ကို veth0 နဲ့ veth2 Network interfaces တွေနဲ့ ချိတ်ဆက်လိုက်ပါမယ်။
[zawzaw@fedora-linux:~]$ sudo ip link add br0 type bridge
[zawzaw@fedora-linux:~]$ sudo ip link set veth0 master br0
[zawzaw@fedora-linux:~]$ sudo ip link set veth2 master br0
ထို့နောက် br0 Bridge network interface ရဲ့ IP Address ကို 172.19.35.1 လို့ သတ်မှတ်လိုက်ပါမယ်။ ပြီးရင်တော့ Up လိုက်ပြီး IP address ကို စစ်ကြည့်လို့ရပါပြီ။
[zawzaw@fedora-linux:~]$ sudo ip addr add dev br0 172.19.35.1/24
[zawzaw@fedora-linux:~]$ sudo ip link set br0 up
[zawzaw@fedora-linux:~]$ ip addr show br0
14: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 06:97:e6:1f:d4:b3 brd ff:ff:ff:ff:ff:ff
inet 172.19.35.1/24 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::497:e6ff:fe1f:d4b3/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
Testing Connectivity
ပြီးနောက် ping command-line tool ကို အသုံးပြုပြီး Container နှစ်ခုကြားက ကွန်ရက်ချိတ်ဆက်မှု ရှိ၊ မရှိကို စစ်ဆေးနိုင်ပါတယ်။
ဥပမာအားဖြင့် Tiny Linux Container ကနေ Alpine Linux Container (172.19.35.3)ကို ping လုပ်ကြည့်ပါမယ်။
/ # ping -c 5 172.19.35.3
PING 172.19.35.3 (172.19.35.3): 56 data bytes
64 bytes from 172.19.35.3: seq=0 ttl=64 time=0.070 ms
64 bytes from 172.19.35.3: seq=1 ttl=64 time=0.041 ms
64 bytes from 172.19.35.3: seq=2 ttl=64 time=0.059 ms
64 bytes from 172.19.35.3: seq=3 ttl=64 time=0.072 ms
64 bytes from 172.19.35.3: seq=4 ttl=64 time=0.050 ms
--- 172.19.35.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
ဥပမာအားဖြင့် Alpine Linux Container ကနေ Tiny Linux Container (172.19.35.2) ကို ping လုပ်ကြည့်ပါမယ်။
/ # ping -c 5 172.19.35.2
PING 172.19.35.2 (172.19.35.2): 56 data bytes
64 bytes from 172.19.35.2: seq=0 ttl=64 time=0.051 ms
64 bytes from 172.19.35.2: seq=1 ttl=64 time=0.105 ms
64 bytes from 172.19.35.2: seq=2 ttl=64 time=0.042 ms
64 bytes from 172.19.35.2: seq=3 ttl=64 time=0.053 ms
64 bytes from 172.19.35.2: seq=4 ttl=64 time=0.052 ms
--- 172.19.35.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
ယခုဆိုရင် Container နှစ်လုံးဟာ အချင်းချင်း ဆက်သွယ်နိုင်ပြီး ကောင်းမွန်စွာ အလုပ်လုပ်နေကြောင်း အတည်ပြုနိုင်ပါပြီ။
Reference Links
