ওয়ার্ফের সাথে 3-ওয়ে মার্জ: হেলমের সাথে কুবারনেটে স্থাপন করা "স্টেরয়েডগুলিতে"

আমরা (এবং শুধুমাত্র আমরাই নয়) দীর্ঘ সময়ের জন্য যা অপেক্ষা করছিলাম তা ঘটেছে: werf, আমাদের ওপেন সোর্স ইউটিলিটি অ্যাপ্লিকেশান তৈরি করতে এবং সেগুলিকে কুবারনেটে পৌঁছে দেওয়ার জন্য, এখন 3-ওয়ে মার্জ প্যাচ ব্যবহার করে পরিবর্তনগুলি প্রয়োগ করা সমর্থন করে! এইগুলি ছাড়াও, এই সংস্থানগুলি পুনর্নির্মাণ না করেই হেলম রিলিজে বিদ্যমান K8s সংস্থানগুলি গ্রহণ করা সম্ভব।

এটা খুব সংক্ষিপ্ত হলে, তারপর আমরা করা WERF_THREE_WAY_MERGE=enabled — আমরা নিয়োজিত পাই kubectl apply", বিদ্যমান হেলম 2 ইনস্টলেশনের সাথে সামঞ্জস্যপূর্ণ এবং এমনকি আরও একটু বেশি।

তবে আসুন তত্ত্ব দিয়ে শুরু করা যাক: 3-ওয়ে-মার্জ প্যাচগুলি ঠিক কী, লোকেরা কীভাবে সেগুলি তৈরি করার পদ্ধতি নিয়ে এসেছিল এবং কেন কুবারনেটস-ভিত্তিক পরিকাঠামোর সাথে CI/CD প্রক্রিয়াগুলিতে এগুলি গুরুত্বপূর্ণ? এবং এর পরে, আসুন দেখি ওয়ার্ফ-এ 3-ওয়ে-মার্জ কী, ডিফল্টরূপে কী মোড ব্যবহার করা হয় এবং কীভাবে এটি পরিচালনা করা যায়।

একটি 3-ওয়ে-মার্জ প্যাচ কি?

সুতরাং, আসুন YAML-এ বর্ণিত সংস্থানগুলিকে কুবারনেটস-এ প্রকাশ করার কাজ দিয়ে শুরু করা যাক।

সংস্থানগুলির সাথে কাজ করার জন্য, Kubernetes API নিম্নলিখিত মৌলিক ক্রিয়াকলাপগুলি অফার করে: তৈরি করুন, প্যাচ করুন, প্রতিস্থাপন করুন এবং মুছুন৷ এটা অনুমান করা হয় যে তাদের সাহায্যে ক্লাস্টারে সম্পদের একটি সুবিধাজনক ক্রমাগত রোলআউট তৈরি করা প্রয়োজন। কিভাবে?

kubectl আবশ্যিক কমান্ড

Kubernetes-এ বস্তুগুলি পরিচালনা করার প্রথম পদ্ধতি হল সেই বস্তুগুলি তৈরি, সংশোধন এবং মুছে ফেলার জন্য kubectl প্রয়োজনীয় কমান্ডগুলি ব্যবহার করা। সহজভাবে করা:

• টীম kubectl run আপনি স্থাপনা বা চাকরি চালাতে পারেন:

  kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

• টীম kubectl scale - প্রতিলিপি সংখ্যা পরিবর্তন করুন:

  kubectl scale --replicas=3 deployment/mysql

• এবং তাই অন

এই পদ্ধতিটি প্রথম নজরে সুবিধাজনক বলে মনে হতে পারে। তবে সমস্যা আছে:

1. এটা কঠিন স্বয়ংক্রিয়.
2. কিভাবে কনফিগারেশন প্রতিফলিত করুন গিটে? ক্লাস্টারে ঘটছে পরিবর্তনগুলি কীভাবে পর্যালোচনা করবেন?
3. কিভাবে প্রদান করবেন প্রজননযোগ্যতা পুনরায় চালু করার কনফিগারেশন?
4. ...

এটা স্পষ্ট যে এই পদ্ধতিটি কোড হিসাবে অ্যাপ্লিকেশন এবং অবকাঠামো সংরক্ষণের সাথে উপযুক্ত নয় (IaC; বা এমনকি GitOps একটি আরও আধুনিক বিকল্প হিসাবে, কুবারনেটস ইকোসিস্টেমে জনপ্রিয়তা অর্জন করে)। অতএব, এই কমান্ডগুলি কুবেক্টেলে আরও বিকাশ পায়নি।

