اپاچی بگ ٹاپ اور آج ہیڈوپ ڈسٹری بیوشن کا انتخاب کرنا

یہ شاید کوئی راز نہیں ہے کہ گزشتہ سال اپاچی ہڈوپ کے لیے بڑی تبدیلیوں کا سال تھا۔ پچھلے سال، Cloudera اور Hortonworks کو ضم کر دیا گیا (بنیادی طور پر، مؤخر الذکر کا حصول)، اور Mapr، سنگین مالی مسائل کی وجہ سے، ہیولٹ پیکارڈ کو فروخت کر دیا گیا۔ اور اگر کچھ سال پہلے، آن پریمیسس تنصیبات کے معاملے میں، اکثر کلاؤڈرا اور ہارٹن ورکس کے درمیان انتخاب کرنا پڑتا تھا، افسوس، آج ہمارے پاس یہ انتخاب نہیں ہے۔ ایک اور حیران کن حقیقت یہ تھی کہ Cloudera نے اس سال فروری میں اعلان کیا تھا کہ وہ عوامی ذخیرے میں اپنی تقسیم کی بائنری اسمبلیوں کو جاری کرنا بند کر دے گا، اور وہ اب صرف ادا شدہ سبسکرپشن کے ذریعے دستیاب ہیں۔ بلاشبہ، 2019 کے اختتام سے پہلے جاری ہونے والے CDH اور HDP کے تازہ ترین ورژنز کو ڈاؤن لوڈ کرنا اب بھی ممکن ہے، اور ان کے لیے ایک سے دو سال تک تعاون کی توقع ہے۔ لیکن آگے کیا کرنا ہے؟ ان لوگوں کے لیے جنہوں نے پہلے سبسکرپشن کے لیے ادائیگی کی، کچھ بھی نہیں بدلا ہے۔ اور ان لوگوں کے لیے جو ڈسٹری بیوشن کے ادا شدہ ورژن پر سوئچ نہیں کرنا چاہتے، لیکن ساتھ ہی ساتھ کلسٹر پرزوں کے تازہ ترین ورژن کے ساتھ ساتھ پیچ اور دیگر اپ ڈیٹس حاصل کرنے کے قابل ہونا چاہتے ہیں، ہم نے یہ مضمون تیار کیا ہے۔ اس میں ہم اس صورتحال سے نکلنے کے ممکنہ آپشنز پر غور کریں گے۔

مضمون ایک جائزہ سے زیادہ ہے۔ اس میں تقسیم کا موازنہ اور ان کا تفصیلی تجزیہ نہیں ہوگا، اور ان کو انسٹال کرنے اور ترتیب دینے کی کوئی ترکیبیں نہیں ہوں گی۔ کیا ہو گا؟ ہم Arenadata Hadoop جیسی تقسیم کے بارے میں مختصراً بات کریں گے، جو اس کی دستیابی کی وجہ سے بجا طور پر ہماری توجہ کا مستحق ہے، جو آج بہت کم ہے۔ اور پھر ہم ونیلا ہڈوپ کے بارے میں بات کریں گے، بنیادی طور پر اس بارے میں کہ اسے اپاچی بگ ٹاپ کا استعمال کرتے ہوئے کیسے "پکا" کیا جا سکتا ہے۔ تیار؟ پھر بلی میں خوش آمدید۔

اریناڈاٹا ہڈوپ

یہ مکمل طور پر نئی اور، ابھی تک، گھریلو ترقی کی بہت کم معلوم ڈسٹری بیوشن کٹ ہے۔ بدقسمتی سے، اس وقت Habré پر صرف ہے۔ اس مضمون.

مزید معلومات اہلکار پر مل سکتی ہیں۔ ڈاؤن لوڈ، اتارنا پروجیکٹ تقسیم کے تازہ ترین ورژن ورژن 3.1.2 کے لیے Hadoop 3 اور ورژن 2.8.5 کے لیے 2 پر مبنی ہیں۔

روڈ میپ کے بارے میں معلومات حاصل کی جا سکتی ہیں۔ یہاں.

ارینا ڈیٹا کلسٹر مینیجر انٹرفیس

