Quay.io অনুপলব্ধতায় পোস্ট মর্টেম

বিঃদ্রঃ. অনুবাদ: আগস্টের শুরুতে, Red Hat প্রকাশ্যে অ্যাক্সেসযোগ্যতার সমস্যাগুলি সমাধানের বিষয়ে কথা বলেছিল যা এর পরিষেবার ব্যবহারকারীরা আগের মাসগুলিতে সম্মুখীন হয়েছিল Quay.io (এটি কন্টেইনার ইমেজগুলির জন্য একটি রেজিস্ট্রির উপর ভিত্তি করে, যা কোম্পানী CoreOS কেনার সাথে পেয়েছে)। এই পরিষেবাতে আপনার আগ্রহ যাই হোক না কেন, কোম্পানির SRE ইঞ্জিনিয়াররা দুর্ঘটনার কারণ নির্ণয় এবং নির্মূল করার জন্য যে পথটি গ্রহণ করেছেন তা শিক্ষামূলক।

19 মে, খুব ভোরে (ইস্টার্ন ডেলাইট টাইম, EDT), quay.io পরিষেবাটি ক্র্যাশ হয়ে যায়। দুর্ঘটনাটি quay.io ভোক্তা এবং ওপেন সোর্স প্রকল্প উভয়কেই প্রভাবিত করেছে quay.io কে সফ্টওয়্যার তৈরি এবং বিতরণের জন্য একটি প্ল্যাটফর্ম হিসাবে ব্যবহার করে৷ রেড হ্যাট উভয়ের বিশ্বাসকে মূল্য দেয়।

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

«কি পরিবর্তন হয়েছে?"- এটিই প্রথম প্রশ্ন যা সাধারণত এই ধরনের ক্ষেত্রে জিজ্ঞাসা করা হয়। আমরা লক্ষ্য করেছি যে ইস্যুটির কিছুক্ষণ আগে, OpenShift ডেডিকেটেড ক্লাস্টার (যা quay.io চালায়) 4.3.19 সংস্করণে আপডেট হতে শুরু করেছে। যেহেতু quay.io রেড হ্যাট ওপেনশিফট ডেডিকেটেড (ওএসডি) তে চলে, তাই নিয়মিত আপডেটগুলি রুটিন ছিল এবং কখনও সমস্যা সৃষ্টি করেনি। তাছাড়া, গত ছয় মাসে, আমরা সেবার কোনো বাধা ছাড়াই বেশ কয়েকবার Quay ক্লাস্টারগুলিকে আপগ্রেড করেছি।

আমরা যখন পরিষেবাটি পুনরুদ্ধার করার চেষ্টা করছিলাম, তখন অন্যান্য প্রকৌশলীরা সফ্টওয়্যারটির পূর্ববর্তী সংস্করণের সাথে একটি নতুন OSD ক্লাস্টার প্রস্তুত করতে শুরু করেছিলেন, যাতে কিছু ঘটে গেলে, তারা এটিতে সবকিছু স্থাপন করতে পারে।

মূল কারণ বিশ্লেষণ

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

আমরা ডাটাবেস ট্র্যাফিকের একটি প্যাটার্ন সনাক্ত করার চেষ্টা করেছি যা এই তুষারপাতের কারণ হতে পারে। যাইহোক, আমরা লগগুলিতে কোন নিদর্শন খুঁজে পাইনি। OSD 4.3.18 সহ নতুন ক্লাস্টার প্রস্তুত হওয়ার জন্য অপেক্ষা করার সময়, আমরা quay.io পড চালু করার চেষ্টা চালিয়ে যাচ্ছি। প্রতিবার ক্লাস্টারটি পূর্ণ ক্ষমতায় পৌঁছালে, ডাটাবেস হিমায়িত হবে। এর মানে হল যে সমস্ত quay.io পড ছাড়াও RDS ইন্সট্যান্স রিস্টার্ট করা প্রয়োজন।

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

