ತಿಳಿದುಕೊಳ್ಳುವುದು ಮತ್ತು ನಿರ್ಮಿಸುವುದರ ನಡುವಿನ ಅಂತರ

ನೀವು Docker ಪರೀಕ್ಷೆಯಲ್ಲಿ ಅತ್ಯುತ್ತಮ ಅಂಕ ಪಡೆಯಬಹುದು, ಸರಿಯಾದ ಪದಗಳನ್ನು—namespaces, cgroups, images, layers, PID 1, Kubernetes Pods—ಸಟಪಟವಾಗಿ ಹೇಳಬಹುದು, ಆದರೂ ನಿಜವಾಗಿ ಕಂಟೇನರ್ ನಿರ್ಮಿಸಲು ಯತ್ನಿಸಿದಾಗ ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ತಿಳಿಯದಿರಬಹುದು. ಇತ್ತೀಚೆಗೆ DEV Community ಯಲ್ಲಿ ತಮ್ಮ ಕಥೆಯನ್ನು ಹಂಚಿಕೊಂಡ ಡೆವಲಪರ್ ಒಬ್ಬರಿಂದ ಸಿಕ್ಕ ಪಾಠ ಇದಾಗಿದೆ, ಮತ್ತು ಸಿದ್ಧಾಂತ ಹಾಗೂ ಅಭ್ಯಾಸವು ವಿಭಿನ್ನ ಪ್ರಪಂಚಗಳಲ್ಲಿ ಜೀವಿಸುತ್ತವೆ ಎಂಬುದಕ್ಕೆ ಇದೊಂದು ನೆನಪೋಲೆ. ಕಂಟೇನರೈಸೇಶನ್ ಎಲ್ಲೆಡೆ ಇರುವುದರಿಂದ ಇದು ಈಗ ಮುಖ್ಯವಾಗಿದೆ—Docker, Kubernetes, ಮತ್ತು ಸಾವಿರಾರು ಡೆಪ್ಲಾಯ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳು ನೀವು ನೈಜ ಸಮಯದಲ್ಲಿ ಅವುಗಳನ್ನು ಎದುರಿಸುವವರೆಗೆ ಅಮೂರ್ತವಾಗಿ ಕಾಣುವ ಕಲ್ಪನೆಗಳ ಮೇಲೆ ನಿಂತಿವೆ.

ಮೊದಲ Command: ನಮ್ರತೆಯಿಂದ ಕೂಡಿದ ಆರಂಭ

ಇದು ಸರಳವಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು: ಕೆಳಗಿನ ನಿಯಂತ್ರಣ ಬಳಸಿ ಹೊಸ namespace ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು (process) ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು unshare command. ಮೊದಲ ಪ್ರಯತ್ನ ಹೀಗಿತ್ತು:

bash sudo unshare -p 1 test

Error: unshare: failed to execute 1: No such file or directory

Flags ಗಳು ತಪ್ಪಾಗಿದ್ದವು. Command ವ್ಯವಸ್ಥೆಗೆ "1" ಎಂಬ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕೇಳಿತು, ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಏನನ್ನಾದರೂ ನಿರ್ಮಿಸುವ ಮೊದಲು, ನೈಜ ಸಮಸ್ಯೆಗಳನ್ನು ತಲುಪುವ ಮೊದಲೇ, ಏನಾಗಬೇಕಿತ್ತು ಎಂಬುದರ ಕುರಿತು ಕೀಬೋರ್ಡ್ ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ವಿಭಿನ್ನ ಆಲೋಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದವು.

ಭಾಗ 1: Namespaces ಮತ್ತು PID 1

ಮೊದಲ ನೈಜ ಪ್ರಯತ್ನವೆಂದರೆ ಹೊಸ PID (process ID) namespace ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಚಲಾಯಿಸುವುದು ಮತ್ತು ಅದು ತನ್ನನ್ನು PID 1—process ವೃಕ್ಷದ ಮೂಲ—ಎಂದು ನೋಡುತ್ತದೆ ಎಂದು ನಿರೂಪಿಸುವುದು. ಆದ್ದರಿಂದ command ಅನ್ನು ಚಲಾಯಿಸಲಾಯಿತು:

bash sudo unshare --pid bash

