કન્ટેનરમાં સિસ્ટમમાં ચાલી રહ્યું છે

અમે લાંબા સમયથી કન્ટેનરમાં systemd નો ઉપયોગ કરવાના વિષયને અનુસરીએ છીએ. 2014 માં, અમારા સુરક્ષા ઇજનેર ડેનિયલ વોલ્શે એક લેખ લખ્યો હતો ડોકર કન્ટેનરની અંદર સિસ્ટમમાં ચાલી રહ્યું છે, અને થોડા વર્ષો પછી - બીજું, જેને બોલાવવામાં આવ્યું હતું બિન-વિશેષાધિકૃત કન્ટેનરમાં સિસ્ટમમાં ચાલી રહ્યું છે, જેમાં તેમણે જણાવ્યું હતું કે પરિસ્થિતિમાં વધુ સુધારો થયો નથી. ખાસ કરીને, તેણે લખ્યું કે "દુર્ભાગ્યે, બે વર્ષ પછી પણ, જો તમે "ડોકર સિસ્ટમ" ગૂગલ કરો છો, તો પ્રથમ વસ્તુ જે આવે છે તે તેનો તે જ જૂનો લેખ છે. તેથી કંઈક બદલવાનો આ સમય છે.” વધુમાં, અમે પહેલાથી જ વિશે વાત કરી છે ડોકર અને સિસ્ટમડ ડેવલપર્સ વચ્ચે સંઘર્ષ.

આ લેખમાં અમે બતાવીશું કે સમય સાથે શું બદલાયું છે અને પોડમેન આ બાબતમાં અમને કેવી રીતે મદદ કરી શકે છે.

કન્ટેનરની અંદર systemd ચલાવવાના ઘણા કારણો છે, જેમ કે:

1. મલ્ટિસર્વિસ કન્ટેનર - ઘણા લોકો તેમની મલ્ટિ-સર્વિસ એપ્લિકેશન્સને વર્ચ્યુઅલ મશીનોમાંથી બહાર કાઢવા અને કન્ટેનરમાં ચલાવવા માંગે છે. અલબત્ત, આવી એપ્લિકેશનોને માઇક્રોસર્વિસિસમાં તોડવી તે વધુ સારું રહેશે, પરંતુ દરેક જણ જાણે નથી કે આ કેવી રીતે કરવું અથવા ફક્ત સમય નથી. તેથી, એકમ ફાઈલોમાંથી systemd દ્વારા શરૂ કરાયેલી સેવાઓ તરીકે આવી એપ્લિકેશનો ચલાવવાનો સંપૂર્ણ અર્થ થાય છે.
2. સિસ્ટમડ યુનિટ ફાઇલો - કન્ટેનરની અંદર ચાલતી મોટાભાગની એપ્લિકેશનો કોડથી બનેલી છે જે અગાઉ વર્ચ્યુઅલ અથવા ભૌતિક મશીનો પર ચાલતી હતી. આ એપ્લિકેશન્સમાં એક યુનિટ ફાઇલ છે જે આ એપ્લિકેશન્સ માટે લખવામાં આવી હતી અને તે સમજે છે કે તેને કેવી રીતે લોંચ કરવી જોઈએ. તેથી તમારી પોતાની ઇનિટ સર્વિસને હેક કરવાને બદલે સપોર્ટેડ પદ્ધતિઓનો ઉપયોગ કરીને સેવાઓ શરૂ કરવી વધુ સારું છે.
3. Systemd એ પ્રોસેસ મેનેજર છે. તે સેવાઓનું સંચાલન કરે છે (શટ ડાઉન કરે છે, સેવાઓ પુનઃપ્રારંભ કરે છે અથવા ઝોમ્બી પ્રક્રિયાઓને મારી નાખે છે) અન્ય કોઈપણ સાધન કરતાં વધુ સારી રીતે.

તેણે કહ્યું, કન્ટેનરમાં સિસ્ટમ ન ચલાવવાના ઘણા કારણો છે. મુખ્ય એ છે કે systemd/journald કન્ટેનર અને સાધનોના આઉટપુટને નિયંત્રિત કરે છે ક્યુબર્નેટિસ અથવા ઓપનશીફ્ટ કન્ટેનર સીધા stdout અને stderr પર લોગ લખવાની અપેક્ષા રાખે છે. તેથી, જો તમે ઉપર જણાવેલા જેવા ઓર્કેસ્ટ્રેશન ટૂલ્સ દ્વારા કન્ટેનરનું સંચાલન કરવા જઈ રહ્યા છો, તો તમારે સિસ્ટમ-આધારિત કન્ટેનરનો ઉપયોગ કરવાનું ગંભીરતાથી વિચારવું જોઈએ. વધુમાં, ડોકર અને મોબી ડેવલપર્સ ઘણીવાર કન્ટેનરમાં systemd નો ઉપયોગ કરવાનો સખત વિરોધ કરે છે.