Arenadata کی بنیادی مصنوعات ہے Arenadata کلسٹر مینیجر (ADCM)، جو مختلف کمپنی سافٹ ویئر سلوشنز کو انسٹال کرنے، ترتیب دینے اور ان کی نگرانی کے لیے استعمال ہوتا ہے۔ ADCM مفت تقسیم کیا جاتا ہے، اور بنڈل جوڑ کر اس کی فعالیت کو بڑھایا جاتا ہے، جو کہ جوابدہ پلے بکس کا ایک سیٹ ہے۔ بنڈل کو دو اقسام میں تقسیم کیا گیا ہے: انٹرپرائز اور کمیونٹی۔ مؤخر الذکر Arenadata ویب سائٹ سے مفت ڈاؤن لوڈ کے لیے دستیاب ہیں۔ اپنا بنڈل تیار کرنا اور اسے ADCM سے جوڑنا بھی ممکن ہے۔

Hadoop 3 کی تعیناتی اور انتظام کے لیے، بنڈل کا ایک کمیونٹی ورژن ADCM کے ساتھ مل کر پیش کیا جاتا ہے، لیکن Hadoop 2 کے لیے صرف اپاچی امباری ایک متبادل کے طور پر. جہاں تک پیکجوں کے ساتھ ریپوزٹریز کا تعلق ہے، وہ عوامی رسائی کے لیے کھلے ہیں، انہیں کلسٹر کے تمام اجزاء کے لیے معمول کے مطابق ڈاؤن لوڈ اور انسٹال کیا جا سکتا ہے۔ مجموعی طور پر، تقسیم بہت دلچسپ لگ رہا ہے. مجھے یقین ہے کہ ایسے لوگ ہوں گے جو Cloudera مینیجر اور Ambari جیسے حل کے عادی ہوں گے، اور جو خود ADCM کو پسند کریں گے۔ کچھ کے لئے، یہ بھی تقسیم ہے کہ ایک بہت بڑا پلس ہو جائے گا سافٹ ویئر رجسٹر میں شامل ہے۔ درآمد کے متبادل کے لیے۔

اگر ہم نقصانات کے بارے میں بات کرتے ہیں، تو وہ تمام دیگر ہڈوپ تقسیموں کی طرح ہی ہوں گے۔ یعنی:

• نام نہاد "وینڈر لاک ان"۔ Cloudera اور Hortonworks کی مثالوں کا استعمال کرتے ہوئے، ہم نے پہلے ہی محسوس کیا ہے کہ کمپنی کی پالیسی کو تبدیل کرنے کا خطرہ ہمیشہ رہتا ہے۔
• Apache upstream کے پیچھے نمایاں وقفہ۔

ونیلا ہڈوپ

جیسا کہ آپ جانتے ہیں، Hadoop کوئی یک سنگی پروڈکٹ نہیں ہے، بلکہ درحقیقت، اس کے تقسیم شدہ فائل سسٹم HDFS کے ارد گرد خدمات کی ایک پوری کہکشاں ہے۔ بہت کم لوگوں کے پاس ایک فائل کلسٹر کافی ہوگا۔ کچھ کو Hive کی ضرورت ہے، دوسروں کو Presto، اور پھر HBase اور Phoenix ہیں؛ چنگاری تیزی سے استعمال ہوتی ہے۔ آرکیسٹریشن اور ڈیٹا لوڈنگ کے لیے، Oozie، Sqoop اور Flume کبھی کبھار پائے جاتے ہیں۔ اور اگر سیکورٹی کا مسئلہ پیدا ہوتا ہے، تو رینجر کے ساتھ مل کر کربروس فوری طور پر ذہن میں آتا ہے۔

Hadoop اجزاء کے بائنری ورژن ٹربالز کی شکل میں ماحولیاتی نظام کے ہر پروجیکٹ کی ویب سائٹ پر دستیاب ہیں۔ آپ انہیں ڈاؤن لوڈ کر سکتے ہیں اور انسٹالیشن شروع کر سکتے ہیں، لیکن ایک شرط کے ساتھ: "خام" بائنریز سے پیکجوں کو آزادانہ طور پر جمع کرنے کے علاوہ، جو آپ زیادہ تر کرنا چاہتے ہیں، آپ کو ہر ایک کے ساتھ اجزاء کے ڈاؤن لوڈ کردہ ورژن کی مطابقت پر کوئی اعتماد نہیں ہوگا۔ دوسرے ترجیحی آپشن Apache Bigtop کا استعمال کرتے ہوئے تعمیر کرنا ہے۔ Bigtop آپ کو Apache maven repositories سے بنانے، ٹیسٹ چلانے اور پیکجز بنانے کی اجازت دے گا۔ لیکن، جو ہمارے لیے بہت اہم ہے، Bigtop اجزاء کے ان ورژنز کو جمع کرے گا جو ایک دوسرے کے ساتھ ہم آہنگ ہوں گے۔ ہم ذیل میں اس کے بارے میں مزید تفصیل سے بات کریں گے۔

