🥓 🍪 📨 ज्यूपिटर की अनुमति क्या है? 🚵🏽 🙁 🧔🏻

हमारी कहानी एक साधारण काम से शुरू हुई थी। डेटा विज्ञान विशेषज्ञों और सिर्फ डेटा विश्लेषकों के लिए विश्लेषणात्मक उपकरण स्थापित करना आवश्यक था। यह कार्य हमें खुदरा जोखिम और CRM प्रभागों के सहयोगियों द्वारा संबोधित किया गया था, जहां डेटा विज्ञान विशेषज्ञों की एकाग्रता ऐतिहासिक रूप से उच्च है। ग्राहकों की एक सरल इच्छा थी - पायथन कोड लिखना, उन्नत पुस्तकालयों (xgboost, pytorch, टेंसोरफ़्लो, आदि) को आयात करना और hdfs क्लस्टर से उठाए गए डेटा पर एल्गोरिदम चलाना।

सब कुछ सरल और स्पष्ट लगता है। लेकिन बहुत सारे नुकसान थे कि हमने इसके बारे में एक पोस्ट लिखने और गीथहब पर तैयार समाधान पोस्ट करने का फैसला किया।

सबसे पहले, सोर्स इन्फ्रास्ट्रक्चर के बारे में कुछ विवरण:

एचडीएफएस डेटा वेयरहाउस (12 ओरेकल बिग डेटा उपकरण नोड्स, क्लाउडस वितरण)। कुल मिलाकर, स्टोरहाउस में बैंक के विभिन्न आंतरिक प्रणालियों से 130 टीबी डेटा है; बाहरी स्रोतों से विषम जानकारी भी है।
दो एप्लिकेशन सर्वर जिस पर विश्लेषणात्मक उपकरणों की तैनाती चाहिए थी। यह ध्यान देने योग्य है कि इन सर्वरों पर न केवल उन्नत एनालिटिक्स कार्य "स्पिन" करते हैं, इसलिए आवश्यकताओं में से एक सर्वर संसाधनों का प्रबंधन करने, विभिन्न वातावरणों का उपयोग करने और उन्हें कॉन्फ़िगर करने के लिए कंटेनराइजेशन टूल (डोकर) का उपयोग था।

विश्लेषकों के काम के लिए मुख्य वातावरण के रूप में, उन्होंने जुपिटरहब को चुनने का फैसला किया, जो वास्तव में डेटा और मशीन लर्निंग मॉडल के साथ काम करने के मानकों में से एक बन गया है। इसके बारे में यहाँ और पढ़ें। भविष्य में, हमने पहले से ही जुपिटरलैब की कल्पना की थी।

ऐसा लगता है कि सब कुछ सरल है: आपको पायथन + एनाकोंडा + स्पार्क का एक गुच्छा लेने और कॉन्फ़िगर करने की आवश्यकता है। एप्लिकेशन सर्वर पर ज्यूपिटर हब स्थापित करें, एलडीएपी के साथ एकीकृत करें, स्पार्क को कनेक्ट करें या किसी अन्य तरीके से एचडीएफएस डेटा से कनेक्ट करें और आगे बढ़ें - मॉडल बनाएं!
यदि आप सभी स्रोत डेटा और आवश्यकताओं में देरी करते हैं, तो यहां एक अधिक विस्तृत सूची दी गई है:

डॉकटर में जयुपरहब (बेस ओएस - ओरेकल लिनक्स 7) चलाना
सक्रिय निर्देशिका कॉन्फ़िगरेशन में Kerberos प्रमाणीकरण के साथ Cloudera CDH क्लस्टर 5.15.1 + स्पार्क 2.3.0 + क्लस्टर में समर्पित MIT Kerberos ( सक्रिय निर्देशिका के साथ क्लस्टर-समर्पित MIT KDC देखें), Oracle Linux 6
सक्रिय निर्देशिका एकीकरण
Hadoop और Spark में पारदर्शी प्रमाणीकरण
अजगर 2 और 3 समर्थन करते हैं
स्पार्क 1 और 2 (प्रशिक्षण मॉडल के लिए क्लस्टर संसाधनों का उपयोग करने की क्षमता और pyspark का उपयोग करके डेटा प्रसंस्करण को समानांतर करने के साथ)
मेजबान संसाधनों को सीमित करने की क्षमता
लाइब्रेरी सेट

