أباتشي Bigtop واختيار توزيع Hadoop اليوم



ربما لم يكن سرا أن العام الماضي كان عام التغيير الكبير لأباتشي هادووب. في العام الماضي ، تم دمج Cloudera و Hortonworks (بشكل أساسي الاستحواذ على الثانية) ، وتم بيع Mapr ، بسبب مشاكل مالية خطيرة ، لشركة Hewlett Packard. وإذا كان ذلك قبل بضع سنوات ، في حالة التركيبات الداخلية ، غالبًا ما كان يجب الاختيار بين Cloudera و Hortonworks ، اليوم ، للأسف ، لم يكن لدينا هذا الاختيار. المفاجأة الأخرى كانت حقيقة أنه منذ فبراير من هذا العام ، أعلنت Cloudera إنهاء الإفراج عن التجميعات الثنائية لتوزيعها في مستودع عام ، وهي متاحة الآن فقط عن طريق الاشتراك المدفوع. بالطبع ، لا تزال القدرة على تنزيل أحدث إصدارات CDH و HDP ، التي تم إصدارها قبل نهاية عام 2019 ، موجودة ، ويتوقع دعمها لمدة عام إلى عامين. ولكن ماذا تفعل بعد ذلك؟ لأولئك،الذي دفع مقابل الاشتراك سابقًا ، لم يتغير شيء. وبالنسبة لأولئك الذين لا يريدون التبديل إلى إصدار مدفوع من مجموعة التوزيع ، ولكنهم يريدون الحصول على أحدث الإصدارات من مكونات نظام المجموعة ، بالإضافة إلى التصحيحات والتحديثات الأخرى ، قمنا بإعداد هذه المقالة. في ذلك ، سننظر في الطرق الممكنة للخروج من هذا الوضع.

. , . ? Arenadata Hadoop, , . Vanilla Hadoop, , “” Apache Bigtop. ? .

Arenadata Hadoop




هذا توزيع جديد تمامًا وغير معروف حتى الآن للتنمية المحلية. لسوء الحظ ، في الوقت الحالي لا يوجد سوى هذا المقال عن حبري حول هذا الموضوع .

يمكن العثور على مزيد من المعلومات على الموقع الرسمي للمشروع. تعتمد أحدث التوزيعات على Hadoop 3.1.2 للنسخة 3 و 2.8.5 للنسخة 2.

يمكن العثور على معلومات حول خريطة الطريق هنا .


Arenadata Cluster Manager Interface

المنتج الرئيسي لـ Arenadata هو Arenadata Cluster Manager (ADCM)والذي يستخدم لتثبيت وتكوين ومراقبة الحلول البرمجية المختلفة للشركة. ADCM مجاني ، ويتم توسيع وظائفه عن طريق إضافة حزم إليه ، وهي مجموعة من كتب اللعب غير المرئية. تنقسم الحزم إلى نوعين: المؤسسة والمجتمع. تتوفر هذه الأخيرة للتحميل المجاني من Arenadata. من الممكن أيضًا تطوير الحزمة الخاصة بك وتوصيلها بـ ADCM.

لنشر Hadoop 3 وإدارته ، يتم تقديم نسخة مجتمعية من الحزمة بالتزامن مع ADCM ، وبالنسبة لـ hadoop 2 ، لا يتوفر سوى Apache Ambariكبديل. أما بالنسبة للمستودعات التي تحتوي على حزم ، فهي مفتوحة للوصول العام ، ويمكن تنزيلها وتثبيتها بالطريقة المعتادة لجميع مكونات المجموعة. بشكل عام ، يبدو التوزيع مثيرًا للاهتمام. أنا متأكد من أن هناك من اعتادوا على حلول مثل Cloudera Manager و Ambari ، والذين سيحبون ADCM نفسها. بالنسبة للبعض ، فإن حقيقة أن مجموعة التوزيع مدرجة في سجل برامج استبدال الواردات ستكون إضافة كبيرة .

إذا تحدثنا عن السلبيات ، فستكون هي نفسها بالنسبة لجميع توزيعات Hadoop الأخرى. يسمى:

  • ما يسمى ب "حبس البائع". باستخدام أمثلة Cloudera و Hortonworks ، أدركنا بالفعل أن هناك دائمًا خطر تغيير سياسات الشركة.
  • تأخر كبير خلف المنبع أباتشي.

فانيلا هادوب