ক্রিয়াকলাপগুলি তৈরি করুন, পান, প্রতিস্থাপন করুন এবং মুছুন৷

প্রাইমারী সহ সৃষ্টি এটা সহজ: অপারেশনে ম্যানিফেস্ট পাঠান create কুবে এপিআই এবং রিসোর্স তৈরি করা হয়েছে। ম্যানিফেস্টের YAML উপস্থাপনা Git এ সংরক্ষণ করা যেতে পারে এবং কমান্ড ব্যবহার করে তৈরি করা যেতে পারে kubectl create -f manifest.yaml.

С অপসারণ এছাড়াও সহজ: একই বিকল্প manifest.yaml গিট থেকে দলে kubectl delete -f manifest.yaml.

অপারেশন replace রিসোর্স পুনরায় তৈরি না করেই আপনাকে রিসোর্স কনফিগারেশন সম্পূর্ণভাবে একটি নতুন দিয়ে প্রতিস্থাপন করতে দেয়। এর মানে হল যে কোনও সংস্থানে পরিবর্তন করার আগে, অপারেশন সহ বর্তমান সংস্করণটি অনুসন্ধান করা যুক্তিযুক্ত get, এটি পরিবর্তন করুন এবং অপারেশনের সাথে এটি আপডেট করুন replace. kube apiserver তৈরি করা হয়েছে আশাবাদী লকিং এবং, যদি অস্ত্রোপচারের পরে get বস্তু পরিবর্তিত হয়েছে, তারপর অপারেশন replace পাস হবে না।

গিট-এ কনফিগারেশন সংরক্ষণ করতে এবং প্রতিস্থাপন ব্যবহার করে এটি আপডেট করতে, আপনাকে অপারেশনটি করতে হবে get, আমরা যা পেয়েছি তার সাথে গিট থেকে কনফিগারেশনটি মার্জ করুন এবং কার্যকর করুন replace. ডিফল্টরূপে, kubectl শুধুমাত্র আপনাকে কমান্ড ব্যবহার করার অনুমতি দেয় kubectl replace -f manifest.yamlযেখানে manifest.yaml — একটি ইতিমধ্যে সম্পূর্ণ প্রস্তুত (আমাদের ক্ষেত্রে, একত্রিত) ম্যানিফেস্ট যা ইনস্টল করা প্রয়োজন৷ দেখা যাচ্ছে যে ব্যবহারকারীকে মার্জ ম্যানিফেস্টগুলি বাস্তবায়ন করতে হবে এবং এটি একটি তুচ্ছ বিষয় নয় ...

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

মোট: আমরা কি একটানা রোলআউট তৈরি করতে পারি? শুধুমাত্র তৈরি, প্রতিস্থাপন এবং মুছে ফেলা ব্যবহার করে, নিশ্চিত করে যে পরিকাঠামো কনফিগারেশনটি কোড এবং সুবিধাজনক CI/CD সহ Git-এ সংরক্ষণ করা হয়েছে?

নীতিগতভাবে, আমরা করতে পারি... এর জন্য আপনাকে মার্জ অপারেশন বাস্তবায়ন করতে হবে ম্যানিফেস্টো এবং কিছু ধরনের বাঁধাই যে:

• ক্লাস্টারে একটি বস্তুর উপস্থিতি পরীক্ষা করে,
• প্রাথমিক সম্পদ তৈরি করে,
• আপডেট বা মুছে দেয়।

আপডেট করার সময়, দয়া করে নোট করুন সম্পদ পরিবর্তিত হতে পারে শেষ থেকে get এবং স্বয়ংক্রিয়ভাবে আশাবাদী লকিং কেস পরিচালনা করুন - বারবার আপডেট করার চেষ্টা করুন।

যাইহোক, যখন কুবে-এপিসার্ভার রিসোর্স আপডেট করার আরেকটি উপায় অফার করে তখন কেন চাকাটি পুনরায় উদ্ভাবন করা হয়: অপারেশন patch, যা ব্যবহারকারীকে বর্ণিত কিছু সমস্যা থেকে মুক্তি দেয়?

তালি

এখন আমরা প্যাচ পেতে.