यह पोस्ट आईटी पेशेवरों के लिए डिज़ाइन किया गया है, जिन्हें इस तरह की समस्याओं को हल करने की आवश्यकता होती है।

समाधान का वर्णन

Docker + Cloudera क्लस्टर इंटीग्रेशन में लॉन्च

यहां कुछ भी असामान्य नहीं है। JupyterHub और Cloudera उत्पाद क्लाइंट कंटेनर में स्थापित किए गए हैं (जैसे - नीचे देखें), और कॉन्फ़िगरेशन फ़ाइलें होस्ट मशीन से माउंट की जाती हैं:

start-hub.sh

VOLUMES="-v/var/run/docker.sock:/var/run/docker.sock:Z -v/var/lib/pbis/.lsassd:/var/lib/pbis/.lsassd:Z -v/var/lib/pbis/.netlogond:/var/lib/pbis/.netlogond:Z -v/var/jupyterhub/home:/home/BANK/:Z -v/u00/:/u00/:Z -v/tmp:/host/tmp:Z -v${CONFIG_DIR}/krb5.conf:/etc/krb5.conf:ro -v${CONFIG_DIR}/hadoop/:/etc/hadoop/conf.cloudera.yarn/:ro -v${CONFIG_DIR}/spark/:/etc/spark/conf.cloudera.spark_on_yarn/:ro -v${CONFIG_DIR}/spark2/:/etc/spark2/conf.cloudera.spark2_on_yarn/:ro -v${CONFIG_DIR}/jupyterhub/:/etc/jupyterhub/:ro" docker run -p0.0.0.0:8000:8000/tcp ${VOLUMES} -e VOLUMES="${VOLUMES}" -e HOST_HOSTNAME=`hostname -f` dsai1.2

सक्रिय निर्देशिका एकीकरण

सक्रिय निर्देशिका / केर्बरोस लोहा और बहुत मेजबान नहीं के साथ एकीकरण के लिए, हमारी कंपनी में मानक PBIS ओपन उत्पाद है। तकनीकी रूप से, यह उत्पाद सक्रिय निर्देशिका के साथ संचार करने वाली सेवाओं का एक समूह है, जिसके साथ, ग्राहक, यूनिक्स डोमेन सॉकेट के माध्यम से काम करते हैं। यह उत्पाद लिनक्स पीएएम और एनएसएस के साथ एकीकृत करता है।

हमने मानक डॉकर विधि का उपयोग किया - मेजबान सेवाओं के यूनिक्स डोमेन सॉकेट्स को कंटेनर में रखा गया था (lsof कमांड के साथ सरल जोड़तोड़ द्वारा अनुभवजन्य रूप से सॉकेट पाए गए थे):

start-hub.sh

 VOLUMES="-v/var/run/docker.sock:/var/run/docker.sock:Z -v/var/lib/pbis/.lsassd:/var/lib/pbis/.lsassd:Z <b>-v/var/lib/pbis/.netlogond:/var/lib/pbis/.netlogond:Z -v/var/jupyterhub/home:/home/BANK/:Z -v/u00/:/u00/:Z -v/tmp:/host/tmp:Z -v${CONFIG_DIR}/krb5.conf:/etc/krb5.conf:ro </b> -v${CONFIG_DIR}/hadoop/:/etc/hadoop/conf.cloudera.yarn/:ro -v${CONFIG_DIR}/spark/:/etc/spark/conf.cloudera.spark_on_yarn/:ro -v${CONFIG_DIR}/spark2/:/etc/spark2/conf.cloudera.spark2_on_yarn/:ro -v${CONFIG_DIR}/jupyterhub/:/etc/jupyterhub/:ro" docker run -p0.0.0.0:8000:8000/tcp ${VOLUMES} -e VOLUMES="${VOLUMES}" -e HOST_HOSTNAME=`hostname -f` dsai1.2

