ڈوکر کھلونا ہے یا نہیں؟ یا یہ اب بھی ہے؟

ہر کسی کو خوش!

میں واقعی میں سیدھا موضوع کی طرف جانا چاہتا ہوں، لیکن اپنی کہانی کے بارے میں تھوڑا بتانا زیادہ درست ہوگا:

داخلہ

میں ایک پروگرامر ہوں جس کے پاس سرور پر فرنٹ اینڈ سنگل پیج ایپلی کیشنز، اسکیلا/جاوا اور نوڈجز تیار کرنے کا تجربہ ہے۔

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

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

استعمال کی وجوہات

میں نے ڈوکر کیوں استعمال کیا؟ شاید درج ذیل وجوہات کی بناء پر:

• ڈیٹا بیس لانچ، 99% ایپلی کیشنز انہیں استعمال کرتی ہیں۔
• فرنٹ اینڈ ڈسٹری بیوشن کے لیے nginx لانچ کرنا اور بیک اینڈ پر پراکسی کرنا
• آپ ایپلیکیشن کو ڈوکر امیج میں پیک کر سکتے ہیں، اس طرح میری ایپلیکیشن کام کرے گی جہاں بھی ڈوکر موجود ہے، تقسیم کا مسئلہ فوری طور پر حل ہو جائے گا
• باکس سے باہر سروس کی دریافت، آپ مائیکرو سروسز بنا سکتے ہیں، ہر کنٹینر (ایک مشترکہ نیٹ ورک سے منسلک) آسانی سے ایک عرف کے ذریعے دوسرے تک پہنچ سکتا ہے، بہت آسان
• ایک کنٹینر بنانا اور اس میں "کھیلنا" کرنا مزہ آتا ہے۔

مجھے ہمیشہ ڈوکر کے بارے میں کیا پسند نہیں ہے:

• میری درخواست کے کام کرنے کے لیے، مجھے سرور پر ڈوکر کی ضرورت ہے۔ اگر میری ایپلی کیشنز jre یا nodejs پر چلتی ہیں اور ان کے لیے ماحول پہلے ہی سرور پر موجود ہے تو مجھے اس کی ضرورت کیوں ہے؟
• اگر میں اپنی (نجی) مقامی طور پر بنائی گئی تصویر کو ریموٹ سرور پر چلانا چاہتا ہوں، تو مجھے اپنی ڈوکر ریپوزٹری کی ضرورت ہے، مجھے کہیں کام کرنے کے لیے رجسٹری کی ضرورت ہے اور مجھے https کو کنفیگر کرنے کی بھی ضرورت ہے، کیونکہ docker cli صرف https پر کام کرتا ہے۔ اوہ لات... یقیناً تصویر کو مقامی طور پر محفوظ کرنے کے لیے آپشنز موجود ہیں۔ docker save اور صرف scp کے ذریعے تصویر بھیجیں... لیکن یہ بہت زیادہ جسمانی حرکت ہے۔ اور اس کے علاوہ، یہ ایک "بیساکھی" حل کی طرح لگتا ہے جب تک کہ آپ کا اپنا ذخیرہ ظاہر نہ ہو۔
• docker-compose. یہ صرف کنٹینرز چلانے کی ضرورت ہے۔ بس۔ وہ اور کچھ نہیں کر سکتا۔ Docker-compose اس کی فائلوں کے ورژن کا ایک گروپ ہے، اس کا اپنا نحو۔ اس سے کوئی فرق نہیں پڑتا ہے کہ یہ کتنا ہی اعلانیہ ہے، میں ان کی دستاویزات نہیں پڑھنا چاہتا۔ مجھے اس کی کہیں اور ضرورت نہیں پڑے گی۔
• کسی ٹیم میں کام کرتے وقت، زیادہ تر لوگ ایک ڈاکر فائل کو بہت ٹیڑھے طریقے سے لکھتے ہیں، یہ نہیں سمجھتے کہ اسے کیسے کیش کیا جاتا ہے، ہر وہ چیز شامل کرتے ہیں جس کی انہیں ضرورت ہوتی ہے اور اس کی تصویر میں ضرورت نہیں ہوتی، ایسی تصاویر سے وراثت حاصل کرتے ہیں جو Dockerhub یا کسی نجی ذخیرہ میں نہیں ہیں، کچھ تخلیق کرتے ہیں۔ docker-compose ڈیٹا بیس کے ساتھ فائلیں اور کچھ بھی برقرار نہیں رہتا ہے۔ ایک ہی وقت میں، ڈویلپرز فخر سے اعلان کرتے ہیں کہ ڈوکر ٹھنڈا ہے، ہر چیز ان کے لیے مقامی طور پر کام کرتی ہے، اور HR اہم طور پر خالی جگہ پر لکھتا ہے: "ہم Docker استعمال کرتے ہیں اور ہمیں ایسے امیدوار کی ضرورت ہے جس کے ساتھ کام کا تجربہ ہو۔"
• میں ڈوکر میں ہر چیز کو بڑھانے کے بارے میں خیالات سے مسلسل پریشان ہوں: postgresql، kafka، redis۔ یہ افسوس کی بات ہے کہ کنٹینرز میں ہر چیز کام نہیں کرتی، ہر چیز کو ترتیب دینا اور چلانا آسان نہیں ہے۔ اس کی تائید فریق ثالث کے ڈویلپرز کے ذریعہ کی جاتی ہے، نہ کہ خود وینڈرز کے ذریعہ۔ اور ویسے، سوال فوری طور پر پیدا ہوتا ہے: دکاندار اپنی مصنوعات کو ڈوکر میں برقرار رکھنے کی فکر نہیں کرتے، ایسا کیوں ہے، شاید وہ کچھ جانتے ہوں؟
• سوال ہمیشہ کنٹینر ڈیٹا کی استقامت کے بارے میں پیدا ہوتا ہے۔ اور پھر آپ سوچتے ہیں، کیا مجھے صرف میزبان ڈائرکٹری کو ماؤنٹ کرنا چاہئے یا ڈوکر والیوم بنانا چاہئے یا ڈیٹا کنٹینر بنانا چاہئے جو اب ہے deprecated? اگر میں ایک ڈائرکٹری کو ماؤنٹ کرتا ہوں، تو مجھے یہ یقینی بنانا ہوگا کہ کنٹینر میں موجود صارف کی uid اور gid کنٹینر کو لانچ کرنے والے صارف کی آئی ڈی سے میل کھاتا ہے، ورنہ کنٹینر کے ذریعے بنائی گئی فائلیں روٹ رائٹس کے ساتھ بنائی جائیں گی۔ اگر میں استعمال کروں volume پھر ڈیٹا صرف کچھ میں بنایا جائے گا /usr/* اور uid اور gid کے ساتھ وہی کہانی ہوگی جو پہلی صورت میں تھی۔ اگر آپ فریق ثالث کا جزو شروع کر رہے ہیں، تو آپ کو دستاویزات کو پڑھنے اور اس سوال کا جواب تلاش کرنے کی ضرورت ہے: "جزاء فائلوں کو کس کنٹینر ڈائرکٹری میں لکھتا ہے؟"

مجھے ہمیشہ یہ حقیقت پسند نہیں تھی کہ مجھے ڈوکر کے ساتھ زیادہ دیر تک ٹنکر کرنا پڑا ابتدائی مرحلے میں: میں نے سوچا کہ کنٹینرز کو کیسے لانچ کیا جائے، کن امیجز سے لانچ کیا جائے، میک فائلز بنائے جن میں لمبے ڈوکر کمانڈز کے عرفی نام شامل تھے۔ مجھے ڈوکر کمپوز سے نفرت تھی کیونکہ میں ڈوکر ماحولیاتی نظام میں کوئی اور ٹول نہیں سیکھنا چاہتا تھا۔ اور docker-compose up اس نے مجھے پریشان کیا، خاص طور پر اگر وہ اب بھی وہاں ملے build پہلے سے جمع شدہ تصاویر کے بجائے تعمیرات۔ میں صرف اتنا چاہتا تھا کہ صرف ایک پروڈکٹ کو موثر اور تیزی سے بنانا تھا۔ لیکن میں یہ نہیں جان سکا کہ ڈوکر کو کیسے استعمال کیا جائے۔

Ansible کا تعارف

حال ہی میں (تین مہینے پہلے)، میں نے ایک DevOps ٹیم کے ساتھ کام کیا، جس کے تقریباً ہر رکن کا Docker کے بارے میں منفی رویہ تھا۔ وجوہات کی بناء پر:

• ڈوکر رولز iptables (اگرچہ آپ اسے daemon.json میں غیر فعال کر سکتے ہیں)
• ڈاکر چھوٹی چھوٹی ہے اور ہم اسے پروڈکشن میں نہیں چلائیں گے۔
• اگر ڈوکر ڈیمون کریش ہو جاتا ہے، تو اس کے مطابق انفراسٹرکچر کریش والے تمام کنٹینرز
• ڈاکر کی ضرورت نہیں ہے
• اگر جوابی اور ورچوئل مشینیں ہیں تو ڈاکر کیوں؟

اسی کام میں، میں ایک اور آلے سے واقف ہوا - جواب دینے والا۔ میں نے اس کے بارے میں ایک بار سنا، لیکن میں نے اپنی پلے بکس لکھنے کی کوشش نہیں کی۔ اور اب میں نے اپنے کام لکھنا شروع کیے اور پھر میرا نقطہ نظر بالکل بدل گیا! کیونکہ میں نے محسوس کیا: Ansible میں ایک ہی ڈوکر کنٹینرز، امیج بلڈس، نیٹ ورکس وغیرہ کو چلانے کے لیے ماڈیولز ہیں اور کنٹینرز کو نہ صرف مقامی طور پر بلکہ ریموٹ سرورز پر بھی چلایا جا سکتا ہے! میری خوشی کی کوئی حد نہیں تھی - مجھے ایک نارمل ٹول ملا اور میں نے اپنی میک فائل اور ڈوکر کمپوز فائلیں پھینک دیں، ان کی جگہ یامل ٹاسکس کر دی گئیں۔ کوڈ کو تعمیرات جیسے استعمال کرکے کم کیا گیا تھا۔ loop, when، وغیرہ

تیسری پارٹی کے اجزاء جیسے ڈیٹا بیس کو چلانے کے لیے ڈوکر

میں حال ہی میں ssh سرنگوں سے واقف ہوا ہوں۔ یہ پتہ چلا کہ ریموٹ سرور کی بندرگاہ کو مقامی بندرگاہ پر "فارورڈ" کرنا بہت آسان ہے۔ ریموٹ سرور یا تو کلاؤڈ میں ایک مشین ہو سکتا ہے یا ورچوئل باکس میں چلنے والی ورچوئل مشین۔ اگر میرے ساتھی یا مجھے کسی ڈیٹا بیس (یا کسی دوسرے فریق ثالث کے اجزاء) کی ضرورت ہے، تو ہم اس جزو کے ساتھ سرور کو شروع کر سکتے ہیں اور جب سرور کی ضرورت نہ ہو تو اسے بند کر سکتے ہیں۔ پورٹ فارورڈنگ وہی اثر دیتا ہے جیسا کہ ڈیٹا بیس ڈوکر کنٹینر میں چلتا ہے۔

یہ کمانڈ میری لوکل پورٹ کو پوسٹگریس کیو ایل چلانے والے ریموٹ سرور پر بھیجتی ہے۔

ssh -L 9000:localhost:5432 [ای میل محفوظ]

ریموٹ سرور کا استعمال ٹیم کی ترقی کا مسئلہ حل کرتا ہے۔ اس طرح کے سرور کو کئی ڈویلپرز ایک ساتھ استعمال کر سکتے ہیں؛ انہیں postgresql کو ترتیب دینے، Docker اور دیگر پیچیدگیوں کو سمجھنے کے قابل ہونے کی ضرورت نہیں ہے۔ اگر کسی مخصوص ورژن کو انسٹال کرنا مشکل ہو تو ریموٹ سرور پر، آپ ڈوکر میں ہی وہی ڈیٹا بیس انسٹال کر سکتے ہیں۔ تمام ڈویلپرز کو ssh رسائی فراہم کرنے کی ضرورت ہے!

میں نے حال ہی میں پڑھا ہے کہ SSH سرنگیں ایک باقاعدہ VPN کی محدود فعالیت ہیں! آپ آسانی سے OpenVPN یا دیگر VPN نفاذ کو انسٹال کر سکتے ہیں، انفراسٹرکچر ترتیب دے سکتے ہیں اور اسے استعمال کے لیے ڈویلپرز کو دے سکتے ہیں۔ یہ بہت اچھا ہے!

خوش قسمتی سے، AWS، GoogleCloud اور دیگر آپ کو ایک سال مفت استعمال کرتے ہیں، لہذا ان کا استعمال کریں! وہ سستے ہیں اگر آپ استعمال میں نہ ہونے پر انہیں بند کردیں۔ میں ہمیشہ سوچتا تھا کہ مجھے gcloud جیسے ریموٹ سرور کی ضرورت کیوں پڑے گی، ایسا لگتا ہے کہ مجھے وہ مل گئے۔

مقامی ورچوئل مشین کے طور پر، آپ وہی الپائن استعمال کر سکتے ہیں، جو ڈوکر کنٹینرز میں فعال طور پر استعمال ہوتی ہے۔ ٹھیک ہے، یا مشین کے بوٹ کو تیز تر بنانے کے لیے کچھ اور ہلکی پھلکی تقسیم۔

پایان لائن: آپ ریموٹ سرورز یا ورچوئل باکس میں ڈیٹا بیس اور دیگر انفراسٹرکچر گڈیز چلا سکتے ہیں اور چلا سکتے ہیں۔ مجھے ان مقاصد کے لیے ڈاکر کی ضرورت نہیں ہے۔

ڈاکر کی تصاویر اور تقسیم کے بارے میں تھوڑا سا

میں پہلے ہی لکھ چکا ہوں۔ مضمون جس میں میں یہ بتانا چاہتا تھا کہ ڈاکر امیجز کا استعمال کوئی گارنٹی فراہم نہیں کرتا۔ ڈوکر کی تصاویر صرف ڈوکر کنٹینر بنانے کے لیے درکار ہیں۔ اگر آپ ڈوکر امیج میں اپ گریڈ کر رہے ہیں، تو آپ ڈوکر کنٹینرز استعمال کرنے کے لیے اپ گریڈ کر رہے ہیں اور آپ انہیں صرف استعمال کریں گے۔

کیا آپ نے کہیں دیکھا ہے جہاں سافٹ ویئر ڈویلپر اپنی مصنوعات کو صرف ڈاکر امیج میں پورٹ کرتے ہیں؟
زیادہ تر پروڈکٹس کا نتیجہ ایک مخصوص پلیٹ فارم کے لیے بائنری فائلز ہوتے ہیں؛ انہیں بس ڈوکر امیج میں شامل کیا جاتا ہے، جو مطلوبہ پلیٹ فارم سے وراثت میں ملتی ہے۔ کیا آپ نے کبھی سوچا ہے کہ ڈوکر ہب پر اتنی ملتی جلتی تصاویر کیوں ہیں؟ مثال کے طور پر nginx درج کریں، آپ کو مختلف لوگوں کی 100500 تصاویر نظر آئیں گی۔ ان لوگوں نے خود nginx تیار نہیں کیا، انہوں نے صرف اپنی ڈاکر امیج میں آفیشل nginx کو شامل کیا اور کنٹینرز کو لانچ کرنے کی سہولت کے لیے اسے اپنی ترتیب کے ساتھ تیار کیا۔

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

نیچے کی سطر: مجھے ڈاکر رجسٹری کی ضرورت نہیں ہے، میں کسی قسم کی S3 یا صرف فائل اسٹوریج جیسے گوگل ڈرائیو/ڈراپ باکس استعمال کروں گا۔

سی آئی میں ڈوکر

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

یہ کمپنیاں اپنے سرورز پر ڈوکر استعمال کرتی ہیں جہاں سی آئی کا عمل چلتا ہے۔ سوال: آپ کو اپنے سرورز پر ڈوکر کنٹینر میں پروجیکٹ بنانے کی ضرورت کیوں ہے؟ کیوں نہ صرف تعمیر کے لیے ایک ماحول تیار کریں، مثال کے طور پر، ایک جوابی پلے بک لکھیں جو nodejs، php، jdk، کاپی ssh کیز وغیرہ کے ضروری ورژن اس سرور پر انسٹال کرے گی جس میں تعمیر ہو گی؟

اب میں سمجھ گیا ہوں کہ یہ اپنے پاؤں پر گولی مار رہا ہے، کیونکہ ڈوکر اپنی تنہائی سے کوئی فائدہ نہیں لاتا۔ ڈوکر میں CI کے ساتھ مجھے جن مسائل کا سامنا کرنا پڑا:

• دوبارہ آپ کو بنانے کے لیے ایک ڈاکر امیج کی ضرورت ہے۔ آپ کو ایک تصویر تلاش کرنے یا اپنی ڈاکر فائل لکھنے کی ضرورت ہے۔
• 90% کہ آپ کو کچھ ssh کیز، خفیہ ڈیٹا کو آگے بھیجنے کی ضرورت ہے جو آپ ڈاکر امیج پر نہیں لکھنا چاہتے۔
• کنٹینر بنتا ہے اور مر جاتا ہے، اس کے ساتھ تمام کیچز ضائع ہو جاتے ہیں۔ اگلی تعمیر تمام پروجیکٹ انحصار کو دوبارہ ڈاؤن لوڈ کرے گی، جو کہ وقت طلب اور غیر موثر ہے، اور وقت پیسہ ہے۔

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

آؤٹ پٹ

مجھے یقین ہے کہ ڈوکر ایک بہت طاقتور اور لچکدار ٹول ہے، یہ اس کی خرابی ہے (جی ہاں، عجیب لگتا ہے)۔ اس کی مدد سے کمپنیاں آسانی سے اس پر ہک کر سکتی ہیں اور جہاں ضرورت ہو اور ضرورت نہ ہو اسے استعمال کر سکتی ہیں۔ ڈویلپرز اپنے کنٹینرز، ان کے کچھ ماحول کو لانچ کرتے ہیں، پھر یہ سب آسانی سے CI اور پیداوار میں بہہ جاتا ہے۔ DevOps ٹیم ان کنٹینرز کو چلانے کے لیے کچھ قسم کا کوڈ لکھ رہی ہے۔

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

جب ڈاکر کی ضرورت ہوتی ہے۔: میں اس نتیجے پر پہنچا ہوں کہ ڈوکر دیئے گئے عمل کو بہتر بنانے میں بہت اچھا ہے، لیکن بنیادی فعالیت بنانے میں نہیں۔

اگر آپ اب بھی ڈوکر استعمال کرنے کا فیصلہ کرتے ہیں، تو:

• انتہائی محتاط رہیں
• ڈویلپرز کو docker استعمال کرنے پر مجبور نہ کریں۔
• اس کے استعمال کو ایک جگہ مقامی بنائیں، اسے تمام Dockfile اور docker-compose repositories میں نہ پھیلائیں۔

PS:

• میں نے حال ہی میں دیکھا پیکر اور ان کا کہنا ہے کہ یہ Ansible کے ساتھ بہت اچھی طرح سے کام کرتا ہے اور آپ کو تصاویر بنانے کے عمل کو یکجا کرنے کی اجازت دیتا ہے (بشمول ڈاکر امیج)
• ڈاکر کے بارے میں بھی، دلچسپ مضمون

پڑھنے کے لیے آپ کا شکریہ، میری خواہش ہے کہ آپ اپنے معاملات میں شفاف فیصلے اور نتیجہ خیز کام کے دنوں میں ہوں!

ماخذ: www.habr.com