Kubernetes-এ বিদ্যমান বস্তুতে পরিবর্তন প্রয়োগ করার প্রাথমিক উপায় হল প্যাচ। অপারেশন patch এটা এই মত কাজ করে:

• kube-apiserver ব্যবহারকারীকে JSON আকারে একটি প্যাচ পাঠাতে হবে এবং বস্তুটি নির্দিষ্ট করতে হবে,
• এবং apiserver নিজেই বস্তুর বর্তমান অবস্থার সাথে মোকাবিলা করবে এবং এটিকে প্রয়োজনীয় ফর্মে নিয়ে আসবে।

এই ক্ষেত্রে আশাবাদী লকিং প্রয়োজন হয় না। এই অপারেশনটি প্রতিস্থাপনের চেয়ে আরও ঘোষণামূলক, যদিও প্রথমে এটি অন্যভাবে মনে হতে পারে।

এই ভাবে:

• একটি অপারেশন ব্যবহার করে create আমরা গিট থেকে ম্যানিফেস্ট অনুযায়ী একটি বস্তু তৈরি করি,
• সাহায্যে delete - বস্তুটির আর প্রয়োজন না হলে মুছুন,
• সাহায্যে patch — আমরা বস্তুকে পরিবর্তন করি, এটিকে গিট-এ বর্ণিত ফর্মে নিয়ে আসছি।

যাইহোক, এটি করার জন্য, আপনাকে তৈরি করতে হবে সঠিক প্যাচ!

হেলম 2: 2-ওয়ে-মার্জে কীভাবে প্যাচগুলি কাজ করে

আপনি যখন প্রথম একটি রিলিজ ইনস্টল করেন, তখন হেলম অপারেশনটি সঞ্চালন করে create চার্ট সম্পদ জন্য.

প্রতিটি সম্পদের জন্য একটি হেলম রিলিজ আপডেট করার সময়:

• আগের চার্ট থেকে রিসোর্স সংস্করণ এবং বর্তমান চার্ট সংস্করণের মধ্যে প্যাচ বিবেচনা করে,
• এই প্যাচ প্রয়োগ করে।

আমরা এই প্যাচ কল হবে 2-ওয়ে মার্জ প্যাচ, কারণ 2টি ম্যানিফেস্টো এর সৃষ্টিতে জড়িত:

• আগের রিলিজ থেকে রিসোর্স ম্যানিফেস্ট,
• বর্তমান সম্পদ থেকে রিসোর্স মেনিফেস্ট।

অপারেশন অপসারণ করার সময় delete kube এপিসার্ভারকে সেই সংস্থানগুলির জন্য বলা হয় যা পূর্ববর্তী রিলিজে ঘোষণা করা হয়েছিল, কিন্তু বর্তমানটিতে ঘোষণা করা হয়নি।

2 উপায় মার্জ প্যাচ পদ্ধতির একটি সমস্যা আছে: এটি বাড়ে ক্লাস্টারে রিসোর্সের প্রকৃত অবস্থা এবং গিট-এ ম্যানিফেস্টের সাথে সিঙ্কের বাইরে.

একটি উদাহরণ দিয়ে সমস্যার চিত্র তুলে ধরুন

• Git-এ, একটি চার্ট একটি ম্যানিফেস্ট সঞ্চয় করে যেখানে ক্ষেত্রটি রয়েছে image স্থাপনার বিষয় ubuntu:18.04.
• এর মাধ্যমে ব্যবহারকারী kubectl edit এই ক্ষেত্রের মান পরিবর্তন করে ubuntu:19.04.
• হেলম চার্ট পুনরায় স্থাপন করার সময় একটি প্যাচ তৈরি করে না, কারণ ক্ষেত্র image রিলিজের পূর্ববর্তী সংস্করণে এবং বর্তমান চার্টে একই।
• পুনরায় স্থাপনার পর image দেহাবশেষ ubuntu:19.04, যদিও চার্ট বলে ubuntu:18.04.

আমরা ডিসিঙ্ক্রোনাইজেশন পেয়েছি এবং ঘোষণামূলকতা হারিয়েছি।

একটি সিঙ্ক্রোনাইজড সম্পদ কি?

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

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

3-ওয়ে মার্জ প্যাচ