बदले में, पीबीआईएस पैकेज कंटेनर के अंदर स्थापित किए जाते हैं, लेकिन पोस्ट-इंस्टॉलेशन अनुभाग को निष्पादित किए बिना। इसलिए हम केवल निष्पादन योग्य फ़ाइलों और पुस्तकालयों को रखते हैं, लेकिन कंटेनर के अंदर सेवाएं शुरू नहीं करते हैं - यह हमारे लिए बहुत अच्छा है। PAM और NSS लिनक्स एकीकरण कमांड मैन्युअल रूप से चलाए जाते हैं।

Dockerfile:

 # Install PAM itself and standard PAM configuration packages. RUN yum install -y pam util-linux \ # Here we just download PBIS RPM packages then install them omitting scripts. # We don't need scripts since they start PBIS services, which are not used - we connect to the host services instead. && find /var/yum/localrepo/ -type f -name 'pbis-open*.rpm' | xargs rpm -ivh --noscripts \ # Enable PBIS PAM integration. && domainjoin-cli configure --enable pam \ # Make pam_loginuid.so module optional (Docker requirement) and add pam_mkhomedir.so to have home directories created automatically. && mv /etc/pam.d/login /tmp \ && awk '{ if ($1 == "session" && $2 == "required" && $3 == "pam_loginuid.so") { print "session optional pam_loginuid.so"; print "session required pam_mkhomedir.so skel=/etc/skel/ umask=0022";} else { print $0; } }' /tmp/login > /etc/pam.d/login \ && rm /tmp/login \ # Enable PBIS nss integration. && domainjoin-cli configure --enable nsswitch

यह पता चला है कि PBIS कंटेनर के ग्राहक PBIS होस्ट सेवाओं के साथ संवाद करते हैं। JupyterHub एक PAM प्रमाणक का उपयोग करता है, और होस्ट पर ठीक से कॉन्फ़िगर PBIS के साथ, सब कुछ बॉक्स से बाहर काम करता है।

AD से सभी उपयोगकर्ताओं को JupyterHub में प्रवेश करने से रोकने के लिए, आप उन सेटिंग का उपयोग कर सकते हैं जो उपयोगकर्ताओं को विशिष्ट AD समूहों में प्रतिबंधित करती हैं।

config-example / jupyterhub / jupyterhub_config.py

 c.DSAIAuthenticator.group_whitelist = ['COMPANY\\domain^users']

Hadoop और Spark में पारदर्शी प्रमाणीकरण

JupyterHub में लॉग इन करते समय, PBIS / tmp निर्देशिका में एक विशिष्ट फ़ाइल में उपयोगकर्ता के Kerberos टिकट को कैश करता है। इस तरह से पारदर्शी प्रमाणीकरण के लिए, यह कंटेनर में होस्ट की / tmp निर्देशिका को माउंट करने और KRB5CCNAME चर को वांछित मान में सेट करने के लिए पर्याप्त है (यह हमारे प्रमाणक वर्ग में किया जाता है)।

start-hub.sh

 VOLUMES="-v/var/run/docker.sock:/var/run/docker.sock:Z -v/var/lib/pbis/.lsassd:/var/lib/pbis/.lsassd:Z -v/var/lib/pbis/.netlogond:/var/lib/pbis/.netlogond:Z -v/var/jupyterhub/home:/home/BANK/:Z -v/u00/:/u00/:Z -v/tmp:/host/tmp:Z -v${CONFIG_DIR}/krb5.conf:/etc/krb5.conf:ro -v${CONFIG_DIR}/hadoop/:/etc/hadoop/conf.cloudera.yarn/:ro -v${CONFIG_DIR}/spark/:/etc/spark/conf.cloudera.spark_on_yarn/:ro -v${CONFIG_DIR}/spark2/:/etc/spark2/conf.cloudera.spark2_on_yarn/:ro -v${CONFIG_DIR}/jupyterhub/:/etc/jupyterhub/:ro" docker run -p0.0.0.0:8000:8000/tcp ${VOLUMES} -e VOLUMES="${VOLUMES}" -e HOST_HOSTNAME=`hostname -f` dsai1.2

संपत्तियाँ / jupyterhub / dsai.py

 env['KRB5CCNAME'] = '/host/tmp/krb5cc_%d' % pwd.getpwnam(self.user.name).pw_uid

