അറിയുന്നതും നിർമ്മിക്കുന്നതും തമ്മിലുള്ള വ്യത്യാസം

നിങ്ങൾക്ക് ഒരു Docker പരീക്ഷയിൽ ഉന്നത വിജയം നേടാം, ശരിയായ വാക്കുകൾ—namespaces, cgroups, images, layers, PID 1, Kubernetes Pods—മനഃപാഠം പറയാം; എങ്കിലും യഥാർത്ഥത്തിൽ ഒരു കണ്ടെയ്നർ നിർമ്മിക്കാൻ ശ്രമിക്കുമ്പോൾ നിങ്ങൾ എന്താണ് ചെയ്യുന്നതെന്ന് ഒരു ധാരണയും ഉണ്ടാകണമെന്നില്ല. അടുത്തിടെ DEV Community-യിൽ തന്റെ കഥ പങ്കുവെച്ച ഒരു ഡെവലപ്പറിൽ നിന്നുള്ള പാഠമാണിത്. സിദ്ധാന്തവും പ്രായോഗികതയും വ്യത്യസ്ത ലോകങ്ങളിലാണ് ജീവിക്കുന്നത് എന്നതിന്റെ ഓർമ്മപ്പെടുത്തലാണിത്. കണ്ടെയ്നറൈസേഷൻ ഇന്ന് എല്ലാടത്തുമുണ്ട് എന്നതിനാൽ ഇത് ഇപ്പോൾ പ്രധാനമാണ്—Docker, Kubernetes, കൂടാതെ ആയിരക്കണക്കിന് ഡെപ്ലോയ്മെന്റ് സിസ്റ്റങ്ങൾ എന്നിവ തത്സമയം നേരിട്ട് അനുഭവിച്ചറിയുന്നത് വരെ അമൂർത്തമായി തോന്നുന്ന ആശയങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

ആദ്യത്തെ കമാൻഡ്: വിനയം പഠിപ്പിച്ച തുടക്കം

ഇത് ലളിതമായാണ് തുടങ്ങിയത്: പുതിയൊരു namespace-ൽ ഒരു പ്രോസസ്സ് പ്രവർത്തിപ്പിക്കാൻ unshare കമാൻഡ് ഉപയോഗിച്ചു. ആദ്യത്തെ ശ്രമം ഇതായിരുന്നു:

bash sudo unshare -p 1 test

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

ഫ്ലാഗുകൾ തെറ്റായിരുന്നു. "1" എന്ന് പേരുള്ള ഒരു പ്രോഗ്രാം പ്രവർത്തിപ്പിക്കാനാണ് കമാൻഡ് സിസ്റ്റത്തോട് ആവശ്യപ്പെട്ടത്, അങ്ങനെ ഒന്ന് നിലവിലില്ല. എന്തെങ്കിലും നിർമ്മിക്കുന്നതിന് മുമ്പ്, യഥാർത്ഥ പ്രശ്നങ്ങളിലേക്ക് എത്തുന്നതിന് മുമ്പ് തന്നെ, എന്താണ് സംഭവിക്കേണ്ടതെന്ന കാര്യത്തിൽ കീബോർഡിനും ഡോക്യുമെന്റേഷനും വ്യത്യസ്ത അഭിപ്രായങ്ങളായിരുന്നു ഉണ്ടായിരുന്നത്.

Part 1: Namespaces-ഉം PID 1-ഉം

ഒരു പുതിയ PID (process ID) namespace-ൽ ഒരു പ്രോസസ്സ് പ്രവർത്തിപ്പിക്കുകയും അത് പ്രോസസ്സ് ട്രീയുടെ റൂട്ട് ആയ PID 1 ആയി സ്വയം കാണുന്നു എന്ന് തെളിയിക്കുകയുമായിരുന്നു ആദ്യത്തെ യഥാർത്ഥ ശ്രമം. അതിനാൽ കമാൻഡ് പ്രവർത്തിപ്പിച്ചു:

bash sudo unshare --pid bash