كما تعلم ، فإن Hadoop ليس منتجًا متآلفًا ، ولكنه في الواقع مجموعة كاملة من الخدمات حول نظام ملفات HDFS الموزع. قليل من الناس سيحتاجون إلى مجموعة ملفات واحدة. يحتاج المرء إلى Hive ، والآخر Presto ، وهناك HBase و Phoenix ، يتم استخدام Spark بشكل متزايد. تم العثور على Oozie و Sqoop و Flume في بعض الأحيان لتنظيم وتنزيل البيانات. وإذا ظهرت مشكلة أمنية ، يتم تذكر Kerberos بالاشتراك مع Ranger على الفور.

تتوفر الإصدارات الثنائية لمكونات Hadoop على موقع الويب لكل مشروع نظام بيئي في شكل كرات. يمكن تنزيلها وبدء التثبيت ، ولكن بشرط واحد: بالإضافة إلى التجميع الذاتي للحزم من ثنائيات "أولية" ، والتي من المحتمل أن ترغب في تشغيلها ، لن يكون لديك أي ثقة في توافق الإصدارات التي تم تنزيلها من المكونات مع بعضها البعض. الخيار المفضل هو البناء باستخدام Apache Bigtop. يسمح لك Bigtop بالبناء من مستودعات Apache الرائعة ، وإجراء الاختبارات ، وبناء الحزم. ولكن ، وهو أمر مهم للغاية بالنسبة لنا ، سيجمع Bigtop تلك الإصدارات من المكونات التي ستكون متوافقة مع بعضها البعض. سنتحدث عنه بمزيد من التفصيل أدناه.

اباتشي bigtop




Apache Bigtop هي أداة لبناء وتعبئة واختبار عدد من
المشاريع مفتوحة المصدر ، على سبيل المثال ، Hadoop و Greenplum. لدى Bigtop العديد من
الإصدارات. في وقت كتابة هذا التقرير ، كان الإصدار المستقر الأخير هو الإصدار 1.4 ، وكان في الإصدار
الرئيسي 1.5. تستخدم الإصدارات المختلفة من الإصدارات إصدارات مختلفة من
المكونات. على سبيل المثال ، بالنسبة لـ 1.4 ، فإن مكونات Hadoop الأساسية هي الإصدار 2.8.5 ، وفي الإصدار الرئيسي
2.10.0. يتم أيضًا تغيير تكوين المكونات المدعومة. هناك شيء عفا عليه الزمن
وغير قابل للتجديد ، ويأتي مكانه شيئًا جديدًا ، وأكثر طلبًا ،
وليس بالضرورة شيء من عائلة Apache نفسها.

لدى Bigtop أيضًا العديد من الشوك .

عندما بدأنا في التعرف على Bigtop ، فوجئنا بشكل أساسي بتواضعه ، مقارنةً بمشاريع أباتشي الأخرى ، الانتشار والشهرة ، بالإضافة إلى مجتمع صغير جدًا. ويترتب على ذلك أن هناك حد أدنى من معلومات المنتج ، وقد لا ينتج عن البحث عن حلول للمشاكل التي نشأت من خلال المنتديات والرسائل الإخبارية أي شيء على الإطلاق. في البداية ، اتضح أن المهمة الصعبة بالنسبة لنا أن نكمل تجميع مجموعة التوزيع بسبب ميزات الأداة نفسها ، ولكننا سنتحدث عن ذلك بعد ذلك بقليل.

كإعلان تشويقي ، بالنسبة لأولئك الذين زاروا مرة واحدة مشروعات الكون Linux مثل Gentoo و LFS ، قد يبدو من الحنين إلى العمل مع هذا الشيء والتذكر تلك الأوقات "السابقة" عندما بحثنا أنفسنا عن (أو حتى كتبنا) عمليات بناء إلكترونية وإعادة بنائها بانتظام مع بقع جديدة موزيلا.

يمكن اعتبار الزيادة الكبيرة في Bigtop هي انفتاح وتعدد الأدوات التي تستند إليها. أساسها هو Gradle و Apache Maven. يُعرف Gradle بشكل معقول بأنه الأداة التي تجمعها Google من أجل Android. إنها مرنة ، وكما يقولون ، "تم اختبارها في المعركة". Maven هي أداة بدوام كامل لبناء المشاريع في Apache نفسها ، وبما أن معظم منتجاتها يتم إصدارها من خلال Maven ، فلا يمكن الاستغناء عنها. يجدر الانتباه إلى POM (نموذج كائن المشروع) - ملف xml "أساسي" مع وصف لكل ما هو ضروري لكي يعمل Maven مع مشروعك ، والذي يتم بناء جميع الأعمال حوله. في
الجزء المخضرم تظهر بعض العقبات التي عادة ما تصادف للمرة الأولى عندما تأخذ Bigtop.