ನಂತರ ಆ shell ನ ಒಳಗೆ:

bash echo $$

ನಿರೀಕ್ಷಿತ output: 1. ವಾಸ್ತವಿಕ output: 25184.

ಇದು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ. ಅದು PID 1 ಆಗಿರಲಿಲ್ಲ; ಅದು ಹೋಸ್ಟ್‌ನಿಂದ ಬಂದ ಮೂಲ ಪ್ರಕ್ರಿಯೆ ID (parent process ID) ಆಗಿತ್ತು. ನಿಯಮ ಸರಳವಾಗಿತ್ತು ಆದರೆ ನಿರೀಕ್ಷೆಗೆ ವಿರುದ್ಧವಾಗಿತ್ತು: PID namespaces child processes ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತವೆ, ಕೆಳಗಿನದನ್ನು ಕರೆಯುವ ಪ್ರಕ್ರಿಯೆಗಲ್ಲ unshare. ನೀವು fork ಮಾಡಬೇಕಾಗಿದೆ. ಹೊಸ namespace ಗೆ ಜನಿಸಿದ ಮೊದಲ child, PID 1 ಆಗುತ್ತದೆ.

ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಆವೃತ್ತಿಯು ಹೀಗಿತ್ತು:

bash sudo unshare --pid --fork bash echo $$

ಈಗ output 1 ಆಗಿತ್ತು. Shell ತಾನು process ವೃಕ್ಷದ ಮೂಲ ಎಂದು ಭಾವಿಸಿತು. ಒಳಗಿನಿಂದ ಎಲ್ಲವೂ ವಿಭಿನ್ನವಾಗಿ ಅನುಭವಕ್ಕೆ ಬಂತು.

ನಂತರ ಮುಂದಿನ ಆಶ್ಚರ್ಯ ಕಾದಿತ್ತು. ಕೆಳಗಿನದನ್ನು ಚಲಾಯಿಸಿದಾಗ ps ಒಳಗಿನಿಂದ ತೋರಿಸಿದ್ದು:

PID PPID COMMAND 25310 25304 bash 25344 25310 ps

ಆದರೆ shell ಅದು PID 1 ಎಂದು ಹೇಳಿತ್ತು. ಅದರಲ್ಲಿ ಅರ್ಥವಿರಲಿಲ್ಲ. ಬಹಿರಂಗಗೊಂಡ ವಿಷಯ: ps ಕರ್ನಲ್ ಅನ್ನು "ಯಾವ ಪ್ರಕ್ರಿಯೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ?" ಎಂಬ ಶುದ್ಧ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವುದಿಲ್ಲ. ಅದು ಫೈಲ್‌ಗಳನ್ನು ಓದುತ್ತದೆ. ವೇಳೆ /proc ಇನ್ನೂ ಹೋಸ್ಟ್‌ನ process filesystem ಗೆ ಬೆಟ್ಟು ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಉಪಕರಣಗಳು ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತವೆ. ಅವು ಹೋಸ್ಟ್‌ನ ಸಂಖ್ಯೆಯ ಯೋಜನೆಯನ್ನು ತೋರಿಸುತ್ತವೆ.

ಪರಿಹಾರವೆಂದರೆ ಕೆಳಗಿನದನ್ನು remount ಮಾಡುವುದು /proc namespace ನ ಒಳಗಿನಿಂದ:

bash mount -t proc proc /proc ps -o pid,ppid,comm

ಈಗ ಅದು ತೋರಿಸಿದ್ದು:

PID PPID COMMAND 1 0 bash 7 1 ps

ಆ ಕ್ಷಣದಲ್ಲೇ ವಿಷಯ ಸ್ಪಷ್ಟವಾಯಿತು. Namespace ನೈಜ ಪ್ರತ್ಯೇಕತೆಯನ್ನು (isolation) ಒದಗಿಸಿತು, ಆದರೆ filesystem ನೋಟ ಬದಲಾಗುವವರೆಗೆ ಉಪಕರಣಗಳಿಗೆ ಅದನ್ನು ನೋಡಲಾಗಲಿಲ್ಲ. ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ದೃಶ್ಯತೆ (visibility) ವಿಭಿನ್ನ ಸಂಗತಿಗಳು.