തുടർന്ന് ആ ഷെല്ലിനുള്ളിൽ:

bash echo $$

പ്രതീക്ഷിച്ച ഔട്ട്പുട്ട്: 1. യഥാർത്ഥ ഔട്ട്പുട്ട്: 25184.

അത് പ്രവർത്തിച്ചില്ല. അത് PID 1 ആയിരുന്നില്ല; ഹോസ്റ്റിൽ നിന്നുള്ള മാതൃ പ്രോസസ്സ് ID (parent process ID) മാത്രമായിരുന്നു അത്. നിയമം ലളിതമായിരുന്നു എന്നാൽ സാധാരണ ചിന്തയ്ക്ക് വിപരീതമായിരുന്നു: PID namespaces ഉപപ്രോസസ്സുകൾക്കാണ് (child processes) ബാധകമാകുന്നത്, വിളിപ്പിക്കുന്ന unshareപ്രോസസ്സിനല്ല. നിങ്ങൾ fork ചെയ്യണം. പുതിയ namespace-ലേക്ക് ജനിക്കുന്ന ആദ്യത്തെ child പ്രോസസ്സ് PID 1 ആയി മാറുന്നു.

അതുകൊണ്ട് പ്രവർത്തിക്കുന്ന പതിപ്പ് ഇതായിരുന്നു:

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

ഇപ്പോൾ ഔട്ട്പുട്ട് 1 ആയിരുന്നു. താൻ പ്രോസസ്സ് ട്രീയുടെ റൂട്ട് ആണെന്ന് ഷെൽ കരുതി. ഉള്ളിൽ നിന്ന് എല്ലാം വ്യത്യസ്തമായി തോന്നി.

അടുത്ത അത്ഭുതം അതിനുശേഷമായിരുന്നു. ഉള്ളിൽ നിന്ന് ps പ്രവർത്തിപ്പിച്ചപ്പോൾ കാണിച്ച വിവരങ്ങൾ:

PID PPID COMMAND 25310 25304 bash 25344 25310 ps

എന്നാൽ ഷെൽ പറഞ്ഞത് അത് PID 1 ആണെന്നാണ്. അതിൽ ഒരർത്ഥവും ഉണ്ടായിരുന്നില്ല. ആ തിരിച്ചറിവ് ഇതായിരുന്നു: ps കേർണലിനോട് കേവലം "ഏതൊക്കെ പ്രോസസ്സുകൾ നിലവിലുണ്ട്?" എന്ന് ചോദിക്കുകയല്ല ചെയ്യുന്നത്. അത് ഫയലുകൾ വായിക്കുകയാണ് ചെയ്യുന്നത്. എങ്കിൽ /proc ഇപ്പോഴും ഹോസ്റ്റിന്റെ പ്രോസസ്സ് ഫയൽസിസ്റ്റത്തിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ ടൂളുകൾ നിങ്ങളോട് നുണ പറയും. അവ ഹോസ്റ്റിന്റെ നമ്പർ ക്രമം കാണിക്കും.

namespace-ന്റെ ഉള്ളിൽ നിന്ന് /proc വീണ്ടും മൗണ്ട് ചെയ്യുകയായിരുന്നു പരിഹാരം:

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

ഇപ്പോൾ അത് കാണിച്ചു:

PID PPID COMMAND 1 0 bash 7 1 ps

ആ നിമിഷത്തിലാണ് കാര്യം വ്യക്തമായത്. namespace യഥാർത്ഥ ഐസൊലേഷൻ നൽകി, എന്നാൽ ഫയൽസിസ്റ്റം വ്യൂ മാറുന്നത് വരെ ടൂളുകൾക്ക് അത് കാണാൻ കഴിഞ്ഞില്ല. ഐസൊലേഷനും വിസിബിലിറ്റിയും വ്യത്യസ്ത കാര്യങ്ങളാണ്.

