হাই সব! আমার নাম পাভেল আগালেটস্কি। আমি একটি টিম লিড হিসাবে কাজ করি যেটি Lamoda ডেলিভারি সিস্টেম বিকাশ করে। 2018 সালে, আমি HighLoad++ সম্মেলনে বক্তৃতা দিয়েছিলাম, এবং আজ আমি আমার প্রতিবেদনের একটি প্রতিলিপি উপস্থাপন করতে চাই।

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

VM এ অ্যাপ্লিকেশন স্থাপন করা হচ্ছে

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

ওটা কিসের জন্য ছিলো?

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

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

এই সব আমরা কি সুবিধা দেখতে?

1. প্রথমত, এটা যথেষ্ট এটা শুধু কাজ করে সবাই বোঝে যে এই ধরনের একটি স্থাপনার স্কিম কিভাবে কাজ করে, কারণ বেশিরভাগ লোকই নিয়মিত ভার্চুয়াল সার্ভারে স্থাপন করেছে।
2. এই যথেষ্ট নির্ভরযোগ্যভাবে, যেহেতু স্থাপনার প্রযুক্তি সহজ, হাজার হাজার কোম্পানি দ্বারা পরীক্ষিত। লক্ষ লক্ষ সার্ভার এই ভাবে স্থাপন করা হয়. কিছু ভাঙা কঠিন।
3. এবং অবশেষে আমরা পেতে পারে পারমাণবিক স্থাপনা. পুরানো সংস্করণ এবং নতুন সংস্করণের মধ্যে পরিবর্তনের লক্ষণীয় পর্যায় ছাড়াই ব্যবহারকারীদের জন্য একযোগে ঘটতে থাকা স্থাপনা৷

তবে আমরা এই সমস্ত কিছুর মধ্যে বেশ কয়েকটি ত্রুটিও দেখেছি:

1. উৎপাদন পরিবেশ, উন্নয়ন পরিবেশ ছাড়াও অন্যান্য পরিবেশ রয়েছে। যেমন, qa এবং preproduction। সেই সময়ে আমাদের অনেক সার্ভার এবং প্রায় 60টি পরিষেবা ছিল। এই কারণে এটি প্রয়োজনীয় ছিল প্রতিটি পরিষেবার জন্য, এটির জন্য সর্বশেষ সংস্করণ বজায় রাখুন ভার্চুয়াল মেশিন. অধিকন্তু, আপনি যদি লাইব্রেরি আপডেট করতে চান বা নতুন নির্ভরতা ইনস্টল করতে চান তবে আপনাকে এটি সমস্ত পরিবেশে করতে হবে। devops প্রয়োজনীয় এনভায়রনমেন্ট সেটিংস সম্পাদন করার সাথে সাথে আপনার অ্যাপ্লিকেশনের পরবর্তী নতুন সংস্করণ স্থাপন করার সময়টিও আপনাকে সিঙ্ক্রোনাইজ করতে হবে। এই ক্ষেত্রে, আমাদের পরিবেশ একবারে সমস্ত পরিবেশে কিছুটা আলাদা হবে এমন পরিস্থিতিতে প্রবেশ করা সহজ। উদাহরণস্বরূপ, একটি QA পরিবেশে লাইব্রেরির কিছু সংস্করণ থাকবে, এবং একটি উত্পাদন পরিবেশে বিভিন্ন সংস্করণ থাকবে, যা সমস্যার দিকে পরিচালিত করবে।
2. নির্ভরতা আপডেট করতে অসুবিধা আপনার আবেদন. এটা আপনার উপর নয়, অন্য দলের উপর নির্ভর করে। যথা, সার্ভার রক্ষণাবেক্ষণকারী ডেভপস দল থেকে। আপনি তাদের একটি উপযুক্ত কাজ এবং আপনি কি করতে চান একটি বিবরণ দিতে হবে।
3. সেই সময়ে, আমরা আমাদের কাছে থাকা বড় বড় মনোলিথগুলিকে আলাদা ছোট পরিষেবাগুলিতে ভাগ করতে চেয়েছিলাম, যেহেতু আমরা বুঝতে পেরেছিলাম যে সেগুলি আরও বেশি হবে৷ সেই সময়ে, আমাদের ইতিমধ্যে 100 টিরও বেশি ছিল। প্রতিটি নতুন পরিষেবার জন্য, একটি পৃথক নতুন ভার্চুয়াল মেশিন তৈরি করা প্রয়োজন ছিল, যা রক্ষণাবেক্ষণ এবং স্থাপন করা প্রয়োজন। এছাড়াও, আপনার একটি গাড়ি নয়, কমপক্ষে দুটি দরকার। এই সবের সাথে যুক্ত হয়েছে QA পরিবেশ। এটি সমস্যার সৃষ্টি করে এবং নতুন সিস্টেম তৈরি এবং চালানো আপনার জন্য আরও কঠিন করে তোলে। জটিল, ব্যয়বহুল এবং দীর্ঘ প্রক্রিয়া।

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

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