उपरोक्त कोड के लिए धन्यवाद, JupyterHub उपयोगकर्ता Jupyter टर्मिनल से hdfs कमांड निष्पादित कर सकता है और अतिरिक्त प्रमाणीकरण चरणों के बिना स्पार्क नौकरियां चला सकता है। कंटेनर में होस्ट की पूरी / tmp निर्देशिका को माउंट करना असुरक्षित है - हम इस समस्या से अवगत हैं, लेकिन इसका समाधान अभी भी विकास के अधीन है।

पायथन संस्करण 2 और 3

यहां, यह प्रतीत होता है, सब कुछ सरल है: आपको पायथन के आवश्यक संस्करणों को स्थापित करने और उन्हें आवश्यक कर्नेल बनाने के साथ, ज्यूपिटर के साथ एकीकृत करने की आवश्यकता है। यह मुद्दा पहले ही कई जगहों पर छाया हुआ है। Conda का उपयोग Python वातावरण के प्रबंधन के लिए किया जाता है। सभी सादगी केवल स्पष्ट क्यों है यह अगले भाग से स्पष्ट होगा। पायथन 3.6 के लिए कर्नेल उदाहरण (यह फ़ाइल git में नहीं है - सभी कर्नेल फ़ाइलें कोड द्वारा उत्पन्न होती हैं)

/opt/cloudera/parcels/Anaconda-5.3.1-dsai1.0/envs/python3.6.6/share/jupyter/kernels/python3.6.6/kernel.json

 {   "argv": [      "/opt/cloudera/parcels/Anaconda-5.3.1-dsai1.0/envs/python3.6.6/bin/python",       "-m",       "ipykernel_launcher",       "-f",      "{connection_file}"   ],   "display_name": "Python 3",   "language": "python" }

स्पार्क 1 और 2

स्पार्क ग्राहकों के साथ एकीकृत करने के लिए, आपको कर्नेल बनाने की भी आवश्यकता है। पायथन 3.6 और स्पार्क 2 के लिए कर्नेल उदाहरण।

/opt/cloudera/parcels/Anaconda-5.3.1-dsai1.0/envs/python3.6.6/share/jupyter/kernels/python3.6.6-pyspark2/kernel.json

 {   "argv": [       "/opt/cloudera/parcels/Anaconda-5.3.1-dsai1.0/envs/python3.6.6/bin/python",       "-m",       "ipykernel_launcher",       "-f",      "{connection_file}"   ],   "display_name": "Python 3 + PySpark 2",   "language": "python",   "env": {       "JAVA_HOME": "/usr/java/default/",       "SPARK_HOME": "/opt/cloudera/parcels/SPARK2/lib/spark2/",       "PYTHONSTARTUP": "/opt/cloudera/parcels/SPARK2/lib/spark2/python/pyspark/shell.py",       "PYTHONPATH": "/opt/cloudera/parcels/SPARK2/lib/spark2/python/:/opt/cloudera/parcels/SPARK2/lib/spark2/python/lib/py4j-0.10.7-src.zip",       "PYSPARK_PYTHON": "/opt/cloudera/parcels/Anaconda-5.3.1-dsai1.0/envs/python3.6.6/bin/python"   } }

बस ध्यान दें कि स्पार्क 1 समर्थन की आवश्यकता ऐतिहासिक रूप से विकसित हुई है। हालांकि, यह संभव है कि कोई व्यक्ति समान प्रतिबंधों का सामना करेगा - आप उदाहरण के लिए, क्लस्टर में स्पार्क 2 को स्थापित नहीं कर सकते। इसलिए, हम यहां उन नुकसानों का वर्णन करते हैं जो हम कार्यान्वयन के रास्ते पर मिले थे।
पहला, स्पार्क 1.6.1 पायथन 3.6 के साथ काम नहीं करता है । दिलचस्प है, सीडीएच 5.12.1 में यह तय किया गया था, लेकिन 5.15.1 में - किसी कारण से नहीं)। सबसे पहले, हम केवल उचित पैच को लागू करके इस समस्या को हल करना चाहते थे। हालांकि, भविष्य में, इस विचार को छोड़ना पड़ा, क्योंकि इस दृष्टिकोण के लिए एक क्लस्टर में एक संशोधित स्पार्क की स्थापना की आवश्यकता है, जो हमारे लिए अस्वीकार्य था। इसका समाधान पायथन 3.5 के साथ एक अलग कोन्डा वातावरण बनाने में पाया गया।

