werf 1.1 রিলিজ: আজ নির্মাতার উন্নতি এবং ভবিষ্যতের জন্য পরিকল্পনা

werf Kubernetes-এ অ্যাপ্লিকেশন তৈরি এবং বিতরণের জন্য আমাদের ওপেন সোর্স GitOps CLI ইউটিলিটি। প্রতিশ্রুত, সংস্করণ v1.0 প্রকাশ werf-এ নতুন বৈশিষ্ট্য যোগ করার এবং ঐতিহ্যগত পদ্ধতির সংশোধনের সূচনা চিহ্নিত করেছে। এখন আমরা রিলিজ v1.1 উপস্থাপন করতে পেরে আনন্দিত, যা উন্নয়নের একটি বড় পদক্ষেপ এবং ভবিষ্যতের জন্য একটি ভিত্তি সংগ্রাহক werf সংস্করণ বর্তমানে উপলব্ধ চ্যানেল 1.1 ea.

রিলিজের ভিত্তি হল স্টেপেল স্টোরেজের নতুন আর্কিটেকচার এবং উভয় সংগ্রাহকের কাজের অপ্টিমাইজেশন (স্ট্যাপেল এবং ডকারফাইলের জন্য)। নতুন স্টোরেজ আর্কিটেকচার একই হোস্টে একাধিক হোস্ট এবং সমান্তরাল সমাবেশগুলি থেকে বিতরণ করা সমাবেশগুলি বাস্তবায়নের সম্ভাবনা উন্মুক্ত করে।

কাজের অপ্টিমাইজেশনের মধ্যে রয়েছে পর্যায় স্বাক্ষর গণনা করার পর্যায়ে অপ্রয়োজনীয় গণনা থেকে পরিত্রাণ পাওয়া এবং ফাইল চেকসামগুলি গণনা করার পদ্ধতিগুলিকে আরও কার্যকরীতে পরিবর্তন করা। এই অপ্টিমাইজেশানটি 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 একটি পর্যায় স্বাক্ষর, যা স্টেজের বিষয়বস্তুর শনাক্তকারীকে প্রতিনিধিত্ব করে এবং গিট-এর সম্পাদনার ইতিহাসের উপর নির্ভর করে যা এই বিষয়বস্তুর দিকে পরিচালিত করে;
• TIMESTAMP_MILLISEC একটি গ্যারান্টিযুক্ত অনন্য ইমেজ আইডেন্টিফায়ার যা একটি নতুন ছবি তৈরি করার সময় তৈরি হয়।

ক্যাশে থেকে পর্যায় নির্বাচন করার জন্য অ্যালগরিদম গিট কমিটের সম্পর্ক পরীক্ষা করার উপর ভিত্তি করে:

1. Werf একটি নির্দিষ্ট পর্যায়ে স্বাক্ষর গণনা করে।
2. В স্টেজ-সঞ্চয়স্থান প্রদত্ত স্বাক্ষরের জন্য বেশ কয়েকটি ধাপ থাকতে পারে। Werf স্বাক্ষরের সাথে মেলে এমন সমস্ত ধাপ নির্বাচন করে।
3. যদি বর্তমান পর্যায়টি গিটের সাথে সংযুক্ত থাকে (গিট-আর্কাইভ, গিট প্যাচ সহ কাস্টম পর্যায়: install, beforeSetup, setup; অথবা git-latest-patch), তারপর werf শুধুমাত্র সেই পর্যায়গুলি নির্বাচন করে যেগুলি একটি কমিটের সাথে যুক্ত যা বর্তমান কমিটের পূর্বপুরুষ (যার জন্য বিল্ড বলা হয়)।
4. অবশিষ্ট উপযুক্ত পর্যায় থেকে, একটি নির্বাচন করা হয় - সৃষ্টির তারিখ অনুসারে প্রাচীনতম।

বিভিন্ন গিট শাখার একটি পর্যায়ে একই স্বাক্ষর থাকতে পারে। কিন্তু werf বিভিন্ন শাখার সাথে যুক্ত ক্যাশেকে এই শাখাগুলির মধ্যে ব্যবহার করা থেকে বাধা দেবে, এমনকি স্বাক্ষরগুলি মিললেও।

→ ডকুমেন্টেশন.

স্টেজ স্টোরেজের স্টেজ তৈরি এবং সেভ করার জন্য নতুন অ্যালগরিদম

যদি, ক্যাশে থেকে পর্যায়গুলি নির্বাচন করার সময়, werf একটি উপযুক্ত পর্যায় খুঁজে না পায়, তাহলে একটি নতুন পর্যায় একত্রিত করার প্রক্রিয়া শুরু হয়।