ഹോസ്റ്റ്നാമം (hostname) നിയന്ത്രിക്കുന്ന UTS namespace മനസ്സിലാക്കാൻ കൂടുതൽ എളുപ്പമായിരുന്നു. ഹോസ്റ്റിൽ hostname പ്രവർത്തിപ്പിച്ചപ്പോൾ ഒരു പേര് കാണിച്ചു. പുതിയൊരു UTS namespace-ന് ഉള്ളിൽ ( sudo unshare --uts bash) അത് മാറ്റിയപ്പോൾ മറ്റൊന്ന് കാണിച്ചു. തിരികെ ഹോസ്റ്റിൽ എത്തിയപ്പോൾ അത് പഴയപടിയായി. ഒരു മെഷീൻ, ഒരു കേർണൽ, മൂന്ന് വ്യത്യസ്ത കാഴ്ചകൾ.

Part 2: ഫയൽസിസ്റ്റം കൈമാറ്റം

namespaces-ന് ശേഷം, അടുത്ത പതിപ്പ് പ്രോസസ്സിന് അതിന്റേതായ ഒരു ഫയൽസിസ്റ്റം നൽകേണ്ടതായിരുന്നു: BusyBox-ഉം ഒരു ഷെല്ലും ഉള്ള ഒരു rootfs (root filesystem). മികച്ചൊരു കണ്ടെയ്നർ രീതി.

ആദ്യത്തെ പിശക് ലളിതമായിരുന്നു:

exec /bin/sh: no such file or directory

സ്ക്രിപ്റ്റ് പറഞ്ഞ സ്ഥലത്തായിരുന്നില്ല ഷെൽ ഉണ്ടായിരുന്നത്. അത് പരിഹരിച്ചു. എന്നാൽ അതിനുശേഷം:

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

ഈ എറർ വളരെ ക്രൂരമാണ്, കാരണം ഫയൽ അവിടെത്തന്നെയുണ്ട്. നിങ്ങൾക്ക് അത് ലിസ്റ്റ് ചെയ്യാം. അത് കാണാം. എങ്കിലും കേർണൽ അത് പ്രവർത്തിപ്പിക്കാൻ വിസമ്മതിക്കുന്നു. file കമാൻഡ് ഉപയോഗിച്ചപ്പോഴാണ് സത്യം വെളിപ്പെട്ടത്:

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

ബൈനറി അവിടെയുണ്ടായിരുന്നു. അതിന് ആവശ്യമായ ഇന്റർപ്രെറ്റർ—ഡൈനാമിക് ലിങ്കർ—പഴയ ലോകത്ത് ലഭ്യമായിരുന്നില്ല. ഫയൽ നിലവിലില്ല എന്നല്ല Linux പറഞ്ഞത്. "ഇവിടെ നിന്ന്, ഈ ELF-ന് ആവശ്യമായ ഇന്റർപ്രെറ്റർ എനിക്ക് ലോഡ് ചെയ്യാൻ കഴിയില്ല" എന്നാണ് അത് പറഞ്ഞത്.

BusyBox സ്റ്റാറ്റിക് ആക്കുകയല്ലായിരുന്നു പരിഹാരം. ഇന്റർപ്രെറ്റർ ശരിയായ പാതയിലാകാൻ Alpine-നെ പുതിയ റൂട്ട് ഫയൽസിസ്റ്റം ആക്കുകയായിരുന്നു പരിഹാരം. എന്നാൽ ആദ്യം, പരിവർത്തനത്തിന് ഒരു പാലം ആവശ്യമായിരുന്നു—ഫയൽസിസ്റ്റം സ്വിച്ചിന് മുമ്പും ശേഷവും പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു ടൂൾ. BusyBox രണ്ട് രൂപങ്ങളിൽ വന്നു: Alpine-ന് ഉള്ളിൽ ഉപയോഗിക്കാനുള്ള ഡൈനാമിക് പതിപ്പും കൈമാറ്റത്തിനുള്ള സ്റ്റാറ്റിക് പതിപ്പും:

bash /bin/busybox pivot_root . put_old