दूसरी समस्या स्पार्क 1 को डॉकर के अंदर काम करने से रोकती है। स्पार्क ड्राइवर एक विशिष्ट पोर्ट खोलता है जिसके माध्यम से वर्कर ड्राइवर से जुड़ता है - इसके लिए ड्राइवर उसे अपना आईपी पता भेजता है। डॉकर वर्कर के मामले में, यह कंटेनर के आईपी के माध्यम से ड्राइवर से जुड़ने की कोशिश करता है, और नेटवर्क = ब्रिज का उपयोग करते समय यह स्वाभाविक रूप से काम नहीं करता है।

स्पष्ट समाधान कंटेनर का आईपी नहीं भेजना है, लेकिन मेजबान का आईपी, जिसे उपयुक्त कॉन्फ़िगरेशन सेटिंग्स जोड़कर स्पार्क 2 में लागू किया गया था। इस पैच को रचनात्मक रूप से नया रूप दिया गया और स्पार्क 1 पर लागू किया गया। इस तरह से संशोधित स्पार्क को क्लस्टर मेजबानों पर रखने की आवश्यकता नहीं है, इसलिए पायथन 3.6 के साथ असंगति के समान कोई समस्या नहीं है।

स्पार्क के संस्करण के बावजूद, इसकी कार्यक्षमता के लिए यह आवश्यक है कि कंटेनर में क्लस्टर में समान पायथन संस्करण हों। क्लोएडा प्रबंधक को दरकिनार करके एनाकोंडा को सीधे स्थापित करने के लिए, हमें दो काम करना सीखना होगा:

एनाकोंडा और सभी सही वातावरण के साथ अपने पार्सल का निर्माण करें
इसे डॉकर में स्थापित करें (संगति के लिए)

विधानसभा पार्सल एनाकोंडा

यह काफी सरल कार्य था। आप सभी की जरूरत है:

एनाकोंडा और पायथन पर्यावरण के आवश्यक संस्करणों को स्थापित करके पार्सल सामग्री तैयार करें
मेटाडेटा फ़ाइल (फ़ाइलें) बनाएँ और इसे मेटा डायरेक्टरी में डालें
सरल टार के साथ पार्सल बनाएं
Cloudera से वैध पार्सल उपयोगिता

प्रक्रिया को गीथहब पर अधिक विस्तार से वर्णित किया गया है , वहां एक सत्यापनकर्ता कोड भी है। हमने क्लाउडरा के लिए आधिकारिक एनाकोंडा पार्सल में मेटाडेटा उधार लिया, रचनात्मक रूप से इसे फिर से काम करना।

डॉकर में पार्सल स्थापित करें

यह अभ्यास दो कारणों से उपयोगी साबित हुआ है:

स्पार्क संचालन सुनिश्चित करना - एनाकोंडा को पार्सल के बिना क्लस्टर में रखना असंभव है
स्पार्क 2 को केवल पार्सल के रूप में वितरित किया जाता है - आप निश्चित रूप से इसे जार फ़ाइलों के रूप में कंटेनर में स्थापित कर सकते हैं, लेकिन यह दृष्टिकोण अस्वीकार कर दिया गया था

एक बोनस के रूप में, उपरोक्त समस्याओं को हल करने के परिणामस्वरूप, हमने प्राप्त किया:

Hadoop और Spark ग्राहकों को स्थापित करने में आसानी - जब Docker और क्लस्टर में समान पार्सल स्थापित करते हैं, तो क्लस्टर और कंटेनर में पथ समान होते हैं
कंटेनर और क्लस्टर में एक समान वातावरण बनाए रखने में आसानी - क्लस्टर को अपडेट करते समय, डॉकर छवि को बस उसी पार्सल के साथ फिर से बनाया जाता है जो क्लस्टर में स्थापित किया गया था।

