بدأت قصتنا بمهمة تبدو بسيطة. كان من الضروري إعداد أدوات تحليلية لمتخصصي علوم البيانات ومحللي البيانات فقط. لقد تم توجيه هذه المهمة إلينا من قبل زملاء من أقسام مخاطر التجزئة وإدارة علاقات العملاء ، حيث كان تركيز المتخصصين في علم البيانات مرتفعًا من الناحية التاريخية. كان لدى العملاء رغبة بسيطة - كتابة شفرة Python ، واستيراد مكتبات متقدمة (xgboost ، و pytorch ، و tensorflow ، وما إلى ذلك) وتشغيل الخوارزميات على البيانات التي تم جمعها من مجموعة hdfs.
يبدو أن كل شيء بسيط وواضح. ولكن كان هناك الكثير من المزالق التي قررنا أن نكتب منشورًا عنها وننشر الحل الجاهز على GitHub.
أولاً ، بعض التفاصيل حول البنية التحتية للمصدر:
- HDFS Data Warehouse (12 عقد Oracle Big Data Appliance ، توزيع Cloudera). في المجموع ، يحتوي المستودع على 130 تيرابايت من البيانات من مختلف النظم الداخلية للبنك ؛ وهناك أيضًا معلومات غير متجانسة من مصادر خارجية.
- اثنين من خوادم التطبيقات التي كان من المفترض نشر الأدوات التحليلية. تجدر الإشارة إلى أن مهام التحليل المتقدمة ليست فقط "تدور" على هذه الخوادم ، لذلك كان أحد المتطلبات هو استخدام أدوات حاويات (Docker) لإدارة موارد الخادم ، واستخدام بيئات مختلفة وتكوينها.
باعتبارها البيئة الرئيسية لعمل المحللين ، فقد قرروا اختيار JupyterHub ، والذي أصبح بالفعل أحد المعايير للعمل مع البيانات وتطوير نماذج التعلم الآلي. اقرأ المزيد عنها
هنا . في المستقبل ، تخيلنا بالفعل JupyterLab.
يبدو أن كل شيء بسيط: عليك أن تأخذ وتكوين مجموعة من Python + Anaconda + Spark. قم بتثبيت Jupyter Hub على خادم التطبيق ، والتكامل مع LDAP ، أو توصيل Spark أو الاتصال ببيانات hdfs بطريقة أخرى والمضي قدمًا - إنشاء نماذج!
إذا بحثت في جميع البيانات والمتطلبات المصدر ، فإليك قائمة أكثر تفصيلاً:
- تشغيل JupyterHub في Docker (نظام التشغيل الأساسي - Oracle Linux 7)
- Cloudera CDH 5.15.1 cluster + Spark 2.3.0 مع مصادقة Kerberos في تكوين Active Directory + Kerberos MIT مخصص في الكتلة (انظر Clust-Dedicated MIT KDC مع Active Directory ) ، Oracle Linux 6
- تكامل الدليل النشط
- مصادقة شفافة في Hadoop و Spark
- بيثون 2 و 3 الدعم
- الشرارة 1 و 2 (مع القدرة على استخدام موارد المجموعة لنماذج التدريب وموازنة معالجة البيانات باستخدام pyspark)
- القدرة على الحد من موارد المضيف
- مجموعة المكتبة
تم تصميم هذا المنشور لمتخصصي تكنولوجيا المعلومات الذين يواجهون الحاجة إلى حل هذه المشكلات.
وصف الحل
إطلاق في Docker + Cloudera Cluster Integration
لا يوجد شيء غير عادي هنا. يتم تثبيت عملاء منتجات JupyterHub و Cloudera في الحاوية (كما هو موضح أدناه) ، ويتم تثبيت ملفات التكوين من الجهاز المضيف:
start-hub.shVOLUMES="-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
تكامل الدليل النشط
للتكامل مع الحديد Active Directory / Kerberos وليس المضيفين للغاية ، فإن المعيار في شركتنا هو منتج
PBIS Open . تقنيًا ، هذا المنتج عبارة عن مجموعة من الخدمات التي تتصل بـ Active Directory ، والتي بدورها تعمل العملاء من خلال مآخذ المجال unix. يتكامل هذا المنتج مع Linux PAM و NSS.
استخدمنا طريقة Docker القياسية - حيث تم تركيب مآخذ مجال خدمات المضيف في يونكس في حاوية (تم العثور على مآخذ تجريبية من خلال عمليات بسيطة باستخدام الأمر 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
بدوره ، يتم تثبيت حزم PBIS داخل الحاوية ، ولكن دون تنفيذ قسم postinstall. لذلك نضع الملفات والمكتبات القابلة للتنفيذ فقط ، لكن لا تبدأ الخدمات داخل الحاوية - وهذا أمر لا لزوم له بالنسبة لنا. يتم تشغيل أوامر تكامل PAM و NSS Linux يدويًا.
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 الذي تم تكوينه بشكل صحيح على المضيف ، كل شيء يعمل خارج الصندوق.
لمنع جميع المستخدمين من م من دخول JupyterHub ، يمكنك استخدام الإعداد الذي يقيد المستخدمين إلى مجموعات م محددة.
config-example / jupyterhub / jupyterhub_config.py c.DSAIAuthenticator.group_whitelist = ['COMPANY\\domain^users']
مصادقة شفافة في Hadoop و Spark
عند تسجيل الدخول إلى JupyterHub ، تخزن PBIS تذكرة Kerberos للمستخدم في ملف محدد في الدليل / tmp. للمصادقة الشفافة بهذه الطريقة ، يكفي تحميل دليل / 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 تنفيذ أوامر hdfs من محطة Jupyter وتشغيل مهام Spark دون خطوات مصادقة إضافية. تثبيت دليل / tmp بأكمله للمضيف في الحاوية غير آمن - نحن على دراية بهذه المشكلة ، لكن الحل لا يزال قيد التطوير.
إصدارات بايثون 2 و 3
هنا ، يبدو أن كل شيء بسيط: تحتاج إلى تثبيت الإصدارات الضرورية من Python ودمجها مع Jupyter ، مما يؤدي إلى إنشاء Kernel الضروري. تمت تغطية هذه المشكلة بالفعل في العديد من الأماكن. يستخدم كوندا لإدارة بيئات بيثون. لماذا كل البساطة واضحة فقط سيكون واضحا من القسم التالي. مثال Kernel لـ Python 3.6 (هذا الملف ليس موجودًا في git - يتم إنشاء جميع ملفات kernel بواسطة الكود):
/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
للتكامل مع عملاء SPARK ، تحتاج أيضًا إلى إنشاء Kernels. مثال Kernel لـ Python 3.6 و SPARK 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" } }
لاحظ فقط أن متطلبات الحصول على دعم Spark 1 قد تطورت تاريخياً. ومع ذلك ، من الممكن أن يواجه شخص ما قيودًا مماثلة - لا يمكنك ، على سبيل المثال ، تثبيت Spark 2 في كتلة. لذلك ، نصف هنا المزالق التي التقينا بها في طريق التنفيذ.
أولاً ،
لا يعمل Spark 1.6.1 مع Python 3.6. ومن المثير للاهتمام ، في CDH 5.12.1 تم إصلاح هذا ، ولكن في 5.15.1 - لسبب ما لا). في البداية ، أردنا حل هذه المشكلة ببساطة عن طريق تطبيق التصحيح المناسب. ومع ذلك ، في المستقبل ، كان لا بد من التخلي عن هذه الفكرة ، لأن هذا النهج يتطلب تثبيت شرارة معدلة في كتلة ، وهو ما كان غير مقبول بالنسبة لنا. تم العثور على الحل في إنشاء بيئة كوندا منفصلة مع Python 3.5.
المشكلة الثانية يمنع Spark 1 من العمل داخل Docker. يفتح برنامج تشغيل Spark منفذًا محددًا يتصل العامل من خلاله ببرنامج التشغيل - ولهذا السبب يرسل برنامج التشغيل عنوان IP الخاص به. في حالة Docker Worker ، يحاول الاتصال ببرنامج التشغيل عبر IP للحاوية ، وعند استخدام الشبكة = جسر لا يعمل بشكل طبيعي.
الحل الواضح هو عدم إرسال IP للحاوية ، ولكن IP للمضيف ، والذي تم
تطبيقه في Spark 2 عن طريق إضافة إعدادات التكوين المناسبة. تمت إعادة تصميم هذا التصحيح بشكل خلاق وتطبيقه على Spark 1. لا يلزم وضع Spark المعدلة بهذه الطريقة على مضيفي الكتلة ، وبالتالي ، لا تنشأ مشكلة مشابهة لعدم التوافق مع Python 3.6.
بغض النظر عن إصدار Spark ، نظرًا لوظائفها ، فمن الضروري أن يكون لديك نفس إصدارات Python في المجموعة كما في الحاوية. لتثبيت Anaconda مباشرة لتجاوز Cloudera Manager ، كان علينا أن نتعلم القيام بأمرين:
- بناء الطرود الخاصة بك مع أناكوندا وجميع البيئات الصحيحة
- تثبيته في Docker (للتناسق)
تجميع الطرود اناكوندا
هذا تبين أن مهمة بسيطة إلى حد ما. كل ما تحتاجه هو:
- قم بإعداد محتوى الطرد عن طريق تثبيت الإصدارات المطلوبة من بيئة أناكوندا وبيثون
- إنشاء ملف (ملفات) بيانات أولية ووضعها في دليل التعريف
- إنشاء الطرود مع القطران بسيطة
- التحقق من صحة الطرود فائدة من Cloudera
تم وصف العملية بمزيد من التفصيل على
GitHub ، وهناك أيضًا رمز المدقق هناك. لقد استعارنا البيانات الوصفية في
طرد Anaconda الرسمي لشركة Cloudera ، ونعيد ابتكارها بشكل خلاق.
تثبيت الطرود في عامل الميناء
أثبتت هذه الممارسة أنها مفيدة لسببين:
- ضمان إمكانية تشغيل Spark - من المستحيل وضع Anaconda في كتلة بدون طرد
- يتم توزيع Spark 2 فقط في شكل طرد - يمكنك بالطبع تثبيته في حاوية في شكل ملفات jar فقط ، ولكن تم رفض هذا النهج
على سبيل المكافأة ، نتيجة لحل المشكلات المذكورة أعلاه ، تلقينا:
- سهولة إعداد عملاء Hadoop و Spark - عند تثبيت نفس الطرود في Docker وفي الكتلة ، تكون المسارات على الكتلة وفي الحاوية متماثلة
- سهولة الحفاظ على بيئة موحدة في الحاوية وفي المجموعة - عند تحديث الكتلة ، تتم إعادة إنشاء صورة Docker بنفس الطرود التي تم تثبيتها في الكتلة.
لتثبيت الطرود في Docker ، يتم تثبيت Cloudera Manager لأول مرة من حزم RPM. للتثبيت الفعلي للطرود ، يتم استخدام كود جافا. يعرف العميل في Java ما لا يمكن للعميل في Python القيام به ، لذلك اضطررت إلى استخدام Java وتفقد بعض التوحيد) ، والتي تستدعي API.
الأصول / تثبيت الطرود / 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); } }
قيود المورد المضيف
لإدارة موارد الجهاز المضيف ، يتم استخدام مزيج من
DockerSpawner - وهو مكون يقوم بتشغيل المستخدمين النهائيين لـ Jupyter في حاوية Docker منفصلة - و
cgroups - آلية لإدارة الموارد في Linux. يستخدم DockerSpawner واجهة برمجة تطبيقات Docker ، والتي تسمح لك بتعيين cgroup الأصل للحاوية. لا يوجد مثل هذا الاحتمال في DockerSpawner العادية ، لذلك كتبنا رمزًا بسيطًا يسمح لنا بضبط المراسلات بين الكيانات AD ومجموعة الأم الأصل في التكوين.
الأصول / 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
تم إدخال تعديل صغير يقوم بإطلاق Jupyter من نفس الصورة التي تم إطلاق JupyterHub منها. لذلك ، ليست هناك حاجة لاستخدام أكثر من صورة واحدة.
الأصول / 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']
يتم تحديد بالضبط ما يتم تشغيله في الحاوية ، Jupyter أو JupyterHub ، في البرنامج النصي لبدء التشغيل بواسطة متغيرات البيئة:
الأصول / 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
يتم تحقيق القدرة على بدء تشغيل حاوية Jupyter Docker من حاوية JupyterHub Docker من خلال تركيب مقبس Docker daemon في حاوية JupyterHub.
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
في المستقبل ، من المخطط التخلي عن هذا القرار لصالح ، على سبيل المثال ، سه.
عند استخدام DockerSpawner بالاقتران مع Spark ، تنشأ مشكلة أخرى: يفتح برنامج تشغيل Spark منافذ عشوائية ، يقوم العمال من خلالها بتأسيس اتصال خارجي. يمكننا التحكم في نطاق أرقام المنافذ التي يتم تحديد أرقام عشوائية منها عن طريق تعيين هذه النطاقات في تكوين Spark. ومع ذلك ، يجب أن تكون هذه النطاقات مختلفة للمستخدمين المختلفين ، حيث لا يمكننا تشغيل حاويات Jupyter مع المنافذ المنشورة نفسها. لحل هذه المشكلة ، تمت كتابة التعليمات البرمجية التي تنشئ نطاقات المنافذ ببساطة بواسطة معرف المستخدم من قاعدة بيانات JupyterHub وتطلق حاوية Docker و Spark مع التكوين المناسب:
الأصول / 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 ، على سبيل المثال ، تغيير التكوين ، فإننا لا نلمس الحاوية نفسها ، ولكننا نعيد فقط عملية 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 نفسها بواسطة أدوات Linux القياسية ، ويبدو أن المراسلات بين كيانات ميلادي ومجموعات 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'
رمز بوابة
حلنا متاح للجمهور على GitHub:
https://github.com/DS-AI/dsai/ (DSAI - علوم البيانات والذكاء الاصطناعي). يتم ترتيب جميع التعليمات البرمجية في الدلائل مع الأرقام التسلسلية - رمز من كل دليل لاحق يمكن استخدام القطع الأثرية من السابق. ستكون نتيجة الرمز من الدليل الأخير صورة Docker.
كل دليل يحتوي على ملفات:
- الأصول.sh - إنشاء الأعمال الفنية اللازمة للتجميع (التنزيل من الإنترنت أو نسخ من الدلائل من الخطوات السابقة)
- build.sh - بناء
- clean.sh - تنظيف القطع اللازمة للتجميع
من أجل إعادة إنشاء صورة Docker بشكل كامل ، من الضروري تشغيل clean.sh ، stocks.sh ، build.sh من الأدلة وفقًا لأرقامها التسلسلية.
للتجميع ، نستخدم جهازًا يعمل بنظام Linux RedHat 7.4 ، Docker 17.05.0-ce. الجهاز يحتوي على 8 النوى ، ذاكرة الوصول العشوائي 32 جيجابايت و 250 جيجابايت من مساحة القرص. يوصى بشدة بعدم استخدام مضيف له أسوأ إعدادات RAM و HDD لإنشاءه.
فيما يلي المساعدة للأسماء المستخدمة:
- 01-spark-patched - تم تطبيق RPM Spark 1.6.1 مع رقعتين SPARK-4563 و SPARK-19019.
- 02-validator - لا يتجزأ من المدقق
- 03-anaconda-dsai-parcel-1.0 - لا يتجزأ أناكوندا مع بيثون الصحيح (2 ، 3.5 و 3.6)
- 04-cloudera-manager-api - مكتبات API Cloudera Manager
- 05-dsai1.2-offline - الصورة النهائية
للأسف ، قد يتعطل التجميع لأسباب لم نتمكن من إصلاحها (على سبيل المثال ،
يتم إسقاط القطران أثناء تجميع الطرود. في هذه الحالة ، تحتاج فقط إلى إعادة تشغيل التجميع ، لكن هذا لا يساعد دائمًا (على سبيل المثال ، يعتمد Spark assembly على الموارد الخارجية Cloudera ، والتي قد لا تكون متاحة ، وما إلى ذلك).
عيب آخر هو أن مجموعة الطرود غير قابلة للإنتاج. نظرًا لأن المكتبات يتم تحديثها باستمرار ، فقد ينتج عن تكرار التجميع نتيجة مختلفة عن سابقتها.
النهائي الكبير
الآن يستخدم المستخدمون الأدوات بنجاح ، وقد تجاوز عددهم العشرات ويستمر في النمو. في المستقبل ، نخطط لتجربة JupyterLab ونفكر في توصيل وحدة معالجة الرسومات (GPU) بالمجموعة ، لأن موارد الحوسبة لخادمي تطبيقات قويين إلى حد ما لم تعد كافية الآن.