মনে রাখবেন যে একাধিক প্রক্রিয়া (এক বা একাধিক হোস্টে) প্রায় একই সময়ে একই পর্যায় তৈরি করা শুরু করতে পারে। Werf একটি আশাবাদী ব্লকিং অ্যালগরিদম ব্যবহার করে স্টেজ-সঞ্চয়স্থান সদ্য সংগৃহীত ছবিটি সংরক্ষণ করার মুহূর্তে স্টেজ-সঞ্চয়স্থান. এইভাবে, যখন নতুন স্টেজ বিল্ড প্রস্তুত, werf ব্লক স্টেজ-সঞ্চয়স্থান এবং সেখানে একটি নতুন সংগৃহীত ছবি সংরক্ষণ করে শুধুমাত্র যদি একটি উপযুক্ত চিত্র সেখানে আর বিদ্যমান না থাকে (স্বাক্ষর এবং অন্যান্য পরামিতি দ্বারা - ক্যাশে থেকে পর্যায় নির্বাচন করার জন্য নতুন অ্যালগরিদম দেখুন).

একটি নতুন একত্রিত চিত্রের দ্বারা একটি অনন্য শনাক্তকারীর নিশ্চয়তা রয়েছে৷ TIMESTAMP_MILLISEC (নতুন পর্যায় নামকরণ বিন্যাস দেখুন). ক্ষেত্রে স্টেজ-সঞ্চয়স্থান একটি উপযুক্ত চিত্র পাওয়া যাবে, werf সদ্য সংকলিত চিত্রটি বাতিল করে দেবে এবং ক্যাশে থেকে ছবিটি ব্যবহার করবে।

অন্য কথায়: ইমেজ নির্মাণ শেষ করার প্রথম প্রক্রিয়া (দ্রুততমটি) এটিকে পর্যায়-সঞ্চয়স্থানে সংরক্ষণ করার অধিকার পাবে (এবং তারপরে এটি এই একক চিত্র যা সমস্ত বিল্ডের জন্য ব্যবহার করা হবে)। একটি ধীর বিল্ড প্রক্রিয়া বর্তমান পর্যায়ের বিল্ড ফলাফল সংরক্ষণ এবং পরবর্তী বিল্ডে যেতে একটি দ্রুততর প্রক্রিয়াকে কখনই ব্লক করবে না।

→ ডকুমেন্টেশন.

উন্নত Dockerfile নির্মাতা কর্মক্ষমতা

এই মুহুর্তে, একটি ডকারফাইল থেকে নির্মিত একটি চিত্রের জন্য ধাপগুলির পাইপলাইন একটি পর্যায় নিয়ে গঠিত - dockerfile. স্বাক্ষর গণনা করার সময়, ফাইলগুলির চেকসাম গণনা করা হয় context, যা সমাবেশের সময় ব্যবহার করা হবে। এই উন্নতির আগে, werf পুনরাবৃত্তভাবে সমস্ত ফাইলের মধ্য দিয়ে হেঁটেছিল এবং প্রতিটি ফাইলের প্রসঙ্গ এবং মোড যোগ করে একটি চেকসাম পেয়েছে। v1.1 দিয়ে শুরু করে, werf একটি গিট রিপোজিটরিতে সংরক্ষিত গণনাকৃত চেকসাম ব্যবহার করতে পারে।

অ্যালগরিদম উপর ভিত্তি করে git ls-বৃক্ষ. অ্যালগরিদম অ্যাকাউন্টে রেকর্ড গ্রহণ করে .dockerignore এবং প্রয়োজন হলেই ফাইল ট্রিকে পুনরাবৃত্তি করে। এইভাবে, আমরা ফাইল সিস্টেম পড়া থেকে আলাদা হয়েছি, এবং আকারের উপর অ্যালগরিদমের নির্ভরতা context উল্লেখযোগ্য নয়।

অ্যালগরিদম আনট্র্যাক করা ফাইলগুলিও পরীক্ষা করে এবং প্রয়োজনে চেকসামে সেগুলিকে বিবেচনায় নেয়।

ফাইল আমদানি করার সময় উন্নত কর্মক্ষমতা

werf v1.1 এর সংস্করণগুলি যখন একটি rsync সার্ভার ব্যবহার করে আর্টিফ্যাক্ট এবং ছবি থেকে ফাইল আমদানি করা. পূর্বে, হোস্ট সিস্টেম থেকে একটি ডিরেক্টরি মাউন্ট ব্যবহার করে দুটি ধাপে আমদানি করা হত।

