কনটেইনার ইমেজগুলির "স্মার্ট" পরিষ্কারের সমস্যা এবং ওয়ার্ফে এর সমাধান

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

ভূমিকা

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

1. ছবির জন্য একটি নির্দিষ্ট সংখ্যক ট্যাগ ব্যবহার করুন;
2. কোনোভাবে ছবি পরিষ্কার করুন।

প্রথম সীমাবদ্ধতা কখনও কখনও ছোট দলের জন্য গ্রহণযোগ্য। যদি বিকাশকারীদের পর্যাপ্ত স্থায়ী ট্যাগ থাকে (latest, main, test, boris ইত্যাদি), রেজিস্ট্রি আকারে ফুলে উঠবে না এবং দীর্ঘ সময়ের জন্য আপনাকে এটি পরিষ্কার করার কথা ভাবতে হবে না। সব পরে, সমস্ত অপ্রাসঙ্গিক ইমেজ মুছে ফেলা হয়, এবং পরিষ্কার করার জন্য কোন কাজ বাকি নেই (সবকিছু একটি নিয়মিত আবর্জনা সংগ্রহকারী দ্বারা করা হয়)।

যাইহোক, এই পদ্ধতিটি বিকাশকে ব্যাপকভাবে সীমিত করে এবং আধুনিক CI/CD প্রকল্পের ক্ষেত্রে খুব কমই প্রযোজ্য। উন্নয়নের অবিচ্ছেদ্য অংশ ছিল অটোমেশন, যা আপনাকে অনেক দ্রুত ব্যবহারকারীদের কাছে নতুন কার্যকারিতা পরীক্ষা, স্থাপন এবং বিতরণ করতে দেয়। উদাহরণস্বরূপ, আমাদের সমস্ত প্রকল্পে, প্রতিটি কমিটের সাথে একটি CI পাইপলাইন স্বয়ংক্রিয়ভাবে তৈরি হয়। এটিতে, চিত্রটিকে একত্রিত করা হয়, পরীক্ষা করা হয়, ডিবাগ করার জন্য বিভিন্ন কুবারনেটস সার্কিটে রোল আউট করা হয় এবং অবশিষ্ট চেকগুলি এবং যদি সবকিছু ঠিক থাকে তবে পরিবর্তনগুলি শেষ ব্যবহারকারীর কাছে পৌঁছে যায়। এবং এটি আর রকেট বিজ্ঞান নয়, অনেকের জন্য একটি দৈনন্দিন ঘটনা - সম্ভবত আপনার জন্য, যেহেতু আপনি এই নিবন্ধটি পড়ছেন।

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

কিন্তু কিভাবে আপনি এমনকি একটি ইমেজ প্রাসঙ্গিক কিনা তা নির্ধারণ করবেন?

ছবির প্রাসঙ্গিকতার জন্য মানদণ্ড

বেশিরভাগ ক্ষেত্রে, প্রধান মানদণ্ড হবে:

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

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

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

4. চতুর্থ - ইমেজ যে আমাদের অ্যাপ্লিকেশনের সংস্করণের সাথে মিলে যায়, অর্থাৎ চূড়ান্ত পণ্য: v1.0.0, 20.04.01/XNUMX/XNUMX, সিয়েরা, ইত্যাদি

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

যোগ্যতা এবং বিদ্যমান সমাধান

কনটেইনার রেজিস্ট্রিগুলির সাথে জনপ্রিয় পরিষেবাগুলি, একটি নিয়ম হিসাবে, তাদের নিজস্ব ইমেজ ক্লিনআপ নীতিগুলি অফার করে: তাদের মধ্যে আপনি রেজিস্ট্রি থেকে একটি ট্যাগ সরানো হয় এমন শর্তগুলি সংজ্ঞায়িত করতে পারেন। যাইহোক, এই শর্তগুলি নাম, তৈরির সময় এবং ট্যাগের সংখ্যা* এর মত পরামিতি দ্বারা সীমাবদ্ধ।

