మేము చాలా కాలంగా systemdని కంటైనర్‌లలో ఉపయోగించడం అనే అంశాన్ని అనుసరిస్తున్నాము. తిరిగి 2014లో, మా సెక్యూరిటీ ఇంజనీర్ డేనియల్ వాల్ష్ ఒక కథనాన్ని రాశారు , మరియు కొన్ని సంవత్సరాల తరువాత - మరొకటి, దీనిని పిలుస్తారు , అందులో పరిస్థితి పెద్దగా మెరుగుపడలేదని పేర్కొన్నాడు. ముఖ్యంగా, "దురదృష్టవశాత్తూ, రెండు సంవత్సరాల తరువాత కూడా, మీరు "డాకర్ సిస్టమ్" అని గూగుల్ చేస్తే, మొదటగా వచ్చేది అతని పాత కథనమే. కాబట్టి ఇది ఏదైనా మార్చడానికి సమయం." అదనంగా, మేము ఇప్పటికే గురించి మాట్లాడాము .
ఈ వ్యాసంలో కాలక్రమేణా ఏమి మారిందో మరియు ఈ విషయంలో పాడ్మాన్ మాకు ఎలా సహాయపడగలడో చూపుతాము.
ఒక కంటైనర్ లోపల systemdని అమలు చేయడానికి అనేక కారణాలు ఉన్నాయి, అవి:
- మల్టీసర్వీస్ కంటైనర్లు - చాలా మంది వ్యక్తులు తమ బహుళ-సేవ అప్లికేషన్‌లను వర్చువల్ మెషీన్‌ల నుండి బయటకు తీసి వాటిని కంటైనర్‌లలో అమలు చేయాలనుకుంటున్నారు. అటువంటి అనువర్తనాలను మైక్రోసర్వీస్‌లుగా విభజించడం మంచిది, అయితే దీన్ని ఎలా చేయాలో అందరికీ ఇంకా తెలియదు లేదా సమయం లేదు. అందువల్ల, యూనిట్ ఫైల్‌ల నుండి systemd ద్వారా ప్రారంభించబడిన సేవలు వంటి అప్లికేషన్‌లను అమలు చేయడం ఖచ్చితంగా అర్ధమే.
- Systemd యూనిట్ ఫైల్స్ - కంటైనర్ల లోపల అమలవుతున్న చాలా అప్లికేషన్‌లు గతంలో వర్చువల్ లేదా ఫిజికల్ మెషీన్‌లలో నడిచే కోడ్ నుండి రూపొందించబడ్డాయి. ఈ అప్లికేషన్‌లు ఈ అప్లికేషన్‌ల కోసం వ్రాయబడిన యూనిట్ ఫైల్‌ను కలిగి ఉంటాయి మరియు వాటిని ఎలా ప్రారంభించాలో అర్థం చేసుకుంటాయి. కాబట్టి మీ స్వంత init సేవను హ్యాక్ చేయడం కంటే, మద్దతు ఉన్న పద్ధతులను ఉపయోగించి సేవలను ప్రారంభించడం ఉత్తమం.
- Systemd ఒక ప్రాసెస్ మేనేజర్. ఇది ఏ ఇతర సాధనం కంటే మెరుగైన సేవలను (షట్ డౌన్, సేవలను పునఃప్రారంభించడం లేదా జోంబీ ప్రక్రియలను చంపడం) నిర్వహిస్తుంది.
సిస్టమ్‌డిని కంటైనర్‌లలో అమలు చేయకపోవడానికి చాలా కారణాలు ఉన్నాయి. ప్రధానమైనది systemd/journald కంటైనర్ల అవుట్‌పుట్ మరియు సాధనాలను నియంత్రిస్తుంది లేదా కంటైనర్లు నేరుగా stdout మరియు stderr లకు లాగ్‌ను వ్రాయాలని ఆశించవచ్చు. అందువల్ల, మీరు పైన పేర్కొన్న వాటి వంటి ఆర్కెస్ట్రేషన్ సాధనాల ద్వారా కంటైనర్‌లను నిర్వహించబోతున్నట్లయితే, మీరు systemd-ఆధారిత కంటైనర్‌లను ఉపయోగించడాన్ని తీవ్రంగా పరిగణించాలి. అదనంగా, డాకర్ మరియు మోబి డెవలపర్లు తరచుగా systemdని కంటైనర్‌లలో ఉపయోగించడాన్ని తీవ్రంగా వ్యతిరేకిస్తున్నారు.
ది కమింగ్ ఆఫ్ పాడ్మాన్
పరిస్థితి ఎట్టకేలకు ముందుకు సాగిందని నివేదించడానికి మేము సంతోషిస్తున్నాము. Red Hat వద్ద కంటైనర్‌లను నడిపే బాధ్యత కలిగిన బృందం అభివృద్ధి చేయాలని నిర్ణయించుకుంది . అతనికి పేరు వచ్చింది మరియు డాకర్ వలె అదే కమాండ్ లైన్ ఇంటర్‌ఫేస్ (CLI)ని అందిస్తుంది. మరియు దాదాపు అన్ని డాకర్ ఆదేశాలను పాడ్‌మాన్‌లో కూడా అదే విధంగా ఉపయోగించవచ్చు. మేము తరచుగా సెమినార్లు నిర్వహిస్తాము, వీటిని ఇప్పుడు పిలుస్తారు , మరియు మొదటి స్లయిడ్ వ్రాయడానికి పిలుపునిస్తుంది: అలియాస్ డాకర్=పాడ్మాన్.
చాలా మంది ఇలా చేస్తుంటారు.
నా Podman మరియు నేను systemd-ఆధారిత కంటైనర్‌లకు ఏ విధంగానూ వ్యతిరేకం కాదు. అన్నింటికంటే, Systemd అనేది సాధారణంగా ఉపయోగించే Linux init సబ్‌సిస్టమ్, మరియు దానిని కంటైనర్‌లలో సరిగ్గా పని చేయడానికి అనుమతించకపోవడం అంటే వేలాది మంది వ్యక్తులు కంటైనర్‌లను అమలు చేయడానికి ఎలా అలవాటు పడ్డారో విస్మరించడం.
కంటైనర్‌లో systemd సరిగ్గా పని చేయడానికి ఏమి చేయాలో పాడ్‌మాన్‌కు తెలుసు. దీనికి /రన్ మరియు /tmpపై tmpfsని మౌంట్ చేయడం వంటివి అవసరం. ఆమె "కంటైనరైజ్డ్" ఎన్విరాన్మెంట్ ఎనేబుల్ చేయడాన్ని ఇష్టపడుతుంది మరియు cgroup డైరెక్టరీలోని తన భాగానికి మరియు /var/log/journald ఫోల్డర్‌కి వ్రాయడానికి అనుమతులను ఆశించింది.
మీరు మొదటి కమాండ్ init లేదా systemd ఉన్న కంటైనర్ను ప్రారంభించినప్పుడు, systemd సమస్యలు లేకుండా ప్రారంభమవుతుందని నిర్ధారించడానికి Podman స్వయంచాలకంగా tmpfs మరియు Cgroupలను కాన్ఫిగర్ చేస్తుంది. ఈ ఆటో లాంచ్ మోడ్‌ను నిరోధించడానికి, --systemd=false ఎంపికను ఉపయోగించండి. Podman అది systemd లేదా init ఆదేశాన్ని అమలు చేయవలసి ఉందని చూసినప్పుడు మాత్రమే systemd మోడ్‌ని ఉపయోగిస్తుందని దయచేసి గమనించండి.
మాన్యువల్ నుండి సారాంశం ఇక్కడ ఉంది:
మనిషి పాడ్మాన్ రన్
...–systemd=నిజం|తప్పు
systemd మోడ్‌లో కంటైనర్ను రన్ చేస్తోంది. డిఫాల్ట్‌గా ప్రారంభించబడింది.
మీరు ఒక కంటైనర్ లోపల systemd లేదా init ఆదేశాన్ని అమలు చేస్తే, Podman కింది డైరెక్టరీలలో tmpfs మౌంట్ పాయింట్‌లను కాన్ఫిగర్ చేస్తుంది:
/రన్, /రన్/లాక్, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal
అలాగే డిఫాల్ట్ స్టాప్ సిగ్నల్ SIGRTMIN+3 అవుతుంది.
ఇవన్నీ సిస్టమ్‌డిని ఎటువంటి మార్పులు లేకుండా క్లోజ్డ్ కంటైనర్‌లో అమలు చేయడానికి అనుమతిస్తుంది.
గమనిక: systemd cgroup ఫైల్ సిస్టమ్‌కు వ్రాయడానికి ప్రయత్నిస్తుంది. అయితే, SELinux డిఫాల్ట్‌గా దీన్ని చేయకుండా కంటైనర్‌లను నిరోధిస్తుంది. వ్రాయడం ప్రారంభించడానికి, container_manage_cgroup boolean పరామితిని ప్రారంభించండి:
setsebool -P container_manage_cgroup ఒప్పు
ఇప్పుడు Podmanని ఉపయోగించి ఒక కంటైనర్‌లో systemdని అమలు చేయడానికి డాకర్‌ఫైల్ ఎలా ఉంటుందో చూడండి:
# cat Dockerfile
FROM fedora
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
అంతే.
ఇప్పుడు మేము కంటైనర్ను సమీకరించాము:
# podman build -t systemd .
Cgroups కాన్ఫిగరేషన్‌ను సవరించడానికి systemdని అనుమతించమని మేము SELinuxకి చెప్పాము:
# 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>
గమనిక: దీన్ని డాకర్‌లో ప్రయత్నించవద్దు! డెమోన్ ద్వారా ఈ రకమైన కంటైనర్‌లను లాంచ్ చేయడానికి మీరు ఇప్పటికీ టాంబురైన్‌తో నృత్యం చేయాలి. (ఇవన్నీ డాకర్‌లో సజావుగా పని చేసేలా చేయడానికి అదనపు ఫీల్డ్‌లు మరియు ప్యాకేజీలు అవసరం లేదా ఇది ప్రత్యేక కంటెయినర్‌లో అమలు చేయబడాలి. వివరాల కోసం, చూడండి .)
Podman మరియు systemd గురించి మరికొన్ని మంచి విషయాలు
Systemd యూనిట్ ఫైల్‌లలో డాకర్ కంటే Podman మెరుగ్గా పనిచేస్తుంది
సిస్టమ్ బూట్ అయినప్పుడు కంటైనర్‌లను ప్రారంభించాల్సిన అవసరం ఉంటే, అప్పుడు మీరు తగిన Podman ఆదేశాలను systemd యూనిట్ ఫైల్‌లోకి చొప్పించవచ్చు, ఇది సేవను ప్రారంభించి దానిని పర్యవేక్షిస్తుంది. పాడ్మాన్ ప్రామాణిక ఫోర్క్-ఎక్సెక్ మోడల్‌ని ఉపయోగిస్తుంది. మరో మాటలో చెప్పాలంటే, కంటైనర్ ప్రక్రియలు Podman ప్రక్రియ యొక్క పిల్లలు, కాబట్టి systemd వాటిని సులభంగా పర్యవేక్షించగలదు.
డాకర్ క్లయింట్-సర్వర్ మోడల్‌ను ఉపయోగిస్తుంది మరియు డాకర్ CLI ఆదేశాలను నేరుగా యూనిట్ ఫైల్‌లో కూడా ఉంచవచ్చు. అయినప్పటికీ, డాకర్ క్లయింట్ డాకర్ డెమోన్‌కి కనెక్ట్ అయిన తర్వాత, అది (క్లయింట్) stdin మరియు stdoutలను నిర్వహించే మరొక ప్రక్రియగా మారుతుంది. క్రమంగా, డాకర్ క్లయింట్ మరియు డాకర్ డెమోన్ నియంత్రణలో పనిచేసే కంటైనర్ మధ్య కనెక్షన్ గురించి systemdకి తెలియదు, అందువల్ల, ఈ మోడల్‌లో, systemd ప్రాథమికంగా సేవను పర్యవేక్షించదు.
సాకెట్ ద్వారా systemdని సక్రియం చేస్తోంది
Podman సరిగ్గా సాకెట్ ద్వారా క్రియాశీలతను నిర్వహిస్తుంది. Podman fork-exec మోడల్‌ని ఉపయోగిస్తున్నందున, ఇది సాకెట్‌ను దాని చైల్డ్ కంటైనర్ ప్రాసెస్‌లకు ఫార్వార్డ్ చేయగలదు. క్లయింట్-సర్వర్ మోడల్‌ని ఉపయోగిస్తున్నందున డాకర్ దీన్ని చేయలేరు.
రిమోట్ క్లయింట్‌లతో కంటైనర్‌లకు కమ్యూనికేట్ చేయడానికి Podman ఉపయోగించే varlink సేవ నిజానికి సాకెట్ ద్వారా యాక్టివేట్ చేయబడింది. కాక్‌పిట్-పాడ్మాన్ ప్యాకేజీ, Node.jsలో వ్రాయబడింది మరియు కాక్‌పిట్ ప్రాజెక్ట్‌లో భాగం, వెబ్ ఇంటర్‌ఫేస్ ద్వారా పాడ్మాన్ కంటైనర్‌లతో పరస్పర చర్య చేయడానికి వ్యక్తులను అనుమతిస్తుంది. కాక్‌పిట్-పాడ్మాన్ నడుస్తున్న వెబ్ డెమోన్ సిస్టమ్‌డి వినే వార్‌లింక్ సాకెట్‌కు సందేశాలను పంపుతుంది. Systemd సందేశాలను స్వీకరించడానికి మరియు కంటైనర్‌లను నిర్వహించడం ప్రారంభించేందుకు Podman ప్రోగ్రామ్‌ను సక్రియం చేస్తుంది. సాకెట్‌పై systemdని యాక్టివేట్ చేయడం వలన రిమోట్ APIలను అమలు చేస్తున్నప్పుడు నిరంతరం నడుస్తున్న డెమోన్ అవసరం ఉండదు.
అదనంగా, మేము పాడ్మాన్-రిమోట్ అని పిలువబడే మరొక పాడ్మాన్ క్లయింట్‌ను అభివృద్ధి చేస్తున్నాము, ఇది అదే పాడ్మాన్ CLIని అమలు చేస్తుంది కానీ కంటైనర్‌లను అమలు చేయడానికి వార్‌లింక్‌ని పిలుస్తుంది. Podman-remote SSH సెషన్‌ల పైన రన్ అవుతుంది, వివిధ మెషీన్‌లలోని కంటైనర్‌లతో సురక్షితంగా ఇంటరాక్ట్ అవ్వడానికి మిమ్మల్ని అనుమతిస్తుంది. కాలక్రమేణా, మేము Linuxతో పాటు MacOS మరియు Windowsకి మద్దతు ఇచ్చేలా podman-రిమోట్‌ని ప్రారంభించాలని ప్లాన్ చేస్తున్నాము, తద్వారా ఆ ప్లాట్‌ఫారమ్‌లలోని డెవలపర్లు Podman varlink రన్నింగ్‌తో Linux వర్చువల్ మెషీన్‌ను అమలు చేయగలరు మరియు స్థానిక మెషీన్‌లో కంటైనర్లు రన్ అవుతున్న పూర్తి అనుభవాన్ని పొందగలరు.
SD_NOTIFY
Systemd మీకు అవసరమైన కంటెయినరైజ్డ్ సేవ ప్రారంభమయ్యే వరకు సహాయక సేవల ప్రారంభాన్ని వాయిదా వేయడానికి మిమ్మల్ని అనుమతిస్తుంది. Podman SD_NOTIFY సాకెట్‌ను కంటెయినరైజ్డ్ సేవకు ఫార్వార్డ్ చేయగలదు, తద్వారా సర్వీస్ సిస్టమ్‌కి ఆపరేట్ చేయడానికి సిద్ధంగా ఉందని తెలియజేస్తుంది. మళ్ళీ, క్లయింట్-సర్వర్ మోడల్‌ని ఉపయోగించే డాకర్ దీన్ని చేయలేము.
ప్రణాళికలలో
పేర్కొన్న నిర్దిష్ట కంటైనర్ను నిర్వహించడానికి systemd యూనిట్ ఫైల్‌ను రూపొందించే, systemd CONTAINERIDని ఉత్పత్తి చేసే పాడ్మాన్ ఆదేశాన్ని జోడించాలని మేము ప్లాన్ చేస్తున్నాము. ఇది అన్‌ప్రివిలేజ్డ్ కంటైనర్ల కోసం రూట్ మరియు రూట్‌లెస్ మోడ్‌లు రెండింటిలోనూ పని చేస్తుంది. మేము OCI-అనుకూల systemd-nspawn రన్‌టైమ్ కోసం అభ్యర్థనను కూడా చూశాము.
తీర్మానం
ఒక కంటైనర్‌లో systemdని అమలు చేయడం అర్థమయ్యే అవసరం. మరియు Podmanకి ధన్యవాదాలు, మేము చివరకు systemdతో విభేదించని కంటైనర్ రన్‌టైమ్‌ని కలిగి ఉన్నాము, కానీ దానిని ఉపయోగించడం సులభం చేస్తుంది.
మూలం: www.habr.com