میرا نام وکٹر یگوفاروف ہے، اور میں DomClick پر Kubernetes پلیٹ فارم کو Ops (آپریشنز) ٹیم میں ٹیکنیکل ڈیولپمنٹ مینیجر کے طور پر تیار کر رہا ہوں۔ میں آپ کو ہمارے Dev <-> Ops عمل کے ڈھانچے کے بارے میں بتانا چاہتا ہوں، روس میں سب سے بڑے k8s کلسٹرز میں سے ایک کو چلانے کی خصوصیات کے ساتھ ساتھ DevOps/SRE طریقوں کے بارے میں جو ہماری ٹیم استعمال کرتی ہے۔
ٹیم آپریشن
Ops ٹیم میں فی الحال 15 افراد ہیں۔ ان میں سے تین دفتر کے ذمہ دار ہیں، دو مختلف ٹائم زون میں کام کرتے ہیں اور دستیاب ہیں، بشمول رات کے وقت۔ اس طرح، Ops سے کوئی شخص ہمیشہ مانیٹر پر ہوتا ہے اور کسی بھی پیچیدگی کے واقعے کا جواب دینے کے لیے تیار ہوتا ہے۔ ہمارے پاس رات کی شفٹیں نہیں ہوتیں، جو ہماری ذہنیت کو محفوظ رکھتی ہیں اور ہر ایک کو نہ صرف کمپیوٹر پر کافی نیند لینے اور فرصت کا وقت گزارنے کا موقع فراہم کرتی ہیں۔
ہر ایک کے پاس مختلف صلاحیتیں ہیں: نیٹ ورکرز، DBAs، ELK اسٹیک ماہرین، Kubernetes ایڈمنز/ڈیولپرز، نگرانی، ورچوئلائزیشن، ہارڈویئر ماہرین وغیرہ۔ ایک چیز سب کو متحد کرتی ہے - ہر کوئی کسی حد تک ہم میں سے کسی کی جگہ لے سکتا ہے: مثال کے طور پر، k8s کلسٹر میں نئے نوڈس متعارف کروائیں، PostgreSQL کو اپ ڈیٹ کریں، ایک CI/CD + Ansible پائپ لائن لکھیں، Python/Bash/Go میں کچھ خودکار کریں، ایک ٹکڑا جوڑیں۔ DPC کو ہارڈ ویئر کا۔ کسی بھی علاقے میں مضبوط قابلیت سرگرمی کی سمت کو تبدیل کرنے اور کسی دوسرے علاقے میں پمپ شروع کرنے میں مداخلت نہیں کرتی ہے۔ مثال کے طور پر، مجھے پوسٹگری ایس کیو ایل ماہر کے طور پر ایک کمپنی میں ملازمت ملی، اور اب میری ذمہ داری کا بنیادی شعبہ Kubernetes کلسٹرز ہے۔ ٹیم میں، کسی بھی ترقی کا خیر مقدم کیا جاتا ہے اور کندھے کا احساس بہت ترقی یافتہ ہے.
ویسے ہم شکار کرتے ہیں۔ امیدواروں کی ضروریات کافی معیاری ہیں۔ میرے لیے ذاتی طور پر، یہ ضروری ہے کہ ایک شخص ٹیم میں فٹ ہو، غیر متضاد ہو، لیکن یہ بھی جانتا ہے کہ اپنے نقطہ نظر کا دفاع کیسے کرنا ہے، ترقی کرنا چاہتا ہے اور اپنے خیالات پیش کرنے کے لیے کچھ نیا کرنے سے نہیں ڈرتا۔ اس کے علاوہ، اسکرپٹنگ زبانوں میں پروگرامنگ کی مہارت، لینکس اور انگریزی کی بنیادی باتوں کا علم درکار ہے۔ انگریزی کی ضرورت صرف اس لیے ہے کہ فیکپ کی صورت میں کوئی شخص 10 منٹ میں نہیں بلکہ 10 سیکنڈ میں مسئلہ کا حل گوگل کر سکے۔ لینکس کے بارے میں گہری معلومات رکھنے والے ماہرین کے ساتھ، اب یہ بہت مشکل ہے: مضحکہ خیز، لیکن تین میں سے دو امیدوار اس سوال کا جواب نہیں دے سکتے کہ "لوڈ اوسط کیا ہے؟ اس میں کیا شامل ہے؟”، اور سوال “سش پروگرام سے کور ڈمپ کیسے اکٹھا کیا جائے” کو مافوق الفطرت انسانوں کی دنیا سے سمجھا جاتا ہے ... یا ڈایناسور۔ ہمیں اس کو برداشت کرنا ہوگا، کیونکہ عام طور پر لوگوں نے دوسری قابلیت کو بہت زیادہ ترقی دی ہے، اور ہم لینکس سکھائیں گے۔ اس سوال کا جواب "ایک ڈیو اوپس انجینئر کو بادلوں کی جدید دنیا میں یہ سب کچھ جاننے کی ضرورت کیوں ہے" کو مضمون کے دائرہ کار سے باہر چھوڑنا پڑے گا، لیکن تین الفاظ میں: یہ سب ضروری ہے۔
ٹولز کمانڈ
ٹولز ٹیم آٹومیشن میں اہم کردار ادا کرتی ہے۔ ان کا بنیادی کام ڈویلپرز کے لیے آسان گرافیکل اور CLI ٹولز بنانا ہے۔ مثال کے طور پر، Confer کی ہماری داخلی ترقی آپ کو صرف چند ماؤس کلکس کے ساتھ Kubernetes پر ایک ایپلیکیشن رول آؤٹ کرنے، اس کے وسائل کو ترتیب دینے، والٹ سے کیز وغیرہ کی اجازت دیتی ہے۔ جینکنز + ہیلم 2 ہوا کرتا تھا، لیکن مجھے کاپی پیسٹ کو ختم کرنے اور سافٹ ویئر لائف سائیکل میں یکسانیت لانے کے لیے اپنا ٹول تیار کرنا تھا۔
Ops ٹیم ڈویلپرز کے لیے پائپ لائنز نہیں لکھتی ہے، لیکن انہیں لکھنے میں کسی بھی مسئلے پر مشورہ دے سکتی ہے (کچھ کے پاس اب بھی ہیلم 3 ہے)۔
DevOps
جہاں تک DevOps کا تعلق ہے، ہم اسے اس طرح دیکھتے ہیں:
دیو ٹیمیں کوڈ لکھتی ہیں، اسے Confer to dev -> qa/stage -> prod کے ذریعے رول آؤٹ کرتی ہیں۔ یہ ڈیو اور اوپس ٹیموں کی ذمہ داری ہے کہ وہ اس بات کو یقینی بنائیں کہ کوڈ سست نہ ہو اور غلطیاں نہ ہوں۔ دن کے وقت، Ops ٹیم کے ڈیوٹی آفیسر کو اپنی درخواست کے ساتھ کسی واقعے کا جواب دینا چاہیے، اور شام اور رات کے وقت، ڈیوٹی ایڈمن (Ops) کو چاہیے کہ وہ ڈیوٹی پر موجود ڈویلپر کو بیدار کرے اگر اسے یقین ہو کہ مسئلہ نہیں ہے۔ بنیادی ڈھانچے میں. نگرانی میں تمام میٹرکس اور انتباہات خود بخود یا نیم خودکار طور پر ظاہر ہوتے ہیں۔
Ops کی ذمہ داری کا دائرہ اس وقت سے شروع ہوتا ہے جب ایپلی کیشن کو پروڈکشن تک پہنچایا جاتا ہے، لیکن دیو کی ذمہ داری وہیں ختم نہیں ہوتی - ہم ایک کام کرتے ہیں اور ایک ہی کشتی میں سوار ہیں۔
ڈویلپرز ایڈمنز کو مشورہ دیتے ہیں کہ اگر انہیں ایڈمن مائیکرو سروس لکھنے میں مدد کی ضرورت ہو (مثال کے طور پر، Go backend + HTML5)، اور ایڈمنز ڈویلپرز کو کسی بھی انفراسٹرکچر یا k8s سے متعلق مسائل پر مشورہ دیتے ہیں۔
ویسے، ہمارے پاس یک سنگی بالکل نہیں ہے، صرف مائیکرو سروسز ہیں۔ ان کی تعداد اب تک پروڈ k900s کلسٹر میں 1000 اور 8 کے درمیان اتار چڑھاؤ آتی ہے، اگر تعداد سے ناپا جائے تعینات. پھلیوں کی تعداد 1700 اور 2000 کے درمیان اتار چڑھاؤ آتی ہے۔ پروڈ کلسٹر میں پوڈز اب 2000 کے قریب ہیں۔
میں درست نمبر نہیں دے سکتا، کیونکہ ہم غیر ضروری مائیکرو سروسز کی نگرانی کرتے ہیں اور انہیں نیم خودکار موڈ میں کاٹ دیتے ہیں۔ k8s میں غیر ضروری اداروں پر نظر رکھنے سے ہماری مدد ہوتی ہے۔ جس سے وسائل اور پیسے کی بچت ہوتی ہے۔
وسائل کے انتظام
نگرانی
قابلیت کے ساتھ تعمیر شدہ اور معلوماتی نگرانی ایک بڑے کلسٹر کے آپریشن میں سنگ بنیاد بن جاتی ہے۔ ہمیں ابھی تک کوئی ایسا عالمی حل نہیں ملا ہے جو نگرانی کی تمام ضروریات کا 100% پورا کرے، اس لیے ہم وقتاً فوقتاً اس ماحول میں مختلف حسب ضرورت حل تلاش کرتے ہیں۔
- زبیبس. اچھی پرانی نگرانی، جو بنیادی طور پر بنیادی ڈھانچے کی مجموعی حالت کی نگرانی کے لیے بنائی گئی ہے۔ یہ ہمیں بتاتا ہے کہ جب کوئی نوڈ پروسیسر، میموری، ڈسک، نیٹ ورک وغیرہ کے ذریعے مر جاتا ہے۔ کچھ بھی مافوق الفطرت نہیں ہے، لیکن ہمارے پاس ایجنٹوں کا ایک الگ ڈیمون سیٹ بھی ہے، جس کی مدد سے، مثال کے طور پر، ہم کلسٹر میں DNS حالت کی نگرانی کرتے ہیں: ہم بیوقوف کورڈینز پوڈز تلاش کرتے ہیں، ہم بیرونی میزبانوں کی دستیابی کو چیک کرتے ہیں۔ ایسا لگتا ہے کہ اس کی خاطر کیوں پریشان ہوں، لیکن ٹریفک کی بڑی مقدار میں یہ جزو ناکامی کا ایک سنگین نقطہ ہے۔ پہلے میرے پاس ہے۔ کلسٹر میں DNS کارکردگی کے ساتھ کس طرح جدوجہد کی۔
- پرومیتھیس آپریٹر. مختلف برآمد کنندگان کا ایک مجموعہ کلسٹر کے تمام اجزاء کا بہترین جائزہ پیش کرتا ہے۔ اس کے بعد، ہم گرافانا میں بڑے ڈیش بورڈز پر یہ سب دیکھتے ہیں، اور اطلاعات کے لیے الرٹ مینیجر کا استعمال کرتے ہیں۔
ہمارے لیے ایک اور مفید ٹول ہے۔ . ہم نے اسے کئی بار اس صورت حال کا سامنا کرنے کے بعد لکھا جہاں ایک ٹیم نے دوسری ٹیم کے داخلے کو اس کے راستوں سے اوورلیپ کیا، جس کی وجہ سے 50x غلطیاں ہوئیں۔ اب، پروڈکشن میں تعینات کرنے سے پہلے، ڈویلپرز چیک کرتے ہیں کہ وہ کسی کو تکلیف نہیں پہنچائیں گے، اور میری ٹیم کے لیے یہ Ingresses کے مسائل کی ابتدائی تشخیص کے لیے ایک اچھا ٹول ہے۔ یہ مضحکہ خیز بات ہے کہ پہلے یہ ایڈمنز کے لیے لکھا گیا تھا اور یہ "اناڑی" لگ رہا تھا، لیکن دیو ٹیموں کو اس ٹول سے پیار ہونے کے بعد، یہ بہت بدل گیا اور ایسا نہیں لگنے لگا کہ "ایڈمن نے ایڈمنز کے لیے ویب چہرہ بنایا"۔ . جلد ہی ہم اس ٹول کو ترک کر دیں گے اور اس طرح کے حالات کی توثیق پائپ لائن کے رول آؤٹ ہونے سے پہلے ہی ہو جائے گی۔
"کیوب" میں ٹیم کے وسائل
مثالوں کے ساتھ آگے بڑھنے سے پہلے، یہ وضاحت کرنے کے قابل ہے کہ ہمارے پاس وسائل کی تقسیم کیسے ہے۔ مائیکرو سروسز.
یہ سمجھنے کے لیے کہ کون سی ٹیمیں اور کس مقدار میں ان کا استعمال کرتی ہیں۔ حوالہ جات (پروسیسر، میموری، لوکل ایس ایس ڈی)، ہم اپنا اپنا مختص کرتے ہیں۔ نام کی جگہ۔ "کیوب" میں اور پروسیسر، میموری اور ڈسک کے لحاظ سے اس کی زیادہ سے زیادہ صلاحیتوں کو محدود کریں، پہلے ٹیموں کی ضروریات پر بات کر چکے ہوں۔ اس کے مطابق، ایک کمانڈ، عام صورت میں، تعیناتی کے لیے پورے کلسٹر کو بلاک نہیں کرے گی، اپنے لیے ہزاروں کور اور ٹیرا بائٹس میموری مختص کرتی ہے۔ نام کی جگہ تک رسائی AD کے ذریعے جاری کی جاتی ہے (ہم RBAC استعمال کرتے ہیں)۔ نام کی جگہوں اور ان کی حدود کو GIT ریپوزٹری میں پل کی درخواست کے ذریعے شامل کیا جاتا ہے، اور پھر سب کچھ خود بخود جوابی پائپ لائن کے ذریعے رول آؤٹ ہوجاتا ہے۔
فی ٹیم وسائل کی تقسیم کی ایک مثال:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
درخواستیں اور حدود
کیوبڈ" کی درخواست کے تحت ضمانت یافتہ محفوظ وسائل کی تعداد ہے۔ پوڈ (ایک یا زیادہ ڈوکر کنٹینرز) ایک کلسٹر میں۔ حد ایک غیر گارنٹی شدہ زیادہ سے زیادہ ہے۔ آپ اکثر چارٹ پر دیکھ سکتے ہیں کہ کس طرح کچھ ٹیم نے اپنی تمام ایپلی کیشنز کے لیے بہت زیادہ درخواستیں ترتیب دی ہیں اور ایپلیکیشن کو "کیوب" پر تعینات نہیں کر سکتی، کیونکہ ان کے نام کی جگہ کے تحت تمام درخواستیں پہلے ہی "خرچ" کی جا چکی ہیں۔
اس صورت حال سے نکلنے کا صحیح طریقہ یہ ہے کہ وسائل کی اصل کھپت کو دیکھیں اور اس کا تقابل مطلوبہ رقم (درخواست) سے کریں۔
مندرجہ بالا اسکرین شاٹس سے پتہ چلتا ہے کہ "درخواست کردہ" (درخواست شدہ) سی پی یو کو دھاگوں کی حقیقی تعداد کے لیے منتخب کیا گیا ہے، اور حدیں CPU تھریڈز کی حقیقی تعداد سے تجاوز کر سکتی ہیں =)
اب آئیے کچھ نیم اسپیس پر گہری نظر ڈالتے ہیں (میں نے نیم اسپیس کیوب سسٹم کا انتخاب کیا - خود "کیوب" کے اجزاء کے لئے سسٹم نیم اسپیس) اور درخواست کردہ پروسیسر کے وقت اور میموری کا اصل میں استعمال شدہ تناسب دیکھیں:
یہ ظاہر ہے کہ سسٹم سروسز کے لیے اصل میں استعمال ہونے والی میموری اور سی پی یو بہت زیادہ ہے۔ کیوب سسٹم کے معاملے میں، یہ جائز ہے: ایسا ہوا ہے کہ چوٹی پر nginx ingress کنٹرولر یا nodelocaldns CPU پر آرام کرتا ہے اور بہت زیادہ RAM کھاتا ہے، لہذا یہاں ایسا مارجن جائز ہے۔ اس کے علاوہ، ہم پچھلے 3 گھنٹوں کے لیے چارٹس پر بھروسہ نہیں کر سکتے ہیں: ایک بڑے عرصے میں تاریخی میٹرکس دیکھنا ضروری ہے۔
"سفارشات" کا ایک نظام تیار کیا گیا۔ مثال کے طور پر، یہاں آپ دیکھ سکتے ہیں کہ کون سے وسائل "حدود" (اوپر کی اجازت والی بار) کو بڑھانے سے بہتر ہوں گے تاکہ "تھروٹلنگ" نہ ہو: وہ لمحہ جب پوڈ نے مختص وقت کوانٹم کے لیے CPU یا میموری کو پہلے ہی خرچ کر دیا ہو۔ اور انتظار کر رہا ہے جب تک کہ یہ "غیر منجمد" نہیں ہو جائے گا:
اور یہاں وہ پھلی ہیں جو اپنی بھوک کو اعتدال میں رکھیں:
کے بارے میں تھروٹلنگ + نگرانی کے وسائل، آپ ایک سے زیادہ مضمون لکھ سکتے ہیں، لہذا تبصرے میں سوالات پوچھیں۔ چند الفاظ میں، میں یہ کہہ سکتا ہوں کہ اس طرح کے میٹرکس کو خودکار کرنے کا کام بہت مشکل ہے اور اس کے لیے "ونڈو" فنکشنز اور "CTE" Prometheus/ VictoriaMetrics کے ساتھ بہت زیادہ وقت اور بیلنسنگ ایکٹ درکار ہے (یہ اصطلاحات کوٹیشن مارکس میں ہیں، کیونکہ PromQL میں تقریباً ایسا کچھ بھی نہیں ہے، اور آپ کو متن کی کئی اسکرینوں پر خوفناک سوالات کو باڑ لگانا اور ان کو بہتر بنانا ہوگا)۔
نتیجے کے طور پر، ڈویلپرز کے پاس "کیوب" میں اپنے نام کی جگہوں کی نگرانی کے لیے ٹولز ہوتے ہیں، اور وہ یہ انتخاب کرنے کے قابل ہوتے ہیں کہ کہاں اور کس وقت کون سی ایپلی کیشنز وسائل کو "کاٹ" سکتی ہیں، اور کون سی پوڈز کو پوری رات پوری سی پی یو دی جا سکتی ہے۔
طریقہ کار
اب کی طرح کمپنی میں فیشن، ہم DevOps- اور پر عمل کرتے ہیں۔ SRE-پریکٹیشنر جب کسی کمپنی کے پاس 1000 مائیکرو سروسز، تقریباً 350 ڈویلپرز اور پورے انفراسٹرکچر کے لیے 15 ایڈمنز ہوتے ہیں، تو آپ کو "فیشن ایبل" ہونا پڑتا ہے: ان تمام "بز ورڈز" کے پیچھے ہر چیز اور ہر چیز کو خودکار کرنے کی فوری ضرورت ہوتی ہے، اور منتظمین کو کوئی رکاوٹ نہیں بننا چاہیے۔ عمل میں.
آپریشن کے طور پر، ہم خدمات کے جوابی وقت اور ان کی غلطیوں سے متعلق ڈویلپرز کے لیے مختلف میٹرکس اور ڈیش بورڈ فراہم کرتے ہیں۔
ہم طریقہ کار استعمال کرتے ہیں جیسے: , и ان کو ایک ساتھ جوڑ کر۔ ہم ڈیش بورڈز کی تعداد کو کم سے کم کرنے کی کوشش کرتے ہیں تاکہ ایک نظر میں یہ واضح ہو جائے کہ کون سی سروس فی الحال تنزلی کا شکار ہے (مثال کے طور پر، رسپانس کوڈز فی سیکنڈ، 99ویں پرسنٹائل پر رسپانس ٹائم)، وغیرہ۔ جیسے ہی عام ڈیش بورڈز کے لیے کچھ نئے میٹرکس ضروری ہو جاتے ہیں، ہم فوری طور پر انہیں کھینچ کر شامل کر لیتے ہیں۔
میں نے اب ایک مہینے سے گرافکس نہیں بنائے ہیں۔ یہ شاید ایک اچھی علامت ہے: اس کا مطلب ہے کہ زیادہ تر "خواہشات" پہلے ہی نافذ ہو چکی ہیں۔ ایسا ہوا کہ ایک ہفتے تک میں نے دن میں کم از کم ایک بار کچھ نیا چارٹ کھینچا۔
نتیجہ خیز نتیجہ اس لحاظ سے قابل قدر ہے کہ اب ڈویلپر شاذ و نادر ہی سوالات کے ساتھ منتظمین کے پاس جاتے ہیں "کہاں کسی قسم کے میٹرکس دیکھیں"۔
عمل سروس میش بالکل کونے کے آس پاس ہے اور اسے ہر ایک کے لیے زندگی کو بہت آسان بنانا چاہیے، ٹولز کے ساتھی پہلے سے ہی خلاصہ "ایک صحت مند شخص کا Istio" نافذ کرنے کے قریب ہیں: ہر HTTP (s) کی درخواست کا لائف سائیکل نگرانی میں نظر آئے گا، اور انٹرسروس (اور نہ صرف) تعامل میں "سب کچھ کس مرحلے پر ٹوٹ گیا" کو سمجھنا ہمیشہ ممکن ہوگا۔ DomClick مرکز سے خبروں کو سبسکرائب کریں۔ =)
Kubernetes انفراسٹرکچر سپورٹ
تاریخی طور پر، ہم پیچ شدہ ورژن استعمال کرتے ہیں۔ کیوبسپرے - Kubernetes کی تعیناتی، توسیع اور اپ ڈیٹ کرنے کے لیے جوابدہ کردار۔ کسی وقت، مین برانچ سے نان کیوبیڈم تنصیبات کے لیے سپورٹ کاٹ دی گئی تھی، اور کیوبیڈم میں منتقلی کا عمل تجویز نہیں کیا گیا تھا۔ نتیجے کے طور پر، ساؤتھ برج نے اپنا کانٹا بنایا (کیوبیڈم کی حمایت اور اہم مسائل کے لیے فوری حل کے ساتھ)۔
تمام k8s کلسٹرز کے لیے اپ گریڈ کا عمل اس طرح لگتا ہے:
- لے لو کیوبسپرے ساؤتھ برج سے، ہماری برانچ، مرجیم سے چیک کریں۔
- اپ ڈیٹ کو رول آؤٹ کر رہا ہے۔ دباؤ- "کیوب"۔
- ہم ایک وقت میں ایک نوڈ کو اپ ڈیٹ کرتے ہیں (جواب میں یہ "سیریل: 1" ہے) دیو- "کیوب"۔
- اپ ڈیٹ کر رہا ہے۔ Prod کی ہفتہ کی شام، ایک وقت میں ایک نوڈ۔
مستقبل میں تبدیل کرنے کے منصوبے ہیں کیوبسپرے تیزی سے کچھ کرنے کے لئے اور جاؤ kubeadm.
مجموعی طور پر، ہمارے پاس تین "کیوبز" ہیں: تناؤ، دیو اور پروڈ۔ ہم ایک اور لانچ کرنے کا ارادہ رکھتے ہیں۔گرم یوز) پروڈ- دوسرے ڈیٹا سینٹر میں "کیوب"۔ دباؤ и دیو ورچوئل مشینوں میں رہتے ہیں (اوورٹ برائے تناؤ اور وی ایم ویئر کلاؤڈ برائے دیو)۔ Prod کی- "کیوب" "ننگی دھات" (ننگی دھات) پر رہتا ہے: یہ وہی نوڈس ہیں جن میں 32 سی پی یو تھریڈز، 64-128 جی بی میموری اور 300 جی بی ایس ایس ڈی RAID 10 ہیں - ان میں سے کل 50 ہیں۔ تین "پتلی" نوڈس "ماسٹرز" کے لیے وقف ہیں Prod کی- "کیوبا": 16 جی بی میموری، 12 سی پی یو تھریڈز۔
فروخت کے لیے، ہم "ننگی دھات" استعمال کرنے کو ترجیح دیتے ہیں اور غیر ضروری پرتوں سے پرہیز کرتے ہیں۔ OpenStack: ہمیں "شور پڑوسیوں" اور سی پی یو کی ضرورت نہیں ہے۔ وقت چوری. اور اندرون خانہ OpenStack کے معاملے میں انتظامیہ کی پیچیدگی تقریباً نصف تک بڑھ جاتی ہے۔
CI/CD کیوبک اور دیگر بنیادی ڈھانچے کے اجزاء کے لیے ہم ایک الگ GIT سرور استعمال کرتے ہیں، Helm 3 جوہری)، جینکنز، جوابدہ اور ڈاکر۔ ہمیں فیچر برانچز پسند ہیں اور ایک ہی ذخیرہ سے مختلف ماحول میں تعینات کرتے ہیں۔
حاصل يہ ہوا
اس طرح، عام اصطلاحات میں، DomClick پر DevOps عمل کسی آپریشن انجینئر کی طرف سے لگتا ہے۔ مضمون میری توقع سے کم تکنیکی نکلا: لہذا، Habré پر DomClick کی خبروں کو فالو کریں: Kubernetes اور اس سے زیادہ کے بارے میں مزید "سخت" مضامین ہوں گے۔
ماخذ: www.habr.com