ممارسة


إذن من أين تبدأ؟ ننتقل إلى صفحة التنزيل ونقوم بتنزيل أحدث إصدار ثابت كأرشيف. يمكن العثور على القطع الأثرية الثنائية التي جمعتها Bigtop هناك. بالمناسبة ، من بين مديري الحزم المشتركة ، يتم دعم YUM و APT.

بدلاً من ذلك ، يمكنك تنزيل أحدث إصدار ثابت مباشرة من
github:

$ git clone --branch branch-1.4 https://github.com/apache/bigtop.git

الاستنساخ في "bigtop" ...

remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 40217 (delta 14), reused 10 (delta 1), pack-reused 40171
 : 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, .
 : 100% (20503/20503), .
Updating files: 100% (1998/1998), .

يبدو الدليل ./bigtop الناتج شيئًا مثل هذا:

./bigtop-bigpetstore- تطبيقات تجريبية ، أمثلة اصطناعية
./bigtop-ci- أدوات CI ، جنكينز
./bigtop-data-generators- توليد البيانات ، المواد التركيبية ، لاختبارات الدخان ، إلخ.
./bigtop-deploy- أدوات النشر
./bigtop-packages- التكوينات ، البرامج النصية ، التصحيحات للتجميع ، الجزء الرئيسي من الأداة
./bigtop-test-framework- إطار
./bigtop-testsالاختبار - الاختبارات نفسها ، الإجهاد والدخان
./bigtop_toolchain- بيئة التجميع ، إعداد البيئة لأداة العمل
./build- دليل عمل التجميع
./dl- دليل المصادر التي تم تنزيلها
./docker- التجميع في عامل الميناء - الصور ، والاختبار
./gradle- gradle config
./output - الدليل الذي تدخل فيه عناصر التجميع
./provisioner- التزويد

الأكثر إثارة للاهتمام بالنسبة لنا في هذه المرحلة هو التكوين الرئيسي./bigtop/bigtop.bom، حيث نرى جميع المكونات المدعومة مع الإصدارات. هذا هو المكان الذي يمكننا فيه تحديد إصدار مختلف من المنتج (إذا أردنا فجأة محاولة إنشائه) أو إصدار من التجميع (إذا أضفنا ، على سبيل المثال ، رقعة مهمة).

كما أن الدليل الفرعي ذو أهمية كبيرة ./bigtop/bigtop-packages، والذي يرتبط بشكل مباشر بعملية تجميع المكونات والحزم معهم.

لذا ، قمنا بتنزيل الأرشيف أو فكه أو إنشاء نسخة مع github ، هل يمكننا بدء التجميع؟

لا ، أعد البيئة أولاً.

إعداد البيئة


وهنا هناك حاجة إلى انضغاط صغير. لبناء أي منتج أكثر أو أقل تعقيدًا تقريبًا ، تحتاج إلى بيئة معينة - في حالتنا ، فهي JDK ، نفس المكتبات المشتركة ، ملفات الرأس ، وما إلى ذلك ، والأدوات ، على سبيل المثال ، النملة ، ivy2 وأكثر من ذلك بكثير. أحد الخيارات للحصول على البيئة اللازمة لـ Bigtop هو تثبيت المكونات الضرورية على مضيف التجميع. قد أكون مخطئًا في التسلسل الزمني ، ولكن يبدو أنه من الإصدار 1.0 كان هناك أيضًا خيار بناء في صور عامل إرساء مهيأة مسبقًا ويمكن الوصول إليها ، يمكنك العثور عليها هنا.

أما بالنسبة لإعداد البيئة ، فهناك مساعد لهذا - دمية.

يمكنك استخدام الأوامر التالية ، ويتم الإطلاق من الدليل الجذر
للأداة ،./bigtop:

./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules

أو مباشرة من خلال دمية:

puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::installer"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::deployment-tools"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::development-tools"

لسوء الحظ ، قد تنشأ صعوبات بالفعل في هذه المرحلة. النصيحة العامة هنا هي استخدام توزيع مدعوم ، محدث على مضيف البناء ، أو تجربة المسار مع عامل الميناء.

المجسم


ما الذي نحاول جمعه؟ الجواب على هذا السؤال سيعطي إخراج الأمر

./gradlew tasks