Quay.io নতুন ওএসডি ক্লাস্টারে স্থিরভাবে কাজ করেছে, তাই আমরা ডাটাবেস লগগুলিতে ফিরে গিয়েছিলাম, কিন্তু বাধাগুলি ব্যাখ্যা করবে এমন একটি সম্পর্ক খুঁজে পাইনি। Red Hat OpenShift 4.3.19-এর পরিবর্তন Quay-এর সাথে সমস্যা সৃষ্টি করতে পারে কিনা তা বোঝার জন্য OpenShift ইঞ্জিনিয়াররা আমাদের সাথে কাজ করেছেন। যাইহোক, কিছুই পাওয়া যায়নি, এবং ল্যাবরেটরি অবস্থায় সমস্যাটি পুনরুত্পাদন করা সম্ভব ছিল না.

দ্বিতীয় ব্যর্থতা

28 মে, EDT দুপুরের কিছু আগে, quay.io একই উপসর্গের সাথে আবার ক্র্যাশ হয়েছিল: ডাটাবেসটি ব্লক করা হয়েছিল। এবং আবার আমরা তদন্তে আমাদের সমস্ত প্রচেষ্টা নিক্ষেপ করেছি। প্রথমত, পরিষেবাটি পুনরুদ্ধার করা প্রয়োজন ছিল। যাহোক এইবার RDS রিবুট করা এবং quay.io পড রিস্টার্ট করা কিছুই করেনি: সংযোগের আরেকটি তুষারপাত বেসকে অভিভূত করেছে। কিন্তু কেন?

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

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

এইবার আমরা সমস্যার উৎস খুঁজে বের করতে এবং নির্মূল করার জন্য দৃঢ়প্রতিজ্ঞ ছিলাম, এবং নিজেদেরকে রিবুটের মধ্যে সীমাবদ্ধ রাখিনি। Quay কোডবেস থেকে প্রতিটি কর্মীর জন্য ডাটাবেসের সাথে সংযোগের সংখ্যা সীমিত করার জন্য পরিবর্তন করা হয়েছে gevent এই সংখ্যাটি কনফিগারেশনের একটি প্যারামিটার হয়ে উঠেছে: এটি একটি নতুন ধারক চিত্র তৈরি না করেই এটি পরিবর্তন করা সম্ভব হয়েছে। কতগুলি সংযোগ বাস্তবসম্মতভাবে পরিচালনা করা যেতে পারে তা খুঁজে বের করার জন্য, আমরা একটি স্টেজিং পরিবেশে বেশ কয়েকটি পরীক্ষা চালিয়েছি, এটি কীভাবে লোড পরীক্ষার পরিস্থিতিকে প্রভাবিত করবে তা দেখার জন্য বিভিন্ন মান সেট করেছি। ফলস্বরূপ, এটি আবিষ্কৃত হয় সংযোগের সংখ্যা 502 হাজার ছাড়িয়ে গেলে Quay 10 ত্রুটি নিক্ষেপ শুরু করে।

আমরা অবিলম্বে এই নতুন সংস্করণটি উত্পাদনে স্থাপন করেছি এবং ডাটাবেস সংযোগের সময়সূচী পর্যবেক্ষণ শুরু করেছি। অতীতে, প্রায় 20 মিনিটের পরে ঘাঁটিটি তালাবদ্ধ করা হয়েছিল। 30টি ঝামেলামুক্ত মিনিটের পরে আমাদের আশা ছিল, এবং এক ঘন্টা পরে আমাদের আত্মবিশ্বাস ছিল। আমরা সাইটে ট্রাফিক পুনরুদ্ধার করেছি এবং পোস্টমর্টেম বিশ্লেষণ শুরু করেছি।