اپاچی بگ ٹاپ

اپاچی بگ ٹاپ کی تعمیر، پیکیجنگ اور متعدد کی جانچ کے لیے ایک ٹول ہے۔
اوپن سورس پروجیکٹس، جیسے ہڈوپ اور گرین پلم۔ بگ ٹاپ کے پاس کافی ہے۔
ریلیز لکھنے کے وقت، تازہ ترین مستحکم ریلیز ورژن 1.4 تھا،
اور ماسٹر میں 1.5 تھا۔ ریلیز کے مختلف ورژن مختلف ورژن استعمال کرتے ہیں۔
اجزاء مثال کے طور پر، 1.4 ہڈوپ کے بنیادی اجزاء میں ورژن 2.8.5 ہے، اور ماسٹر میں
2.10.0 معاون اجزاء کی ترکیب بھی بدل رہی ہے۔ کچھ فرسودہ اور
ناقابل تجدید دور چلا جاتا ہے، اور اس کی جگہ کچھ نیا آتا ہے، زیادہ مانگ میں، اور
یہ ضروری نہیں کہ یہ اپاچی فیملی سے ہی ہو۔

اس کے علاوہ، Bigtop بہت سے ہیں کانٹے.

جب ہم نے Bigtop سے واقفیت حاصل کرنا شروع کی، تو ہم سب سے پہلے اس کے معمولی، دوسرے اپاچی پروجیکٹس، پھیلاؤ اور مقبولیت کے ساتھ ساتھ ایک بہت چھوٹی کمیونٹی کے مقابلے میں حیران ہوئے۔ اس سے یہ معلوم ہوتا ہے کہ پروڈکٹ کے بارے میں کم سے کم معلومات ہیں، اور فورمز اور میلنگ لسٹوں پر پیدا ہونے والے مسائل کے حل کی تلاش سے کچھ حاصل نہیں ہو سکتا۔ پہلے تو یہ ہمارے لیے ٹول کی خصوصیات کی وجہ سے ڈسٹری بیوشن کی مکمل اسمبلی کو مکمل کرنا ایک مشکل کام ثابت ہوا، لیکن ہم اس کے بارے میں تھوڑی دیر بعد بات کریں گے۔

ایک ٹیزر کے طور پر، وہ لوگ جو کسی زمانے میں لینکس کائنات کے ایسے منصوبوں میں دلچسپی رکھتے تھے جیسے Gentoo اور LFS، اس چیز کے ساتھ کام کرنا پرانی یادوں سے خوشگوار محسوس کر سکتے ہیں اور ان "ایپک" اوقات کو یاد کر سکتے ہیں جب ہم خود تلاش کر رہے تھے (یا لکھنا بھی) نئے پیچ کے ساتھ موزیلا کو دوبارہ بناتا ہے اور باقاعدگی سے دوبارہ بناتا ہے۔

بگ ٹاپ کا بڑا فائدہ ان ٹولز کی کشادگی اور استعداد ہے جس پر یہ مبنی ہے۔ یہ گریڈل اور اپاچی ماون پر مبنی ہے۔ گریڈل کافی مشہور ہے اس ٹول کے طور پر جو گوگل اینڈرائیڈ بنانے کے لیے استعمال کرتا ہے۔ یہ لچکدار ہے، اور جیسا کہ وہ کہتے ہیں، "جنگ کا تجربہ کیا گیا ہے۔" Maven خود اپاچی میں پراجیکٹس بنانے کا ایک معیاری ٹول ہے، اور چونکہ اس کی زیادہ تر پروڈکٹس Maven کے ذریعے جاری کی جاتی ہیں، اس لیے یہاں بھی اس کے بغیر یہ کام نہیں ہو سکتا۔ یہ POM (پروجیکٹ آبجیکٹ ماڈل) پر توجہ دینے کے قابل ہے - "بنیادی" xML فائل جو Maven کے لیے آپ کے پروجیکٹ کے ساتھ کام کرنے کے لیے ضروری ہر چیز کو بیان کرتی ہے، جس کے ارد گرد تمام کام بنایا گیا ہے۔ بالکل پر
Maven کے حصے اور کچھ رکاوٹیں ہیں جن کا عام طور پر پہلی بار بگ ٹاپ استعمال کرنے والوں کو سامنا کرنا پڑتا ہے۔