ધ કમિંગ ઓફ પોડમેન

અમને જણાવતા આનંદ થાય છે કે પરિસ્થિતિ આખરે આગળ વધી છે. Red Hat ખાતે કન્ટેનર ચલાવવા માટે જવાબદાર ટીમે વિકાસ કરવાનું નક્કી કર્યું તમારું પોતાનું કન્ટેનર એન્જિન. તેને નામ મળ્યું પોડમેન અને ડોકર જેવું જ કમાન્ડ લાઇન ઇન્ટરફેસ (CLI) ઓફર કરે છે. અને લગભગ તમામ ડોકર આદેશો પોડમેનમાં એ જ રીતે વાપરી શકાય છે. અમે વારંવાર સેમિનાર યોજીએ છીએ, જેને હવે કહેવામાં આવે છે ડોકરને પોડમેનમાં બદલવું, અને ખૂબ જ પ્રથમ સ્લાઇડ લખવા માટે કહે છે: ઉર્ફે ડોકર=પોડમેન.

ઘણા લોકો આવું કરે છે.

મારા પોડમેન અને હું કોઈ પણ રીતે સિસ્ટમ-આધારિત કન્ટેનર વિરુદ્ધ નથી. છેવટે, Systemd એ સૌથી સામાન્ય રીતે ઉપયોગમાં લેવાતી Linux init સબસિસ્ટમ છે, અને તેને કન્ટેનરમાં યોગ્ય રીતે કામ કરવાની મંજૂરી ન આપવાનો અર્થ એ છે કે કેવી રીતે હજારો લોકો કન્ટેનર ચલાવવા માટે ટેવાયેલા છે તેની અવગણના કરવી.

પોડમેન જાણે છે કે કન્ટેનરમાં સિસ્ટમ યોગ્ય રીતે કામ કરવા માટે શું કરવું. તેને /run અને /tmp પર tmpfs માઉન્ટ કરવા જેવી વસ્તુઓની જરૂર છે. તેણીને "કન્ટેનરાઇઝ્ડ" પર્યાવરણ સક્ષમ કરવાનું પસંદ છે અને cgroup ડિરેક્ટરીના તેના ભાગ અને /var/log/journald ફોલ્ડરમાં લખવાની પરવાનગીની અપેક્ષા રાખે છે.

જ્યારે તમે કન્ટેનર શરૂ કરો કે જેમાં પ્રથમ આદેશ init અથવા systemd છે, Podman આપોઆપ tmpfs અને Cgroups રૂપરેખાંકિત કરે છે તેની ખાતરી કરવા માટે કે systemd સમસ્યા વિના શરૂ થાય છે. આ ઓટો લોન્ચ મોડને બ્લોક કરવા માટે, --systemd=false વિકલ્પ વાપરો. મહેરબાની કરીને નોંધ કરો કે Podman માત્ર systemd મોડનો ઉપયોગ કરે છે જ્યારે તે જુએ છે કે તેને systemd અથવા init આદેશ ચલાવવાની જરૂર છે.

અહીં મેન્યુઅલમાંથી એક અવતરણ છે:

માણસ પોડમેન રન
...

–systemd=true|false

systemd મોડમાં કન્ટેનર ચલાવી રહ્યા છીએ. ડિફૉલ્ટ રૂપે સક્ષમ.

જો તમે કન્ટેનરની અંદર systemd અથવા init આદેશ ચલાવો છો, તો Podman નીચેની ડિરેક્ટરીઓમાં tmpfs માઉન્ટ પોઈન્ટને ગોઠવશે:

/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal

તેમજ ડિફોલ્ટ સ્ટોપ સિગ્નલ SIGRTMIN+3 હશે.

આ બધું systemd ને કોઈપણ ફેરફારો વગર બંધ કન્ટેનરમાં ચલાવવા માટે પરવાનગી આપે છે.

નોંધ: systemd cgroup ફાઈલ સિસ્ટમ પર લખવાનો પ્રયત્ન કરે છે. જો કે, SELinux કન્ટેનરને મૂળભૂત રીતે આવું કરવાથી અટકાવે છે. લેખન સક્ષમ કરવા માટે, કન્ટેનર_મેનેજ_સીગ્રુપ બુલિયન પેરામીટરને સક્ષમ કરો:

setsebool -P કન્ટેનર_મેનેજ_સીગ્રુપ સાચું