ব্লক করার দিকে নিয়ে যাওয়া সমস্যাটিকে বাইপাস করতে পেরে, আমরা এর আসল কারণ খুঁজে পাইনি. এটি নিশ্চিত করা হয়েছিল যে এটি OpenShift 4.3.19-এর কোনো পরিবর্তনের সাথে সম্পর্কিত নয়, যেহেতু একই জিনিসটি 4.3.18 সংস্করণে ঘটেছে, যা পূর্বে Quay-এর সাথে কোনো সমস্যা ছাড়াই কাজ করেছিল।

ক্লাস্টারে স্পষ্টতই অন্য কিছু লুকিয়ে ছিল।

বিস্তারিত অধ্যয়ন

Quay.io কোনো সমস্যা ছাড়াই ছয় বছরের জন্য ডাটাবেসের সাথে সংযোগ করতে ডিফল্ট সেটিংস ব্যবহার করেছে। কি পরিবর্তন? এটা স্পষ্ট যে এই সমস্ত সময় quay.io-তে ট্র্যাফিক ক্রমাগত বৃদ্ধি পাচ্ছে। আমাদের ক্ষেত্রে, দেখে মনে হচ্ছিল যেন কিছু থ্রেশহোল্ড মান পৌঁছে গেছে, যা সংযোগের তুষারপাতের জন্য ট্রিগার হিসাবে কাজ করে। আমরা দ্বিতীয় ব্যর্থতার পরে ডাটাবেস লগগুলি অধ্যয়ন করতে থাকি, কিন্তু কোনও নিদর্শন বা সুস্পষ্ট সম্পর্ক খুঁজে পাইনি।

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

Quay.io 9 ই জুন পর্যন্ত ভাল কাজ করেছে। আজ সকালে (EDT) আমরা আবার ডাটাবেস সংযোগের সংখ্যায় উল্লেখযোগ্য বৃদ্ধি দেখেছি। এবার কোনো ডাউনটাইম ছিল না, যেহেতু নতুন প্যারামিটার তাদের সংখ্যা সীমিত করেছে এবং তাদের MySQL থ্রুপুট অতিক্রম করার অনুমতি দেয়নি। যাইহোক, প্রায় আধা ঘন্টা ধরে, অনেক ব্যবহারকারী quay.io-এর ধীর কর্মক্ষমতা উল্লেখ করেছেন। আমরা অতিরিক্ত মনিটরিং সরঞ্জাম ব্যবহার করে দ্রুত সমস্ত সম্ভাব্য ডেটা সংগ্রহ করেছি। হঠাৎ একটা প্যাটার্ন দেখা দিল।

সংযোগ বৃদ্ধির ঠিক আগে, অ্যাপ রেজিস্ট্রি এপিআই-তে বিপুল সংখ্যক অনুরোধ করা হয়েছিল. অ্যাপ রেজিস্ট্রি quay.io এর একটি স্বল্প পরিচিত বৈশিষ্ট্য। এটি আপনাকে হেলম চার্ট এবং সমৃদ্ধ মেটাডেটা সহ পাত্রের মতো জিনিসগুলি সংরক্ষণ করতে দেয়৷ বেশিরভাগ quay.io ব্যবহারকারীরা এই বৈশিষ্ট্যটির সাথে কাজ করে না, তবে Red Hat OpenShift সক্রিয়ভাবে এটি ব্যবহার করে। OpenShift-এর অংশ হিসেবে OperatorHub অ্যাপ রেজিস্ট্রিতে সমস্ত অপারেটরকে সঞ্চয় করে। এই অপারেটরগুলি ওপেনশিফট ওয়ার্কলোড ইকোসিস্টেম এবং অংশীদার-কেন্দ্রিক অপারেটিং মডেলের (দিন 2 অপারেশন) ভিত্তি তৈরি করে।