സിസ്റ്റം പൂർണ്ണമായും പുതിയ ലോകത്തേക്ക് മാറുന്നതിന് മുമ്പ് സ്റ്റാറ്റിക് BusyBox ആയിരുന്നു pivot_root പ്രവർത്തിപ്പിക്കാൻ സഹായിച്ച പ്രധാന താക്കോൽ.

Alpine പുതിയ റൂട്ട് ആയതിനുശേഷവും കൂടുതൽ അത്ഭുതങ്ങൾ ഉയർന്നുവന്നു. പഴയ ഫയൽസിസ്റ്റത്തിൽ നിന്നുള്ള കമാൻഡ് പാത്തുകൾ Bash ഇപ്പോഴും ഓർത്തു വെച്ചിരുന്നു. അത് mountപ്രവർത്തിപ്പിക്കാൻ ശ്രമിച്ചപ്പോൾ, ഒഴിവാക്കപ്പെട്ട ഒരു ലോകത്തിലെ /usr/bin/mount -ൽ അന്വേഷിച്ചു:

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

കമാൻഡ് കാഷെ ക്ലിയർ ചെയ്യുന്ന hash -rആയിരുന്നു പരിഹാരം. പഴയ ലോകത്തിൽ വെച്ച് Bash ഒരു തീരുമാനമെടുത്തിരുന്നു, അതിൽ നിന്ന് പിന്മാറാൻ അതിന് കഴിഞ്ഞില്ല.

Part 3: Mac സങ്കീർണ്ണത

ഇതൊരു സാധാരണ Linux ലാപ്ടോപ്പ് ആയിരുന്നില്ല. Apple Silicon Mac → പ്രിവിലേജ്ഡ് Ubuntu കണ്ടെയ്നർ → macOS-ൽ നിന്ന് മൗണ്ട് ചെയ്ത റിപ്പോ എന്നിവയായിരുന്നു. അതായത് വിർച്ച്വലൈസേഷനായുള്ള ഫയൽസിസ്റ്റം പാസ്ത്രൂ ആയ virtiofs ഉൾപ്പെട്ടിരുന്നു, അത് ആരെങ്കിലും ആഗ്രഹിച്ചാലും ഇല്ലെങ്കിലും.

ഇപ്പോൾ റൂട്ട് ഫയൽസിസ്റ്റം ആയിരിക്കുന്ന Alpine-ന് ഉള്ളിൽ, symlinks വഴി പ്രവർത്തിപ്പിക്കുന്നത് Mac-പങ്കിട്ട മൗണ്ടിൽ "Permission denied" കാരണം പരാജയപ്പെടാം, അതേസമയം BusyBox നേരിട്ട് വിളിക്കുന്നത് പ്രവർത്തിച്ചു:

bash ls

sh: ls: Permission denied

/bin/busybox ls

(works)

ഫയലുകൾ അവിടെയുണ്ടായിരുന്നു. ആ symlinks വഴി പ്രവർത്തിപ്പിക്കുന്നതായിരുന്നു വിചിത്രമായ ഭാഗം. പരിഹാരം ലളിതവും ശരിയുമായിരുന്നു: rootfs ഒരു കണ്ടെയ്നർ-നേറ്റീവ് പാതയിലേക്ക് മാറ്റി അവിടെ നിന്ന് ശ്രമിക്കുക. ഒരു Mac-പങ്കിട്ട മൗണ്ടിനെ സാധാരണ Linux പോലെ പെരുമാറാൻ നിർബന്ധിക്കരുത്.

Part 4: pivot_root-ന്റെ നിബന്ധനകൾ

ഇത്രയൊക്കെ കഴിഞ്ഞിട്ടും, pivot_root സ്വയം പഠിപ്പിക്കൽ നിർത്തിയിരുന്നില്ല. പിശക് ഇതായിരുന്നു:

pivot_root: invalid argument

പുതിയ റൂട്ട് ഒരു മൗണ്ട് പോയിന്റ് ആയിരിക്കണം. പഴയ റൂട്ടിന് പോകാൻ ഒരിടം ആവശ്യമായിരുന്നു. അതിനാൽ ചടങ്ങ് ഇതായിരുന്നു:

1. പുതിയ റൂട്ടിനെ അതിലേക്ക് തന്നെ bind-mount ചെയ്യുക
2. ഒരു oldroot ഡയറക്ടറി ഉണ്ടാക്കുക
3. പ്രവർത്തിപ്പിക്കുക pivot_root(newroot, oldroot)
4. പുതിയ റൂട്ടിലേക്ക് ഡയറക്ടറി മാറ്റുക
5. പഴയ റൂട്ട് unmount ചെയ്യുക

അവസാനം അത് പ്രവർത്തിച്ചപ്പോൾ, ലഭിച്ച പ്രതിഫലം ചെറുതും പൂർണ്ണവുമായിരുന്നു:

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

കേവലം ഒരു ടെക്സ്റ്റ് ഫയൽ. എന്നാൽ കണ്ടെയ്നർ പ്രവർത്തിച്ചു എന്നതിന്റെ തെളിവായിരുന്നു അത്.

ഉപസംഹാരം

പൂജ്യത്തിൽ നിന്ന് ഒരു കണ്ടെയ്നർ നിർമ്മിക്കുന്നത് ഒരു കോഴ്സിനും ഒരിക്കലും പഠിപ്പിക്കാൻ കഴിയാത്ത ഒന്നാണ് പഠിപ്പിക്കുന്നത്: സിദ്ധാന്തം അറിയുന്നതും തത്സമയം അത് പരാജയപ്പെടുന്നത് കാണുന്നതും തമ്മിലുള്ള വ്യത്യാസം. Namespaces, cgroups, ബാക്കിയുള്ളവയെല്ലാം യഥാർത്ഥമാണ്. ഡോക്യുമെന്റ് ചെയ്തതുപോലെ തന്നെ അവ പ്രവർത്തിക്കുന്നു. എന്നാൽ "എനിക്ക് ഇത് മനസ്സിലായി" എന്നതിൽ നിന്ന് "എനിക്ക് ഇത് പ്രവർത്തിപ്പിക്കാൻ കഴിയും" എന്നതിലേക്കുള്ള പാത എറർ മെസ്സേജുകൾ, Bash കാഷെകൾ, ഫയൽസിസ്റ്റം പെർമിഷനുകൾ, ഫയൽസിസ്റ്റം ശരിയല്ലെങ്കിൽ നിങ്ങളുടെ ടൂളുകൾ നിങ്ങളോട് നുണ പറയും എന്ന തിരിച്ചറിവ് എന്നിവയിലൂടെയാണ് കടന്നുപോകുന്നത്.

മേന്മകൾ

• സ്വയം ചെയ്ത് പഠിക്കുന്നത് (hands-on learning), ഒറ്റയ്ക്ക് പഠിക്കുന്നതിനേക്കാൾ കൂടുതൽ ആഴത്തിൽ ധാരണ നൽകുന്നു
• യഥാർത്ഥ പിശകുകൾ ഡോക്യുമെന്റേഷൻ പലപ്പോഴും ഒഴിവാക്കുന്ന പരിമിതികളെക്കുറിച്ച് പഠിപ്പിക്കുന്നു
• പൂജ്യത്തിൽ നിന്ന് നിർമ്മിക്കുന്നത് ആധുനിക കണ്ടെയ്നർ ടൂളുകൾ സങ്കീർണ്ണത എങ്ങനെ മറച്ചുവെക്കുന്നുവെന്ന് വെളിപ്പെടുത്തുന്നു
• namespaces, ഫയൽസിസ്റ്റങ്ങൾ, ഇന്റർപ്രെറ്ററുകൾ എന്നിവ മനസ്സിലാക്കുന്നത് Docker, Kubernetes എന്നിവയെക്കുറിച്ച് കൂടുതൽ വ്യക്തത നൽകുന്നു

പോരായ്മകൾ