যাযাবরে যান

Nomad HashiCorp এর একটি পণ্য। তারা তাদের অন্যান্য সমাধানের জন্যও পরিচিত:

"কনসাল" পরিষেবা আবিষ্কারের জন্য একটি হাতিয়ার।

"টেরাফর্ম" - সার্ভার পরিচালনার জন্য একটি সিস্টেম যা আপনাকে কনফিগারেশনের মাধ্যমে কনফিগার করতে দেয়, তথাকথিত অবকাঠামো-এ-কোড।

"ভবঘুরে" আপনাকে নির্দিষ্ট কনফিগারেশন ফাইলের মাধ্যমে স্থানীয়ভাবে বা ক্লাউডে ভার্চুয়াল মেশিন স্থাপন করার অনুমতি দেয়।

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

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

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

যখন আমরা Nomad সম্পর্কে কথা বলি, তখন এটি HCL ভাষাকে তার তথ্য ফাইল বিন্যাস হিসাবে ব্যবহার করে, যার জন্য দাঁড়ায় HashiCorp কনফিগারেশন ভাষা. এটি ইয়ামলের একটি সুপারসেট যা আপনাকে যাযাবর পদে আপনার পরিষেবা বর্ণনা করতে দেয়।

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

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

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

যাইহোক, আমাদের কিছু সিস্টেম এক কপিতে নয়, কিন্তু একবারে বেশ কয়েকটিতে উৎপাদনে মোতায়েন করা হয়। অতএব, আমরা সিদ্ধান্ত নিয়েছি যে কনফিগারগুলিকে তাদের বিশুদ্ধ আকারে নয়, তাদের টেমপ্লেট করা ফর্মে সংরক্ষণ করা আমাদের পক্ষে সুবিধাজনক হবে। এবং আমরা বেছে নিয়েছি জিঞ্জা 2. এই বিন্যাসে, আমরা পরিষেবার কনফিগার এবং এর জন্য প্রয়োজনীয় env ফাইল উভয়ই সংরক্ষণ করি।

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

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

উদাহরণস্বরূপ, আপনি প্রাক-উৎপাদন এবং উৎপাদনে আপনার পরিষেবা স্থাপন করতে চান। ধরা যাক যে প্রি-প্রোডাকশনে আপনি ক্রোন স্ক্রিপ্ট চালাতে চান না, তবে এটি কাজ করছে কিনা তা নিশ্চিত করতে একটি পৃথক ডোমেনে পরিষেবাটি দেখতে চান। যে কেউ পরিষেবাটি স্থাপন করে, প্রক্রিয়াটি খুব সহজ এবং স্বচ্ছ দেখায়। আপনাকে যা করতে হবে তা হল deploy.sh ফাইলটি চালান, আপনি কোন পরিষেবাটি স্থাপন করতে চান এবং কোন টার্গেট করতে চান তা উল্লেখ করুন। উদাহরণস্বরূপ, আপনি রাশিয়া, বেলারুশ বা কাজাখস্তানে একটি নির্দিষ্ট সিস্টেম স্থাপন করতে চান। এটি করার জন্য, কেবলমাত্র একটি প্যারামিটার পরিবর্তন করুন এবং আপনার কাছে সঠিক কনফিগারেশন ফাইল থাকবে।

