ওয়ার্ফ বিল্ডারে বিষয়বস্তু-ভিত্তিক ট্যাগিং: কেন এবং কীভাবে এটি কাজ করে?

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

একটি গিট রিপোজিটরি থেকে মাইক্রোসার্ভিসের একটি সেট রোল আউট করা হচ্ছে

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

এমন পরিস্থিতি রয়েছে যখন পরিষেবাগুলি সত্যই স্বাধীন এবং একটি একক অ্যাপ্লিকেশনের সাথে যুক্ত নয়। এই ক্ষেত্রে, তারা পৃথক প্রকল্পে অবস্থিত হবে এবং প্রতিটি প্রকল্পে পৃথক CI/CD প্রক্রিয়ার মাধ্যমে তাদের প্রকাশ করা হবে।

যাইহোক, বাস্তবে, বিকাশকারীরা প্রায়শই একটি একক অ্যাপ্লিকেশনকে কয়েকটি মাইক্রোসার্ভিসে বিভক্ত করে, তবে প্রতিটির জন্য একটি পৃথক সংগ্রহস্থল এবং প্রকল্প তৈরি করা... একটি স্পষ্ট ওভারকিল। এই পরিস্থিতিটিই আরও আলোচনা করা হবে: এই ধরনের বেশ কয়েকটি মাইক্রোসার্ভিস একটি একক প্রকল্প সংগ্রহস্থলে অবস্থিত এবং CI/CD-এ একটি একক প্রক্রিয়ার মাধ্যমে প্রকাশ করা হয়।

Git শাখা এবং Git ট্যাগ দ্বারা ট্যাগিং

ধরা যাক সবচেয়ে সাধারণ ট্যাগিং কৌশল ব্যবহার করা হয় - ট্যাগ-বা-শাখা. গিট শাখাগুলির জন্য, শাখার নামের সাথে চিত্রগুলি ট্যাগ করা হয়, এক সময়ে একটি শাখার জন্য সেই শাখার নামে শুধুমাত্র একটি প্রকাশিত চিত্র থাকে৷ গিট ট্যাগের জন্য, ট্যাগের নাম অনুসারে ছবি ট্যাগ করা হয়।

যখন একটি নতুন গিট ট্যাগ তৈরি করা হয় - উদাহরণস্বরূপ, যখন একটি নতুন সংস্করণ প্রকাশিত হয় - একটি নতুন ডকার ট্যাগ তৈরি করা হবে ডকার রেজিস্ট্রির সমস্ত প্রকল্প চিত্রের জন্য:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

এই নতুন ছবির নামগুলো হেলম টেমপ্লেটের মাধ্যমে কুবারনেটস কনফিগারেশনে পাঠানো হয়েছে। কমান্ড দিয়ে স্থাপনা শুরু করার সময় werf deploy ক্ষেত্র আপডেট করা হচ্ছে image Kubernetes রিসোর্স-এ পরিবর্তিত ইমেজ নামের কারণে সংশ্লিষ্ট রিসোর্স প্রকাশ করে এবং রিস্টার্ট করে।

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

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

Git কমিট দ্বারা ট্যাগিং

werf এর গিট কমিটের সাথে যুক্ত একটি ট্যাগিং কৌশলও রয়েছে।

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

যাইহোক, গিট কমিট দ্বারা ট্যাগ করার গিট শাখা বা গিট ট্যাগ দ্বারা ট্যাগিংয়ের মতো একই অসুবিধা রয়েছে:

• একটি খালি প্রতিশ্রুতি তৈরি করা যেতে পারে যা কোনো ফাইল পরিবর্তন করে না, তবে ছবির ডকার ট্যাগ পরিবর্তন করা হবে।
• একটি মার্জ কমিট তৈরি করা যেতে পারে যা ফাইলগুলিকে পরিবর্তন করে না, তবে ছবির ডকার ট্যাগ পরিবর্তন করা হবে।
• একটি প্রতিশ্রুতি তৈরি করা যেতে পারে যা গিটে সেই ফাইলগুলিকে পরিবর্তন করে যা ছবিতে আমদানি করা হয়নি এবং চিত্রটির ডকার ট্যাগ আবার পরিবর্তন করা হবে।

