werf - Kubernetes میں CI/CD کے لیے ہمارا ٹول (جائزہ اور ویڈیو رپورٹ)

فیسٹیول کے ایک حصے کے طور پر منعقد ہونے والی DevOpsConf 27 کانفرنس کے مرکزی ہال میں 2019 مئی کو RIT++ 2019، "مسلسل ترسیل" کے حصے کے طور پر، ایک رپورٹ دی گئی تھی "werf - Kubernetes میں CI/CD کے لیے ہمارا ٹول"۔ یہ ان کے بارے میں بات کرتا ہے۔ مسائل اور چیلنجز جن کا سامنا ہر کسی کو کبرنیٹس میں تعینات کرتے وقت ہوتا ہے۔، نیز باریکیوں کے بارے میں جو فوری طور پر قابل توجہ نہیں ہوسکتے ہیں۔ ممکنہ حلوں کا تجزیہ کرتے ہوئے، ہم یہ ظاہر کرتے ہیں کہ اسے اوپن سورس ٹول میں کیسے لاگو کیا جاتا ہے۔ werf.

پریزنٹیشن کے بعد سے، ہماری افادیت (پہلے ڈیپ کے طور پر جانا جاتا تھا) کے ایک تاریخی سنگ میل کو پہنچ گیا ہے۔ GitHub پر 1000 ستارے۔ — ہم امید کرتے ہیں کہ اس کے صارفین کی بڑھتی ہوئی کمیونٹی بہت سے DevOps انجینئرز کی زندگی کو آسان بنا دے گی۔

تو آئیے تعارف کرواتے ہیں۔ رپورٹ کی ویڈیو (~47 منٹ، مضمون سے کہیں زیادہ معلوماتی) اور اس کا بنیادی اقتباس متن کی شکل میں۔ جاؤ!

کوبرنیٹس کو کوڈ کی فراہمی

بات اب werf کے بارے میں نہیں ہوگی، بلکہ Kubernetes میں CI/CD کے بارے میں ہوگی، جس کا مطلب یہ ہے کہ ہمارا سافٹ ویئر ڈوکر کنٹینرز میں پیک کیا گیا ہے۔ (میں نے اس کے بارے میں بات کی تھی۔ 2016 کی رپورٹ)، اور K8s اسے پیداوار میں چلانے کے لیے استعمال کیا جائے گا۔ (اس بارے میں مزید 2017 سال).

Kubernetes میں ڈیلیوری کیسی نظر آتی ہے؟

• اس کی تعمیر کے لیے کوڈ اور ہدایات کے ساتھ ایک Git ذخیرہ موجود ہے۔ ایپلیکیشن کو ڈوکر امیج میں بنایا گیا ہے اور اسے ڈاکر رجسٹری میں شائع کیا گیا ہے۔
• اسی ذخیرے میں ایپلی کیشن کو تعینات کرنے اور چلانے کے بارے میں بھی ہدایات موجود ہیں۔ تعیناتی کے مرحلے پر، یہ ہدایات Kubernetes کو بھیجی جاتی ہیں، جو رجسٹری سے مطلوبہ تصویر حاصل کرتی ہے اور اسے لانچ کرتی ہے۔
• اس کے علاوہ، عام طور پر ٹیسٹ ہوتے ہیں. ان میں سے کچھ تصویر شائع کرتے وقت کیے جا سکتے ہیں۔ آپ (انہی ہدایات پر عمل کرتے ہوئے) ایپلیکیشن کی ایک کاپی (ایک علیحدہ K8s نام کی جگہ یا علیحدہ کلسٹر میں) بھی لگا سکتے ہیں اور وہاں ٹیسٹ چلا سکتے ہیں۔
• آخر میں، آپ کو ایک CI سسٹم کی ضرورت ہے جو Git (یا بٹن کلکس) سے ایونٹس وصول کرے اور تمام نامزد مراحل کو کال کرے: تعمیر، شائع، تعینات، ٹیسٹ۔

یہاں چند اہم نوٹ ہیں:

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

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

اسٹیج بنائیں

ایسا لگتا ہے کہ آپ 2019 میں ڈوکر امیجز بنانے کے بارے میں بات کر سکتے ہیں، جب ہر کوئی جانتا ہے کہ Dockerfiles کو کیسے لکھنا اور چلانا ہے۔ docker buildیہاں وہ باریکیاں ہیں جن پر میں توجہ دینا چاہوں گا:

1. تصویر کا وزن معاملات، لہذا استعمال کریں کثیر مرحلےتصویر میں صرف وہی ایپلیکیشن چھوڑنا جو واقعی آپریشن کے لیے ضروری ہے۔
2. تہوں کی تعداد کی زنجیروں کو ملا کر کم سے کم کیا جانا چاہیے۔ RUN- معنی کے مطابق احکامات۔
3. تاہم، یہ مسائل میں اضافہ کرتا ہے ڈیبگنگ، کیونکہ جب اسمبلی کریش ہوتی ہے، تو آپ کو اس سلسلہ سے صحیح کمانڈ تلاش کرنا ہوتی ہے جس کی وجہ سے مسئلہ پیدا ہوتا ہے۔
4. اسمبلی کی رفتار اہم کیونکہ ہم تبدیلیوں کو تیزی سے رول آؤٹ کرنا اور نتائج دیکھنا چاہتے ہیں۔ مثال کے طور پر، جب بھی آپ درخواست بناتے ہیں تو آپ زبان کی لائبریریوں میں انحصار کو دوبارہ نہیں بنانا چاہتے۔
5. اکثر آپ کو ایک Git ذخیرہ سے ضرورت ہوتی ہے۔ بہت سی تصاویر، جسے Dockerfiles کے ایک سیٹ (یا ایک فائل میں نامزد مراحل) اور ان کی ترتیب وار اسمبلی کے ساتھ ایک Bash اسکرپٹ کے ذریعہ حل کیا جاسکتا ہے۔

یہ آئس برگ کا صرف ایک سرہ تھا جس کا سب کو سامنا ہے۔ لیکن دیگر مسائل ہیں، خاص طور پر:

1. اکثر اسمبلی کے مرحلے میں ہمیں کسی چیز کی ضرورت ہوتی ہے۔ پہاڑ (مثال کے طور پر، تھرڈ پارٹی ڈائرکٹری میں apt جیسے کمانڈ کا نتیجہ کیش کریں)۔
2. ہم چاہتے ہیں ناممکن شیل میں لکھنے کے بجائے۔
3. ہم چاہتے ہیں ڈوکر کے بغیر تعمیر کریں۔ (ہمیں ایک اضافی ورچوئل مشین کی ضرورت کیوں ہے جس میں ہمیں اس کے لیے ہر چیز کو ترتیب دینے کی ضرورت ہے، جب کہ ہمارے پاس پہلے سے ہی ایک Kubernetes کلسٹر موجود ہے جس میں ہم کنٹینرز چلا سکتے ہیں؟)
4. متوازی اسمبلی، جسے مختلف طریقوں سے سمجھا جا سکتا ہے: Dockerfile سے مختلف کمانڈز (اگر ملٹی اسٹیج استعمال کیا جاتا ہے)، ایک ہی ذخیرہ کے کئی کمٹ، کئی Dockerfiles۔
5. تقسیم شدہ اسمبلی: ہم ایسی چیزوں کو پھلی میں جمع کرنا چاہتے ہیں جو "فوقتل" ہیں کیونکہ ان کا ذخیرہ غائب ہو جاتا ہے، جس کا مطلب ہے کہ اسے کہیں الگ سے ذخیرہ کرنے کی ضرورت ہے۔
6. آخر میں، میں نے خواہشات کے عروج کا نام دیا۔ خودکار: ریپوزٹری میں جانا، کچھ کمانڈ ٹائپ کرنا اور ایک ریڈی میڈ امیج حاصل کرنا مثالی ہوگا، جس کو اس بات کی سمجھ کے ساتھ جمع کیا جائے کہ کیسے اور کیا صحیح طریقے سے کرنا ہے۔ تاہم، مجھے ذاتی طور پر یقین نہیں ہے کہ اس طرح تمام باریکیوں کا اندازہ لگایا جا سکتا ہے۔

اور یہاں منصوبے ہیں:

• moby/buildkit - ڈوکر انکارپوریشن کا ایک بلڈر (پہلے سے ہی ڈوکر کے موجودہ ورژن میں ضم ہے)، جو ان تمام مسائل کو حل کرنے کی کوشش کر رہا ہے۔
• کانیکو - گوگل کا ایک بلڈر جو آپ کو ڈوکر کے بغیر تعمیر کرنے کی اجازت دیتا ہے۔
• Buildpacks.io - CNCF کی خودکار جادو بنانے کی کوشش اور خاص طور پر تہوں کے لیے ریبیس کے ساتھ ایک دلچسپ حل؛
• اور دیگر افادیت کا ایک گروپ، جیسے تعمیر, genuinetools/img...

اور دیکھو GitHub پر ان کے کتنے ستارے ہیں۔ یعنی ایک طرف، docker build موجود ہے اور کچھ کر سکتا ہے، لیکن حقیقت میں مسئلہ مکمل طور پر حل نہیں ہوا ہے - اس کا ثبوت متبادل جمع کرنے والوں کی متوازی ترقی ہے، جن میں سے ہر ایک مسائل کا کچھ حصہ حل کرتا ہے۔

werf میں اسمبلی

تو ہمیں مل گیا۔ werf (پہلے مشہور ڈیپ کی طرح) — فلانٹ کمپنی کی طرف سے ایک اوپن سورس یوٹیلیٹی، جسے ہم کئی سالوں سے بنا رہے ہیں۔ یہ سب 5 سال پہلے باش اسکرپٹ کے ساتھ شروع ہوا تھا جس نے ڈاکر فائلز کی اسمبلی کو بہتر بنایا تھا، اور پچھلے 3 سالوں سے مکمل ترقی ایک پروجیکٹ کے فریم ورک کے اندر اس کی اپنی گٹ ریپوزٹری کے ساتھ کی گئی ہے۔ (پہلے روبی میں، اور پھر دوبارہ لکھا جانا، اور ایک ہی وقت میں نام تبدیل کر دیا گیا). ورف میں اسمبلی کے کون سے مسائل حل ہوتے ہیں؟

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

رجسٹری میں اشاعت کا مرحلہ (شائع)

ہم نے ڈائل کیا۔ docker push... - رجسٹری میں تصویر اپ لوڈ کرنے میں کیا مشکل ہو سکتی ہے؟ اور پھر سوال پیدا ہوتا ہے: "میں تصویر پر کون سا ٹیگ لگاؤں؟" یہ اس وجہ سے پیدا ہوتا ہے کہ ہمارے پاس ہے۔ گٹ فلو (یا دوسری Git حکمت عملی) اور Kubernetes، اور انڈسٹری اس بات کو یقینی بنانے کی کوشش کر رہی ہے کہ جو کچھ Kubernetes میں ہوتا ہے وہ گٹ میں ہوتا ہے۔ سب کے بعد، Git ہماری سچائی کا واحد ذریعہ ہے.

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

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

ٹیگنگ کی حکمت عملی

پہلا سادہ ہے۔ گٹ دن. ہمارے پاس ایک رجسٹری ہے جس میں ایک تصویر ٹیگ کی گئی ہے۔ 1.0. Kubernetes میں اسٹیج اور پروڈکشن ہے، جہاں یہ تصویر اپ لوڈ کی گئی ہے۔ گٹ میں ہم کمٹ کرتے ہیں اور کسی وقت ہم ٹیگ کرتے ہیں۔ 2.0. ہم اسے ذخیرہ کی ہدایات کے مطابق جمع کرتے ہیں اور اسے ٹیگ کے ساتھ رجسٹری میں رکھتے ہیں۔ 2.0. ہم اسے اسٹیج پر لے جاتے ہیں اور، اگر سب ٹھیک ہے، تو پروڈکشن کے لیے۔

اس نقطہ نظر کے ساتھ مسئلہ یہ ہے کہ ہم نے پہلے ٹیگ لگایا، اور اس کے بعد ہی اسے آزمایا اور رول آؤٹ کیا۔ کیوں؟ سب سے پہلے، یہ بالکل غیر منطقی ہے: ہم سافٹ ویئر کا ایک ایسا ورژن جاری کر رہے ہیں جس کا ہم نے ابھی تک تجربہ بھی نہیں کیا ہے (ہم دوسری صورت میں نہیں کر سکتے، کیونکہ چیک کرنے کے لیے، ہمیں ٹیگ لگانا ہوگا)۔ دوم، یہ راستہ Gitflow کے ساتھ مطابقت نہیں رکھتا۔