ম্যাকওএস-এ আমদানি কার্যকারিতা আর ডকার ভলিউম দ্বারা সীমাবদ্ধ নয় এবং লিনাক্স এবং উইন্ডোজের মতো একই সময়ে আমদানি সম্পূর্ণ হয়।

বিষয়বস্তু ভিত্তিক ট্যাগিং

Werf v1.1 ছবির বিষয়বস্তু দ্বারা তথাকথিত ট্যাগিং সমর্থন করে - বিষয়বস্তু ভিত্তিক ট্যাগিং. ফলস্বরূপ ডকার চিত্রগুলির ট্যাগগুলি সেই চিত্রগুলির বিষয়বস্তুর উপর নির্ভর করে।

কমান্ড চালানোর সময় werf publish --tags-by-stages-signature বা werf ci-env --tagging-strategy=stages-signature তথাকথিত প্রকাশিত ছবি মঞ্চ স্বাক্ষর ইমেজ প্রতিটি চিত্রকে এই চিত্রের পর্যায়গুলির নিজস্ব স্বাক্ষরের সাথে ট্যাগ করা হয়, যা প্রতিটি পর্যায়ের নিয়মিত স্বাক্ষরের মতো আলাদাভাবে একই নিয়ম অনুসারে গণনা করা হয়, তবে এটি চিত্রটির একটি সাধারণ সনাক্তকারী।

চিত্র পর্যায়ে স্বাক্ষর নির্ভর করে:

1. এই ছবির বিষয়বস্তু;
2. গিট পরিবর্তনের ইতিহাস যা এই বিষয়বস্তুর দিকে পরিচালিত করে।

একটি গিট রিপোজিটরিতে সবসময় ডামি কমিট থাকে যা ইমেজ ফাইলের বিষয়বস্তু পরিবর্তন করে না। উদাহরণস্বরূপ, শুধুমাত্র মন্তব্যের সাথে প্রতিশ্রুতি দেয় বা মার্জ কমিট করে, বা প্রতিশ্রুতি দেয় যা গিটে সেই ফাইলগুলিকে পরিবর্তন করে যা ছবিতে আমদানি করা হবে না।

বিষয়বস্তু-ভিত্তিক ট্যাগিং ব্যবহার করার সময়, ছবির নাম পরিবর্তনের কারণে কুবারনেটে অ্যাপ্লিকেশন পডগুলির অপ্রয়োজনীয় পুনরায় চালু হওয়ার সমস্যাগুলি সমাধান করা হয়, এমনকি ছবির বিষয়বস্তু পরিবর্তিত না হলেও। যাইহোক, এটি একটি কারণ যা একটি একক গিট সংগ্রহস্থলে একটি অ্যাপ্লিকেশনের অনেকগুলি মাইক্রোসার্ভিস সংরক্ষণ করতে বাধা দেয়।

এছাড়াও, বিষয়বস্তু-ভিত্তিক ট্যাগিং হল গিট শাখায় ট্যাগ করার চেয়ে আরও নির্ভরযোগ্য ট্যাগিং পদ্ধতি, কারণ ফলাফলের চিত্রগুলির বিষয়বস্তু একই শাখার একাধিক প্রতিশ্রুতি একত্রিত করার জন্য CI সিস্টেমে পাইপলাইনগুলি যে ক্রমানুসারে কার্যকর করা হয় তার উপর নির্ভর করে না।

গুরুত্বপূর্ণ: এখন থেকে শুরু ধাপ-স্বাক্ষর - এটা শুধুমাত্র প্রস্তাবিত ট্যাগিং কৌশল. এটি কমান্ডে ডিফল্টরূপে ব্যবহার করা হবে werf ci-env (যদি না আপনি স্পষ্টভাবে একটি ভিন্ন ট্যাগিং স্কিম উল্লেখ করেন)।

→ ডকুমেন্টেশন. একটি পৃথক প্রকাশনা এছাড়াও এই বৈশিষ্ট্য নিবেদিত করা হবে. আপডেট করা হয়েছে (3 এপ্রিল): বিস্তারিত সহ নিবন্ধ প্রকাশিত.

লগিং স্তর

ব্যবহারকারীর এখন আউটপুট নিয়ন্ত্রণ করার, লগিং স্তর সেট করার এবং ডিবাগিং তথ্যের সাথে কাজ করার সুযোগ রয়েছে। বিকল্প যোগ করা হয়েছে --log-quiet, --log-verbose, --log-debug.