پریکٹس

تو آپ کو کہاں سے شروع کرنا چاہئے؟ ڈاؤن لوڈ صفحہ پر جائیں اور محفوظ شدہ دستاویزات کے طور پر تازہ ترین مستحکم ورژن ڈاؤن لوڈ کریں۔ آپ وہاں Bigtop کے ذریعے جمع کردہ بائنری نمونے بھی تلاش کر سکتے ہیں۔ ویسے، عام پیکج مینیجرز میں سے، YUM اور APT کو سپورٹ کیا جاتا ہے۔

متبادل طور پر، آپ تازہ ترین مستحکم ریلیز کو براہ راست ڈاؤن لوڈ کر سکتے ہیں۔
github:

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

"بگ ٹاپ" میں کلوننگ…

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جس کا براہ راست تعلق ان کے ساتھ اجزاء اور پیکجوں کو جمع کرنے کے عمل سے ہے۔

تو، ہم نے آرکائیو کو ڈاؤن لوڈ کیا، اسے پیک کھول دیا یا گیتھب سے کلون بنایا، کیا ہم تعمیر شروع کر سکتے ہیں؟

نہیں، آئیے پہلے ماحول تیار کریں۔

ماحول کی تیاری

اور یہاں ہمیں ایک چھوٹی سی اعتکاف کی ضرورت ہے۔ تقریباً کسی بھی کم یا زیادہ پیچیدہ پروڈکٹ کو بنانے کے لیے، آپ کو ایک خاص ماحول کی ضرورت ہے - ہمارے معاملے میں، یہ JDK ہے، وہی مشترکہ لائبریریاں، ہیڈر فائلز، وغیرہ، ٹولز، مثال کے طور پر، چیونٹی، ivy2 اور بہت کچھ۔ بگ ٹاپ کے لیے آپ کو مطلوبہ ماحول حاصل کرنے کے اختیارات میں سے ایک یہ ہے کہ بلڈ ہوسٹ پر ضروری اجزاء کو انسٹال کیا جائے۔ میں تاریخ میں غلط ہو سکتا ہوں، لیکن ایسا لگتا ہے کہ ورژن 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

پیکیج ٹاسک سیکشن میں بہت سی ایسی مصنوعات ہیں جو بگ ٹاپ کے حتمی نمونے ہیں۔
ان کی شناخت لاحقہ -rpm یا -pkg-ind (عمارت کے معاملے میں) سے کی جا سکتی ہے۔
ڈاکر میں)۔ ہمارے معاملے میں، سب سے زیادہ دلچسپ Hadoop ہے.

آئیے اپنے بلڈ سرور کے ماحول میں تعمیر کرنے کی کوشش کریں:

./gradlew hadoop-rpm

بگ ٹاپ خود ایک مخصوص جزو کے لیے ضروری ذرائع کو ڈاؤن لوڈ کرے گا اور اسمبلی شروع کرے گا۔ اس طرح، ٹول کا آپریشن ماون ریپوزٹریز اور دیگر ذرائع پر منحصر ہے، یعنی اسے انٹرنیٹ تک رسائی کی ضرورت ہے۔

آپریشن کے دوران، معیاری پیداوار پیدا ہوتی ہے۔ بعض اوقات یہ اور غلطی کے پیغامات آپ کو یہ سمجھنے میں مدد کر سکتے ہیں کہ کیا غلط ہوا ہے۔ اور بعض اوقات آپ کو اضافی معلومات حاصل کرنے کی ضرورت ہوتی ہے۔ اس صورت میں یہ دلائل شامل کرنے کے قابل ہے --info یا --debug، اور مفید بھی ہو سکتا ہے۔ –stacktrace. میلنگ لسٹوں تک بعد میں رسائی کے لیے ڈیٹا سیٹ بنانے کا ایک آسان طریقہ ہے، کلید --scan.

اس کی مدد سے بگ ٹاپ تمام معلومات اکٹھا کر کے گریڈل میں ڈالے گا جس کے بعد یہ ایک لنک فراہم کرے گا،
جس پر عمل کرنے سے ایک اہل شخص سمجھ سکے گا کہ اسمبلی کیوں ناکام ہوئی۔
براہ کرم آگاہ رہیں کہ یہ آپشن ایسی معلومات کو ظاہر کر سکتا ہے جو آپ نہیں چاہتے، جیسے صارف کے نام، نوڈس، ماحولیاتی متغیرات وغیرہ، لہذا محتاط رہیں۔