প্রতিটি OpenShift 4 ক্লাস্টার ইনস্টলেশনের জন্য উপলব্ধ অপারেটরগুলির একটি ক্যাটালগ প্রকাশ করার জন্য অন্তর্নির্মিত OperatorHub থেকে অপারেটর ব্যবহার করে এবং ইতিমধ্যে ইনস্টল করা আপডেটগুলি প্রদান করে। OpenShift 4 এর ক্রমবর্ধমান জনপ্রিয়তার সাথে, বিশ্বজুড়ে এটিতে ক্লাস্টারের সংখ্যাও বৃদ্ধি পেয়েছে। এই ক্লাস্টারগুলির প্রত্যেকটি ব্যাকএন্ড হিসাবে quay.io-এর ভিতরে অ্যাপ রেজিস্ট্রি ব্যবহার করে অন্তর্নির্মিত OperatorHub চালানোর জন্য অপারেটর সামগ্রী ডাউনলোড করে। সমস্যার উৎসের জন্য আমাদের অনুসন্ধানে, আমরা এই সত্যটি মিস করেছি যে ওপেনশিফ্ট ধীরে ধীরে জনপ্রিয়তা বাড়ার সাথে সাথে খুব কমই ব্যবহৃত quay.io ফাংশনের লোডও বেড়েছে।.

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

কারণ নির্মূল

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

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

আমরা কি শিখেছি?

এটা স্পষ্ট যে কোনো পরিষেবা ডাউনটাইম এড়াতে চেষ্টা করে। আমাদের ক্ষেত্রে, আমরা বিশ্বাস করি যে সাম্প্রতিক বিভ্রাটগুলি quay.io কে আরও ভাল করতে সাহায্য করেছে৷ আমরা কয়েকটি মূল পাঠ শিখেছি যা আমরা শেয়ার করতে চাই:

1. কে আপনার পরিষেবা ব্যবহার করে এবং কীভাবে ব্যবহার করে সে সম্পর্কে ডেটা কখনই অতিরিক্ত নয়৷. কারণ Quay "শুধু কাজ করেছে", আমাদের কখনই ট্র্যাফিক অপ্টিমাইজ করতে এবং লোড পরিচালনা করতে সময় ব্যয় করতে হয়নি। এই সমস্ত নিরাপত্তার একটি মিথ্যা ধারণা তৈরি করেছে যে পরিষেবাটি অনির্দিষ্টকালের জন্য স্কেল করতে পারে।
2. সেবা বন্ধ হয়ে গেলে, এটিকে ব্যাক আপ করা এবং চালানো একটি শীর্ষ অগ্রাধিকার।. যেহেতু Quay প্রথম বিভ্রাটের সময় একটি লক করা ডাটাবেস থেকে ভুগতে থাকে, আমাদের স্ট্যান্ডার্ড পদ্ধতিগুলির উদ্দেশ্যমূলক প্রভাব ছিল না এবং আমরা সেগুলি ব্যবহার করে পরিষেবাটি পুনরুদ্ধার করতে অক্ষম ছিলাম৷ এটি এমন একটি পরিস্থিতির দিকে পরিচালিত করেছিল যেখানে কার্যকারিতা পুনরুদ্ধারের জন্য সমস্ত প্রচেষ্টাকে ফোকাস করার পরিবর্তে মূল কারণ খুঁজে পাওয়ার আশায় বিশ্লেষণ এবং ডেটা সংগ্রহ করতে সময় ব্যয় করতে হয়েছিল।
3. প্রতিটি পরিষেবা বৈশিষ্ট্যের প্রভাব মূল্যায়ন করুন. ক্লায়েন্টরা খুব কমই অ্যাপ রেজিস্ট্রি ব্যবহার করে, তাই এটি আমাদের দলের জন্য অগ্রাধিকার ছিল না। যখন কিছু পণ্য বৈশিষ্ট্য সবেমাত্র ব্যবহার করা হয়, তখন তাদের বাগগুলি খুব কমই দেখা যায় এবং বিকাশকারীরা কোডটি পর্যবেক্ষণ করা বন্ধ করে দেয়। এই ভুল ধারণার শিকার হওয়া সহজ যে এটি এমন হওয়া উচিত - যতক্ষণ না হঠাৎ করে সেই ফাংশনটি একটি বড় ঘটনার কেন্দ্রে নিজেকে খুঁজে পায়।