ডিফল্টরূপে, আউটপুটে ন্যূনতম তথ্য থাকে:

ভার্বোস আউটপুট ব্যবহার করার সময় (--log-verbose) আপনি দেখতে পারেন কিভাবে werf কাজ করে:

বিস্তারিত আউটপুট (--log-debug, werf ডিবাগিং তথ্য ছাড়াও, ব্যবহৃত লাইব্রেরিগুলির লগও রয়েছে। উদাহরণস্বরূপ, আপনি দেখতে পারেন কিভাবে ডকার রেজিস্ট্রির সাথে মিথস্ক্রিয়া ঘটে এবং সেই জায়গাগুলিও রেকর্ড করুন যেখানে উল্লেখযোগ্য পরিমাণ সময় ব্যয় হয়:

আরও পরিকল্পনা

সতর্কতা নীচে বর্ণিত বিকল্পগুলি চিহ্নিত করা হয়েছে v1.1 এই সংস্করণে উপলব্ধ হবে, তাদের অনেকগুলি নিকট ভবিষ্যতে। স্বয়ংক্রিয় আপডেটের মাধ্যমে আপডেট আসবে multiwerf ব্যবহার করার সময়. এই বৈশিষ্ট্যগুলি v1.1 ফাংশনের স্থিতিশীল অংশকে প্রভাবিত করে না; তাদের উপস্থিতির জন্য বিদ্যমান কনফিগারেশনগুলিতে ম্যানুয়াল ব্যবহারকারীর হস্তক্ষেপের প্রয়োজন হবে না।

বিভিন্ন ডকার রেজিস্ট্রি বাস্তবায়নের জন্য সম্পূর্ণ সমর্থন (নতুন)

• সংস্করণ: v1.1
• তারিখ: মার্চ
• সমস্যা

লক্ষ্য হল ব্যবহারকারীর জন্য werf ব্যবহার করার সময় সীমাবদ্ধতা ছাড়াই একটি কাস্টম বাস্তবায়ন ব্যবহার করা।

বর্তমানে, আমরা নিম্নলিখিত সমাধানগুলি চিহ্নিত করেছি যার জন্য আমরা সম্পূর্ণ সমর্থনের গ্যারান্টি দিতে যাচ্ছি:

• ডিফল্ট (লাইব্রেরি/রেজিস্ট্রি)*,
• AWS ECR
• আকাশী*,
• ডকার হাব
• GCR*,
• গিটহাব প্যাকেজ
• গিটল্যাব রেজিস্ট্রি*,
• হারবার*,
• কোয়ে।

বর্তমানে werf দ্বারা সম্পূর্ণরূপে সমর্থিত সমাধানগুলি একটি তারকাচিহ্ন দিয়ে চিহ্নিত করা হয়েছে। অন্যদের জন্য সমর্থন আছে, কিন্তু সীমাবদ্ধতা সঙ্গে.

দুটি প্রধান সমস্যা চিহ্নিত করা যেতে পারে:

• কিছু সমাধান ডকার রেজিস্ট্রি API ব্যবহার করে ট্যাগ অপসারণ সমর্থন করে না, ব্যবহারকারীদের werf-এর স্বয়ংক্রিয় ক্লিনআপ ব্যবহার করতে বাধা দেয়। এটি AWS ECR, Docker Hub এবং GitHub প্যাকেজের জন্য সত্য।
• কিছু সমাধান তথাকথিত নেস্টেড রিপোজিটরি (ডকার হাব, গিটহাব প্যাকেজ এবং কোয়ে) সমর্থন করে না বা করে, তবে ব্যবহারকারীকে অবশ্যই UI বা API (AWS ECR) ব্যবহার করে ম্যানুয়ালি তৈরি করতে হবে।

আমরা সমাধানগুলির নেটিভ API ব্যবহার করে এই এবং অন্যান্য সমস্যাগুলি সমাধান করতে যাচ্ছি। এই টাস্কের মধ্যে রয়েছে ওয়ারফ অপারেশনের সম্পূর্ণ চক্রকে তাদের প্রত্যেকের জন্য পরীক্ষার মাধ্যমে কভার করা।

ডিস্ট্রিবিউটেড ইমেজ বিল্ড (↑)

• সংস্করণ: v1.2 v1.1 (এই বৈশিষ্ট্যটি বাস্তবায়নের জন্য অগ্রাধিকার বৃদ্ধি করা হয়েছে)
• তারিখ: মার্চ-এপ্রিল মার্চ
• সমস্যা

এই মুহুর্তে, werf v1.0 এবং v1.1 শুধুমাত্র একটি ডেডিকেটেড হোস্টে ব্যবহার করা যেতে পারে ইমেজ তৈরি ও প্রকাশ করার জন্য এবং কুবারনেটসে অ্যাপ্লিকেশন স্থাপন করার জন্য।

werf-এর বিতরণকৃত কাজের সম্ভাবনা উন্মুক্ত করার জন্য, যখন Kubernetes-এ অ্যাপ্লিকেশনের বিল্ড এবং ডিপ্লোয়মেন্ট বেশ কয়েকটি নির্বিচারে হোস্টে চালু করা হয় এবং এই হোস্টগুলি বিল্ড (অস্থায়ী রানার্স) এর মধ্যে তাদের অবস্থা সংরক্ষণ করে না, তখন ব্যবহার করার ক্ষমতা বাস্তবায়নের জন্য werf-এর প্রয়োজন হয়। একটি স্টেজ স্টোর হিসাবে ডকার রেজিস্ট্রি।

পূর্বে, যখন ওয়ার্ফ প্রকল্পটিকে এখনও ড্যাপ বলা হত, তখন এটি এমন একটি সুযোগ ছিল। যাইহোক, werf-এ এই কার্যকারিতা বাস্তবায়ন করার সময় আমরা বেশ কয়েকটি সমস্যার সম্মুখীন হয়েছি যা বিবেচনায় নেওয়া দরকার।

মন্তব্য. এই বৈশিষ্ট্যটির জন্য কুবারনেটস পডের ভিতরে কাজ করার জন্য সংগ্রাহকের প্রয়োজন নেই, কারণ এটি করার জন্য, আপনাকে স্থানীয় ডকার সার্ভারের উপর নির্ভরতা থেকে মুক্তি পেতে হবে (কুবারনেটস পডে স্থানীয় ডকার সার্ভারে কোনও অ্যাক্সেস নেই, কারণ প্রক্রিয়াটি নিজেই একটি পাত্রে চলছে এবং ওয়ার্ফ সমর্থন করে না এবং করবে না। নেটওয়ার্কে ডকার সার্ভারের সাথে কাজ করা)। Kubernetes চালানোর জন্য সমর্থন আলাদাভাবে প্রয়োগ করা হবে।

গিটহাব অ্যাকশন (নতুন) এর জন্য সরকারী সমর্থন

• সংস্করণ: v1.1
• তারিখ: মার্চ
• সমস্যা

ওয়ার্ফ ডকুমেন্টেশন অন্তর্ভুক্ত করে (বিভাগ উল্লেখ и কৌশল), পাশাপাশি werf এর সাথে কাজ করার জন্য অফিসিয়াল GitHub অ্যাকশন।

উপরন্তু, এটি ওয়ারফকে ক্ষণস্থায়ী রানার্সে কাজ করার অনুমতি দেবে।

সিআই সিস্টেমের সাথে ব্যবহারকারীর ইন্টারঅ্যাকশনের মেকানিক্সটি অ্যাপ্লিকেশন তৈরি/রোল আউট করার জন্য নির্দিষ্ট ক্রিয়া শুরু করার জন্য পুল অনুরোধে লেবেল স্থাপনের উপর ভিত্তি করে হবে।

werf (↓) এর সাথে অ্যাপ্লিকেশনগুলির স্থানীয় উন্নয়ন এবং স্থাপনা

• সংস্করণ: v1.1
• তারিখ: জানুয়ারি-ফেব্রুয়ারি এপ্রিল
• সমস্যা

মূল লক্ষ্য হল একটি একক ইউনিফাইড কনফিগারেশন অর্জন করা যাতে স্থানীয়ভাবে এবং উত্পাদন উভয় ক্ষেত্রেই, জটিল ক্রিয়া ছাড়াই, বাক্সের বাইরে অ্যাপ্লিকেশনগুলি স্থাপন করা যায়।

werf-এরও একটি অপারেটিং মোড থাকা প্রয়োজন যেখানে এটি অ্যাপ্লিকেশন কোড সম্পাদনা করতে সুবিধাজনক হবে এবং ডিবাগিংয়ের জন্য চলমান অ্যাপ্লিকেশন থেকে অবিলম্বে প্রতিক্রিয়া পাবেন৷

নতুন ক্লিনিং অ্যালগরিদম (নতুন)

• সংস্করণ: v1.1
• তারিখ: এপ্রিল
• সমস্যা

পদ্ধতিতে werf v1.1 এর বর্তমান সংস্করণে cleanup বিষয়বস্তু-ভিত্তিক ট্যাগিং স্কিমের জন্য চিত্রগুলি পরিষ্কার করার কোনও ব্যবস্থা নেই - এই চিত্রগুলি জমা হবে।

এছাড়াও, werf এর বর্তমান সংস্করণ (v1.0 এবং v1.1) ট্যাগিং স্কিমগুলির অধীনে প্রকাশিত চিত্রগুলির জন্য বিভিন্ন ক্লিনআপ নীতি ব্যবহার করে: গিট শাখা, গিট ট্যাগ বা গিট কমিট৷

সমস্ত ট্যাগিং স্কিমগুলির জন্য একীভূত গিটে প্রতিশ্রুতির ইতিহাসের উপর ভিত্তি করে চিত্রগুলি পরিষ্কার করার জন্য একটি নতুন অ্যালগরিদম উদ্ভাবন করা হয়েছে:

• প্রতিটি গিট হেড (শাখা এবং ট্যাগ) এর জন্য N1 সবচেয়ে সাম্প্রতিক প্রতিশ্রুতির সাথে যুক্ত N2 চিত্রের বেশি রাখবেন না।
• প্রতিটি গিট হেড (শাখা এবং ট্যাগ) এর জন্য N1 সবচেয়ে সাম্প্রতিক প্রতিশ্রুতিগুলির সাথে যুক্ত N2 স্টেজের ছবিগুলির বেশি সংরক্ষণ করবেন না।
• যেকোন কুবারনেটস ক্লাস্টার রিসোর্সে ব্যবহৃত সমস্ত ছবি সংরক্ষণ করুন (কনফিগারেশন ফাইলের সমস্ত কুবের প্রসঙ্গ এবং নেমস্পেসগুলি স্ক্যান করা হয়েছে; আপনি বিশেষ বিকল্পগুলির সাথে এই আচরণটি সীমিত করতে পারেন)।
• হেলম রিলিজে সংরক্ষিত রিসোর্স কনফিগারেশন ম্যানিফেস্টে ব্যবহৃত সমস্ত ছবি সংরক্ষণ করুন।
• একটি চিত্র মুছে ফেলা যেতে পারে যদি এটি গিট থেকে কোনো HEAD এর সাথে যুক্ত না হয় (উদাহরণস্বরূপ, কারণ সংশ্লিষ্ট HEAD নিজেই মুছে ফেলা হয়েছিল) এবং Kubernetes ক্লাস্টারে এবং Helm রিলিজে কোনো ম্যানিফেস্টে ব্যবহার করা হয় না।

সমান্তরাল ইমেজ বিল্ডিং (↓)

• সংস্করণ: v1.1
• তারিখ: জানুয়ারি-ফেব্রুয়ারি এপ্রিল*

werf-এর বর্তমান সংস্করণে বর্ণিত চিত্র এবং শিল্পকর্ম সংগ্রহ করা হয়েছে werf.yaml, ক্রমানুসারে। ইমেজ এবং আর্টিফ্যাক্টগুলির স্বাধীন পর্যায়গুলি একত্রিত করার প্রক্রিয়াটিকে সমান্তরাল করার পাশাপাশি সুবিধাজনক এবং তথ্যপূর্ণ আউটপুট প্রদান করা প্রয়োজন।

* দ্রষ্টব্য: বিতরণ করা সমাবেশ বাস্তবায়নের জন্য অগ্রাধিকার বৃদ্ধির কারণে সময়সীমা স্থানান্তরিত করা হয়েছে, যা আরও অনুভূমিক স্কেলিং ক্ষমতা যোগ করবে, সেইসাথে GitHub অ্যাকশনের সাথে werf-এর ব্যবহার। সমান্তরাল সমাবেশ হল পরবর্তী অপ্টিমাইজেশান ধাপ, একটি প্রকল্প একত্রিত করার সময় উল্লম্ব মাপযোগ্যতা প্রদান করে।

হেলম 3 (↓) এ স্থানান্তর

• সংস্করণ: v1.2
• তারিখ: ফেব্রুয়ারি-মার্চ মে*

নতুন কোডবেসে মাইগ্রেশন অন্তর্ভুক্ত হেলম 3 এবং বিদ্যমান ইনস্টলেশন স্থানান্তর করার একটি প্রমাণিত, সুবিধাজনক উপায়।

* দ্রষ্টব্য: Helm 3-এ স্যুইচ করলে werf-এ উল্লেখযোগ্য বৈশিষ্ট্য যুক্ত হবে না, কারণ Helm 3-এর সমস্ত মূল বৈশিষ্ট্য (3-ওয়ে-মার্জ এবং নো টিলার) ইতিমধ্যেই werf-এ প্রয়োগ করা হয়েছে। তাছাড়া, werf আছে অতিরিক্ত বৈশিষ্ট্য নির্দেশিত যারা ছাড়াও. যাইহোক, এই পরিবর্তন আমাদের পরিকল্পনায় রয়ে গেছে এবং বাস্তবায়িত হবে।

কুবারনেটস কনফিগারেশন বর্ণনা করার জন্য জসননেট (↓)

• সংস্করণ: v1.2
• তারিখ: জানুয়ারি-ফেব্রুয়ারি এপ্রিল-মে

Werf Jsonnet বিন্যাসে Kubernetes-এর জন্য কনফিগারেশন বিবরণ সমর্থন করবে। একই সময়ে, werf হেলমের সাথে সামঞ্জস্যপূর্ণ থাকবে এবং বর্ণনা বিন্যাসের একটি পছন্দ থাকবে।

কারণ হ'ল গো টেমপ্লেটগুলি, অনেক লোকের মতে, একটি উচ্চ এন্ট্রি বাধা রয়েছে এবং এই টেমপ্লেটগুলির কোড বোঝার ক্ষমতাও ক্ষতিগ্রস্থ হয়৷

অন্যান্য Kubernetes কনফিগারেশন বর্ণনা সিস্টেম চালু করার সম্ভাবনাও বিবেচনা করা হচ্ছে (উদাহরণস্বরূপ, Kustomize)।

কুবারনেটসের ভিতরে কাজ করা (↓)

• সংস্করণ: v1.2
• তারিখ: এপ্রিল-মে মে-জুন

লক্ষ্য: নিশ্চিত করুন যে ছবিগুলি তৈরি করা হয়েছে এবং কুবারনেটসে রানার ব্যবহার করে অ্যাপ্লিকেশনটি বিতরণ করা হয়েছে৷ সেগুলো. কুবারনেটস পড থেকে সরাসরি নতুন ছবি তৈরি, প্রকাশ, পরিষ্কার এবং স্থাপন করা যেতে পারে।

এই ক্ষমতা বাস্তবায়নের জন্য, আপনাকে প্রথমে বিতরণ করা ছবি তৈরি করতে সক্ষম হতে হবে (উপরের পয়েন্ট দেখুন).

এটির জন্য ডকার সার্ভার ছাড়াই নির্মাতার অপারেটিং মোডের জন্য সমর্থন প্রয়োজন (যেমন কানিকো-এর মতো বিল্ড বা ইউজারস্পেসে বিল্ড)।

Werf শুধুমাত্র Dockerfile দিয়েই নয়, এর Stapel নির্মাতার সাথে ক্রমবর্ধমান পুনর্নির্মাণ এবং Ansible-এর সাহায্যে কুবারনেটে নির্মাণকে সমর্থন করবে।

উন্মুক্ত উন্নয়নের দিকে এক ধাপ

আমরা আমাদের সম্প্রদায়কে ভালবাসি (GitHub, Telegram) এবং আমরা আরও বেশি সংখ্যক লোককে ওয়ার্ফকে আরও ভাল করতে সাহায্য করতে চাই, আমরা যে দিকে এগিয়ে যাচ্ছি তা বুঝতে এবং উন্নয়নে অংশগ্রহণ করতে চাই।

বেশ সম্প্রতি এটি স্যুইচ করার সিদ্ধান্ত নেওয়া হয়েছে GitHub প্রকল্প বোর্ড আমাদের দলের কাজের প্রক্রিয়া প্রকাশ করার জন্য। এখন আপনি তাত্ক্ষণিক পরিকল্পনা দেখতে পারেন, পাশাপাশি নিম্নলিখিত ক্ষেত্রে বর্তমান কাজগুলি দেখতে পারেন:

• ডকুমেন্টেশন এবং সাইট;
• পরীক্ষামূলক;
• বাগ এবং খারাপ UX;
• 1.1.

সমস্যা নিয়ে অনেক কাজ করা হয়েছে:

• অপ্রাসঙ্গিক অপসারণ.
• বিদ্যমানগুলিকে একটি একক বিন্যাসে আনা হয়, পর্যাপ্ত সংখ্যক বিবরণ এবং বিবরণ সহ।
• ধারণা এবং পরামর্শ সঙ্গে নতুন সমস্যা যোগ করা হয়েছে.

সংস্করণ v1.1 কিভাবে সক্ষম করবেন

সংস্করণ বর্তমানে উপলব্ধ চ্যানেল 1.1 ea (চ্যানেলগুলিতে স্থিতিশীল и শিলা-কঠিন স্থিতিশীলতা ঘটলে রিলিজ প্রদর্শিত হবে, যাইহোক ea নিজেই ইতিমধ্যে ব্যবহারের জন্য যথেষ্ট স্থিতিশীল, কারণ চ্যানেলের মধ্য দিয়ে গেছে আরম্ভ и বিটা) সক্রিয় multiwerf এর মাধ্যমে নিম্নলিখিত উপায়ে:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

উপসংহার

স্টেপেল এবং ডকারফাইল বিল্ডারদের জন্য নতুন স্টেজ স্টোরেজ আর্কিটেকচার এবং বিল্ডার অপ্টিমাইজেশানগুলি ওয়ার্ফ-এ বিতরণ করা এবং সমান্তরাল বিল্ডগুলি বাস্তবায়নের সম্ভাবনা উন্মুক্ত করে। এই বৈশিষ্ট্যগুলি শীঘ্রই একই v1.1 রিলিজে প্রদর্শিত হবে এবং স্বয়ংক্রিয়-আপডেট প্রক্রিয়ার মাধ্যমে স্বয়ংক্রিয়ভাবে উপলব্ধ হবে (ব্যবহারকারীদের জন্য মাল্টিওয়ার্ফ).

এই রিলিজে, ছবির বিষয়বস্তুর উপর ভিত্তি করে একটি ট্যাগিং কৌশল যুক্ত করা হয়েছে - বিষয়বস্তু ভিত্তিক ট্যাগিং, যা ডিফল্ট কৌশল হয়ে উঠেছে। প্রধান কমান্ড লগ আবার কাজ করা হয়েছে: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

পরবর্তী উল্লেখযোগ্য পদক্ষেপ হল বিতরণ করা সমাবেশ যোগ করা। ডিস্ট্রিবিউটেড বিল্ডগুলি v1.0 থেকে সমান্তরাল বিল্ডগুলির তুলনায় একটি উচ্চ অগ্রাধিকার হয়ে উঠেছে কারণ তারা werf-এ আরও মান যোগ করে: বিল্ডারদের উল্লম্ব স্কেলিং এবং বিভিন্ন CI/CD সিস্টেমে ক্ষণস্থায়ী বিল্ডারদের সমর্থন, সেইসাথে গিটহাব অ্যাকশনগুলির জন্য অফিসিয়াল সমর্থন করার ক্ষমতা . অতএব, সমান্তরাল সমাবেশগুলির বাস্তবায়নের সময়সীমা স্থানান্তরিত হয়েছে। যাইহোক, আমরা যত তাড়াতাড়ি সম্ভব উভয় সম্ভাবনা বাস্তবায়নের জন্য কাজ করছি।

খবর অনুসরণ করুন! এবং আমাদের সাথে দেখা করতে ভুলবেন না GitHubএকটি সমস্যা তৈরি করতে, একটি বিদ্যমান একটি খুঁজুন এবং একটি প্লাস যোগ করুন, একটি PR তৈরি করুন, বা কেবল প্রকল্পের উন্নয়ন দেখুন৷

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «werf 1.0 স্থিতিশীল উপস্থাপন করা হচ্ছে: GitOps এর সাথে এর কী সম্পর্ক, স্থিতি এবং পরিকল্পনা»
• «werf - Kubernetes-এ CI/CD-এর জন্য আমাদের টুল (ওভারভিউ এবং ভিডিও রিপোর্ট)";
• ওয়ার্ফে উদ্ভাবন সম্পর্কে নোটের একটি সিরিজ:
  • «ওয়ার্ফের সাথে 3-ওয়ে মার্জ: হেলমের সাথে কুবারনেটে স্থাপন করা "স্টেরয়েডগুলিতে"";
  • «জটিল হেল্ম চার্ট রোল আউট করতে werf ব্যবহার করে";
  • «ওয়ার্ফে মনোরেপো এবং মাল্টিরেপোর জন্য সমর্থন এবং ডকার রেজিস্ট্রি এর সাথে কী করতে হবে";
  • «আপনি এখন নিয়মিত ডকারফাইল ব্যবহার করে ডকার ইমেজ তৈরি করতে পারেন».

উত্স: www.habr.com