Hostname ಅನ್ನು ನಿಯಂತ್ರಿಸುವ UTS namespace ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸ್ಪಷ್ಟವಾಗಿತ್ತು. ಕೆಳಗಿನದನ್ನು ಚಲಾಯಿಸಿದಾಗ hostname ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಒಂದು ಹೆಸರನ್ನು ತೋರಿಸಿದೆ. ಹೊಸ UTS namespace ನ ಒಳಗೆ (ಕೆಳಗಿನದರೊಂದಿಗೆ ರಚಿಸಲಾಗಿದೆ sudo unshare --uts bash), ಅದನ್ನು ಬದಲಾಯಿಸುವುದು ಬೇರೆಯದೇ ಆದ ವಿಷಯವನ್ನು ತೋರಿಸಿದೆ. ಮತ್ತೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ಅದು ಮೂಲ ಸ್ಥಿತಿಗೆ ಮರಳಿತು. ಒಂದು ಯಂತ್ರ, ಒಂದು kernel, ಮೂರು ವಿಭಿನ್ನ ನೋಟಗಳು.

ಭಾಗ 2: Filesystem ಹಸ್ತಾಂತರ

Namespaces ನಂತರ, ಮುಂದಿನ ಆವೃತ್ತಿಯು ಪ್ರಕ್ರಿಯೆಗೆ ತನ್ನದೇ ಆದ filesystem ಅನ್ನು ನೀಡಬೇಕಾಗಿತ್ತು: BusyBox ಮತ್ತು shell ಅನ್ನು ಹೊಂದಿರುವ rootfs (root filesystem). ಅತ್ಯಂತ container-ರೀತಿಯದ್ದು.

ಮೊದಲ ದೋಷ ನೇರವಾಗಿತ್ತು:

exec /bin/sh: no such file or directory

Script ಹೇಳಿದ ಜಾಗದಲ್ಲಿ shell ಇರಲಿಲ್ಲ. ಅದನ್ನು ಸರಿಪಡಿಸಲಾಯಿತು. ಆದರೆ ನಂತರ:

./rootfs/bin/busybox: cannot execute: required file not found

ಈ ದೋಷವು ಕ್ರೂರವಾಗಿದೆ ಏಕೆಂದರೆ ಫೈಲ್ ಇಲ್ಲೇ ಇದೆ. ನೀವು ಅದನ್ನು ಪಟ್ಟಿ ಮಾಡಬಹುದು. ನೀವು ಅದನ್ನು ನೋಡಬಹುದು. ಆದರೂ kernel ಅದನ್ನು ಚಲಾಯಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ. ಕೆಳಗಿನ file command ಸತ್ಯವನ್ನು ಬಹಿರಂಗಪಡಿಸಿತು:

ELF 64-bit LSB pie executable, ARM aarch64, dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped

Binary ಇಲ್ಲೇ ಇತ್ತು. ಅದಕ್ಕೆ ಬೇಕಾದ interpreter—dynamic linker—ಹಳೆಯ ಪ್ರಪಂಚದಿಂದ ಲಭ್ಯವಿರಲಿಲ್ಲ. Linux ಫೈಲ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತಿರಲಿಲ್ಲ. ಅದು "ಇಲ್ಲಿಂದ, ಈ ELF ಗೆ ಅಗತ್ಯವಿರುವ interpreter ಅನ್ನು ನನಗೆ ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ" ಎಂದು ಹೇಳುತ್ತಿತ್ತು.

ಪರಿಹಾರವು BusyBox ಅನ್ನು static ಮಾಡುವುದಾಗಿರಲಿಲ್ಲ. Interpreter ಸರಿಯಾದ ಮಾರ್ಗದಲ್ಲಿ ಇರಲು Alpine ಅನ್ನು ಹೊಸ root filesystem ಮಾಡುವುದಾಗಿತ್ತು. ಆದರೆ ಮೊದಲು, ಪರಿವರ್ತನೆಗೆ ಒಂದು ಸೇತುವೆಯ ಅಗತ್ಯವಿತ್ತು—filesystem ಬದಲಾವಣೆಯ ಮೊದಲು ಮತ್ತು ಸಮಯದಲ್ಲಿ ಚಲಾಯಿಸಬಹುದಾದ ಉಪಕರಣ. BusyBox ಎರಡು ರೂಪಗಳಲ್ಲಿ ಬಂದಿದೆ: Alpine ನ ಒಳಗೆ ಒಂದಷ್ಟು dynamic, ಮತ್ತು ಹಸ್ತಾಂತರಕ್ಕೆ static ಒಂದಷ್ಟು:

bash /bin/busybox pivot_root . put_old

Static BusyBox ಕೆಳಗಿನದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಲ್ಲ ಕೀಲಿಕೈಯಾಗಿತ್ತು pivot_root ವ್ಯವಸ್ಥೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಪಂಚಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು.

Alpine ಹೊಸ root ಆದ ನಂತರ, ಇನ್ನಷ್ಟು ಆಶ್ಚರ್ಯಗಳು ಕಾಣಿಸಿಕೊಂಡವು. Bash ಇನ್ನೂ ಹಳೆಯ filesystem ನಿಂದ command ಮಾರ್ಗಗಳನ್ನು ನೆನಪಿಸಿಕೊಂಡಿತ್ತು. ಅದು ಕೆಳಗಿನದನ್ನು ಚಲಾಯಿಸಲು ಯತ್ನಿಸಿದಾಗ mount, ಅದು ಕೆಳಗಿನ ಸ್ಥಳದಲ್ಲಿ ಹುಡುಕಿತು /usr/bin/mount ತಾನೇ ತಾನಾಗಿ ಖಾಲಿ ಮಾಡಲಾದ ಪ್ರಪಂಚದಲ್ಲಿ:

bash: /usr/bin/mount: No such file or directory

ಪರಿಹಾರವೆಂದರೆ ಕೆಳಗಿನದ್ದಾಗಿತ್ತು hash -r, ಇದು command cache ಅನ್ನು ತೆರವುಗೊಳಿಸುತ್ತದೆ. Bash ಹಳೆಯ ಪ್ರಪಂಚದಲ್ಲಿ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಂಡಿತ್ತು ಮತ್ತು ಅದನ್ನು ಬಿಟ್ಟುಕೊಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಭಾಗ 3: Mac ನ ಜಟಿಲತೆ

ಈ ಸೆಟಪ್ ಸಾಮಾನ್ಯ Linux ಲ್ಯಾಪ್‌ಟಾಪ್ ಆಗಿರಲಿಲ್ಲ. ಇದು Apple Silicon Mac → ಪ್ರಿವಿಲೇಜ್ಡ್ Ubuntu container → macOS ನಿಂದ mount ಮಾಡಿದ repo ಆಗಿತ್ತು. ಯಾರಾದರೂ ಬಯಸಲಿ ಅಥವಾ ಬಿಡಲಿ, ಅದರ ಅರ್ಥ virtiofs (ವರ್ಚುವಲೈಸೇಶನ್‌ಗಾಗಿ filesystem passthrough) ಸೇರಿಕೊಂಡಿತ್ತು.

ಈಗ root filesystem ಆಗಿರುವ Alpine ಒಳಗೆ, Mac-shared mount ನಲ್ಲಿ symlinks ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು "Permission denied" ನೊಂದಿಗೆ ವಿಫಲವಾಗಬಹುದು, ಆದರೆ ನೇರವಾಗಿ BusyBox ಅನ್ನು ಕರೆಯುವುದು ಕೆಲಸ ಮಾಡಿತು:

bash ls

sh: ls: Permission denied

/bin/busybox ls

(ಕೆಲಸ ಮಾಡುತ್ತದೆ)

ಫೈಲ್‌ಗಳು ಇಲ್ಲೇ ಇದ್ದವು. ಆ symlinks ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ವಿಚಿತ್ರವಾದ ಭಾಗವಾಗಿತ್ತು. ಪರಿಹಾರವು ಸರಳ ಮತ್ತು ಸರಿಯಾಗಿತ್ತು: rootfs ಅನ್ನು container-native ಮಾರ್ಗಕ್ಕೆ ಸರಿಸಿ ಮತ್ತು ಅಲ್ಲಿಂದ ಪ್ರಯತ್ನಿಸಿ. Mac-shared mount ಅನ್ನು ಸಾಮಾನ್ಯ Linux ನಂತೆ ವರ್ತಿಸಲು ನಿರ್ಬಂಧಿಸಬೇಡಿ.