যখন নোম্যাড পরিষেবা ইতিমধ্যেই আপনার ক্লাস্টারে স্থাপন করা হয়, তখন এটি এরকম দেখায়।

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

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

মানব সম্পদের পরিপ্রেক্ষিতে রূপান্তরের জন্য আমাদের কত খরচ হয়েছে?

পুরো কোম্পানির যাযাবরে রূপান্তরিত হতে প্রায় 5-6 মাস সময় লেগেছিল। আমরা একটি পরিষেবা দ্বারা পরিষেবা ভিত্তিতে সরানো হয়েছে, কিন্তু একটি মোটামুটি দ্রুত গতিতে. প্রতিটি দলকে পরিষেবার জন্য তাদের নিজস্ব পাত্র তৈরি করতে হয়েছিল।

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

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

যাযাবর ত্যাগের কারণ

অন্যদের মধ্যে Nomad এবং docker ব্যবহার করে স্থাপনায় স্যুইচ করে আমরা কী সুবিধা পেয়েছি?

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

কিন্তু আমরা বেশ কিছু অসুবিধারও সম্মুখীন হয়েছি:

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

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

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

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

কুবারনেটসে রূপান্তর

আমি আপনাকে কুবারনেটসের মৌলিক ধারণাগুলি এবং কীভাবে তারা যাযাবর থেকে আলাদা তা সম্পর্কে কিছু বলব।

প্রথমত, কুবারনেটসের সবচেয়ে মৌলিক ধারণা হল পডের ধারণা। শুঁটি এক বা একাধিক পাত্রের একটি গ্রুপ যা সবসময় একসাথে চলে। এবং তারা সবসময় একটি ভার্চুয়াল মেশিনে কঠোরভাবে কাজ করে। তারা বিভিন্ন পোর্টে IP 127.0.0.1 এর মাধ্যমে একে অপরের কাছে অ্যাক্সেসযোগ্য।

ধরা যাক যে আপনার কাছে একটি PHP অ্যাপ্লিকেশন রয়েছে যা nginx এবং php-fpm নিয়ে গঠিত - ক্লাসিক স্কিম। সম্ভবত, আপনি সর্বদা nginx এবং php-fpm উভয় কন্টেইনার একসাথে রাখতে চাইবেন। কুবারনেটস আপনাকে একটি সাধারণ পড হিসাবে বর্ণনা করে এটি অর্জন করতে দেয়। যাযাবরদের সাথে আমরা ঠিক এটিই পেতে পারিনি।

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

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

আর চতুর্থ মৌলিক ধারণা হল প্রবেশ. এটি একটি পরিষেবা যা একটি Kubernetes ক্লাস্টারে চলে। এটি একটি বহিরাগত লোড ব্যালেন্সার হিসাবে কাজ করে যা সমস্ত অনুরোধ গ্রহণ করে। Kubernetes API ব্যবহার করে, Ingress এই অনুরোধগুলি কোথায় পাঠাতে হবে তা নির্ধারণ করতে পারে। তদুপরি, তিনি এটি খুব নমনীয়ভাবে করেন। আপনি বলতে পারেন যে এই হোস্টের সমস্ত অনুরোধ এবং এই জাতীয় ইউআরএল এই পরিষেবাতে পাঠানো হয়েছে৷ এবং এই হোস্ট এবং অন্য URL-এ আসা এই অনুরোধগুলি অন্য পরিষেবাতে পাঠানো হয়।

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

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

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

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

হেলমে মৌলিক ধারণা