* নির্দিষ্ট ধারক রেজিস্ট্রি বাস্তবায়নের উপর নির্ভর করে। আমরা নিম্নলিখিত সমাধানগুলির সম্ভাবনা বিবেচনা করেছি: Azure CR, Docker Hub, ECR, GCR, GitHub প্যাকেজ, GitLab কন্টেইনার রেজিস্ট্রি, হারবার রেজিস্ট্রি, JFrog Artifactory, Quay.io - সেপ্টেম্বর'2020 অনুযায়ী।

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

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

প্রথম দুটি মানদণ্ডের সাথে পরিস্থিতি একই: তারা একটি বাহ্যিক সিস্টেম থেকে ডেটা গ্রহণ না করে সন্তুষ্ট হতে পারে না - যেখানে অ্যাপ্লিকেশনগুলি স্থাপন করা হয় (আমাদের ক্ষেত্রে, কুবারনেটস)।

গিটে কর্মপ্রবাহের চিত্র

ধরা যাক আপনি গিট-এ এরকম কিছু কাজ করছেন:

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

ক্লিনআপ নীতিগুলি শুধুমাত্র ছবিগুলিকে ধরে রাখার অনুমতি দিলে কী হবে (মোছা হয় না) প্রদত্ত ট্যাগ নাম দ্বারা?

স্পষ্টতই, এই ধরনের দৃশ্য কাউকে খুশি করবে না।

নীতিগুলি ছবি মুছে ফেলার অনুমতি না দিলে কী পরিবর্তন হবে? একটি নির্দিষ্ট সময়ের ব্যবধান / শেষ কমিট সংখ্যা অনুযায়ী?

ফলাফল অনেক ভাল হয়েছে, কিন্তু এখনও আদর্শ থেকে অনেক দূরে. সর্বোপরি, আমাদের কাছে এখনও বিকাশকারী রয়েছে যাদের বাগগুলি ডিবাগ করার জন্য রেজিস্ট্রিতে (বা এমনকি K8 তে স্থাপন করা) চিত্রের প্রয়োজন...

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

যাইহোক, আমরা একটি সার্বজনীন সমাধান খুঁজছিলাম যা বিভিন্ন রেজিস্ট্রি ব্যবহার করে বিভিন্ন দলের জন্য ইমেজ ক্লিনআপ স্বয়ংক্রিয় করবে...

সর্বজনীন ইমেজ পরিষ্কারের জন্য আমাদের পথ

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

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

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

যদিও আমরা একটি উদাহরণ বাস্তবায়ন হিসাবে werf ব্যবহার করছি, আমরা আশা করি যে ব্যবহৃত পদ্ধতিগুলি অনুরূপ সমস্যার সম্মুখীন অন্যান্য দলগুলির জন্য কার্যকর হবে।

তাই আমরা ব্যস্ত হয়ে পড়লাম বহিরাগত ইমেজ পরিষ্কারের জন্য একটি প্রক্রিয়া বাস্তবায়ন - সেই ক্ষমতাগুলির পরিবর্তে যা ইতিমধ্যে পাত্রে রেজিস্ট্রিগুলিতে তৈরি করা হয়েছে। প্রথম পদক্ষেপটি ছিল ডকার রেজিস্ট্রি API ব্যবহার করে ট্যাগগুলির সংখ্যা এবং তাদের তৈরির সময় (উপরে উল্লিখিত) জন্য একই আদিম নীতি তৈরি করা। তাদের সাথে যুক্ত হয়েছে স্থাপন করা পরিকাঠামোতে ব্যবহৃত ছবির উপর ভিত্তি করে তালিকার অনুমতি দিন, অর্থাৎ কুবারনেটস। পরেরটির জন্য, সমস্ত স্থাপন করা সংস্থানগুলির মাধ্যমে পুনরাবৃত্তি করতে এবং মানগুলির একটি তালিকা পেতে Kubernetes API ব্যবহার করা যথেষ্ট ছিল image.

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

ট্যাগিং স্কিম

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

এই পদ্ধতির ফলে নীতিগুলির একটি সেট তৈরি হয়েছিল যা গিটকে সত্যের একক উত্স হিসাবে ব্যবহার করার অনুমতি দেয়:

• Git-এ একটি শাখা/ট্যাগ মুছে ফেলার সময়, রেজিস্ট্রিতে সংশ্লিষ্ট ছবিগুলি স্বয়ংক্রিয়ভাবে মুছে ফেলা হয়।
• গিট ট্যাগ এবং কমিটের সাথে যুক্ত ছবির সংখ্যা নির্বাচিত স্কিমাতে ব্যবহৃত ট্যাগের সংখ্যা এবং সংশ্লিষ্ট প্রতিশ্রুতি তৈরি করার সময় দ্বারা নিয়ন্ত্রিত হতে পারে।

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

নতুন অ্যালগরিদম

কেন? বিষয়বস্তু-ভিত্তিক ট্যাগিংয়ের সাথে, প্রতিটি ট্যাগ গিট-এ একাধিক প্রতিশ্রুতি পূরণ করতে পারে। ছবি পরিষ্কার করার সময়, আপনি আর অনুমান করতে পারবেন না শুধুমাত্র কমিট থেকে যেখানে রেজিস্ট্রিতে নতুন ট্যাগ যোগ করা হয়েছে।

নতুন ক্লিনিং অ্যালগরিদমের জন্য, ট্যাগিং স্কিম থেকে সরে যাওয়ার এবং তৈরি করার সিদ্ধান্ত নেওয়া হয়েছিল মেটা-ইমেজ প্রক্রিয়া, যার প্রতিটি একগুচ্ছ সঞ্চয় করে:

• যে প্রতিশ্রুতিতে প্রকাশনাটি সম্পাদিত হয়েছিল (ইমেজটি যোগ করা হয়েছে, পরিবর্তিত হয়েছে বা কন্টেইনার রেজিস্ট্রিতে একই ছিল কিনা তা বিবেচ্য নয়);
• এবং আমাদের অভ্যন্তরীণ শনাক্তকারী একত্রিত চিত্রের সাথে সম্পর্কিত।

অন্য কথায়, এটি প্রদান করা হয়েছিল Git-এ কমিটের সাথে প্রকাশিত ট্যাগ লিঙ্ক করা.

চূড়ান্ত কনফিগারেশন এবং সাধারণ অ্যালগরিদম

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

• অনেক রেফারেন্স, যেমন গিট ট্যাগ বা গিট শাখা যা স্ক্যান করার সময় ব্যবহার করা হয়;
• এবং সেট থেকে প্রতিটি রেফারেন্সের জন্য অনুসন্ধান করা চিত্রের সীমা।

ব্যাখ্যা করার জন্য, ডিফল্ট নীতি কনফিগারেশনটি এইরকম দেখতে শুরু করেছে:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

এই কনফিগারেশনে তিনটি নীতি রয়েছে যা নিম্নলিখিত নিয়মগুলি মেনে চলে:

1. শেষ 10টি গিট ট্যাগের জন্য চিত্রটি সংরক্ষণ করুন (ট্যাগ তৈরির তারিখ অনুসারে)।
2. গত সপ্তাহে 2টির বেশি থ্রেডের কার্যকলাপের জন্য গত সপ্তাহে প্রকাশিত 10টির বেশি ছবি সংরক্ষণ করবেন না।
3. শাখাগুলির জন্য 10টি ছবি সংরক্ষণ করুন main, staging и production.

চূড়ান্ত অ্যালগরিদম নিম্নলিখিত ধাপে ফুটে ওঠে:

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

আমাদের দৃষ্টান্তে ফিরে আসা, werf এর সাথে এটি ঘটে:

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

উপসংহার

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

দ্রষ্টব্য

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

• «ওয়ার্ফ বিল্ডারে বিষয়বস্তু-ভিত্তিক ট্যাগিং: কেন এবং কীভাবে এটি কাজ করে?";
• «ওয়ার্ফের সাথে 3-ওয়ে মার্জ: হেলমের সাথে কুবারনেটে স্থাপন করা "স্টেরয়েডগুলিতে"";
• «ওয়ার্ফে মনোরেপো এবং মাল্টিরেপোর জন্য সমর্থন এবং ডকার রেজিস্ট্রি এর সাথে কী করতে হবে";
• «werf 1.1 রিলিজ: আজ নির্মাতার উন্নতি এবং ভবিষ্যতের জন্য পরিকল্পনা».

উত্স: www.habr.com