يحتوي قسم مهام الحزم على عدد من المنتجات التي تعد القطع الأثرية النهائية لـ Bigtop.
يمكن تحديدها بواسطة اللاحقة -rpm أو -pkg-ind (في حالة التجميع
في عامل الميناء). في حالتنا ، الأكثر إثارة للاهتمام هو Hadoop.

دعونا نحاول البناء في بيئة خادم البناء لدينا:

./gradlew hadoop-rpm

ستقوم Bigtop نفسها بتنزيل المصادر الضرورية اللازمة لمكون معين وتبدأ في البناء. وبالتالي ، ترتبط الأداة بمستودعات Maven ومصادر أخرى ، أي أنها تحتاج إلى الوصول إلى الإنترنت.

في هذه العملية ، يتم تكوين ناتج قياسي. في بعض الأحيان يمكنك أن تفهم منه ورسائل الخطأ ما حدث من خطأ. وأحيانًا تحتاج إلى مزيد من المعلومات. في هذه الحالة ، يجدر إضافة الحجج --info أو --debug، وقد يكون مفيدًا أيضًا –stacktrace. هناك طريقة ملائمة لإنشاء مجموعة بيانات للرجوع إليها لاحقًا في القوائم البريدية ، المفتاح --scan.

مع ذلك ، ستجمع bigtop جميع المعلومات وتضعها في تدرج ، وبعد ذلك ستعطي رابطًا ،
وبعد ذلك سيتمكن الشخص المختص من فهم سبب فشل التجميع.
يجب أن تضع في اعتبارك أن هذا الخيار قد يجعل المعلومات غير مرغوب فيها بالنسبة لك علنية ، مثل أسماء المستخدمين والعقد ومتغيرات البيئة وما إلى ذلك ، لذا كن حذرًا.

غالبًا ما تكون الأخطاء ناتجة عن عدم القدرة على الحصول على أي مكونات ضرورية للتجميع. كقاعدة ، يمكنك إصلاح المشكلة عن طريق إنشاء تصحيح لإصلاح شيء ما في المصدر ، على سبيل المثال ، العنوان في pom.xml في الدليل الجذر للمصدر. يتم ذلك عن طريق إنشائه ووضعه في دليل ./bigtop/bigtop-packages/src/common/oozie/التصحيح المناسب ، على سبيل المثال ، في شكل patch2-fix.diff.

--- a/pom.xml
+++ b/pom.xml
@@ -136,7 +136,7 @@
<repositories>
<repository>
<id>central</id>
- <url>http://repo1.maven.org/maven2</url>
+ <url>https://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>

على الأرجح ، في وقت قراءة هذا المقال ، لن تحتاج إلى التصحيح أعلاه.

عند إدخال أي تصحيحات وتعديلات في آلية التجميع ، قد تحتاج إلى "إعادة تعيين" التجميع من خلال أمر التنظيف:

./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executed

ستعيد هذه العملية جميع التغييرات في تجميع هذا المكون ، وبعد ذلك سيتم تنفيذ التجميع مرة أخرى. هذه المرة سنحاول بناء المشروع في صورة عامل ميناء:

./gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Building 1.2.1 hadoop-pkg on centos-7 in Docker...
+++ dirname ./bigtop-ci/build.sh
++ cd ./bigtop-ci/..
++ pwd
+ BIGTOP_HOME=/tmp/bigtop
+ '[' 6 -eq 0 ']'
+ [[ 6 -gt 0 ]]
+ key=--prefix
+ case $key in
+ PREFIX=1.2.1
+ shift
+ shift
+ [[ 4 -gt 0 ]]
+ key=--os
+ case $key in
+ OS=centos-7
+ shift
+ shift
+ [[ 2 -gt 0 ]]
+ key=--target
+ case $key in
+ TARGET=hadoop-pkg
+ shift
+ shift
+ [[ 0 -gt 0 ]]
+ '[' -z x ']'
+ '[' -z x ']'
+ '[' '' == true ']'
+ IMAGE_NAME=bigtop/slaves:1.2.1-centos-7
++ uname -m
+ ARCH=x86_64
+ '[' x86_64 '!=' x86_64 ']'
++ docker run -d bigtop/slaves:1.2.1-centos-7 /sbin/init
+
CONTAINER_ID=0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8
+ trap 'docker rm -f
0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8' EXIT
....
 