মূল ধারণা 3-ওয়ে মার্জ প্যাচ: চলমান ক্লাস্টার থেকে ম্যানিফেস্টের বর্তমান সংস্করণকে বিবেচনায় নিয়ে গিট থেকে ম্যানিফেস্টের শেষ প্রয়োগকৃত সংস্করণ এবং গিট থেকে ম্যানিফেস্টের লক্ষ্য সংস্করণের মধ্যে একটি প্যাচ তৈরি করুন। ফলস্বরূপ প্যাচ সিঙ্ক্রোনাইজড রিসোর্স নিয়ম মেনে চলতে হবে:

• লক্ষ্য সংস্করণে যোগ করা নতুন ক্ষেত্র একটি প্যাচ ব্যবহার করে যোগ করা হয়;
• শেষ প্রয়োগকৃত সংস্করণে পূর্বে বিদ্যমান ক্ষেত্রগুলি এবং লক্ষ্য সংস্করণে বিদ্যমান নয় একটি প্যাচ ব্যবহার করে পুনরায় সেট করা হয়;
• ম্যানিফেস্টের টার্গেট সংস্করণ থেকে ভিন্ন বস্তুর বর্তমান সংস্করণের ক্ষেত্রগুলি প্যাচ ব্যবহার করে আপডেট করা হয়।

এই নীতিতে এটি প্যাচ তৈরি করে kubectl apply:

• ম্যানিফেস্টের শেষ প্রয়োগকৃত সংস্করণটি বস্তুর টীকাতে সংরক্ষণ করা হয়,
• লক্ষ্য - নির্দিষ্ট YAML ফাইল থেকে নেওয়া,
• বর্তমান একটি চলমান ক্লাস্টার থেকে.

এখন যেহেতু আমরা তত্ত্বটি সাজিয়েছি, আমরা ওয়ার্ফে কী করেছি তা আপনাকে বলার সময় এসেছে।

werf এ পরিবর্তন প্রয়োগ করা হচ্ছে

পূর্বে, werf, Helm 2 এর মত, 2-ওয়ে-মার্জ প্যাচ ব্যবহার করত।

মেরামত প্যাচ

একটি নতুন ধরণের প্যাচগুলিতে স্যুইচ করার জন্য - 3-ওয়ে-মার্জ - প্রথম পদক্ষেপটি আমরা তথাকথিত চালু করেছি মেরামত প্যাচ.

স্থাপন করার সময়, একটি স্ট্যান্ডার্ড 2-ওয়ে-মার্জ প্যাচ ব্যবহার করা হয়, তবে werf অতিরিক্তভাবে একটি প্যাচ তৈরি করে যা গিট-এ যা লেখা আছে তার সাথে রিসোর্সের প্রকৃত অবস্থা সিঙ্ক্রোনাইজ করবে (উপরে বর্ণিত একই সিঙ্ক্রোনাইজড রিসোর্স নিয়ম ব্যবহার করে এই ধরনের প্যাচ তৈরি করা হয়) .

যদি একটি ডিসিঙ্ক্রোনাইজেশন ঘটে, ডিপ্লয়মেন্টের শেষে ব্যবহারকারী একটি সংশ্লিষ্ট বার্তা এবং একটি প্যাচ সহ একটি সতর্কতা পায় যা রিসোর্সটিকে একটি সিঙ্ক্রোনাইজড ফর্মে আনতে অবশ্যই প্রয়োগ করতে হবে৷ এই প্যাচটি একটি বিশেষ টীকাতেও রেকর্ড করা হয়েছে werf.io/repair-patch. ধারণা করা হচ্ছে ব্যবহারকারীর হাত сам এই প্যাচটি প্রয়োগ করবে: werf এটি মোটেও প্রয়োগ করবে না।

মেরামত প্যাচ তৈরি করা একটি অস্থায়ী পরিমাপ যা আপনাকে 3-ওয়ে-মার্জ নীতির উপর ভিত্তি করে প্যাচ তৈরির পরীক্ষা করতে দেয়, কিন্তু স্বয়ংক্রিয়ভাবে এই প্যাচগুলি প্রয়োগ করে না। এই মুহুর্তে, এই অপারেটিং মোডটি ডিফল্টরূপে সক্রিয় থাকে৷

শুধুমাত্র নতুন রিলিজের জন্য 3-ওয়ে-মার্জ প্যাচ

