سلرم میں 10 اگست کو شروع ہوا۔ ، جس میں ہم اس کا مکمل تجزیہ کرتے ہیں - بنیادی تجرید سے لے کر نیٹ ورک پیرامیٹرز تک۔
اس مضمون میں ہم Docker کی تاریخ اور اس کے اہم خلاصوں کے بارے میں بات کریں گے: Image, Cli, Dockerfile۔ لیکچر ابتدائیوں کے لیے ہے، اس لیے تجربہ کار صارفین کے لیے اس میں دلچسپی کا امکان نہیں ہے۔ کوئی خون، اپینڈکس یا گہری ڈوبی نہیں ہوگی. بہت بنیادی باتیں۔
Docker کیا ہے؟
آئیے ویکیپیڈیا سے ڈوکر کی تعریف کو دیکھتے ہیں۔
ڈوکر کنٹینرائزڈ ماحول میں ایپلی کیشنز کی تعیناتی اور انتظام کو خودکار کرنے کا سافٹ ویئر ہے۔
اس تعریف سے کچھ بھی واضح نہیں ہے۔ یہ خاص طور پر واضح نہیں ہے کہ "ماحول میں جو کنٹینرائزیشن کی حمایت کرتے ہیں" کا کیا مطلب ہے۔ یہ جاننے کے لیے، آئیے وقت پر واپس جائیں۔ آئیے اس دور سے آغاز کرتے ہیں جسے میں روایتی طور پر "مونولیتھک دور" کہتا ہوں۔
یک سنگی دور
یک سنگی دور 2000 کی دہائی کا اوائل ہے، جب تمام ایپلی کیشنز یک سنگی تھے، انحصار کے ایک گروپ کے ساتھ۔ ترقی میں کافی وقت لگا۔ ایک ہی وقت میں، زیادہ سرور نہیں تھے؛ ہم سب انہیں نام سے جانتے تھے اور ان کی نگرانی کرتے تھے۔ اس طرح کا ایک مضحکہ خیز موازنہ ہے:
پالتو جانور گھریلو جانور ہیں۔ یک سنگی دور میں، ہم نے اپنے سرورز کے ساتھ پالتو جانوروں کی طرح برتاؤ کیا، تیار کیا اور پالا، دھول کے دھبوں کو اڑا دیا۔ اور وسائل کے بہتر انتظام کے لیے، ہم نے ورچوئلائزیشن کا استعمال کیا: ہم نے ایک سرور لیا اور اسے کئی ورچوئل مشینوں میں کاٹ دیا، اس طرح ماحول کی تنہائی کو یقینی بنایا۔
ہائپر وائزر پر مبنی ورچوئلائزیشن سسٹم
سب نے شاید ورچوئلائزیشن سسٹمز کے بارے میں سنا ہوگا: VMware، VirtualBox، Hyper-V، Qemu KVM، وغیرہ۔ یہ ایپلیکیشن آئسولیشن اور ریسورس مینجمنٹ فراہم کرتے ہیں، لیکن ان کے نقصانات بھی ہیں۔ ورچوئلائزیشن کرنے کے لیے، آپ کو ایک ہائپر وائزر کی ضرورت ہے۔ اور ہائپر وائزر ایک وسیلہ اوور ہیڈ ہے۔ اور ورچوئل مشین بذات خود عام طور پر ایک مکمل کولسس ہوتی ہے - ایک بھاری تصویر جس میں آپریٹنگ سسٹم، Nginx، Apache، اور ممکنہ طور پر MySQL ہوتا ہے۔ تصویر بڑی ہے اور ورچوئل مشین چلانے میں تکلیف نہیں ہے۔ نتیجے کے طور پر، ورچوئل مشینوں کے ساتھ کام کرنا سست ہو سکتا ہے۔ اس مسئلے کو حل کرنے کے لیے، کرنل کی سطح پر ورچوئلائزیشن سسٹم بنائے گئے تھے۔
کرنل لیول ورچوئلائزیشن سسٹم
کرنل لیول ورچوئلائزیشن کو OpenVZ، Systemd-nspawn، LXC سسٹمز کے ذریعے تعاون حاصل ہے۔ اس طرح کی ورچوئلائزیشن کی ایک شاندار مثال LXC (لینکس کنٹینرز) ہے۔
LXC ایک آپریٹنگ سسٹم کی سطح کا ورچوئلائزیشن سسٹم ہے جو لینکس آپریٹنگ سسٹم کی ایک سے زیادہ الگ تھلگ مثالوں کو ایک نوڈ پر چلاتا ہے۔ LXC ورچوئل مشینیں استعمال نہیں کرتا ہے، لیکن اپنے عمل کی جگہ اور نیٹ ورک اسٹیک کے ساتھ ایک ورچوئل ماحول بناتا ہے۔
بنیادی طور پر LXC کنٹینرز بناتا ہے۔ ورچوئل مشینوں اور کنٹینرز میں کیا فرق ہے؟
کنٹینر الگ تھلگ کرنے کے عمل کے لیے موزوں نہیں ہے: دانا کی سطح پر ورچوئلائزیشن سسٹمز میں کمزوریاں پائی جاتی ہیں جو انہیں کنٹینر سے میزبان تک فرار ہونے کی اجازت دیتی ہیں۔ لہذا، اگر آپ کو کسی چیز کو الگ کرنے کی ضرورت ہے، تو یہ ایک ورچوئل مشین کا استعمال کرنا بہتر ہے.
ورچوئلائزیشن اور کنٹینرائزیشن کے درمیان فرق آریھ میں دیکھا جا سکتا ہے۔
ہارڈویئر ہائپر وائزرز، OS کے اوپری حصے پر ہائپر وائزر، اور کنٹینرز ہیں۔
اگر آپ واقعی کسی چیز کو الگ کرنا چاہتے ہیں تو ہارڈ ویئر ہائپر وائزر اچھے ہیں۔ کیونکہ میموری کے صفحات اور پروسیسرز کی سطح پر الگ تھلگ ہونا ممکن ہے۔
ایک پروگرام کے طور پر ہائپر وائزر ہیں، اور کنٹینرز ہیں، اور ہم ان کے بارے میں مزید بات کریں گے۔ کنٹینرائزیشن سسٹم میں ہائپر وائزر نہیں ہوتا ہے، لیکن ایک کنٹینر انجن ہوتا ہے جو کنٹینرز کو تخلیق اور ان کا انتظام کرتا ہے۔ یہ چیز زیادہ ہلکی ہے، اس لیے کور کے ساتھ کام کرنے کی وجہ سے اوور ہیڈ کم ہے یا بالکل بھی نہیں۔
دانا کی سطح پر کنٹینرائزیشن کے لیے کیا استعمال کیا جاتا ہے۔
اہم ٹیکنالوجیز جو آپ کو دوسرے عمل سے الگ تھلگ ایک کنٹینر بنانے کی اجازت دیتی ہیں وہ نام کی جگہیں اور کنٹرول گروپس ہیں۔
نام کی جگہیں: پی آئی ڈی، نیٹ ورکنگ، ماؤنٹ اور صارف۔ اور بھی ہیں، لیکن سمجھنے میں آسانی کے لیے ہم ان پر توجہ مرکوز کریں گے۔
PID نام کی جگہ عمل کو محدود کرتی ہے۔ جب، مثال کے طور پر، ہم ایک PID نام کی جگہ بناتے ہیں اور وہاں ایک عمل رکھتے ہیں، یہ PID 1 کے ساتھ بن جاتا ہے۔ عام طور پر سسٹمز میں PID 1 systemd یا init ہوتا ہے۔ اس کے مطابق، جب ہم ایک نئے نام کی جگہ میں کوئی عمل رکھتے ہیں، تو اسے PID 1 بھی ملتا ہے۔
نیٹ ورکنگ نیم اسپیس آپ کو نیٹ ورک کو محدود/ الگ تھلگ کرنے اور اپنے انٹرفیس کو اندر رکھنے کی اجازت دیتا ہے۔ ماؤنٹ ایک فائل سسٹم کی حد ہے۔ صارف—صارفین پر پابندی۔
کنٹرول گروپس: میموری، CPU، IOPS، نیٹ ورک - کل تقریباً 12 سیٹنگز۔ بصورت دیگر انہیں Cgroups ("C-groups") بھی کہا جاتا ہے۔
کنٹرول گروپ کنٹینر کے وسائل کا انتظام کرتے ہیں۔ کنٹرول گروپس کے ذریعے ہم کہہ سکتے ہیں کہ کنٹینر کو وسائل کی ایک خاص مقدار سے زیادہ استعمال نہیں کرنا چاہیے۔
کنٹینرائزیشن کو مکمل طور پر کام کرنے کے لیے، اضافی ٹیکنالوجیز استعمال کی جاتی ہیں: صلاحیتیں، کاپی آن رائٹ اور دیگر۔
صلاحیتیں تب ہوتی ہیں جب ہم کسی عمل کو بتاتے ہیں کہ یہ کیا کر سکتا ہے اور کیا نہیں کر سکتا۔ کرنل کی سطح پر، یہ بہت سے پیرامیٹرز کے ساتھ صرف بٹ میپس ہیں۔ مثال کے طور پر، روٹ صارف کو مکمل مراعات حاصل ہیں اور وہ سب کچھ کر سکتا ہے۔ ٹائم سرور سسٹم کا وقت بدل سکتا ہے: اس میں ٹائم کیپسول پر صلاحیتیں ہیں، اور بس۔ مراعات کا استعمال کرتے ہوئے، آپ لچکدار طریقے سے عمل کے لیے پابندیاں ترتیب دے سکتے ہیں، اور اس طرح اپنی حفاظت کر سکتے ہیں۔
کاپی آن رائٹ سسٹم ہمیں ڈوکر امیجز کے ساتھ کام کرنے اور انہیں زیادہ موثر طریقے سے استعمال کرنے کی اجازت دیتا ہے۔
ڈاکر کو فی الحال Cgroups v2 کے ساتھ مطابقت کے مسائل ہیں، لہذا یہ مضمون خاص طور پر Cgroups v1 پر مرکوز ہے۔
لیکن آئیے تاریخ کی طرف لوٹتے ہیں۔
جب ورچوئلائزیشن سسٹم دانا کی سطح پر نمودار ہوئے تو وہ فعال طور پر استعمال ہونے لگے۔ ہائپر وائزر پر اوور ہیڈ غائب ہو گیا، لیکن کچھ مسائل باقی ہیں:
- بڑی تصاویر: وہ ایک آپریٹنگ سسٹم، لائبریریاں، مختلف سافٹ ویئر کا ایک گروپ ایک ہی OpenVZ میں ڈالتے ہیں، اور آخر میں تصویر اب بھی کافی بڑی نکلتی ہے۔
- پیکیجنگ اور ڈیلیوری کے لیے کوئی عام معیار نہیں ہے، اس لیے انحصار کا مسئلہ باقی ہے۔ ایسے حالات ہوتے ہیں جب کوڈ کے دو ٹکڑے ایک ہی لائبریری کا استعمال کرتے ہیں، لیکن مختلف ورژن کے ساتھ۔ ان کے درمیان جھگڑا ہو سکتا ہے۔
ان تمام مسائل کے حل کے لیے اگلا دور آن پہنچا ہے۔
کنٹینر کا دور
کنٹینرز کا دور آیا تو ان کے ساتھ کام کرنے کا فلسفہ بدل گیا:
- ایک عمل - ایک کنٹینر.
- ہم تمام انحصار فراہم کرتے ہیں جس کی ضرورت اس کے کنٹینر میں ہوتی ہے۔ اس کے لیے monoliths کو مائیکرو سروسز میں کاٹنے کی ضرورت ہے۔
- تصویر جتنی چھوٹی ہوگی، اتنا ہی بہتر ہے - اس میں ممکنہ کمزوریاں کم ہیں، یہ تیزی سے نکلتی ہے، وغیرہ۔
- مثالیں عارضی ہو جاتی ہیں۔
یاد ہے میں نے پالتو جانوروں بمقابلہ مویشیوں کے بارے میں کیا کہا تھا؟ پہلے مثالیں گھریلو جانوروں جیسی ہوتی تھیں لیکن اب مویشیوں جیسی ہو گئی ہیں۔ اس سے پہلے، ایک monolith تھا - ایک درخواست. اب یہ 100 مائیکرو سروسز، 100 کنٹینرز ہیں۔ کچھ کنٹینرز میں 2-3 نقلیں ہوسکتی ہیں۔ ہمارے لیے ہر کنٹینر کو کنٹرول کرنا کم اہم ہو جاتا ہے۔ ہمارے لیے جو چیز زیادہ اہم ہے وہ خود سروس کی دستیابی ہے: کنٹینرز کا یہ سیٹ کیا کرتا ہے۔ یہ نگرانی کے طریقوں کو تبدیل کرتا ہے۔
2014-2015 میں، ڈوکر نے ترقی کی - وہ ٹیکنالوجی جس کے بارے میں ہم اب بات کریں گے۔
ڈوکر نے فلسفہ اور معیاری ایپلی کیشن پیکیجنگ کو تبدیل کیا۔ ڈوکر کا استعمال کرتے ہوئے، ہم ایک ایپلیکیشن کو پیک کر سکتے ہیں، اسے ایک ذخیرہ میں بھیج سکتے ہیں، اسے وہاں سے ڈاؤن لوڈ کر سکتے ہیں، اور اسے تعینات کر سکتے ہیں۔
ہم اپنی ضرورت کی ہر چیز کو ڈوکر کنٹینر میں ڈال دیتے ہیں، لہذا انحصار کا مسئلہ حل ہو جاتا ہے۔ ڈوکر تولیدی صلاحیت کی ضمانت دیتا ہے۔ میرے خیال میں بہت سے لوگوں کو ناقابل تولیدی کا سامنا کرنا پڑا ہے: ہر چیز آپ کے لیے کام کرتی ہے، آپ اسے پروڈکشن کی طرف دھکیل دیتے ہیں، اور وہاں یہ کام کرنا بند کر دیتا ہے۔ ڈوکر کے ساتھ یہ مسئلہ دور ہوجاتا ہے۔ اگر آپ کا ڈوکر کنٹینر شروع ہوتا ہے اور وہ کرتا ہے جو اسے کرنے کی ضرورت ہے، تو پھر بہت زیادہ امکان کے ساتھ یہ پیداوار میں شروع ہو جائے گا اور وہاں بھی ایسا ہی کرے گا۔
اوور ہیڈ کے بارے میں اختلاف
اوور ہیڈز کے بارے میں ہمیشہ تنازعات ہوتے رہتے ہیں۔ کچھ لوگوں کا خیال ہے کہ ڈوکر اضافی بوجھ نہیں اٹھاتا، کیونکہ یہ لینکس کرنل اور کنٹینرائزیشن کے لیے ضروری اس کے تمام عمل کو استعمال کرتا ہے۔ جیسے، "اگر آپ کہتے ہیں کہ ڈوکر اوور ہیڈ ہے، تو لینکس کا کرنل اوور ہیڈ ہے۔"
دوسری طرف، اگر آپ گہرائی میں جائیں تو، واقعی ڈوکر میں بہت سی چیزیں ہیں، جن کو ایک کھینچنے کے ساتھ، اوور ہیڈ کہا جا سکتا ہے۔
پہلا PID نام کی جگہ ہے۔ جب ہم ایک نام کی جگہ میں کوئی عمل رکھتے ہیں، تو اسے PID 1 تفویض کیا جاتا ہے۔ اسی وقت، اس عمل میں ایک اور PID ہوتا ہے، جو کنٹینر کے باہر میزبان نام کی جگہ پر واقع ہوتا ہے۔ مثال کے طور پر، ہم نے Nginx کو ایک کنٹینر میں لانچ کیا، یہ PID 1 (ماسٹر پروسیس) بن گیا۔ اور میزبان پر اس کا PID 12623 ہے۔ اور یہ کہنا مشکل ہے کہ یہ کتنا اوور ہیڈ ہے۔
دوسری چیز Cgroups ہے۔ آئیے Cgroups بذریعہ میموری لیتے ہیں، یعنی کنٹینر کی میموری کو محدود کرنے کی صلاحیت۔ جب یہ فعال ہو جاتا ہے، کاؤنٹرز اور میموری اکاؤنٹنگ کو چالو کیا جاتا ہے: کرنل کو یہ سمجھنے کی ضرورت ہوتی ہے کہ اس کنٹینر کے لیے کتنے صفحات مختص کیے گئے ہیں اور کتنے ابھی بھی مفت ہیں۔ یہ ممکنہ طور پر ایک اوور ہیڈ ہے، لیکن میں نے اس بارے میں کوئی درست مطالعہ نہیں دیکھا کہ یہ کارکردگی کو کیسے متاثر کرتا ہے۔ اور میں نے خود نہیں دیکھا کہ ڈوکر میں چلنے والی ایپلیکیشن کو اچانک کارکردگی میں شدید نقصان کا سامنا کرنا پڑا۔
اور کارکردگی کے بارے میں ایک اور نوٹ۔ کرنل کے کچھ پیرامیٹرز میزبان سے کنٹینر میں منتقل کیے جاتے ہیں۔ خاص طور پر، نیٹ ورک کے کچھ پیرامیٹرز۔ لہذا، اگر آپ ڈوکر میں اعلیٰ کارکردگی والی کوئی چیز چلانا چاہتے ہیں، مثال کے طور پر، کوئی ایسی چیز جو نیٹ ورک کو فعال طور پر استعمال کرے، تو آپ کو کم از کم ان پیرامیٹرز کو ایڈجسٹ کرنے کی ضرورت ہے۔ کچھ nf_conntrack، مثال کے طور پر۔
ڈوکر تصور کے بارے میں
ڈاکر کئی اجزاء پر مشتمل ہے:
- ڈوکر ڈیمون وہی کنٹینر انجن ہے۔ کنٹینرز شروع کرتا ہے.
- Docker CII ایک Docker مینجمنٹ کی افادیت ہے۔
- Dockerfile - تصویر بنانے کے طریقے سے متعلق ہدایات۔
- تصویر - وہ تصویر جس سے کنٹینر کو رول آؤٹ کیا جاتا ہے۔
- کنٹینر
- ڈاکر رجسٹری ایک تصویری ذخیرہ ہے۔
منصوبہ بندی سے یہ کچھ اس طرح لگتا ہے:
ڈوکر ڈیمون Docker_host پر چلتا ہے اور کنٹینرز لانچ کرتا ہے۔ ایک کلائنٹ ہے جو کمانڈ بھیجتا ہے: تصویر بنائیں، تصویر ڈاؤن لوڈ کریں، کنٹینر لانچ کریں۔ ڈوکر ڈیمون رجسٹری میں جاتا ہے اور ان پر عمل درآمد کرتا ہے۔ ڈوکر کلائنٹ مقامی طور پر (یونکس ساکٹ تک) اور دور دراز کے میزبان سے TCP کے ذریعے رسائی حاصل کرسکتا ہے۔
آئیے ہر ایک جز کو دیکھتے ہیں۔
ڈوکر ڈیمون - یہ سرور کا حصہ ہے، یہ میزبان مشین پر کام کرتا ہے: تصاویر ڈاؤن لوڈ کرتا ہے اور ان سے کنٹینرز لانچ کرتا ہے، کنٹینرز کے درمیان نیٹ ورک بناتا ہے، لاگ جمع کرتا ہے۔ جب ہم کہتے ہیں کہ "تصویر بنائیں"، تو شیطان بھی ایسا ہی کر رہا ہے۔
ڈوکر سی ایل آئی - ڈوکر کلائنٹ کا حصہ، ڈیمون کے ساتھ کام کرنے کے لیے کنسول کی افادیت۔ میں دہراتا ہوں، یہ نہ صرف مقامی طور پر بلکہ نیٹ ورک پر بھی کام کر سکتا ہے۔
بنیادی احکامات:
docker ps - کنٹینرز دکھائیں جو فی الحال Docker میزبان پر چل رہے ہیں۔
ڈاکر امیجز - مقامی طور پر ڈاؤن لوڈ کی گئی تصاویر دکھائیں۔
docker search <> - رجسٹری میں تصویر تلاش کریں۔
docker pull <> - رجسٹری سے مشین پر ایک تصویر ڈاؤن لوڈ کریں۔
ڈاکر کی تعمیر < > - تصویر جمع کریں۔
docker run <> - کنٹینر لانچ کریں۔
docker rm <> - کنٹینر کو ہٹا دیں۔
ڈاکر لاگز <> - کنٹینر لاگز
docker start/stop/restart <> - کنٹینر کے ساتھ کام کرنا
اگر آپ ان کمانڈز پر عبور رکھتے ہیں اور انہیں استعمال کرنے میں پراعتماد ہیں، تو اپنے آپ کو صارف کی سطح پر Docker میں 70% ماہر سمجھیں۔
ڈاکر فائل - تصویر بنانے کے لیے ہدایات۔ تقریباً ہر انسٹرکشن کمانڈ ایک نئی پرت ہے۔ آئیے ایک مثال دیکھتے ہیں۔
ڈاکر فائل کی طرح دکھتا ہے: بائیں طرف کمانڈز، دائیں طرف دلائل۔ ہر کمانڈ جو یہاں ہے (اور عام طور پر ڈاکر فائل میں لکھا جاتا ہے) امیج میں ایک نئی پرت بناتا ہے۔
یہاں تک کہ بائیں طرف دیکھ کر بھی آپ سمجھ سکتے ہیں کہ کیا ہو رہا ہے۔ ہم کہتے ہیں: "ہمارے لئے ایک فولڈر بنائیں" - یہ ایک پرت ہے۔ "فولڈر کو کام کرنا" ایک اور پرت ہے، اور اسی طرح. پرت کیک زندگی کو آسان بناتا ہے۔ اگر میں ایک اور ڈاکر فائل بناتا ہوں اور آخری لائن میں کچھ تبدیل کرتا ہوں - میں "python" "main.py" کے علاوہ کچھ چلاتا ہوں، یا کسی اور فائل سے انحصار انسٹال کرتا ہوں - تو پچھلی تہوں کو دوبارہ کیشے کے طور پر استعمال کیا جائے گا۔
تصویر - یہ کنٹینر پیکیجنگ ہے؛ کنٹینرز کو تصویر سے لانچ کیا گیا ہے۔ اگر ہم ڈوکر کو پیکیج مینیجر کے نقطہ نظر سے دیکھیں (جیسے کہ ہم ڈیب یا آر پی ایم پیکجوں کے ساتھ کام کر رہے ہیں)، تو تصویر بنیادی طور پر ایک آر پی ایم پیکیج ہے۔ یم انسٹال کے ذریعے ہم ایپلیکیشن کو انسٹال کر سکتے ہیں، اسے ڈیلیٹ کر سکتے ہیں، اسے ریپوزٹری میں ڈھونڈ سکتے ہیں اور اسے ڈاؤن لوڈ کر سکتے ہیں۔ یہاں بھی ایسا ہی ہے: تصویر سے کنٹینرز لانچ کیے جاتے ہیں، وہ ڈاکر رجسٹری میں محفوظ کیے جاتے ہیں (یم کی طرح، ایک ذخیرہ میں)، اور ہر تصویر میں SHA-256 ہیش، ایک نام اور ایک ٹیگ ہوتا ہے۔
تصویر Dockerfile کی ہدایات کے مطابق بنائی گئی ہے۔ Dockerfile کی ہر ہدایت ایک نئی پرت بناتی ہے۔ تہوں کو دوبارہ استعمال کیا جا سکتا ہے۔
ڈاکر رجسٹری ایک ڈاکر امیج ریپوزٹری ہے۔ OS کی طرح، Docker کے پاس ایک عوامی معیاری رجسٹری ہے - dockerhub۔ لیکن آپ اپنا ذخیرہ خود بنا سکتے ہیں، اپنی ڈوکر رجسٹری۔
کنٹینر - تصویر سے کیا لانچ کیا گیا ہے۔ ہم نے Dockerfile کی ہدایات کے مطابق ایک تصویر بنائی، پھر ہم اسے اس تصویر سے لانچ کرتے ہیں۔ یہ کنٹینر دوسرے کنٹینرز سے الگ تھلگ ہے اور ایپلیکیشن کے کام کرنے کے لیے ضروری ہر چیز پر مشتمل ہونا چاہیے۔ اس صورت میں، ایک کنٹینر - ایک عمل. ایسا ہوتا ہے کہ آپ کو دو عمل کرنے ہوں گے، لیکن یہ ڈوکر نظریے کے کسی حد تک مخالف ہے۔
"ایک کنٹینر، ایک عمل" کی ضرورت PID نام کی جگہ سے متعلق ہے۔ جب PID 1 کے ساتھ کوئی عمل Namespace میں شروع ہوتا ہے، اگر یہ اچانک مر جاتا ہے، تو پورا کنٹینر بھی مر جاتا ہے۔ اگر وہاں دو عمل چل رہے ہیں: ایک زندہ ہے اور دوسرا مردہ ہے، تو کنٹینر پھر بھی زندہ رہے گا۔ لیکن یہ بہترین طرز عمل کا سوال ہے، ہم ان کے بارے میں دوسرے مواد میں بات کریں گے۔
کورس کی خصوصیات اور مکمل پروگرام کا مزید تفصیل سے مطالعہ کرنے کے لیے، براہ کرم لنک پر عمل کریں:'.
مصنف: Marcel Ibraev، تصدیق شدہ Kubernetes ایڈمنسٹریٹر، ساؤتھ برج میں پریکٹس کرنے والا انجینئر، Slurm کورسز کا اسپیکر اور ڈویلپر۔
ماخذ: www.habr.com