....
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-client-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-debuginfo-2.8.5-1.el7.x86_64.rpm
+ umask 022
+ cd /bigtop/build/hadoop/rpm//BUILD
+ cd hadoop-2.8.5-src
+ /usr/bin/rm -rf /bigtop/build/hadoop/rpm/BUILDROOT/hadoop-2.8.5-1.el7.x86_64
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.CwDb22
+ cd /bigtop/build/hadoop/rpm//BUILD
+ rm -rf hadoop-2.8.5-src
+ exit 0
[ant:touch] Creating /bigtop/build/hadoop/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) completed. Took 38 mins 1.151 secs.
:hadoop-pkg (Thread[Task worker for ':',5,main]) started.
> Task :hadoop-pkg
Task ':hadoop-pkg' is not up-to-date because:
Task has not declared any outputs despite executing actions.
:hadoop-pkg (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
BUILD SUCCESSFUL in 40m 37s
6 actionable tasks: 6 executed
+ RESULT=0
+ mkdir -p output
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/build .
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/output .
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
+ '[' 0 -ne 0 ']'
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
Error: No such container:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD SUCCESSFUL in 41m 24s
1 actionable task: 1 executed

تم البناء تحت CentOS ، ولكن يمكنك أيضًا القيام بذلك تحت Ubuntu:

./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-ind

بالإضافة إلى تجميع الحزم لمختلف توزيعات Linux ، يمكن للأداة إنشاء مستودع بحزم مجمعة ، على سبيل المثال:

./gradlew yum

قد تتذكر أيضًا اختبارات الدخان والنشر في عامل الميناء.

إنشاء مجموعة من ثلاث عقد:

./gradlew -Pnum_instances=3 docker-provisioner

قم بإجراء اختبارات الدخان في مجموعة من ثلاث عقد:

./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisioner

حذف المجموعة:

./gradlew docker-provisioner-destroy

احصل على أوامر للتوصيل داخل حاويات عامل الميناء:

./gradlew docker-provisioner-ssh

إظهار الحالة:

./gradlew docker-provisioner-status

يمكنك قراءة المزيد حول مهام النشر في الوثائق.

إذا تحدثنا عن الاختبارات ، فهناك عدد كبير جدًا منها ، بالدرجة الأولى الدخان والتكامل. تحليلهم خارج نطاق هذه المقالة. أستطيع أن أقول فقط أن بناء مجموعة التوزيع ليست صعبة كما قد تبدو للوهلة الأولى. تمكنا من جمع وتمرير جميع المكونات التي نستخدمها في منتجاتنا في الاختبارات ، ولم تكن لدينا أيضًا مشكلات في نشرها وعملياتها الأساسية في بيئة الاختبار.

بالإضافة إلى المكونات الموجودة في Bigtop ، من الممكن إضافة شيء آخر ، حتى تطوير البرامج الخاصة بك. كل هذا مؤتمت بشكل مثالي ويتناسب مع مفهوم CI / CD.

استنتاج


من الواضح أنه لا يجب إرسال توزيع مبني بهذه الطريقة إلى الإنتاج على الفور. عليك أن تفهم أنه إذا كانت هناك حاجة حقيقية لبناء التوزيع الخاص بك والحفاظ عليه ، فأنت بحاجة إلى الاستثمار مالياً والوقت.

ومع ذلك ، بالاقتران مع النهج الصحيح وفريق محترف ، من الممكن الاستغناء عن الحلول التجارية.

من المهم أن نلاحظ أن مشروع Bigtop نفسه بحاجة إلى التطوير ويبدو أنه لا يوجد اليوم تطوير نشط فيه. أيضًا ، فإن مظهر مظهر Hadoop 3 غير واضح. بالمناسبة ، إذا كنت بحاجة حقيقية لبناء Hadoop 3 ، يمكنك إلقاء نظرة على الشوكة من Arenadata ، حيث يوجد ، بالإضافة إلى
المكونات القياسية ، عدد من المكونات الإضافية (Ranger ، Knox ، NiFi).

بالنسبة إلى Rostelecom ، بالنسبة لنا Bigtop هو أحد الخيارات التي تم النظر فيها اليوم. سواء أوقفنا ذلك أم لا ، سيخبرنا الوقت.

الملحق


لتضمين مكون جديد في التجميع ، تحتاج إلى إضافة وصفه في bigtop.bom و ./bigtop-packages. يمكنك محاولة القيام بذلك عن طريق القياس مع المكونات الموجودة. حاول معرفة ذلك. ليس الأمر صعبًا كما يبدو للوهلة الأولى.

ما رأيك؟ يسعدنا أن نرى رأيك في التعليقات ونشكرك على اهتمامك!

تم إعداد هذه المقالة من قبل فريق إدارة البيانات Rostelecom

All Articles