اکثر غلطیاں اسمبلی کے لیے ضروری اجزاء حاصل کرنے میں ناکامی کا نتیجہ ہوتی ہیں۔ عام طور پر، آپ سورس میں کسی چیز کو ٹھیک کرنے کے لیے ایک پیچ بنا کر مسئلہ کو حل کر سکتے ہیں، مثال کے طور پر، سورس کی روٹ ڈائرکٹری میں 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

مختلف لینکس ڈسٹری بیوشنز کے لیے پیکجز بنانے کے علاوہ، یہ ٹول مرتب کردہ پیکجوں کے ساتھ ایک ذخیرہ بنا سکتا ہے، مثال کے طور پر:

./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

آپ دستاویزات میں تعیناتی کے کاموں کے بارے میں مزید پڑھ سکتے ہیں۔

اگر ہم ٹیسٹ کے بارے میں بات کرتے ہیں، تو ان میں سے کافی تعداد میں ہیں، بنیادی طور پر دھواں اور انضمام. ان کا تجزیہ اس مضمون کے دائرہ کار سے باہر ہے۔ میں صرف اتنا کہوں گا کہ ڈسٹری بیوشن کٹ کو اسمبل کرنا اتنا مشکل کام نہیں جتنا پہلی نظر میں لگتا ہے۔ ہم ان تمام اجزاء کو جمع کرنے اور ٹیسٹ پاس کرنے میں کامیاب ہو گئے جو ہم اپنی پروڈکشن میں استعمال کرتے ہیں، اور ہمیں ان کی تعیناتی اور ٹیسٹ کے ماحول میں بنیادی کارروائیاں کرنے میں بھی کوئی دشواری نہیں ہوئی۔

بگ ٹاپ میں موجودہ اجزاء کے علاوہ، کچھ بھی شامل کرنا ممکن ہے، یہاں تک کہ آپ کے اپنے سافٹ ویئر کی ترقی بھی۔ یہ سب بالکل خودکار ہے اور CI/CD تصور میں فٹ بیٹھتا ہے۔

حاصل يہ ہوا

ظاہر ہے، اس طرح مرتب کی گئی تقسیم کو فوری طور پر پیداوار میں نہیں بھیجا جانا چاہیے۔ آپ کو یہ سمجھنے کی ضرورت ہے کہ اگر آپ کی تقسیم کو بنانے اور اس کی مدد کرنے کی حقیقی ضرورت ہے، تو آپ کو اس میں پیسہ اور وقت لگانے کی ضرورت ہے۔

تاہم، صحیح نقطہ نظر اور ایک پیشہ ور ٹیم کے ساتھ مل کر، تجارتی حل کے بغیر ایسا کرنا کافی ممکن ہے۔

یہ نوٹ کرنا ضروری ہے کہ بگ ٹاپ پروجیکٹ خود ترقی کا محتاج ہے اور آج کل فعال طور پر تیار ہوتا دکھائی نہیں دیتا۔ اس میں ہڈوپ 3 کے ظاہر ہونے کا امکان بھی غیر واضح ہے۔ کانٹا Arenadata سے، جس میں، معیاری کے علاوہ
بہت سے اضافی اجزاء ہیں (رینجر، ناکس، نی فائی)۔

جہاں تک Rostelecom کا تعلق ہے، ہمارے لیے Bigtop ان اختیارات میں سے ایک ہے جس پر آج غور کیا جا رہا ہے۔ ہم اسے منتخب کرتے ہیں یا نہیں، وقت بتائے گا۔

معاہدہ

اسمبلی میں ایک نیا جزو شامل کرنے کے لیے، آپ کو اس کی تفصیل bigtop.bom اور ./bigtop-packages میں شامل کرنے کی ضرورت ہے۔ آپ موجودہ اجزاء کے ساتھ مشابہت کے ذریعہ ایسا کرنے کی کوشش کر سکتے ہیں۔ اس کا پتہ لگانے کی کوشش کریں۔ یہ اتنا مشکل نہیں جتنا پہلی نظر میں لگتا ہے۔

آپ کیا سوچتے ہیں؟ ہمیں تبصرے میں آپ کی رائے دیکھ کر خوشی ہوگی اور آپ کی توجہ کا شکریہ!

مضمون Rostelecom ڈیٹا مینجمنٹ ٹیم نے تیار کیا تھا۔

ماخذ: www.habr.com