ಭಾಗ 4: pivot_root ಗೆ ಸ್ವಂತ ಅಭಿಪ್ರಾಯಗಳಿವೆ

ಅಷ್ಟೆಲ್ಲದ ನಂತರವೂ, pivot_root ತಾನೇ ಕಲ್ಪಿಸುವುದನ್ನು ಮುಗಿಸಿರಲಿಲ್ಲ. ದೋಷ:

pivot_root: invalid argument

ಹೊಸ root ಒಂದು mount point ಆಗಿರಬೇಕಿತ್ತು. ಹಳೆಯ root ಗೆ ಹೋಗಲು ಎಲ್ಲಿಯಾದರೂ ಜಾಗ ಬೇಕಿತ್ತು. ಹಾಗಾಗಿ ಪ್ರಕ್ರಿಯೆಯು ಹೀಗಿತ್ತು:

1. ಹೊಸ root ಅನ್ನು ಅದಕ್ಕೇ bind-mount ಮಾಡಿ
2. ಒಂದು ಕೆಳಗಿನದನ್ನು ಸೃಷ್ಟಿಸಿ oldroot directory
3. ಕೆಳಗಿನದನ್ನು ಕರೆಯಿರಿ pivot_root(newroot, oldroot)
4. ಹೊಸ root ಗೆ directory ಅನ್ನು ಬದಲಾಯಿಸಿ
5. ಹಳೆಯ root ಅನ್ನು unmount ಮಾಡಿ

ಅದು ಅಂತಿಮವಾಗಿ ಕೆಲಸ ಮಾಡಿದಾಗ, ಪ್ರತಿಫಲವು ಸಣ್ಣದಾಗಿದ್ದರೂ ಪರಿಪೂರ್ಣವಾಗಿತ್ತು:

bash cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.24.1

ಕೇವಲ ಒಂದು ಪಠ್ಯ ಫೈಲ್. ಆದರೆ ಈಗ ಅದು container ಕೆಲಸ ಮಾಡಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಾಗಿತ್ತು.

ತೀರ್ಮಾನ

ಮೊದಲಿನಿಂದ ಕಂಟೇನರ್ ನಿರ್ಮಿಸುವುದು ಕೋರ್ಸ್ ಎಂದಿಗೂ ಕಲಿಸಲಾಗದ ವಿಷಯವನ್ನು ಕಲಿಸುತ್ತದೆ: ಸಿದ್ಧಾಂತವನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಮತ್ತು ನೈಜ ಸಮಯದಲ್ಲಿ ಅದು ವಿಫಲವಾಗುವುದನ್ನು ವೀಕ್ಷಿಸುವುದರ ನಡುವಿನ ಅಂತರ. Namespaces, cgroups ಮತ್ತು ಉಳಿದವು ನೈಜವಾಗಿವೆ. ಅವು ಡಾಕ್ಯುಮೆಂಟ್ ಮಾಡಿದಂತೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಆದರೆ "ನಾನು ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ" ನಿಂದ "ನಾನು ಅದನ್ನು ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡಬಲ್ಲೆ" ಎನ್ನುವವರೆಗಿನ ಮಾರ್ಗವು ದೋಷ ಸಂದೇಶಗಳು, Bash caches, filesystem ಅನುಮತಿಗಳು ಮತ್ತು filesystem ಸರಿಯಾಗಿಲ್ಲದಿದ್ದರೆ ನಿಮ್ಮ ಉಪಕರಣಗಳು ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತವೆ ಎಂಬ ಸಾಕ್ಷಾತ್ಕಾರದ ಮೂಲಕ ಸಾಗುತ್ತದೆ.

ಗುಣಗಳು (Merits)

• ಪ್ರಾಯೋಗಿಕ ಕಲಿಕೆಯು ಕೇವಲ ಓದುವುದರಿಂದ ಸಾಧ್ಯವಾಗದ ರೀತಿಯಲ್ಲಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವಿಕೆಯನ್ನು ಆಳವಾಗಿ ಮೂಡಿಸುತ್ತದೆ
• ನೈಜ ದೋಷಗಳು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಹೆಚ್ಚಾಗಿ ಬಿಟ್ಟುಹೋಗುವ ಮಿತಿಗಳನ್ನು ಕಲಿಸುತ್ತವೆ
• ಮೊದಲಿನಿಂದ ನಿರ್ಮಿಸುವುದು ಆಧುನಿಕ container ಉಪಕರಣಗಳು ಜಟಿಲತೆಯನ್ನು ಹೇಗೆ ಮರೆಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ
• Namespaces, filesystems ಮತ್ತು interpreters ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು Docker ಮತ್ತು Kubernetes ಅನ್ನು ಕಡಿಮೆ ನಿಗೂಢವಾಗಿಸುತ್ತದೆ