1 ডিসেম্বর, 2019 থেকে, werf এর বিটা এবং আলফা সংস্করণ শুরু হবে ডিফল্টরূপে শুধুমাত্র werf-এর মাধ্যমে রোল আউট করা নতুন Helm রিলিজে পরিবর্তনগুলি প্রয়োগ করতে সম্পূর্ণ 3-ওয়ে-মার্জ প্যাচ ব্যবহার করুন। বিদ্যমান রিলিজগুলি 2-ওয়ে-মার্জ + মেরামত প্যাচ পদ্ধতি ব্যবহার করা চালিয়ে যাবে।

এই অপারেটিং মোডটি সেটিং করে স্পষ্টভাবে সক্রিয় করা যেতে পারে WERF_THREE_WAY_MERGE_MODE=onlyNewReleases এখন

মন্তব্য: বৈশিষ্ট্যটি বেশ কয়েকটি প্রকাশে werf-এ উপস্থিত হয়েছে: আলফা চ্যানেলে এটি সংস্করণ সহ প্রস্তুত হয়ে গেছে v1.0.5-আলফা.19, এবং বিটা চ্যানেলে - সাথে v1.0.4-বিটা.20.

সমস্ত রিলিজের জন্য 3-ওয়ে-মার্জ প্যাচ

15 ডিসেম্বর, 2019 থেকে, werf-এর বিটা এবং আলফা সংস্করণগুলি সমস্ত রিলিজে পরিবর্তনগুলি প্রয়োগ করতে ডিফল্টরূপে সম্পূর্ণ 3-ওয়ে-মার্জ প্যাচগুলি ব্যবহার করতে শুরু করে৷

এই অপারেটিং মোডটি সেটিং করে স্পষ্টভাবে সক্রিয় করা যেতে পারে WERF_THREE_WAY_MERGE_MODE=enabled এখন

রিসোর্স অটোস্কেলিং দিয়ে কি করতে হবে?

কুবারনেটসে 2 ধরনের অটোস্কেলিং রয়েছে: এইচপিএ (অনুভূমিক) এবং ভিপিএ (উল্লম্ব)।

অনুভূমিক স্বয়ংক্রিয়ভাবে প্রতিলিপি সংখ্যা নির্বাচন করে, উল্লম্ব - সম্পদ সংখ্যা. রিসোর্স ম্যানিফেস্টে (রিসোর্স ম্যানিফেস্ট দেখুন) প্রতিলিপির সংখ্যা এবং সংস্থানের প্রয়োজনীয়তা উভয়ই নির্দিষ্ট করা আছে। spec.replicas বা spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

সমস্যা: যদি একজন ব্যবহারকারী একটি চার্টে একটি সংস্থান কনফিগার করে যাতে এটি সংস্থানগুলির জন্য নির্দিষ্ট মানগুলি নির্দিষ্ট করে বা এই সংস্থানের জন্য প্রতিলিপি এবং অটোস্ক্যালারগুলি সক্ষম করা হয়, তাহলে প্রতিটি স্থাপনার সাথে werf এই মানগুলিকে চার্ট ম্যানিফেস্টে যা লেখা আছে তাতে পুনরায় সেট করবে .

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

• werf.io/set-replicas-only-on-creation=true
• werf.io/set-resources-only-on-creation=true

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

আরও বিস্তারিত জানার জন্য, প্রকল্পের ডকুমেন্টেশন দেখুন HPA и অর্পিত সম্পত্তি.

3-ওয়ে-মার্জ প্যাচ ব্যবহার নিষিদ্ধ করুন

ব্যবহারকারী বর্তমানে একটি পরিবেশ পরিবর্তনশীল ব্যবহার করে werf এ নতুন প্যাচ ব্যবহার নিষিদ্ধ করতে পারেন WERF_THREE_WAY_MERGE_MODE=disabled. যাইহোক, শুরু 1 মার্চ, 2020 থেকে, এই নিষেধাজ্ঞা আর প্রযোজ্য হবে না। এবং এটি শুধুমাত্র 3-ওয়ে-মার্জ প্যাচ ব্যবহার করা সম্ভব হবে।

werf সম্পদ গ্রহণ

3-ওয়ে-মার্জ প্যাচগুলির সাথে পরিবর্তনগুলি প্রয়োগ করার পদ্ধতিতে দক্ষতা আমাদেরকে অবিলম্বে হেলম রিলিজে ক্লাস্টারে বিদ্যমান সংস্থানগুলি গ্রহণ করার মতো একটি বৈশিষ্ট্য কার্যকর করার অনুমতি দেয়।