হেলম প্যাকেজ ম্যানেজার কুবারনেটসের জন্য। এটি প্রোগ্রামিং ভাষায় প্যাকেজ ম্যানেজাররা কীভাবে কাজ করে তার সাথে খুব মিল। তারা আপনাকে এমন একটি পরিষেবা সঞ্চয় করার অনুমতি দেয় যার মধ্যে রয়েছে, উদাহরণস্বরূপ, ডিপ্লোয়মেন্ট nginx, ডিপ্লোয়মেন্ট php-fpm, config for Ingress, configmaps (এটি এমন একটি সত্তা যা আপনাকে আপনার সিস্টেমের জন্য env এবং অন্যান্য প্যারামিটার সেট করতে দেয়) so- আকারে। চার্ট বলা হয়। একই সঙ্গে হেলম কুবারনেটসের উপরে চলে. অর্থাৎ, এটি একপাশে দাঁড়িয়ে থাকা কোনও ধরণের সিস্টেম নয়, তবে কিউবের ভিতরে চালু করা আরেকটি পরিষেবা। আপনি একটি কনসোল কমান্ডের মাধ্যমে এর API এর মাধ্যমে এটির সাথে ইন্টারঅ্যাক্ট করেন। এর সুবিধা এবং সৌন্দর্য হল যে হেলম ভেঙে গেলেও বা আপনি এটিকে ক্লাস্টার থেকে সরিয়ে ফেললেও আপনার পরিষেবাগুলি অদৃশ্য হয়ে যাবে না, যেহেতু হেলম মূলত শুধুমাত্র সিস্টেম চালু করার জন্য কাজ করে। Kubernetes নিজেই তারপর কর্মক্ষমতা এবং পরিষেবার অবস্থার জন্য দায়ী।

আমরাও সেটা বুঝতে পেরেছি টেমপ্লেটিং, যা আমরা আগে আমাদের কনফিগারেশনে জিঞ্জা প্রবর্তন করে নিজেদের করতে বাধ্য হয়েছিলাম, এটি হেলমের অন্যতম প্রধান বৈশিষ্ট্য। আপনার সিস্টেমের জন্য আপনি যে সমস্ত কনফিগার তৈরি করেন সেগুলি হেলমে টেমপ্লেট আকারে সংরক্ষণ করা হয়, জিঞ্জার মতো কিছুটা মিল, কিন্তু প্রকৃতপক্ষে, গো ভাষার টেমপ্লেটিং ব্যবহার করে, যেখানে হেলম লেখা হয়, যেমন কুবারনেটেস।

হেলম আমাদের জন্য আরও কয়েকটি ধারণা যোগ করে।

তালিকা - এটি আপনার পরিষেবার একটি বিবরণ। অন্যান্য প্যাকেজ পরিচালকদের মধ্যে এটি একটি প্যাকেজ, বান্ডিল বা অনুরূপ কিছু বলা হবে। এখানে এটা চার্ট বলা হয়.

মানগুলি আপনি টেমপ্লেট থেকে আপনার কনফিগার তৈরি করতে ব্যবহার করতে চান যে ভেরিয়েবল হয়.

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

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

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

এই আমাদের কি দিয়েছে?

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

যেহেতু আমাদের কেবল উত্পাদনই নয়, অন্যান্য পরিবেশও রয়েছে, তাই এই বিচ্ছেদের জন্য ধন্যবাদ আমরা আমাদের হেলম চার্টগুলিকে শুধুমাত্র উৎপাদনে নয়, উদাহরণস্বরূপ, একটি QA পরিবেশেও পরিষেবাগুলি স্থাপন করতে পুনরায় ব্যবহার করতে পারি। এমনকি তাদের ব্যবহার করে স্থানীয়ভাবে স্থাপন করা মিনিক्यूब - এটি স্থানীয়ভাবে কুবারনেটস চালানোর জন্য একটি জিনিস।

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

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

তথ্যও

কুবারনেটস পরিষেবা যাযাবরের চেয়ে আরও জটিল বলে মনে হচ্ছে।

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

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

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

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

উত্স: www.habr.com