Docker में पार्सल स्थापित करने के लिए, Cloudera Manager को पहले RPM संकुल से स्थापित किया जाता है। पार्सल की वास्तविक स्थापना के लिए, जावा कोड का उपयोग किया जाता है। जावा में क्लाइंट जानता है कि पायथन में क्लाइंट क्या नहीं कर सकता है, इसलिए मुझे जावा का उपयोग करना पड़ा और कुछ एकरूपता खोनी पड़ी), जिसे एपीआई कहते हैं।

संपत्तियाँ / स्थापित-पार्सल / src / InstallParcels.java

 ParcelsResourceV5 parcels = clusters.getParcelsResource(clusterName); for (int i = 1; i < args.length; i += 2) {   result = installParcel(api, parcels, args[i], args[i + 1], pause);   if (!result) {       System.exit(1);   } }

मेजबान संसाधन सीमा

मेजबान मशीन संसाधनों का प्रबंधन करने के लिए, डॉकरस्पावर के संयोजन का उपयोग किया जाता है - एक घटक जो जुपिटर अंत उपयोगकर्ताओं को एक अलग डॉकटर कंटेनर में चलाता है - और cgroups - लिनक्स में एक संसाधन प्रबंधन तंत्र। DockerSpawner Docker API का उपयोग करता है, जो आपको कंटेनर के लिए मूल cgroup सेट करने की अनुमति देता है। नियमित डॉकपर्सनर में ऐसी कोई संभावना नहीं है, इसलिए हमने सरल कोड लिखा जो हमें कॉन्फ़िगरेशन में एडी संस्थाओं और माता-पिता समूह के बीच पत्राचार को सेट करने की अनुमति देता है।

संपत्तियाँ / jupyterhub / dsai.py

 def set_extra_host_config(self):       extra_host_config = {}       if self.user.name in self.user_cgroup_parent:           cgroup_parent = self.user_cgroup_parent[self.user.name]       else:           pw_name = pwd.getpwnam(self.user.name).pw_name           group_found = False           for g in grp.getgrall():               if pw_name in g.gr_mem and g.gr_name in self.group_cgroup_parent:                   cgroup_parent = self.group_cgroup_parent[g.gr_name]                   group_found = True                   break           if not group_found:               cgroup_parent = self.cgroup_parent extra_host_config['cgroup_parent'] = cgroup_parent

एक छोटा संशोधन भी पेश किया गया है जो जुपिटर को उसी छवि से लॉन्च करता है जिसमें से ज्यूपिटरहब लॉन्च किया गया है। इसलिए, एक से अधिक छवि का उपयोग करने की आवश्यकता नहीं है।

संपत्तियाँ / jupyterhub / dsai.py

 current_container = None host_name = socket.gethostname() for container in self.client.containers():   if container['Id'][0:12] == host_name:       current_container = container       break self.image = current_container['Image']

कंटेनर, जुपिटर या जुपाइटर हूब में चलाने के लिए क्या है, पर्यावरण स्क्रिप्ट द्वारा स्टार्टअप स्क्रिप्ट में निर्धारित किया जाता है:

संपत्तियाँ / jupyterhub / dsai.py

 #!/bin/bash ANACONDA_PATH="/opt/cloudera/parcels/Anaconda/" DEFAULT_ENV=`cat ${ANACONDA_PATH}/envs/default` source activate ${DEFAULT_ENV} if [ -z "${JUPYTERHUB_CLIENT_ID}" ]; then   while true; do       jupyterhub -f /etc/jupyterhub/jupyterhub_config.py   done else   HOME=`su ${JUPYTERHUB_USER} -c 'echo ~'`   cd ~   su ${JUPYTERHUB_USER} -p -c "jupyterhub-singleuser --KernelSpecManager.ensure_native_kernel=False --ip=0.0.0.0" fi

जुपिटर हॉकर कंटेनर से ज्यूपिटर डॉकटर कंटेनरों को शुरू करने की क्षमता ज्यूप्टरहब कंटेनर में डॉकर डेमन सॉकेट बढ़ते हुए हासिल की जाती है।