Git শাখার নাম ট্যাগ করা চিত্র সংস্করণ প্রতিফলিত করে না

গিট শাখার জন্য ট্যাগিং কৌশল সম্পর্কিত আরেকটি সমস্যা আছে।

শাখার নাম দ্বারা ট্যাগ করা ততক্ষণ কাজ করে যতক্ষণ না সেই শাখার প্রতিশ্রুতিগুলি কালানুক্রমিক ক্রমে সংগ্রহ করা হয়।

যদি বর্তমান স্কিমে ব্যবহারকারী একটি নির্দিষ্ট শাখার সাথে যুক্ত একটি পুরানো প্রতিশ্রুতি পুনর্নির্মাণ শুরু করে, তাহলে werf পুরানো প্রতিশ্রুতির জন্য চিত্রটির একটি নতুন নির্মিত সংস্করণ সহ সংশ্লিষ্ট ডকার ট্যাগ ব্যবহার করে চিত্রটি পুনরায় লিখবে। এখন থেকে এই ট্যাগ ব্যবহার করে স্থাপনাগুলি পড পুনরায় চালু করার সময় চিত্রটির একটি ভিন্ন সংস্করণ টেনে নেওয়ার ঝুঁকি চালায়, যার ফলস্বরূপ আমাদের অ্যাপ্লিকেশনটি CI সিস্টেমের সাথে সংযোগ হারাবে এবং ডিসিঙ্ক্রোনাইজ হয়ে যাবে৷

উপরন্তু, তাদের মধ্যে অল্প সময়ের সাথে একটি শাখায় পরপর ধাক্কা দিয়ে, পুরানো প্রতিশ্রুতিটি নতুনটির চেয়ে পরে সংকলিত হতে পারে: চিত্রের পুরানো সংস্করণটি গিট শাখা ট্যাগ ব্যবহার করে নতুনটিকে ওভাররাইট করবে। এই ধরনের সমস্যাগুলি একটি CI/CD সিস্টেম দ্বারা সমাধান করা যেতে পারে (উদাহরণস্বরূপ, গিটল্যাব CI-এ পরবর্তীটির পাইপলাইনটি একাধিক কমিটের জন্য চালু করা হয়)। যাইহোক, সমস্ত সিস্টেম এটিকে সমর্থন করে না এবং এই ধরনের মৌলিক সমস্যা প্রতিরোধ করার জন্য আরও নির্ভরযোগ্য উপায় থাকতে হবে।

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

সুতরাং, বিষয়বস্তু ভিত্তিক ট্যাগিং কি - বিষয়বস্তু দ্বারা ছবি ট্যাগিং।

ডকার ট্যাগ তৈরি করতে, এটি গিট আদিম (গিট শাখা, গিট ট্যাগ...) ব্যবহার করা হয় না, তবে একটি চেকসাম এর সাথে যুক্ত:

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

যেমন একটি শনাক্তকারী ট্যাগ তথাকথিত হয় ছবি মঞ্চ স্বাক্ষর.

প্রতিটি চিত্র ধাপগুলির একটি সেট নিয়ে গঠিত: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch ইত্যাদি প্রতিটি পর্যায়ে একটি শনাক্তকারী থাকে যা এর বিষয়বস্তু প্রতিফলিত করে - মঞ্চ স্বাক্ষর (মঞ্চ স্বাক্ষর).

এই ধাপগুলি নিয়ে গঠিত চূড়ান্ত চিত্রটি এই পর্যায়ের সেটের তথাকথিত স্বাক্ষরের সাথে ট্যাগ করা হয়েছে - পর্যায় স্বাক্ষর, - যা চিত্রের সমস্ত পর্যায়ের জন্য সাধারণীকরণ করা হয়৷

কনফিগারেশন থেকে প্রতিটি ছবির জন্য werf.yaml সাধারণ ক্ষেত্রে, এর নিজস্ব স্বাক্ষর থাকবে এবং সেই অনুযায়ী, একটি ডকার ট্যাগ।

মঞ্চ স্বাক্ষর এই সমস্ত সমস্যার সমাধান করে:

• খালি গিট কমিট প্রতিরোধী.
• গিট কমিট প্রতিরোধী যা ইমেজের সাথে প্রাসঙ্গিক নয় এমন ফাইল পরিবর্তন করে।
• একটি শাখার পুরানো গিট কমিটের জন্য বিল্ডগুলি পুনরায় চালু করার সময় চিত্রের বর্তমান সংস্করণটি ওভারহোল করার সমস্যা সৃষ্টি করে না।

এটি এখন প্রস্তাবিত ট্যাগিং কৌশল এবং সমস্ত CI সিস্টেমের জন্য werf-এ ডিফল্ট।

কিভাবে সক্রিয় এবং werf ব্যবহার করতে হয়

কমান্ডের এখন একটি সংশ্লিষ্ট বিকল্প রয়েছে werf publish: --tag-by-stages-signature=true|false

একটি CI সিস্টেমে, ট্যাগিং কৌশল কমান্ড দ্বারা নির্দিষ্ট করা হয় werf ci-env. পূর্বে, প্যারামিটার এটির জন্য সংজ্ঞায়িত করা হয়েছিল werf ci-env --tagging-strategy=tag-or-branch. এখন, যদি আপনি নির্দিষ্ট করুন werf ci-env --tagging-strategy=stages-signature অথবা এই বিকল্পটি নির্দিষ্ট করবেন না, werf ডিফল্টরূপে ট্যাগিং কৌশল ব্যবহার করবে stages-signature. টীম werf ci-env স্বয়ংক্রিয়ভাবে কমান্ডের জন্য প্রয়োজনীয় পতাকা সেট করবে werf build-and-publish (বা werf publish), তাই এই কমান্ডগুলির জন্য কোনও অতিরিক্ত বিকল্প নির্দিষ্ট করার প্রয়োজন নেই।

উদাহরণস্বরূপ, কমান্ড:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...নিম্নলিখিত ছবি তৈরি করতে পারেন:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

এটা হল 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d চিত্রের ধাপগুলির একটি স্বাক্ষর backendএবং f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - চিত্র পর্যায়ে স্বাক্ষর frontend.

বিশেষ ফাংশন ব্যবহার করার সময় werf_container_image и werf_container_env হেলম টেমপ্লেটগুলিতে কিছু পরিবর্তন করার দরকার নেই: এই ফাংশনগুলি স্বয়ংক্রিয়ভাবে সঠিক ছবির নাম তৈরি করবে।

একটি CI সিস্টেমে কনফিগারেশনের উদাহরণ:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

কনফিগারেশন সম্পর্কে আরও তথ্য ডকুমেন্টেশনে উপলব্ধ:

• ডিরেক্টরি → প্রকাশনা (প্রকাশ);
• CI/CD এর সাথে কাজ করা → সাধারণ তথ্য → ধাপ-স্বাক্ষর;
• GitLab CI/CD → .gitlab-ci.yml-এর সাথে ইন্টিগ্রেশন.

মোটে

• নতুন বিকল্প werf publish --tag-by-stages-signature=true|false.
• নতুন বিকল্প মান werf ci-env --tagging-strategy=stages-signature|tag-or-branch (নির্দিষ্ট না হলে, ডিফল্ট হবে stages-signature).
• আপনি যদি আগে গিট কমিটের জন্য ট্যাগিং বিকল্পগুলি ব্যবহার করেন (WERF_TAG_GIT_COMMIT বা বিকল্প werf publish --tag-git-commit COMMIT), তারপর ট্যাগিং কৌশলে স্যুইচ করতে ভুলবেন না ধাপ-স্বাক্ষর.
• অবিলম্বে নতুন প্রকল্পগুলিকে নতুন ট্যাগিং স্কিমে পরিবর্তন করা ভাল।
• werf 1.1 এ স্থানান্তর করার সময়, পুরানো প্রকল্পগুলিকে নতুন ট্যাগিং স্কিমে স্যুইচ করার পরামর্শ দেওয়া হয়, তবে পুরানো ট্যাগ-বা-শাখা এখনও সমর্থিত।

বিষয়বস্তু-ভিত্তিক ট্যাগিং নিবন্ধে কভার করা সমস্ত সমস্যার সমাধান করে:

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

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

দ্রষ্টব্য

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

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

উত্স: www.habr.com