હવે પોડમેનનો ઉપયોગ કરીને કન્ટેનરમાં સિસ્ટમ્ડ ચલાવવા માટે ડોકરફાઇલ કેવી દેખાય છે તે જુઓ:

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

બસ એટલું જ.

હવે અમે કન્ટેનર એસેમ્બલ કરીએ છીએ:

# podman build -t systemd .

અમે SELinux ને Cgroups રૂપરેખાંકન સુધારવા માટે systemd ને પરવાનગી આપવા કહીએ છીએ:

# setsebool -P container_manage_cgroup true

માર્ગ દ્વારા, ઘણા લોકો આ પગલા વિશે ભૂલી જાય છે. સદનસીબે, આ માત્ર એક જ વાર કરવાની જરૂર છે અને સિસ્ટમ રીબૂટ કર્યા પછી સેટિંગ સાચવવામાં આવે છે.

હવે અમે ફક્ત કન્ટેનર શરૂ કરીએ છીએ:

# podman run -ti -p 80:80 systemd

systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

Detected virtualization container-other.

Detected architecture x86-64.

Welcome to Fedora 29 (Container Image)!

Set hostname to <1b51b684bc99>.

Failed to install release agent, ignoring: Read-only file system

File /usr/lib/systemd/system/systemd-journald.service:26 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

[  OK ] Listening on initctl Compatibility Named Pipe.

[  OK ] Listening on Journal Socket (/dev/log).

[  OK ] Started Forward Password Requests to Wall Directory Watch.

[  OK ] Started Dispatch Password Requests to Console Directory Watch.

[  OK ] Reached target Slices.

…

[  OK ] Started The Apache HTTP Server.

બસ, સેવા ચાલુ છે અને ચાલી રહી છે:

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

નોંધ: ડોકર પર આનો પ્રયાસ કરશો નહીં! ડિમન દ્વારા આ પ્રકારના કન્ટેનરને લોંચ કરવા માટે તમારે હજી પણ ટેમ્બોરિન સાથે ડાન્સ કરવાની જરૂર છે. (ડોકરમાં આ બધું એકીકૃત રીતે કાર્ય કરવા માટે વધારાના ક્ષેત્રો અને પેકેજોની જરૂર પડશે, અથવા તેને વિશેષાધિકૃત કન્ટેનરમાં ચલાવવાની જરૂર પડશે. વિગતો માટે, જુઓ લેખ.)

પોડમેન અને સિસ્ટમડ વિશે થોડી વધુ સરસ વસ્તુઓ

પોડમેન સિસ્ટમ્ડ યુનિટ ફાઇલોમાં ડોકર કરતાં વધુ સારી રીતે કામ કરે છે

જો સિસ્ટમ બુટ થાય ત્યારે કન્ટેનર શરૂ કરવાની જરૂર હોય, તો પછી તમે systemd યુનિટ ફાઇલમાં યોગ્ય પોડમેન આદેશો દાખલ કરી શકો છો, જે સેવા શરૂ કરશે અને તેનું નિરીક્ષણ કરશે. પોડમેન પ્રમાણભૂત ફોર્ક-એક્સેક મોડેલનો ઉપયોગ કરે છે. બીજા શબ્દોમાં કહીએ તો, કન્ટેનર પ્રક્રિયાઓ પોડમેન પ્રક્રિયાના બાળકો છે, તેથી systemd તેમને સરળતાથી મોનિટર કરી શકે છે.

ડોકર ક્લાયંટ-સર્વર મોડેલનો ઉપયોગ કરે છે, અને ડોકર CLI આદેશો પણ એકમ ફાઇલમાં સીધા મૂકી શકાય છે. જો કે, એકવાર ડોકર ક્લાયંટ ડોકર ડિમન સાથે જોડાઈ જાય, તે (ક્લાયન્ટ) માત્ર બીજી પ્રક્રિયા પ્રક્રિયા stdin અને stdout બની જાય છે. બદલામાં, systemd ને ડોકર ક્લાયંટ અને કન્ટેનર વચ્ચેના જોડાણ વિશે કોઈ ખ્યાલ નથી કે જે ડોકર ડિમનના નિયંત્રણ હેઠળ ચાલે છે, અને તેથી, આ મોડેલની અંદર, systemd મૂળભૂત રીતે સેવાનું નિરીક્ષણ કરી શકતું નથી.

સોકેટ મારફતે systemd સક્રિય કરી રહ્યા છીએ