دوسرا آپشن ہے۔ گٹ کمٹ + ٹیگ. ماسٹر برانچ میں ایک ٹیگ ہے۔ 1.0; رجسٹری میں اس کے لیے - پروڈکشن میں تعینات ایک تصویر۔ اس کے علاوہ، Kubernetes کلسٹر میں پیش نظارہ اور اسٹیجنگ کی شکلیں ہیں۔ اگلا ہم گٹ فلو کی پیروی کرتے ہیں: ترقی کے لئے مرکزی شاخ میں (develop) ہم نئی خصوصیات بناتے ہیں، جس کے نتیجے میں شناخت کنندہ کے ساتھ ایک عہد ہوتا ہے۔ #c1. ہم اسے جمع کرتے ہیں اور اس شناخت کنندہ کا استعمال کرتے ہوئے اسے رجسٹری میں شائع کرتے ہیں (#c1)۔ اسی شناخت کنندہ کے ساتھ ہم پیش نظارہ کے لیے رول آؤٹ کرتے ہیں۔ ہم کمٹ کے ساتھ بھی ایسا ہی کرتے ہیں۔ #c2 и #c3.

جب ہم نے محسوس کیا کہ کافی خصوصیات ہیں، ہم ہر چیز کو مستحکم کرنا شروع کر دیتے ہیں۔ گٹ میں ایک برانچ بنائیں release_1.1 (بیس پر #c3 کی develop)۔ اس ریلیز کو جمع کرنے کی ضرورت نہیں ہے، کیونکہ... یہ پچھلے مرحلے میں کیا گیا تھا. لہذا، ہم اسے آسانی سے اسٹیجنگ میں رول آؤٹ کر سکتے ہیں۔ ہم اس میں کیڑے ٹھیک کرتے ہیں۔ #c4 اور اسی طرح سٹیجنگ پر رول آؤٹ. ایک ہی وقت میں، ترقی جاری ہے developجہاں سے وقتاً فوقتاً تبدیلیاں لی جاتی ہیں۔ release_1.1. کسی وقت، ہمیں ایک کمٹ مرتب کیا جاتا ہے اور اسٹیجنگ پر اپ لوڈ کیا جاتا ہے، جس سے ہم خوش ہوتے ہیں (#c25).

پھر ہم ریلیز برانچ کو (تیزی سے آگے کے ساتھ) ضم کرتے ہیں (release_1.1) ماسٹر میں۔ ہم نے اس کمٹ پر نئے ورژن کے ساتھ ٹیگ لگا دیا ہے (1.1)۔ لیکن یہ تصویر پہلے ہی رجسٹری میں جمع کی گئی ہے، اس لیے اسے دوبارہ جمع نہ کرنے کے لیے، ہم صرف موجودہ تصویر میں دوسرا ٹیگ شامل کرتے ہیں (اب اس کے رجسٹری میں ٹیگ ہیں #c25 и 1.1)۔ اس کے بعد، ہم اسے پروڈکشن میں لے جاتے ہیں۔

اس میں ایک خرابی ہے کہ سٹیجنگ پر صرف ایک تصویر اپ لوڈ کی جاتی ہے (#c25)، اور پیداوار میں یہ مختلف قسم کا ہے (1.1)، لیکن ہم جانتے ہیں کہ "جسمانی طور پر" یہ رجسٹری کی ایک ہی تصویر ہیں۔

اصل نقصان یہ ہے کہ مرج کمٹ کے لیے کوئی سپورٹ نہیں ہے، آپ کو فاسٹ فارورڈ کرنا ہوگا۔

ہم آگے جا کر ایک چال کر سکتے ہیں... آئیے ایک سادہ ڈاکر فائل کی مثال دیکھیں:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

آئیے درج ذیل اصول کے مطابق اس سے فائل بناتے ہیں۔

• SHA256 استعمال شدہ تصاویر کے شناخت کنندگان سے (ruby:2.3 и nginx:alpine)، جو ان کے مواد کی جانچ پڑتال ہیں؛
• تمام ٹیمیں (RUN, CMD اور اسی طرح.)؛
• شامل کی گئی فائلوں سے SHA256۔

اور ایسی فائل سے چیکسم (دوبارہ SHA256) لیں۔ یہ دستخط ہر وہ چیز جو ڈوکر امیج کے مندرجات کی وضاحت کرتی ہے۔

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

اب، جب یہ ضروری ہو، مثال کے طور پر، ریلیز سے ماسٹر میں تبدیلیوں کو ضم کرنے کے لیے، ہم ایک حقیقی مرج کمٹ کر سکتے ہیں: اس کا ایک مختلف شناخت کنندہ ہوگا، لیکن ایک ہی دستخط ہوگا۔ اسی شناخت کنندہ کے ساتھ ہم تصویر کو پروڈکشن میں رول آؤٹ کریں گے۔

نقصان یہ ہے کہ اب یہ تعین کرنا ممکن نہیں ہو گا کہ کس قسم کی کمٹمنٹ کو پروڈکشن میں دھکیل دیا گیا تھا - چیکسم صرف ایک سمت میں کام کرتے ہیں۔ یہ مسئلہ میٹا ڈیٹا کے ساتھ ایک اضافی پرت سے حل ہوتا ہے - میں آپ کو بعد میں بتاؤں گا۔

werf میں ٹیگ کرنا

werf میں ہم اور بھی آگے بڑھے ہیں اور ایک کیشے کے ساتھ ایک تقسیم شدہ تعمیر کرنے کی تیاری کر رہے ہیں جو ایک مشین پر محفوظ نہیں ہے... لہذا، ہم دو طرح کی Docker امیجز بنا رہے ہیں، ہم انہیں کہتے ہیں۔ اسٹیج и تصویر.

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

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

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

رجسٹری کی صفائی

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

صفائی کی حکمت عملی کیا ہیں؟

1. تم بس کچھ نہیں کر سکتے صاف نہ کرو. بعض اوقات ٹیگز کی ایک بڑی الجھن کو کھولنے کے بجائے اضافی جگہ کے لیے تھوڑی سی ادائیگی کرنا واقعی آسان ہوتا ہے۔ لیکن یہ صرف ایک خاص مقام تک کام کرتا ہے۔
2. مکمل ری سیٹ. اگر آپ تمام تصاویر کو حذف کرتے ہیں اور CI سسٹم میں صرف موجودہ تصاویر کو دوبارہ بناتے ہیں تو ایک مسئلہ پیدا ہو سکتا ہے۔ اگر کنٹینر پروڈکشن میں دوبارہ شروع ہوتا ہے، تو اس کے لیے ایک نئی تصویر لوڈ کی جائے گی - ایسی جس کا ابھی تک کسی نے تجربہ نہیں کیا ہے۔ یہ ناقابل تغیر انفراسٹرکچر کے خیال کو ختم کر دیتا ہے۔
3. نیلے رنگ سبز. ایک رجسٹری بھرنے لگی - ہم دوسری پر تصاویر اپ لوڈ کرتے ہیں۔ پچھلے طریقہ کار کی طرح ایک ہی مسئلہ: آپ کس مقام پر رجسٹری کو صاف کرسکتے ہیں جو اوور فلو ہونا شروع ہوگئی ہے؟
4. وقت کے ساتھ. 1 ماہ سے پرانی تمام تصاویر کو حذف کریں؟ لیکن کوئی ایسی سروس ضرور ہوگی جو ایک ماہ سے اپڈیٹ نہ ہوئی ہو...
5. ہاتھ سے پہلے سے ہی کیا حذف کیا جا سکتا ہے اس کا تعین کریں.

واقعی دو قابل عمل اختیارات ہیں: صاف نہ کریں یا دستی طور پر نیلے سبز + کا مجموعہ۔ مؤخر الذکر صورت میں، ہم مندرجہ ذیل کے بارے میں بات کر رہے ہیں: جب آپ سمجھتے ہیں کہ رجسٹری کو صاف کرنے کا وقت آگیا ہے، تو آپ ایک نیا بناتے ہیں اور اس میں تمام نئی تصاویر شامل کرتے ہیں، مثال کے طور پر، ایک مہینے کے دوران۔ اور ایک مہینے کے بعد، دیکھیں کہ Kubernetes میں کون سے پوڈ اب بھی پرانی رجسٹری استعمال کر رہے ہیں، اور انہیں بھی نئی رجسٹری میں منتقل کریں۔

ہم کیا کرنے آئے ہیں werf? ہم جمع کرتے ہیں:

1. گٹ ہیڈ: تمام ٹیگز، تمام شاخیں - یہ فرض کرتے ہوئے کہ ہمیں تصویروں میں گٹ میں ٹیگ کردہ ہر چیز کی ضرورت ہے (اور اگر نہیں، تو ہمیں اسے گٹ میں ہی حذف کرنے کی ضرورت ہے)؛
2. تمام پھلی جو فی الحال کوبرنیٹس میں پمپ کر دی گئی ہیں۔
3. پرانے ReplicaSets (جو حال ہی میں جاری کیا گیا تھا)، اور ہم ہیلم ریلیز کو اسکین کرنے اور وہاں کی تازہ ترین تصاویر کو منتخب کرنے کا بھی ارادہ رکھتے ہیں۔

... اور اس سیٹ سے ایک وائٹ لسٹ بنائیں - تصاویر کی ایک فہرست جسے ہم حذف نہیں کریں گے۔ ہم باقی سب کچھ صاف کر دیتے ہیں، جس کے بعد ہم یتیم سٹیج کی تصاویر تلاش کرتے ہیں اور انہیں بھی ڈیلیٹ کر دیتے ہیں۔

اسٹیج تعینات کریں۔

قابل اعتماد بیانیہ

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

1. شناخت کنندگان؛
2. سروس کی معلومات؛
3. بہت سی ڈیفالٹ اقدار؛
4. موجودہ حیثیت کے ساتھ سیکشن؛
5. داخلہ ویب ہک کے حصے کے طور پر کی گئی تبدیلیاں؛
6. مختلف کنٹرولرز (اور شیڈیولر) کے کام کا نتیجہ۔

لہذا، جب ایک نئی وسائل کی ترتیب ظاہر ہوتی ہے (نیا)، ہم صرف اس کے ساتھ موجودہ، "لائیو" کنفیگریشن کو لے اور اوور رائٹ نہیں کر سکتے ہیں (رہتے ہیں)۔ ایسا کرنے کے لیے ہمیں موازنہ کرنا پڑے گا۔ نیا آخری لاگو کنفیگریشن کے ساتھ (آخری لاگو) اور اس پر رول کریں۔ رہتے ہیں پیچ موصول.

یہ نقطہ نظر کہا جاتا ہے 2 طرفہ انضمام. یہ مثال کے طور پر ہیلم میں استعمال ہوتا ہے۔

وہاں بھی ہے 3 طرفہ انضمام، جو اس میں مختلف ہے:

• موازنہ آخری لاگو и نیاہم دیکھتے ہیں کہ کیا حذف کیا گیا تھا۔
• موازنہ نیا и رہتے ہیںہم دیکھتے ہیں کہ کیا شامل یا تبدیل کیا گیا ہے۔
• خلاصہ پیچ پر لاگو کیا جاتا ہے رہتے ہیں.

ہم ہیلم کے ساتھ 1000+ ایپلیکیشنز تعینات کرتے ہیں، لہذا ہم اصل میں 2 طرفہ انضمام کے ساتھ رہتے ہیں۔ تاہم، اس میں بہت سے مسائل ہیں جو ہم نے اپنے پیچ کے ساتھ حل کیے ہیں، جو ہیلم کو عام طور پر کام کرنے میں مدد کرتے ہیں۔

اصلی رول آؤٹ کی حیثیت

ہمارا CI سسٹم اگلے ایونٹ کی بنیاد پر Kubernetes کے لیے ایک نئی کنفیگریشن تیار کرنے کے بعد، یہ اسے استعمال کے لیے منتقل کرتا ہے۔ (درخواست دیں) ایک کلسٹر میں - ہیلم کا استعمال کرتے ہوئے یا kubectl apply. اس کے بعد، پہلے سے بیان کردہ N-way انضمام ہوتا ہے، جس کے لیے Kubernetes API CI سسٹم، اور اپنے صارف کو منظوری کے ساتھ جواب دیتا ہے۔

تاہم، ایک بہت بڑا مسئلہ ہے: سب کے بعد کامیاب درخواست کا مطلب کامیاب رول آؤٹ نہیں ہے۔. اگر Kubernetes سمجھتا ہے کہ کن تبدیلیوں کو لاگو کرنے کی ضرورت ہے اور اس کا اطلاق کرتا ہے، تو ہم ابھی تک نہیں جانتے کہ نتیجہ کیا ہوگا۔ مثال کے طور پر، فرنٹ اینڈ میں پوڈز کو اپ ڈیٹ کرنا اور دوبارہ شروع کرنا کامیاب ہو سکتا ہے، لیکن بیک اینڈ میں نہیں، اور ہمیں چل رہی ایپلیکیشن امیجز کے مختلف ورژن ملیں گے۔

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

werf سطح پر اس ٹریکر کا برتاؤ ان تشریحات کا استعمال کرتے ہوئے ترتیب دیا گیا ہے جو Deployments یا StatefulSets پر رکھے گئے ہیں۔ اہم تشریح - fail-mode - مندرجہ ذیل معنی کو سمجھتا ہے:

• IgnoreAndContinueDeployProcess - ہم اس جزو کو رول آؤٹ کرنے کے مسائل کو نظر انداز کرتے ہیں اور تعیناتی کو جاری رکھتے ہیں۔
• FailWholeDeployProcessImmediately - اس جزو میں خرابی تعیناتی کے عمل کو روک دیتی ہے۔
• HopeUntilEndOfDeployProcess - ہم امید کرتے ہیں کہ یہ جزو تعیناتی کے اختتام تک کام کرے گا۔

مثال کے طور پر، وسائل اور تشریحی اقدار کا یہ مجموعہ fail-mode:

جب ہم پہلی بار تعینات کرتے ہیں، ہو سکتا ہے کہ ڈیٹا بیس (MongoDB) ابھی تک تیار نہ ہو - تعیناتیاں ناکام ہو جائیں گی۔ لیکن آپ اس کے شروع ہونے کے لمحے کا انتظار کر سکتے ہیں، اور تعیناتی اب بھی ہو گی۔

werf میں kubedog کے لیے مزید دو تشریحات ہیں:

• failures-allowed-per-replica - ہر نقل کے لئے اجازت شدہ فالس کی تعداد؛
• show-logs-until - اس لمحے کو منظم کرتا ہے جب تک کہ werf تمام رول آؤٹ پوڈز سے لاگز (stdout میں) دکھاتا ہے۔ پہلے سے طے شدہ ہے۔ PodIsReady (ان پیغامات کو نظر انداز کرنے کے لیے جو ہم شاید نہیں چاہتے کہ جب ٹریفک پوڈ پر آنا شروع ہو جائے)، لیکن اقدار بھی درست ہیں: ControllerIsReady и EndOfDeploy.

ہم تعیناتی سے اور کیا چاہتے ہیں؟

پہلے سے بیان کردہ دو نکات کے علاوہ، ہم چاہیں گے:

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

کے نتائج

ایک کمپنی کے طور پر ہمارے لیے، ڈیلیوری کے مختلف مراحل (تعمیر، اشاعت، تعیناتی) پر بیان کردہ تمام باریکیوں کو نافذ کرنے کے لیے، ایک CI سسٹم اور افادیت کافی ہے۔ werf.

کسی نتیجے کے بجائے:

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

ویڈیوز اور سلائیڈز

کارکردگی سے ویڈیو (~47 منٹ):

رپورٹ کی پیشکش:

PS

ہمارے بلاگ پر Kubernetes کے بارے میں دیگر رپورٹس:

• «Kubernetes میں آٹو اسکیلنگ اور وسائل کا انتظام» (دمتری اسٹولیاروف؛ 27 اپریل 2019 کو "ہڑتال" پر);
• «Kubernetes کی توسیع اور تکمیل» (Andrey Polovov؛ 8 اپریل 2019 سینٹ ہائی لوڈ++ پر);
• «ڈیٹا بیس اور کبرنیٹس» (دمتری اسٹولیاروف؛ 8 نومبر 2018 ہائی لوڈ++ پر);
• «نگرانی اور Kubernetes» (دمتری اسٹولیاروف؛ 28 مئی 2018 کو روٹ کانف میں);
• «Kubernetes اور GitLab کے ساتھ CI/CD بہترین طرز عمل» (دمتری اسٹولیاروف؛ 7 نومبر 2017 ہائی لوڈ++ پر);
• «چھوٹے منصوبوں میں Kubernetes کے ساتھ ہمارا تجربہ» (دمتری اسٹولیاروف؛ 6 جون، 2017 روٹ کانف میں).

ماخذ: www.habr.com