start-hub.sh

 VOLUMES="-<b>v/var/run/docker.sock:/var/run/docker.sock:Z -v/var/lib/pbis/.lsassd:/var/lib/pbis/.lsassd:Z</b> -v/var/lib/pbis/.netlogond:/var/lib/pbis/.netlogond:Z -v/var/jupyterhub/home:/home/BANK/:Z -v/u00/:/u00/:Z -v/tmp:/host/tmp:Z -v${CONFIG_DIR}/krb5.conf:/etc/krb5.conf:ro -v${CONFIG_DIR}/hadoop/:/etc/hadoop/conf.cloudera.yarn/:ro -v${CONFIG_DIR}/spark/:/etc/spark/conf.cloudera.spark_on_yarn/:ro -v${CONFIG_DIR}/spark2/:/etc/spark2/conf.cloudera.spark2_on_yarn/:ro -v${CONFIG_DIR}/jupyterhub/:/etc/jupyterhub/:ro" docker run -p0.0.0.0:8000:8000/tcp ${VOLUMES} -e VOLUMES="${VOLUMES}" -e HOST_HOSTNAME=`hostname -f` dsai1.2

भविष्य में, उदाहरण के लिए, ssh के पक्ष में इस निर्णय को छोड़ने की योजना है।

स्पार्क के साथ संयोजन में डॉकरस्पावर का उपयोग करते समय, एक और समस्या उत्पन्न होती है: स्पार्क चालक यादृच्छिक पोर्ट खोलता है, जिसके माध्यम से श्रमिक फिर एक बाहरी कनेक्शन स्थापित करते हैं। हम पोर्ट नंबरों की उस सीमा को नियंत्रित कर सकते हैं जहां से इन सीमाओं को स्पार्क कॉन्फ़िगरेशन में सेट करके यादृच्छिक का चयन किया जाता है। हालाँकि, ये रेंज अलग-अलग उपयोगकर्ताओं के लिए अलग-अलग होनी चाहिए, क्योंकि हम एक ही प्रकाशित पोर्ट के साथ जुपिटर कंटेनर नहीं चला सकते हैं। इस समस्या को हल करने के लिए, कोड में लिखा गया था कि केवल JupyterHub डेटाबेस से यूजर आईडी द्वारा पोर्ट रेंज जेनरेट करता है और उपयुक्त कॉन्फ़िगरेशन के साथ डॉकटर कंटेनर और स्पार्क लॉन्च करता है:

संपत्तियाँ / jupyterhub / dsai.py

 def set_extra_create_kwargs(self):       user_spark_driver_port, user_spark_blockmanager_port, user_spark_ui_port, user_spark_max_retries = self.get_spark_ports()       if user_spark_driver_port == 0 or user_spark_blockmanager_port == 0 or user_spark_ui_port == 0 or user_spark_max_retries == 0:           return       ports = {}       for p in range(user_spark_driver_port, user_spark_driver_port + user_spark_max_retries):           ports['%d/tcp' % p] = None       for p in range(user_spark_blockmanager_port, user_spark_blockmanager_port + user_spark_max_retries):           ports['%d/tcp' % p] = None       for p in range(user_spark_ui_port, user_spark_ui_port + user_spark_max_retries):           ports['%d/tcp' % p] = None self.extra_create_kwargs = { 'ports' : ports }

इस समाधान का नुकसान यह है कि जब आप कंटेनर को जुपिटरहब के साथ पुनरारंभ करते हैं, तो डेटाबेस हानि के कारण सब कुछ काम करना बंद कर देता है। इसलिए, जब आप JupyterHub को पुनः आरंभ करते हैं, उदाहरण के लिए, कॉन्फ़िगरेशन परिवर्तन, हम कंटेनर को स्वयं नहीं छूते हैं, लेकिन केवल उसके अंदर JupyterHub प्रक्रिया को पुनरारंभ करते हैं।

restart-hub.sh

 #!/bin/bash docker ps | fgrep 'dsai1.2' | fgrep -v 'jupyter-' | awk '{ print $1; }' | while read ID; do docker exec $ID /bin/bash -c "kill \$( cat /root/jupyterhub.pid )"; done