પોડમેન સૉકેટ દ્વારા સક્રિયકરણને યોગ્ય રીતે હેન્ડલ કરે છે. કારણ કે પોડમેન ફોર્ક-એક્સેક મોડલનો ઉપયોગ કરે છે, તે સોકેટને તેની ચાઈલ્ડ કન્ટેનર પ્રક્રિયાઓમાં ફોરવર્ડ કરી શકે છે. ડોકર આ કરી શકતું નથી કારણ કે તે ક્લાયંટ-સર્વર મોડેલનો ઉપયોગ કરે છે.

વર્લિંક સેવા કે જેનો ઉપયોગ પોડમેન રિમોટ ક્લાયન્ટ્સ સાથે કન્ટેનર સાથે વાતચીત કરવા માટે કરે છે તે ખરેખર સોકેટ દ્વારા સક્રિય થાય છે. Cockpit-podman પેકેજ, Node.js માં લખાયેલ છે અને કોકપિટ પ્રોજેક્ટનો એક ભાગ છે, જે લોકોને વેબ ઈન્ટરફેસ દ્વારા પોડમેન કન્ટેનર સાથે ક્રિયાપ્રતિક્રિયા કરવાની મંજૂરી આપે છે. કોકપિટ-પોડમેન ચલાવતું વેબ ડિમન વર્લિંક સોકેટ પર સંદેશા મોકલે છે કે જે સિસ્ટમ સાંભળે છે. Systemd પછી સંદેશા પ્રાપ્ત કરવા અને કન્ટેનરનું સંચાલન શરૂ કરવા માટે પોડમેન પ્રોગ્રામને સક્રિય કરે છે. સૉકેટ પર systemd ને સક્રિય કરવાથી દૂરસ્થ API નો અમલ કરતી વખતે સતત ચાલતા ડિમનની જરૂરિયાત દૂર થાય છે.

વધુમાં, અમે પોડમેન-રિમોટ નામના બીજા પોડમેન ક્લાયંટનો વિકાસ કરી રહ્યા છીએ, જે સમાન પોડમેન CLI ને લાગુ કરે છે પરંતુ કન્ટેનર ચલાવવા માટે varlink કૉલ કરે છે. પોડમેન-રિમોટ SSH સત્રોની ટોચ પર ચાલી શકે છે, જે તમને વિવિધ મશીનો પર કન્ટેનર સાથે સુરક્ષિત રીતે ક્રિયાપ્રતિક્રિયા કરવાની મંજૂરી આપે છે. સમય જતાં, અમે Linux ની સાથે MacOS અને Windows ને સપોર્ટ કરવા માટે પોડમેન-રિમોટને સક્ષમ કરવાની યોજના બનાવીએ છીએ, જેથી તે પ્લેટફોર્મ પરના વિકાસકર્તાઓ પોડમેન વર્લિંક સાથે Linux વર્ચ્યુઅલ મશીન ચલાવી શકે અને સ્થાનિક મશીન પર કન્ટેનર ચાલી રહ્યાં હોય તેવો સંપૂર્ણ અનુભવ મેળવી શકે.

SD_NOTIFY

Systemd તમને સહાયક સેવાઓની શરૂઆતને સ્થગિત કરવાની પરવાનગી આપે છે જ્યાં સુધી તેઓને જરૂરી કન્ટેનરાઇઝ્ડ સેવા શરૂ ન થાય ત્યાં સુધી. પોડમેન SD_NOTIFY સોકેટને કન્ટેનરાઇઝ્ડ સેવામાં ફોરવર્ડ કરી શકે છે જેથી સેવા સિસ્ટમને સૂચિત કરે કે તે ઓપરેટ કરવા માટે તૈયાર છે. અને ફરીથી, ડોકર, જે ક્લાયંટ-સર્વર મોડેલનો ઉપયોગ કરે છે, તે આ કરી શકતું નથી.

યોજનાઓમાં

અમે આદેશ ઉમેરવાની યોજના બનાવીએ છીએ podman generate systemd CONTAINERID, જે ચોક્કસ કન્ટેનરને સંચાલિત કરવા માટે systemd યુનિટ ફાઇલ જનરેટ કરશે. આ અનપ્રિવિલેજ્ડ કન્ટેનર માટે રૂટ અને રૂટલેસ મોડમાં કામ કરવું જોઈએ. અમે OCI-સુસંગત systemd-nspawn રનટાઇમ માટેની વિનંતી પણ જોઈ છે.

નિષ્કર્ષ

કન્ટેનરમાં સિસ્ટમ ચલાવવી એ સમજી શકાય તેવી જરૂરિયાત છે. અને પોડમેનનો આભાર, આખરે અમારી પાસે કન્ટેનર રનટાઇમ છે જે systemd સાથે વિરોધાભાસી નથી, પરંતુ તેનો ઉપયોગ સરળ બનાવે છે.

સોર્સ: www.habr.com