ದೋಷಗಳು (Demerits)

• ಕಲಿಕೆಯ ಹಂತವು ಕಠಿಣವಾಗಿದೆ ಮತ್ತು ಅನೇಕ ಸಣ್ಣ, ಗೊಂದಲಮಯ ದೋಷಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ
• ಪರಿಸರ ಅಂಶಗಳು (macOS ನಲ್ಲಿ virtiofs ನಂತೆ) ಊಹಿಸಲಾಗದ ಜಟಿಲತೆಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ
• ನೇರವಾಗಿ Docker ಬಳಸುವುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಈ ಪ್ರಕ್ರಿಯೆಯು ನಿಧಾನವಾಗಿರುತ್ತದೆ
• ಅನೇಕ ವಿಶೇಷ ಸನ್ನಿವೇಶಗಳು (Bash hash caching, symlink ಅನುಮತಿಗಳು) ಡಾಕ್ಯುಮೆಂಟೇಶನ್‌ನಿಂದ ಸ್ಪಷ್ಟವಾಗಿರುವುದಿಲ್ಲ

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕವಾಗಿದೆ ಮತ್ತು ಮೂಲ ತತ್ವಗಳಿಂದ ಕಂಟೇನರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದರಿಂದ ಸಿಕ್ಕ ನೈಜ ಕಲಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ತೋರಿಸಲಾದ commands ಮತ್ತು ಕಲ್ಪನೆಗಳು ಮೂಲ ವಿಷಯಕ್ಕೆ ನಿಖರವಾಗಿವೆ. ಇದು production-grade container runtime ಅಲ್ಲ; ಕಂಟೇನರ್‌ಗಳು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದೊಂದು ಬೋಧನಾ ಸಾಧನವಾಗಿದೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಯಾವುದೇ container ವ್ಯವಸ್ಥೆಯನ್ನು ನಂಬುವ ಮೊದಲು, ಅಧಿಕೃತ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಮತ್ತು ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಸಂಪರ್ಕಿಸಿ. ನಿಮ್ಮ ಪರಿಸರದಲ್ಲಿ ಏನನ್ನಾದರೂ ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಮೊದಲು ಮೂಲ ಮೂಲದೊಂದಿಗೆ ಎಲ್ಲಾ ಹಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• PID namespace ಎಂದರೇನು ಮತ್ತು containers ನಲ್ಲಿ ಇದು ಏಕೆ ಮುಖ್ಯ?
• unshare ಅನ್ನು ಕರೆಯುವ ಪ್ರಕ್ರಿಯೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ PID 1 ಏಕೆ ಆಗುವುದಿಲ್ಲ?
• /proc filesystem ಗೆ containers ನೊಂದಿಗೆ ಏನು ಸಂಬಂಧ?
• pivot_root ಎಂಬುದು chroot ಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ?
• /proc ಅನ್ನು remount ಮಾಡುವುದು ps ತೋರಿಸಿದ್ದನ್ನು ಏಕೆ ಬದಲಾಯಿಸಿತು?
• Container ನಿರ್ಮಾಣದಲ್ಲಿ BusyBox ನ ಪಾತ್ರವೇನು?
• ಹೊಸ root filesystem ಗೆ ಬದಲಾಯಿಸುವಾಗ dynamic interpreters ಏಕೆ ಮುಖ್ಯವಾಗುತ್ತವೆ?
• macOS ನಲ್ಲಿ virtiofs container ಸೆಟಪ್ ಅನ್ನು ಹೇಗೆ ಜಟಿಲಗೊಳಿಸುತ್ತದೆ?

ಟ್ಯಾಗ್‌ಗಳು

#containers #linux #docker #devops #namespaces #cgroups #filesystem #learning