হেলম 2-এর একটি সমস্যা রয়েছে: আপনি স্ক্র্যাচ থেকে এই সংস্থানটি পুনরায় তৈরি না করে ইতিমধ্যেই ক্লাস্টারে বিদ্যমান চার্ট ম্যানিফেস্টে একটি সংস্থান যোগ করতে পারবেন না (দেখুন। #6031, #3275) আমরা মুক্তির জন্য বিদ্যমান সংস্থানগুলি গ্রহণ করতে ওয়ার্ফকে শিখিয়েছি। এটি করার জন্য, আপনাকে চলমান ক্লাস্টার থেকে রিসোর্সের বর্তমান সংস্করণে একটি টীকা ইনস্টল করতে হবে (উদাহরণস্বরূপ, ব্যবহার করে kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

এখন রিসোর্সটিকে চার্টে বর্ণনা করতে হবে এবং পরের বার যখন werf উপযুক্ত নামের একটি রিলিজ স্থাপন করবে, বিদ্যমান রিসোর্স এই রিলিজে গৃহীত হবে এবং এর নিয়ন্ত্রণে থাকবে। অধিকন্তু, রিলিজের জন্য একটি সংস্থান গ্রহণ করার প্রক্রিয়ায়, werf একই 3-ওয়ে-মার্জ প্যাচ এবং সিঙ্ক্রোনাইজড রিসোর্স নিয়ম ব্যবহার করে চার্টে বর্ণিত চলমান ক্লাস্টার থেকে সম্পদের বর্তমান অবস্থা নিয়ে আসবে।

মন্তব্য: বিন্যাস WERF_THREE_WAY_MERGE_MODE সম্পদ গ্রহণকে প্রভাবিত করে না - দত্তক নেওয়ার ক্ষেত্রে, একটি 3-ওয়ে-মার্জ প্যাচ সর্বদা ব্যবহার করা হয়।

বিস্তারিত - ইন ডকুমেন্টেশন.

উপসংহার এবং ভবিষ্যত পরিকল্পনা

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

হেলম-সদৃশ স্থাপনার সাথে এখনও কিছু সমস্যা এবং চ্যালেঞ্জ রয়েছে, যেমন Go টেমপ্লেটের ব্যবহার, যা আমরা সমাধান করতে থাকব।

রিসোর্স আপডেট পদ্ধতি এবং গ্রহণ সম্পর্কে তথ্য এখানে পাওয়া যাবে এই ডকুমেন্টেশন পাতা.

হেলম 3

বিশেষ নোটের যোগ্য মুক্তি ঠিক অন্য দিন হেলমের একটি নতুন প্রধান সংস্করণ - v3 - যা 3-ওয়ে-মার্জ প্যাচও ব্যবহার করে এবং টিলার থেকে মুক্তি পায়। হেলমের নতুন সংস্করণ প্রয়োজন মাইগ্রেশন বিদ্যমান ইনস্টলেশনগুলিকে নতুন রিলিজ স্টোরেজ বিন্যাসে রূপান্তর করতে।

Werf, তার অংশের জন্য, বর্তমানে Tiller ব্যবহার করা থেকে মুক্তি পেয়েছে, 3-ওয়ে-মার্জে স্যুইচ করেছে এবং যোগ করেছে অনেক বেশি, বিদ্যমান Helm 2 ইনস্টলেশনের সাথে সামঞ্জস্যপূর্ণ থাকা অবস্থায় (কোনও মাইগ্রেশন স্ক্রিপ্ট চালানোর প্রয়োজন নেই)। অতএব, যতক্ষণ না werf হেলম 3-এ স্যুইচ করে, werf ব্যবহারকারীরা Helm 3-এর তুলনায় Helm 2-এর প্রধান সুবিধাগুলি হারাবেন না (ওয়ার্ফেরও রয়েছে)।

যাইহোক, হেলম 3 কোডবেসে ওয়ারফের স্যুইচ অনিবার্য এবং অদূর ভবিষ্যতে ঘটবে। সম্ভবত এটি werf 1.1 বা werf 1.2 হবে (এই মুহূর্তে, werf-এর প্রধান সংস্করণ হল 1.0; werf সংস্করণ ডিভাইস সম্পর্কে আরও তথ্যের জন্য, দেখুন এখানে) এই সময়ের মধ্যে হেলম 3 এর স্থিতিশীল হওয়ার জন্য সময় থাকবে।

দ্রষ্টব্য

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

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

উত্স: www.habr.com