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

আমরা fintech কোম্পানি Exness থেকে এসেছি, যেটি B2B এবং B2C-এর জন্য অনলাইন ট্রেডিং এবং ফিনটেক পণ্যগুলির জন্য পরিষেবাগুলি বিকাশ করে৷ আমাদের R&D-এর বিভিন্ন দল রয়েছে, উন্নয়ন বিভাগে 100+ কর্মী রয়েছে।

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

আমাদের প্রেরণা

কি জ্বলছে? কেউ উত্তর দিতে পারে না। চুলা কোথায়? এটা বোঝা কঠিন। কখন আগুন লেগেছে? আপনি খুঁজে পেতে পারেন, কিন্তু অবিলম্বে না. 

কেন কিছু পাত্র দাঁড়িয়ে আছে যখন অন্য পড়ে আছে? কোন ধারক দোষ ছিল? সর্বোপরি, পাত্রগুলির বাইরের দিকগুলি একই, তবে প্রতিটির ভিতরে নিজস্ব নিও রয়েছে।

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

এজেন্টস

ভিতরে কী ঘটছে তা বোঝার জন্য, আমরা এজেন্টদের সরাসরি পাত্রে রাখার সিদ্ধান্ত নিয়েছি।

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

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

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

অবশেষে, এজেন্টদের অবশ্যই সাধারণ CI/CD সমর্থন করতে হবে যাতে ডকার ফাইলগুলি অন্তর্ভুক্ত থাকে। অন্যথায়, জাহাজটি ভেঙ্গে পড়বে, কারণ পাত্রে "বাঁকা" রেলপথে বিতরণ করা শুরু হবে।

বিল্ড প্রক্রিয়া এবং লক্ষ্য ইমেজ ডিভাইস

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

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

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

এই পদ্ধতির সম্পর্কে ভাল কি? 

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

অন্য কথায়, আমরা একটি নিয়ন্ত্রিত এবং নমনীয় সমাবেশ প্রক্রিয়া অর্জন করেছি। আমরা যেকোন সম্পূর্ণ সংস্করণের পাত্র তৈরি করতে একই সরঞ্জাম ব্যবহার করি। 

আমাদের বিল্ড পদ্ধতি কিভাবে কাজ করে

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

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

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

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

 

একই পাত্রের জন্য আমরা ডকার এবং কুবারনেটসে বিভিন্ন প্রক্রিয়া গাছ পাই:

পেলোড S6 এর তত্ত্বাবধানে সম্পাদিত হয়। সংগ্রাহক এবং ইভেন্টগুলিতে মনোযোগ দিন - এগুলি লগ এবং মেট্রিক্সের জন্য দায়ী আমাদের এজেন্ট। কুবারনেটসের কাছে সেগুলি নেই, তবে ডকারের আছে। কেন? 

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

মেট্রিক্স এবং লগ

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

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

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

এবং শেষ দিক হল সম্পদ খরচ কমিয়ে আনা।

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

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

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

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

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

• লগগুলি গ্রেলগে পাওয়া যায় (ভিজ্যুয়াল বিশ্লেষণের জন্য);
• লগ, মেট্রিক্স, ইভেন্টগুলি দীর্ঘমেয়াদী স্টোরেজের জন্য ক্লিকহাউসে পাঠানো হয়।

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

আমাদের যদি পড সহ কুবারনেটস না থাকে তবে স্কিমটি একটু বেশি জটিল, তবে এটি একই নীতিতে কাজ করে।

একই প্রক্রিয়াগুলি পাত্রের ভিতরে সম্পাদিত হয়, সেগুলি S6 ব্যবহার করে সাজানো হয়। একই পাত্রের ভিতরে সমস্ত একই প্রক্রিয়া চলছে।

ফলস্বরূপ,

আমরা লগ এবং মেট্রিক্স সংগ্রহ এবং বিতরণের বিকল্পগুলির সাথে ছবি তৈরি এবং চালু করার জন্য একটি সম্পূর্ণ সমাধান তৈরি করেছি:

• আমরা চিত্রগুলি একত্রিত করার জন্য একটি প্রমিত পদ্ধতির বিকাশ করেছি এবং এর উপর ভিত্তি করে আমরা CI টেমপ্লেট তৈরি করেছি;
• ডেটা সংগ্রহের এজেন্ট হল আমাদের টেলিগ্রাফ এক্সটেনশন। আমরা তাদের উত্পাদন ভাল পরীক্ষা;
• আমরা মিউটেশন ওয়েবহুক ব্যবহার করি পডের মধ্যে এজেন্ট সহ পাত্রে প্রয়োগ করতে; 
• Kubernetes/Rancher ইকোসিস্টেমে একীভূত;
• আমরা একই পাত্রে বিভিন্ন অর্কেস্ট্রেশন সিস্টেমে চালাতে পারি এবং আমরা আশা করি ফলাফল পেতে পারি;
• একটি সম্পূর্ণ ডাইনামিক কন্টেইনার ম্যানেজমেন্ট কনফিগারেশন তৈরি করা হয়েছে। 

সহ-লেখক: ইলিয়া প্রুডনিকভ

উত্স: www.habr.com