• പഠന പാത വളരെ കുത്തനെയുള്ളതാണ്, ഒപ്പം ചെറുതും ആശയക്കുഴപ്പമുണ്ടാക്കുന്നതുമായ നിരവധി പിശകുകൾ അടങ്ങിയിരിക്കുന്നു
• പരിസ്ഥിതി ഘടകങ്ങൾ (macOS-ലെ virtiofs പോലെ) പ്രവചനാതീതമായ സങ്കീർണ്ണതകൾ ചേർക്കുന്നു
• Docker നേരിട്ട് ഉപയോഗിക്കുന്നതുമായി താരതമ്യം ചെയ്യുമ്പോൾ പ്രക്രിയ മന്ദഗതിയിലാണ്
• നിരവധി പ്രത്യേക സാഹചര്യങ്ങൾ (Bash hash caching, symlink permissions) ഡോക്യുമെന്റേഷനിൽ നിന്ന് വ്യക്തമല്ല

മുൻകരുതൽ

ഈ ലേഖനം വിദ്യാഭ്യാസപരമായ ആവശ്യങ്ങൾക്കുള്ളതാണ് കൂടാതെ അടിസ്ഥാന തത്വങ്ങളിൽ നിന്ന് കണ്ടെയ്നറുകൾ നിർമ്മിക്കുന്നതിലൂടെയുള്ള യഥാർത്ഥ പഠനത്തെ വിവരിക്കുന്നു. ഇവിടെ കാണിച്ചിരിക്കുന്ന കമാൻഡുകളും ആശയങ്ങളും ഉറവിട മെറ്റീരിയലുമായി കൃത്യതയുള്ളതാണ്. ഇതൊരു പ്രൊഡക്ഷൻ-ഗ്രേഡ് കണ്ടെയ്നർ റൺടൈം അല്ല; കണ്ടെയ്നറുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് മനസ്സിലാക്കാനുള്ള ഒരു പഠന ഉപകരണം മാത്രമാണ്. പ്രൊഡക്ഷനിൽ ഏതെങ്കിലും കണ്ടെയ്നർ സിസ്റ്റത്തെ ആശ്രയിക്കുന്നതിന് മുമ്പ്, ഔദ്യോഗിക ഡോക്യുമെന്റേഷനും മികച്ച രീതികളും പരിശോധിക്കുക. നിങ്ങളുടെ എൻവയോൺമെന്റിൽ എന്തെങ്കിലും നടപ്പിലാക്കുന്നതിന് മുമ്പ് യഥാർത്ഥ ഉറവിടവുമായി എല്ലാ അവകാശവാദങ്ങളും ശരിയാണെന്ന് ഉറപ്പാക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• എന്താണ് ഒരു PID namespace, കണ്ടെയ്നറുകളിൽ ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്?
• unshare വിളിക്കുന്ന ഒരു പ്രോസസ്സ് എന്തുകൊണ്ട് സ്വയമേവ PID 1 ആകുന്നില്ല?
• /proc ഫയൽസിസ്റ്റത്തിന് കണ്ടെയ്നറുകളുമായി എന്ത് ബന്ധമാണുള്ളത്?
• pivot_root എങ്ങനെയാണ് chroot-ൽ നിന്ന് വ്യത്യാസപ്പെട്ടിരിക്കുന്നത്?
• /proc വീണ്ടും മൗണ്ട് ചെയ്തപ്പോൾ ps കാണിച്ച വിവരങ്ങൾ എന്തുകൊണ്ട് മാറി?
• കണ്ടെയ്നർ നിർമ്മാണത്തിൽ BusyBox-ന്റെ പങ്ക് എന്താണ്?
• ഒരു പുതിയ റൂട്ട് ഫയൽസിസ്റ്റത്തിലേക്ക് മാറുമ്പോൾ ഡൈനാമിക് ഇന്റർപ്രെറ്ററുകൾ പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്?
• macOS-ൽ കണ്ടെയ്നർ സജ്ജീകരണത്തിന് virtiofs എങ്ങനെയാണ് സങ്കീർണ്ണതയുണ്ടാക്കുന്നത്?

ടാഗുകൾ

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