ہماری اوپن سورس GitOps CLI یوٹیلیٹی ہے جو Kubernetes کو ایپلیکیشنز بنانے اور پہنچانے کے لیے ہے۔ وعدہ کے مطاپق، werf میں نئی خصوصیات شامل کرنے اور روایتی طریقوں پر نظر ثانی کرنے کے آغاز کو نشان زد کیا۔ اب ہمیں ریلیز v1.1 پیش کرتے ہوئے خوشی ہو رہی ہے، جو ترقی میں ایک بڑا قدم اور مستقبل کی بنیاد ہے۔ جمع کرنے والا werf ورژن فی الحال دستیاب ہے۔ .
ریلیز کی بنیاد نئے اسٹیج اسٹوریج آرکیٹیکچر اور دونوں جمع کرنے والوں کے کام کی اصلاح ہے (اسٹیپل اور ڈاکر فائل کے لیے)۔ نیا اسٹوریج آرکیٹیکچر ایک ہی میزبان پر متعدد میزبانوں اور متوازی اسمبلیوں سے تقسیم شدہ اسمبلیوں کو لاگو کرنے کے امکان کو کھولتا ہے۔
کام کی اصلاح میں مرحلے کے دستخطوں کا حساب لگانے کے مرحلے پر غیر ضروری حسابات سے چھٹکارا حاصل کرنا اور فائل چیکسم کا حساب لگانے کے طریقہ کار کو زیادہ موثر میں تبدیل کرنا شامل ہے۔ یہ اصلاح werf کا استعمال کرتے ہوئے پروجیکٹ کی تعمیر کے اوسط وقت کو کم کرتی ہے۔ اور بیکار بناتا ہے، جب تمام مراحل کیشے میں موجود ہوتے ہیں۔ مراحل - ذخیرہ، اب واقعی تیز ہیں۔ زیادہ تر معاملات میں، تعمیر کو دوبارہ شروع کرنے میں 1 سیکنڈ سے بھی کم وقت لگے گا! یہ ٹیموں کے کام کے عمل میں مراحل کی تصدیق کے طریقہ کار پر بھی لاگو ہوتا ہے۔ werf deploy и werf run.
اس ریلیز میں بھی، مواد کے لحاظ سے تصاویر کو ٹیگ کرنے کی حکمت عملی سامنے آئی۔ مواد پر مبنی ٹیگنگ، جو اب بطور ڈیفالٹ فعال ہے اور صرف ایک تجویز کردہ ہے۔
آئیے werf v1.1 میں اہم اختراعات پر گہری نظر ڈالتے ہیں، اور ساتھ ہی آپ کو مستقبل کے منصوبوں کے بارے میں بتاتے ہیں۔
werf v1.1 میں کیا تبدیلی آئی ہے؟
کیشے سے مراحل کے انتخاب کے لیے نئے مرحلے کے نام کی شکل اور الگورتھم
نئے مرحلے کے نام کی نسل کا اصول۔ اب ہر اسٹیج کی تعمیر ایک منفرد اسٹیج کا نام تیار کرتی ہے، جو 2 حصوں پر مشتمل ہے: ایک دستخط (جیسا کہ یہ v1.0 میں تھا) اور ایک منفرد عارضی شناخت کنندہ۔
مثال کے طور پر، مکمل سٹیج کی تصویر کا نام اس طرح نظر آ سکتا ہے:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
یا عام طور پر:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
یہاں:
-
SIGNATUREایک اسٹیج دستخط ہے، جو اسٹیج کے مواد کے شناخت کنندہ کی نمائندگی کرتا ہے اور Git میں ترمیم کی تاریخ پر منحصر ہے جس کی وجہ سے اس مواد کو بنایا گیا؛ -
TIMESTAMP_MILLISECایک گارنٹی شدہ منفرد تصویری شناخت کنندہ ہے جو اس وقت تیار ہوتا ہے جب ایک نئی تصویر بنتی ہے۔
کیشے سے مراحل کو منتخب کرنے کا الگورتھم گٹ کمٹ کے تعلق کو جانچنے پر مبنی ہے:
- Werf ایک مخصوص مرحلے کے دستخط کا حساب لگاتا ہے۔
- В مراحل - ذخیرہ دیئے گئے دستخط کے کئی مراحل ہو سکتے ہیں۔ Werf دستخط سے مماثل تمام مراحل کا انتخاب کرتا ہے۔
- اگر موجودہ مرحلہ گٹ سے منسلک ہے (گٹ آرکائیو، گٹ پیچ کے ساتھ کسٹم اسٹیج:
install,beforeSetup,setup; یا git-latest-patch)، پھر werf صرف ان مراحل کا انتخاب کرتا ہے جو کسی عہد سے وابستہ ہوتے ہیں جو موجودہ کمٹ (جس کے لیے بلڈ کہا جاتا ہے) کا پرکھ ہوتا ہے۔ - باقی مناسب مراحل میں سے، ایک کا انتخاب کیا جاتا ہے - تخلیق کی تاریخ کے لحاظ سے سب سے قدیم۔
مختلف گٹ شاخوں کے ایک مرحلے میں ایک ہی دستخط ہوسکتے ہیں۔ لیکن werf مختلف شاخوں سے وابستہ کیشے کو ان شاخوں کے درمیان استعمال ہونے سے روکے گا، چاہے دستخط مماثل ہوں۔
.
اسٹیج اسٹوریج میں مراحل بنانے اور محفوظ کرنے کے لیے نیا الگورتھم
اگر، کیشے سے مراحل کا انتخاب کرتے وقت، werf کو کوئی مناسب مرحلہ نہیں ملتا، تو پھر ایک نئے مرحلے کو جمع کرنے کا عمل شروع کیا جاتا ہے۔
نوٹ کریں کہ متعدد عمل (ایک یا زیادہ میزبانوں پر) تقریباً ایک ہی وقت میں ایک ہی مرحلے کی تعمیر شروع کر سکتے ہیں۔ Werf ایک پرامید بلاکنگ الگورتھم استعمال کرتا ہے۔ مراحل - ذخیرہ میں تازہ جمع کی گئی تصویر کو محفوظ کرنے کے وقت مراحل - ذخیرہ. اس طرح، جب نئے سٹیج کی تعمیر تیار ہو جائے تو، werf بلاکس مراحل - ذخیرہ اور ایک تازہ جمع کی گئی تصویر کو صرف اس صورت میں محفوظ کرتا ہے جب کوئی مناسب تصویر وہاں موجود نہ ہو۔ (دستخط اور دیگر پیرامیٹرز کے ذریعے - کیشے سے مراحل منتخب کرنے کے لیے نیا الگورتھم دیکھیں).
ایک تازہ اسمبل شدہ تصویر کے لیے ایک منفرد شناخت کنندہ ہونے کی ضمانت ہے۔ TIMESTAMP_MILLISEC (مرحلہ کے نام کی نئی شکل دیکھیں). صورت میں مراحل - ذخیرہ ایک مناسب تصویر مل جائے گی، werf تازہ مرتب کی گئی تصویر کو رد کر دے گا اور تصویر کو کیشے سے استعمال کرے گا۔
دوسرے لفظوں میں: تصویر کی تعمیر مکمل کرنے کے پہلے عمل (سب سے تیز ترین) کو اسے مراحل میں ذخیرہ کرنے کا حق مل جائے گا (اور پھر یہ واحد تصویر ہے جو تمام تعمیرات کے لیے استعمال کی جائے گی)۔ ایک سست تعمیراتی عمل کبھی بھی تیز تر عمل کو موجودہ مرحلے کے تعمیراتی نتائج کو بچانے اور اگلی تعمیر پر جانے سے روک نہیں سکتا۔
.
Dockerfile بلڈر کی کارکردگی میں بہتری
اس وقت، ڈاکر فائل سے بنائی گئی تصویر کے مراحل کی پائپ لائن ایک مرحلے پر مشتمل ہے۔ dockerfile. دستخط کا حساب لگاتے وقت، فائلوں کے چیکسم کا حساب لگایا جاتا ہے۔ context، جو اسمبلی کے دوران استعمال کیا جائے گا۔ اس بہتری سے پہلے، werf بار بار تمام فائلوں کے ذریعے چلتا تھا اور ہر فائل کے سیاق و سباق اور موڈ کا خلاصہ کرکے ایک چیکسم حاصل کرتا تھا۔ v1.1 کے ساتھ شروع کرتے ہوئے، werf گٹ ریپوزٹری میں محفوظ کیلکولیٹڈ چیکسم استعمال کر سکتا ہے۔
الگورتھم پر مبنی ہے۔ . الگورتھم اکاؤنٹ کے ریکارڈز میں لیتا ہے۔ .dockerignore اور صرف ضروری ہونے پر فائل ٹری کو بار بار عبور کرتا ہے۔ اس طرح، ہم نے فائل سسٹم کو پڑھنے سے الگ کر دیا ہے، اور سائز پر الگورتھم کا انحصار context اہم نہیں ہے.
الگورتھم غیر ٹریک شدہ فائلوں کو بھی چیک کرتا ہے اور اگر ضروری ہو تو چیکسم میں ان کو مدنظر رکھتا ہے۔
فائلوں کو درآمد کرتے وقت بہتر کارکردگی
werf v1.1 کے ورژن جب rsync سرور استعمال کرتے ہیں۔ . پہلے، میزبان سسٹم سے ڈائرکٹری ماؤنٹ کا استعمال کرتے ہوئے دو مراحل میں درآمد کی جاتی تھی۔
macOS پر درآمدی کارکردگی اب Docker والیومز تک محدود نہیں ہے، اور درآمدات اسی وقت میں مکمل ہوتی ہیں جیسے لینکس اور ونڈوز۔
مواد پر مبنی ٹیگنگ
Werf v1.1 تصویری مواد کے ذریعے نام نہاد ٹیگنگ کی حمایت کرتا ہے - مواد پر مبنی ٹیگنگ. نتیجے میں ڈوکر امیجز کے ٹیگز ان امیجز کے مواد پر منحصر ہیں۔
کمانڈ چلاتے وقت werf publish --tags-by-stages-signature یا werf ci-env --tagging-strategy=stages-signature نام نہاد کی شائع کردہ تصاویر مرحلے کے دستخط تصویر. ہر تصویر کو اس تصویر کے مراحل کے اپنے دستخط کے ساتھ ٹیگ کیا جاتا ہے، جس کا حساب انہی اصولوں کے مطابق کیا جاتا ہے جس طرح ہر مرحلے کے الگ الگ دستخط ہوتے ہیں، لیکن یہ تصویر کا عمومی شناخت کنندہ ہے۔
تصویر کے مراحل کے دستخط پر منحصر ہے:
- اس تصویر کے مواد؛
- Git تبدیلیوں کی ہسٹری جس کی وجہ سے اس مواد میں اضافہ ہوا۔
گٹ ریپوزٹری میں ہمیشہ ڈمی کمٹ ہوتے ہیں جو امیج فائلوں کے مواد کو تبدیل نہیں کرتے ہیں۔ مثال کے طور پر، صرف تبصروں کے ساتھ کمٹ کرتا ہے یا کمٹ کو ضم کرتا ہے، یا کمٹ کرتا ہے جو Git میں ان فائلوں کو تبدیل کرتا ہے جو امیج میں درآمد نہیں کی جائیں گی۔
مواد پر مبنی ٹیگنگ کا استعمال کرتے وقت، تصویر کے نام میں تبدیلی کی وجہ سے Kubernetes میں ایپلیکیشن پوڈز کے غیر ضروری دوبارہ شروع ہونے کے مسائل حل ہو جاتے ہیں، چاہے تصویر کے مواد میں کوئی تبدیلی نہ ہوئی ہو۔ ویسے، یہ ان وجوہات میں سے ایک ہے جو ایک ایپلی کیشن کی بہت سی مائیکرو سروسز کو ایک ہی Git ریپوزٹری میں اسٹور کرنے سے روکتی ہے۔
اس کے علاوہ، مواد پر مبنی ٹیگنگ گٹ برانچز پر ٹیگنگ کے مقابلے میں زیادہ قابل اعتماد ٹیگنگ طریقہ ہے، کیونکہ نتیجے میں آنے والی تصاویر کا مواد اس ترتیب پر منحصر نہیں ہوتا ہے جس میں ایک ہی برانچ کے متعدد کمٹ کو جمع کرنے کے لیے CI سسٹم میں پائپ لائنوں کو عمل میں لایا جاتا ہے۔
یہ ضروری ہے: ابھی سے شروع مراحل - دستخط ہے - صرف تجویز کردہ ٹیگنگ حکمت عملی. یہ کمانڈ میں بطور ڈیفالٹ استعمال ہوگا۔ werf ci-env (جب تک کہ آپ واضح طور پر ایک مختلف ٹیگنگ اسکیم کی وضاحت نہیں کرتے ہیں)۔
. اس خصوصیت کے لیے ایک علیحدہ اشاعت بھی مختص کی جائے گی۔ اپ ڈیٹ شدہ (3 اپریل): تفصیل کے ساتھ مضمون .
لاگنگ کی سطح
صارف کے پاس اب آؤٹ پٹ کو کنٹرول کرنے، لاگنگ لیول سیٹ کرنے اور ڈیبگنگ کی معلومات کے ساتھ کام کرنے کا موقع ہے۔ اختیارات شامل کیے گئے۔ --log-quiet, --log-verbose, --log-debug.
پہلے سے طے شدہ طور پر، آؤٹ پٹ کم از کم معلومات پر مشتمل ہے:
وربوز آؤٹ پٹ استعمال کرتے وقت (--log-verbose) آپ دیکھ سکتے ہیں کہ werf کیسے کام کرتا ہے:
تفصیلی آؤٹ پٹ (--log-debug, werf ڈیبگنگ کی معلومات کے علاوہ، استعمال شدہ لائبریریوں کے لاگز بھی شامل ہیں۔ مثال کے طور پر، آپ دیکھ سکتے ہیں کہ ڈوکر رجسٹری کے ساتھ کس طرح تعامل ہوتا ہے، اور ان جگہوں کو بھی ریکارڈ کریں جہاں کافی وقت صرف ہوتا ہے:
مستقبل کے منصوبے
ہوشیار! ذیل میں بیان کردہ اختیارات نشان زد ہیں۔ v1.1 اس ورژن میں دستیاب ہوں گے، ان میں سے بہت سے مستقبل قریب میں۔ اپ ڈیٹس خودکار اپ ڈیٹس کے ذریعے آئیں گی۔ . یہ خصوصیات v1.1 فنکشنز کے مستحکم حصے کو متاثر نہیں کرتی ہیں؛ ان کی ظاہری شکل کو موجودہ کنفیگریشنز میں دستی صارف کی مداخلت کی ضرورت نہیں ہوگی۔
مختلف ڈاکر رجسٹری کے نفاذ کے لیے مکمل تعاون (نیا)
- ورژن: v1.1
- تاریخیں: مارچ
مقصد یہ ہے کہ صارف werf کا استعمال کرتے وقت بغیر کسی پابندی کے اپنی مرضی کے نفاذ کا استعمال کرے۔
فی الحال، ہم نے حل کے درج ذیل سیٹ کی نشاندہی کی ہے جس کے لیے ہم مکمل تعاون کی ضمانت دینے جا رہے ہیں:
- پہلے سے طے شدہ (لائبریری/رجسٹری)*،
- AWS ECR
- Azure*،
- ڈاکر حب
- جی سی آر*،
- GitHub پیکجز
- گٹ لیب رجسٹری*،
- بندرگاہ*،
- کوے
حل جو فی الحال مکمل طور پر werf کی طرف سے تعاون یافتہ ہیں ایک ستارے کے ساتھ نشان لگا دیا گیا ہے. دوسروں کے لیے حمایت ہے، لیکن حدود کے ساتھ۔
دو اہم مسائل کی نشاندہی کی جا سکتی ہے:
- کچھ حل ڈوکر رجسٹری API کا استعمال کرتے ہوئے ٹیگ ہٹانے کی حمایت نہیں کرتے ہیں، صارفین کو werf کی خودکار صفائی کے استعمال سے روکتے ہیں۔ یہ AWS ECR، Docker Hub، اور GitHub پیکیجز کے لیے درست ہے۔
- کچھ حل نام نہاد نیسٹڈ ریپوزٹریز (Docker Hub، GitHub Packages اور Quay) کی حمایت نہیں کرتے ہیں یا کرتے ہیں، لیکن صارف کو UI یا API (AWS ECR) کا استعمال کرتے ہوئے انہیں دستی طور پر تخلیق کرنا چاہیے۔
ہم حل کے مقامی APIs کا استعمال کرتے ہوئے ان اور دیگر مسائل کو حل کرنے جا رہے ہیں۔ اس کام میں ان میں سے ہر ایک کے ٹیسٹ کے ساتھ werf آپریشن کے مکمل سائیکل کا احاطہ کرنا بھی شامل ہے۔
تقسیم شدہ تصویر کی تعمیر (↑)
- ورژن: v1.2 v1.1 (اس خصوصیت کو نافذ کرنے کی ترجیح بڑھا دی گئی ہے)
- تاریخیں: مارچ-اپریل مارچ
اس وقت، werf v1.0 اور v1.1 کو صرف ایک مخصوص میزبان پر امیجز بنانے اور شائع کرنے اور ایپلیکیشن کو کوبرنیٹس پر تعینات کرنے کے لیے استعمال کیا جا سکتا ہے۔
werf کے تقسیم شدہ کام کے امکانات کو کھولنے کے لیے، جب Kubernetes میں ایپلی کیشنز کی تعمیر اور تعیناتی کئی صوابدیدی میزبانوں پر شروع کی جاتی ہے اور یہ میزبان اپنی حالت کو بلڈز (عارضی رنرز) کے درمیان نہیں بچاتے ہیں، werf کو استعمال کرنے کی صلاحیت کو نافذ کرنے کی ضرورت ہوتی ہے۔ ڈوکر رجسٹری بطور اسٹیج اسٹور۔
پہلے، جب werf پروجیکٹ کو اب بھی dapp کہا جاتا تھا، اس کے پاس ایسا موقع تھا۔ تاہم، ہمیں متعدد مسائل کا سامنا کرنا پڑا ہے جن کو werf میں اس فعالیت کو نافذ کرتے وقت دھیان میں رکھنا ضروری ہے۔
نوٹ. اس خصوصیت کے لیے کلکٹر کو Kubernetes pods کے اندر کام کرنے کی ضرورت نہیں ہے، کیونکہ ایسا کرنے کے لیے، آپ کو مقامی ڈوکر سرور پر انحصار سے چھٹکارا حاصل کرنے کی ضرورت ہے (Kubernetes پوڈ میں مقامی Docker سرور تک رسائی نہیں ہے، کیونکہ یہ عمل خود ایک کنٹینر میں چل رہا ہے، اور werf اس کی حمایت نہیں کرتا اور نہ کرے گا۔ نیٹ ورک پر ڈوکر سرور کے ساتھ کام کرنا)۔ Kubernetes کو چلانے کے لیے سپورٹ کو الگ سے لاگو کیا جائے گا۔
GitHub ایکشنز کے لیے باضابطہ تعاون (نیا)
- ورژن: v1.1
- تاریخیں: مارچ
ورف دستاویزات پر مشتمل ہے (سیکشنز حوالہ и رہنمائی) کے ساتھ ساتھ werf کے ساتھ کام کرنے کے لیے سرکاری GitHub ایکشن۔
اس کے علاوہ، یہ werf کو عارضی رنرز پر کام کرنے کی اجازت دے گا۔
CI سسٹم کے ساتھ صارف کے تعامل کا میکانکس ایپلی کیشن کو بنانے/رول آؤٹ کرنے کے لیے مخصوص اقدامات شروع کرنے کے لیے پل کی درخواستوں پر لیبل لگانے پر مبنی ہوگا۔
werf (↓) کے ساتھ ایپلی کیشنز کی مقامی ترقی اور تعیناتی
- ورژن: v1.1
- تاریخیں: جنوری-فروری اپریل
بنیادی مقصد یہ ہے کہ ایپلیکیشنز کو مقامی طور پر اور پروڈکشن دونوں جگہوں پر، پیچیدہ کارروائیوں کے بغیر، باکس سے باہر تعینات کرنے کے لیے ایک واحد متحد ترتیب حاصل کرنا ہے۔
werf کے لیے ایک آپریٹنگ موڈ ہونا بھی ضروری ہے جس میں ایپلیکیشن کوڈ میں ترمیم کرنا اور ڈیبگنگ کے لیے چل رہی ایپلیکیشن سے فوری طور پر فیڈ بیک حاصل کرنا آسان ہوگا۔
نیا صفائی الگورتھم (نیا)
- ورژن: v1.1
- تاریخیں: اپریل
طریقہ کار میں werf v1.1 کے موجودہ ورژن میں cleanup مواد پر مبنی ٹیگنگ اسکیم کے لیے تصاویر کی صفائی کا کوئی انتظام نہیں ہے - یہ تصاویر جمع ہو جائیں گی۔
نیز، werf کا موجودہ ورژن (v1.0 اور v1.1) ٹیگنگ اسکیموں کے تحت شائع ہونے والی تصاویر کے لیے صفائی کی مختلف پالیسیوں کا استعمال کرتا ہے: گٹ برانچ، گِٹ ٹیگ یا گِٹ کمٹ۔
گٹ میں کمٹ کی تاریخ پر مبنی تصاویر کی صفائی کے لیے ایک نیا الگورتھم، تمام ٹیگنگ اسکیموں کے لیے متحد، ایجاد کیا گیا ہے:
- ہر گٹ ہیڈ (شاخوں اور ٹیگز) کے لیے N1 کی حالیہ کمٹ کے ساتھ منسلک N2 سے زیادہ تصاویر نہ رکھیں۔
- ہر گٹ ہیڈ (شاخوں اور ٹیگز) کے لیے N1 کی حالیہ کمٹ کے ساتھ منسلک N2 اسٹیج کی تصاویر سے زیادہ ذخیرہ نہ کریں۔
- کسی بھی Kubernetes کلسٹر وسائل میں استعمال ہونے والی تمام تصاویر کو اسٹور کریں (کنفیگریشن فائل کے تمام کیوب سیاق و سباق اور نام کی جگہوں کو اسکین کیا گیا ہے؛ آپ خصوصی اختیارات کے ساتھ اس رویے کو محدود کر سکتے ہیں)۔
- ہیلم ریلیز میں محفوظ کردہ ریسورس کنفیگریشن مینی فیسٹ میں استعمال ہونے والی تمام تصاویر کو اسٹور کریں۔
- کسی تصویر کو حذف کیا جا سکتا ہے اگر وہ گٹ کے کسی ہیڈ کے ساتھ منسلک نہ ہو (مثال کے طور پر، کیونکہ متعلقہ ہیڈ ہی ڈیلیٹ کر دیا گیا تھا) اور اسے کبرنیٹس کلسٹر اور ہیلم ریلیز میں کسی مینی فیسٹ میں استعمال نہیں کیا جاتا ہے۔
متوازی امیج بلڈنگ (↓)
- ورژن: v1.1
- تاریخیں: جنوری-فروری اپریل*
werf کے موجودہ ورژن میں بیان کردہ تصاویر اور نمونے جمع کیے گئے ہیں۔ werf.yaml، ترتیب وار۔ تصاویر اور نمونے کے آزاد مراحل کو جمع کرنے کے عمل کو متوازی بنانے کے ساتھ ساتھ آسان اور معلوماتی پیداوار فراہم کرنا ضروری ہے۔
* نوٹ: تقسیم شدہ اسمبلی کو لاگو کرنے کے لیے بڑھتی ہوئی ترجیح کی وجہ سے ڈیڈ لائن کو تبدیل کر دیا گیا ہے، جس سے مزید افقی پیمانے کی صلاحیتوں کے ساتھ ساتھ GitHub ایکشنز کے ساتھ werf کے استعمال کا اضافہ ہو گا۔ متوازی اسمبلی اگلا اصلاحی مرحلہ ہے، جو ایک پروجیکٹ کو جمع کرتے وقت عمودی اسکیل ایبلٹی فراہم کرتا ہے۔
ہیلم 3 میں منتقلی (↓)
- ورژن: v1.2
- تاریخیں: فروری-مارچ مئی*
نئے کوڈبیس میں منتقلی شامل ہے۔ اور موجودہ تنصیبات کو منتقل کرنے کا ایک ثابت، آسان طریقہ۔
* نوٹ: ہیلم 3 پر سوئچ کرنے سے werf میں اہم خصوصیات شامل نہیں ہوں گی، کیونکہ Helm 3 کی تمام اہم خصوصیات (3 طرفہ مرج اور کوئی ٹیلر نہیں) پہلے سے ہی werf میں لاگو ہیں۔ اس کے علاوہ، werf ہے اشارہ کرنے والوں کے علاوہ۔ تاہم، یہ منتقلی ہمارے منصوبوں میں باقی ہے اور اسے نافذ کیا جائے گا۔
Kubernetes کنفیگریشن (↓) کو بیان کرنے کے لیے Jsonnet
- ورژن: v1.2
- تاریخیں: جنوری-فروری اپریل-مئی
Werf Jsonnet فارمیٹ میں Kubernetes کے لیے کنفیگریشن کی تفصیل کو سپورٹ کرے گا۔ اسی وقت، werf ہیلم کے ساتھ مطابقت رکھتا رہے گا اور وضاحت کی شکل کا انتخاب ہوگا۔
اس کی وجہ یہ ہے کہ گو ٹیمپلیٹس میں، بہت سے لوگوں کے مطابق، داخلے میں زیادہ رکاوٹ ہوتی ہے، اور ان ٹیمپلیٹس کے کوڈ کی سمجھ بوجھ بھی متاثر ہوتی ہے۔
دوسرے Kubernetes کنفیگریشن ڈسکرپشن سسٹمز (مثال کے طور پر Kustomize) متعارف کرانے کے امکان پر بھی غور کیا جا رہا ہے۔
Kubernetes کے اندر کام کرنا (↓)
- ورژن: v1.2
- تاریخیں: اپریل مئی مئی جون
مقصد: یقینی بنائیں کہ تصاویر بنائی گئی ہیں اور ایپلیکیشن کوبرنیٹس میں رنر کا استعمال کرتے ہوئے ڈیلیور کیا گیا ہے۔ وہ. نئی تصاویر بنائی جا سکتی ہیں، شائع کی جا سکتی ہیں، صاف کی جا سکتی ہیں، اور براہ راست Kubernetes pods سے تعینات کی جا سکتی ہیں۔
اس قابلیت کو نافذ کرنے کے لیے، آپ کو پہلے تقسیم شدہ تصاویر بنانے کے قابل ہونے کی ضرورت ہے۔ (اوپر پوائنٹ دیکھیں).
اسے ڈوکر سرور کے بغیر بلڈر کے آپریٹنگ موڈ کے لیے بھی سپورٹ کی ضرورت ہوتی ہے (یعنی کنیکو کی طرح کی تعمیر یا یوزر اسپیس میں تعمیر)۔
Werf نہ صرف Dockerfile کے ساتھ، بلکہ اس کے Stapel بلڈر کے ساتھ بھی incremental rebuilds اور Ansible کے ساتھ Kubernetes پر تعمیر کی حمایت کرے گا۔
کھلی ترقی کی طرف ایک قدم
ہمیں اپنی برادری سے پیار ہے (, اور ہم چاہتے ہیں کہ زیادہ سے زیادہ لوگ werf کو بہتر بنانے میں مدد کریں، ہم جس سمت میں آگے بڑھ رہے ہیں اسے سمجھیں، اور ترقی میں حصہ لیں۔
کافی حال ہی میں اس پر سوئچ کرنے کا فیصلہ کیا گیا تھا۔ ہماری ٹیم کے کام کرنے کے عمل کو ظاہر کرنے کے لیے۔ اب آپ فوری منصوبوں کے ساتھ ساتھ درج ذیل شعبوں میں موجودہ کام دیکھ سکتے ہیں۔
- ;
- ;
- ;
- .
مسائل کے ساتھ بہت سے کام کیے گئے ہیں:
- غیر متعلقہ کو ہٹا دیا۔
- موجودہ کو ایک ہی شکل میں لایا جاتا ہے، جس میں کافی تعداد میں تفصیلات اور تفصیلات ہیں۔
- خیالات اور تجاویز کے ساتھ نئے مسائل شامل کیے گئے ہیں۔
ورژن v1.1 کو کیسے فعال کریں۔
ورژن فی الحال دستیاب ہے۔ (چینلز میں مستحکم и چٹان کی طرح مضبوط تاہم، استحکام کے ہوتے ہی ریلیز ظاہر ہوں گی۔ ea خود استعمال کے لیے پہلے ہی کافی مستحکم ہے، کیونکہ چینلز کے ذریعے چلا گیا الفا и بیٹا)۔ چالو مندرجہ ذیل طریقے سے:
source $(multiwerf use 1.1 ea)
werf COMMAND ...حاصل يہ ہوا
اسٹیپل اور ڈاکر فائل بلڈرز کے لیے نئے اسٹیج اسٹوریج آرکیٹیکچر اور بلڈر کی اصلاح werf میں تقسیم شدہ اور متوازی تعمیرات کو لاگو کرنے کے امکانات کو کھولتی ہے۔ یہ خصوصیات جلد ہی اسی v1.1 ریلیز میں ظاہر ہوں گی اور آٹو اپ ڈیٹ میکانزم (صارفین کے لیے) کے ذریعے خود بخود دستیاب ہو جائیں گی۔ ).
اس ریلیز میں تصویری مواد پر مبنی ٹیگنگ کی حکمت عملی شامل کی گئی ہے۔ مواد پر مبنی ٹیگنگ، جو پہلے سے طے شدہ حکمت عملی بن چکی ہے۔ مین کمانڈ لاگ کو بھی دوبارہ کام کیا گیا ہے: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
اگلا اہم مرحلہ تقسیم شدہ اسمبلیوں کو شامل کرنا ہے۔ تقسیم شدہ تعمیرات v1.0 کے بعد سے متوازی تعمیرات کے مقابلے میں ایک اعلی ترجیح بن گئی ہیں کیونکہ وہ werf میں مزید قدر کا اضافہ کرتے ہیں: مختلف CI/CD سسٹمز میں عارضی تعمیر کرنے والوں کی عمودی اسکیلنگ اور ساتھ ہی GitHub ایکشنز کے لیے باضابطہ تعاون کرنے کی صلاحیت . اس لیے متوازی اسمبلیوں کے لیے عمل درآمد کی آخری تاریخ کو تبدیل کر دیا گیا۔ تاہم، ہم دونوں امکانات کو جلد از جلد نافذ کرنے کے لیے کام کر رہے ہیں۔
خبروں پر عمل کریں! اور ہم سے ملاقات کرنا نہ بھولیں۔ ایک مسئلہ پیدا کرنے کے لیے، ایک موجودہ تلاش کریں اور ایک پلس شامل کریں، ایک PR بنائیں، یا صرف پروجیکٹ کی ترقی کو دیکھیں۔
PS
ہمارے بلاگ پر بھی پڑھیں:
- «»
- «؛ "
- werf میں اختراعات کے بارے میں نوٹوں کا ایک سلسلہ:
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com