এরপরে কী?

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

1. প্রাথমিক RDS দৃষ্টান্তে সমস্যার ক্ষেত্রে পরিষেবাটিকে উপযুক্ত ট্র্যাফিক পরিচালনা করতে সহায়তা করার জন্য শুধুমাত্র-পঠনযোগ্য ডাটাবেস প্রতিলিপিগুলি স্থাপন করুন৷
2. একটি RDS উদাহরণ আপডেট করা হচ্ছে। বর্তমান সংস্করণ নিজেই সমস্যা নয়। বরং, আমরা কেবল মিথ্যা লেজটি সরাতে চাই (যা ব্যর্থতার সময় আমরা অনুসরণ করেছি); সফ্টওয়্যারটিকে আপ টু ডেট রাখলে ভবিষ্যতে বিভ্রাটের ক্ষেত্রে আরেকটি ফ্যাক্টর দূর হবে৷
3. পুরো ক্লাস্টার জুড়ে অতিরিক্ত ক্যাশিং। আমরা এমন অঞ্চলগুলি সন্ধান করতে থাকি যেখানে ক্যাশিং ডাটাবেসের লোড কমাতে পারে।
4. কে quay.io এর সাথে সংযোগ করছে এবং কেন তা দেখতে একটি ওয়েব অ্যাপ্লিকেশন ফায়ারওয়াল (WAF) যুক্ত করা হচ্ছে৷
5. পরবর্তী প্রকাশের সাথে শুরু করে, Red Hat OpenShift ক্লাস্টারগুলি quay.io-তে উপলব্ধ কন্টেইনার চিত্রগুলির উপর ভিত্তি করে অপারেটর ক্যাটালগগুলির পক্ষে অ্যাপ রেজিস্ট্রি ত্যাগ করবে।
6. অ্যাপ রেজিস্ট্রির জন্য একটি দীর্ঘমেয়াদী প্রতিস্থাপন ওপেন কন্টেইনার ইনিশিয়েটিভ (ওসিআই) আর্টিফ্যাক্ট স্পেসিফিকেশনের জন্য সমর্থন হতে পারে। এটি বর্তমানে নেটিভ Quay কার্যকারিতা হিসাবে প্রয়োগ করা হয়েছে এবং স্পেসিফিকেশন নিজেই চূড়ান্ত হয়ে গেলে ব্যবহারকারীদের কাছে উপলব্ধ হবে।

উপরের সবগুলোই quay.io-তে Red Hat-এর চলমান বিনিয়োগের অংশ কারণ আমরা একটি ছোট "স্টার্টআপ-স্টাইল" দল থেকে একটি পরিপক্ক SRE-চালিত প্ল্যাটফর্মে চলে যাই। আমরা জানি যে আমাদের অনেক গ্রাহক তাদের দৈনন্দিন কাজে (Red Hat সহ!) quay.io-এর উপর নির্ভর করে এবং আমরা সাম্প্রতিক বিভ্রাট এবং উন্নতির জন্য চলমান প্রচেষ্টা সম্পর্কে যতটা সম্ভব স্বচ্ছ হওয়ার চেষ্টা করি।

অনুবাদক থেকে PS

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

• «CoreOS কন্টেইনার ইমেজের জন্য Red Hat ওপেন সোর্সড রেজিস্ট্রি কোড - Quay";
• «আমাদের SRE দৈনন্দিন জীবন থেকে ব্যবহারিক গল্প. অংশ ২";
• «Kubernetes-এ পডের অগ্রাধিকার কীভাবে Grafana Labs-এ ডাউনটাইম ঘটায়».

উত্স: www.habr.com