Cgroups खुद को मानक लिनक्स उपकरण द्वारा बनाया जाता है, कॉन्फ़िगरेशन में AD संस्थाओं और cgroups के बीच पत्राचार इस तरह दिखता है।

 <b>config-example/jupyterhub/jupyterhub_config.py</b> c.DSAISpawner.user_cgroup_parent = {   'bank\\user1'    : '/jupyter-cgroup-1', # user 1   'bank\\user2'    : '/jupyter-cgroup-1', # user 2   'bank\\user3'    : '/jupyter-cgroup-2', # user 3 } c.DSAISpawner.cgroup_parent = '/jupyter-cgroup-3'

Git कोड

हमारा समाधान सार्वजनिक रूप से GitHub: https://github.com/DS-AI/dsai/ (DSAI - Data Science and Artificial Intelligence) पर उपलब्ध है। सभी कोडों को क्रम संख्या के साथ निर्देशिकाओं में व्यवस्थित किया जाता है - प्रत्येक बाद की निर्देशिका के कोड पिछले एक से कलाकृतियों का उपयोग कर सकते हैं। अंतिम निर्देशिका से कोड का परिणाम एक डोकर छवि होगा।

प्रत्येक निर्देशिका में फ़ाइलें हैं:

एसेट्स.श - विधानसभा के लिए आवश्यक कलाकृतियों का निर्माण (इंटरनेट से डाउनलोड करना या पिछले चरणों की निर्देशिकाओं से प्रतिलिपि बनाना)
build.sh - निर्माण
clean.sh - विधानसभा के लिए आवश्यक कलाकृतियों की सफाई

डॉकर छवि को पूरी तरह से फिर से बनाने के लिए, उनके सीरियल नंबर के अनुसार डायरेक्टरी से क्लीन.श, एसेट्स.श, बिल्ड.श को चलाना आवश्यक है।

असेंबली के लिए, हम Linux RedHat 7.4, Docker 17.05.0-Ce के साथ एक मशीन का उपयोग करते हैं। मशीन में 8 कोर, 32 जीबी रैम और 250 जीबी डिस्क स्थान है। यह दृढ़ता से अनुशंसा की जाती है कि आप इसे बनाने के लिए सबसे खराब रैम और एचडीडी सेटिंग्स के साथ एक मेजबान का उपयोग न करें।

यहाँ इस्तेमाल किए गए नामों के लिए सहायता है:

01-स्पार्क-पैचेड - RPM स्पार्क 1.6.1 ने दो पैच के साथ SPARK-4563 और SPARK-19019 को लागू किया।
02-सत्यापनकर्ता - पार्सल सत्यापनकर्ता
03-एनाकोंडा-डीएसई-पार्सल-1.0 - पार्सल एनाकोंडा सही पायथन (2, 3.5 इंच और 3.6 इंच) के साथ
04-क्लाउडडर-मैनेजर-एपीआई - क्लाउडरा प्रबंधक एपीआई लाइब्रेरी
05-dsai1.2-offline - अंतिम छवि

काश, असेंबली उन कारणों से क्रैश हो सकती है जिन्हें हम ठीक करने में असमर्थ थे (उदाहरण के लिए, पार्सल की असेंबली के दौरान टार को गिरा दिया जाता है । इस मामले में, एक नियम के रूप में, आपको बस असेंबली को पुनरारंभ करने की आवश्यकता है, लेकिन यह हमेशा मदद नहीं करता है (उदाहरण के लिए, स्पैन्सल असेंबली बाहरी संसाधनों पर निर्भर करता है) क्लाउडरा, जो अब उपलब्ध नहीं हो सकता है, आदि)।

एक और कमी पार्सल असेंबली irreproducible है। चूंकि पुस्तकालयों को लगातार अपडेट किया जाता है, इसलिए विधानसभा की पुनरावृत्ति पिछले एक से भिन्न परिणाम दे सकती है।

ग्रैंड फिनाले

अब उपयोगकर्ता सफलतापूर्वक टूल का उपयोग कर रहे हैं, उनकी संख्या कई दर्जन से अधिक हो गई है और बढ़ना जारी है। भविष्य में, हम JupyterLab की कोशिश करने की योजना बनाते हैं और GPU को क्लस्टर से जोड़ने के बारे में सोच रहे हैं, क्योंकि अब दो काफी शक्तिशाली एप्लिकेशन सर्वर के कंप्यूटिंग संसाधन अब पर्याप्त नहीं हैं।

ज्यूपिटर की अनुमति क्या है?