ক্লাউড-নেটিভ অ্যাপ তৈরির জন্য 5টি সাধারণ জ্ঞানের নীতি

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

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

সফটওয়্যার ডিজাইনের নীতিমালা

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

• চুম্বন (এটি সহজ, বোকা রাখুন) - এটিকে জটিল করবেন না;
• শুকনো (নিজেকে পুনরাবৃত্তি করবেন না) - নিজেকে পুনরাবৃত্তি করবেন না;
• YAGNI (আপনার এটির প্রয়োজন নেই) - এমন কিছু তৈরি করবেন না যা অবিলম্বে প্রয়োজন হয় না;
• SoC উদ্বেগের বিচ্ছেদ - দায়িত্ব ভাগ করুন।

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

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

ক্লাউড-নেটিভ কন্টেনার: রেড হ্যাট পদ্ধতি

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

একক উদ্বেগ নীতি (SCP)

এই নীতিটি অনেক উপায়ে একক দায়িত্ব নীতির অনুরূপ। SRP), যা SOLID সেটের অংশ এবং বলে যে প্রতিটি বস্তুর একটি দায়িত্ব থাকতে হবে এবং সেই দায়িত্বটি অবশ্যই একটি শ্রেণিতে সম্পূর্ণরূপে অন্তর্ভুক্ত করা উচিত। SRP-এর বিষয় হল প্রতিটি দায়িত্ব পরিবর্তনের একটি কারণ, এবং একটি শ্রেণির পরিবর্তনের জন্য একটি এবং একমাত্র কারণ থাকতে হবে।

SCP-তে, OOP ক্লাসের তুলনায় একটি কন্টেইনারের উচ্চ স্তরের বিমূর্ততা এবং বৃহত্তর উদ্দেশ্য নির্দেশ করতে আমরা "দায়িত্ব" শব্দের পরিবর্তে "উদ্বেগ" শব্দটি ব্যবহার করি। এবং যদি SRP-এর লক্ষ্য পরিবর্তনের জন্য শুধুমাত্র একটি কারণ থাকে, তাহলে SCP এর পিছনে কন্টেইনারগুলি পুনঃব্যবহার এবং প্রতিস্থাপন করার ক্ষমতা প্রসারিত করার ইচ্ছা। SRP অনুসরণ করে এবং একটি ধারক তৈরি করে যা একটি একক সমস্যার সমাধান করে এবং এটি একটি কার্যকরীভাবে সম্পূর্ণ উপায়ে করে, আপনি বিভিন্ন অ্যাপ্লিকেশন প্রসঙ্গে সেই কন্টেইনার চিত্রটি পুনরায় ব্যবহার করার সম্ভাবনা বাড়ান।

এসসিপি নীতি বলে যে প্রতিটি পাত্রে একটি একক সমস্যা সমাধান করা উচিত এবং এটি ভালভাবে করা উচিত। অধিকন্তু, কন্টেইনার ওয়ার্ল্ডে SCP অর্জন করা OOP বিশ্বে SRP থেকে সহজ, যেহেতু কন্টেইনারগুলি সাধারণত একটি একক প্রক্রিয়া চালায় এবং বেশিরভাগ সময় এই প্রক্রিয়াটি একটি একক কাজ সমাধান করে।

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

উচ্চ পর্যবেক্ষণের নীতি (HOP)

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

অনুশীলনে, একটি কন্টেইনারাইজড অ্যাপ্লিকেশনে, ন্যূনতম, বিভিন্ন ধরণের স্বাস্থ্য পরীক্ষার জন্য একটি API থাকা উচিত: সজীবতা পরীক্ষা এবং প্রস্তুতি পরীক্ষা। যদি একটি অ্যাপ্লিকেশন আরও কিছু করার দাবি করে, তবে এটি অবশ্যই তার অবস্থা পর্যবেক্ষণের অন্যান্য উপায় সরবরাহ করবে। উদাহরণস্বরূপ, Fluentd, Logstash এবং অন্যান্য অনুরূপ সরঞ্জাম ব্যবহার করে লগ একত্রিতকরণের জন্য STDERR এবং STDOUT এর মাধ্যমে গুরুত্বপূর্ণ ইভেন্টগুলি লগ করা। পাশাপাশি ট্রেসিং এবং মেট্রিক্স সংগ্রহের লাইব্রেরির সাথে একীকরণ, যেমন ওপেনট্রেসিং, প্রমিথিউস ইত্যাদি।

সাধারণভাবে, অ্যাপ্লিকেশনটিকে এখনও একটি ব্ল্যাক বক্স হিসাবে বিবেচনা করা যেতে পারে, তবে এটিকে সর্বোত্তম সম্ভাব্য উপায়ে নিরীক্ষণ এবং পরিচালনা করার জন্য প্ল্যাটফর্মের প্রয়োজনীয় সমস্ত API প্রদান করতে হবে।

লাইফ-সাইকেল কনফরমেন্স প্রিন্সিপল (LCP)

LCP হল HOP-এর বিরোধী। যদিও HOP বলে যে কন্টেইনারকে অবশ্যই প্ল্যাটফর্মে রিড API গুলি প্রকাশ করতে হবে, LCP-এর জন্য অ্যাপ্লিকেশনটি প্ল্যাটফর্ম থেকে তথ্য গ্রহণ করতে সক্ষম হওয়া প্রয়োজন। তদুপরি, ধারকটি কেবল ইভেন্টগুলি গ্রহণ করবে না, তবে অন্য কথায়, তাদের প্রতিক্রিয়াও মানিয়ে নিতে হবে। অত:পর নীতির নাম, যেটিকে API লেখার জন্য প্ল্যাটফর্ম প্রদানের প্রয়োজনীয়তা হিসেবে বিবেচনা করা যেতে পারে।

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

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

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

চিত্র অপরিবর্তনীয়তা নীতি (IIP)

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

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

প্রসেস ডিসপোজেবিলিটি প্রিন্সিপল (PDP)

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

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

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

স্ব-নিয়ন্ত্রণ নীতি (S-CP)

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

ব্যতিক্রমগুলি কনফিগারেশনের জন্য তৈরি করা হয় যা পরিবেশ থেকে পরিবেশে পরিবর্তিত হয় এবং রানটাইমে প্রদান করা আবশ্যক, উদাহরণস্বরূপ একটি Kubernetes ConfigMap এর মাধ্যমে।

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

রানটাইম কনফাইনমেন্ট প্রিন্সিপল (RCP)

S-CP নীতিটি সংজ্ঞায়িত করে কিভাবে ধারকটি তৈরি করা উচিত এবং চিত্র বাইনারিতে কী থাকা উচিত। তবে একটি ধারক কেবল একটি "ব্ল্যাক বক্স" নয় যার কেবল একটি বৈশিষ্ট্য রয়েছে - ফাইলের আকার। কার্যকর করার সময়, ধারকটি অন্যান্য মাত্রা গ্রহণ করে: ব্যবহৃত মেমরির পরিমাণ, CPU সময় এবং অন্যান্য সিস্টেম সংস্থান।

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

কন্টেইনারের সম্পদের প্রয়োজনীয়তা পূরণের পাশাপাশি, অ্যাপ্লিকেশনটির নিজস্ব সীমানা অতিক্রম না করাও গুরুত্বপূর্ণ। অন্যথায়, যখন সম্পদের ঘাটতি দেখা দেয়, প্ল্যাটফর্মটি এটিকে বাতিল বা স্থানান্তরিত করা প্রয়োজন এমন অ্যাপ্লিকেশনগুলির তালিকায় অন্তর্ভুক্ত করার সম্ভাবনা বেশি থাকে।

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

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

• চিত্রের আকার কমানোর চেষ্টা করুন: অস্থায়ী ফাইলগুলি মুছুন এবং অপ্রয়োজনীয় প্যাকেজগুলি ইনস্টল করবেন না - কন্টেইনারের আকার যত ছোট হবে, তত দ্রুত এটি একত্রিত হবে এবং নেটওয়ার্কের লক্ষ্য হোস্টে অনুলিপি করা হবে।
• নির্বিচারে ব্যবহারকারী-আইডিগুলিতে ফোকাস করুন: আপনার কন্টেইনারগুলি চালু করতে sudo কমান্ড বা কোনো বিশেষ userid ব্যবহার করবেন না।
• গুরুত্বপূর্ণ পোর্টগুলি চিহ্নিত করুন: আপনি রানটাইমে পোর্ট নম্বর সেট করতে পারেন, তবে EXPOSE কমান্ড ব্যবহার করে সেগুলি নির্দিষ্ট করা ভাল - এটি অন্যান্য ব্যক্তি এবং প্রোগ্রামগুলির জন্য আপনার ছবিগুলি ব্যবহার করা সহজ করে তুলবে৷
• ভলিউমগুলিতে ক্রমাগত ডেটা সংরক্ষণ করুন: কন্টেইনার ধ্বংস হওয়ার পরে যে ডেটা থাকা উচিত তা ভলিউমে লেখা উচিত।
• চিত্রের মেটাডেটা লিখুন: ট্যাগ, লেবেল এবং টীকা ছবিগুলিকে ব্যবহার করা সহজ করে তোলে - অন্যান্য বিকাশকারীরা আপনাকে ধন্যবাদ জানাবে৷
• হোস্ট এবং ইমেজ সিঙ্ক্রোনাইজ করুন: কিছু কন্টেইনারাইজড অ্যাপ্লিকেশানের জন্য কন্টেইনারকে হোস্টের সাথে নির্দিষ্ট বৈশিষ্ট্যে সিঙ্ক করতে হয়, যেমন সময় বা মেশিন আইডি।
• উপসংহারে, আমরা টেমপ্লেট এবং সর্বোত্তম অনুশীলনগুলি ভাগ করি যা আপনাকে উপরে তালিকাভুক্ত নীতিগুলি আরও কার্যকরভাবে বাস্তবায়নে সহায়তা করবে:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

ওপেনশিফট কন্টেইনার প্ল্যাটফর্মের নতুন সংস্করণে ওয়েবিনার - 4
11 জুন 11.00 এ

আপনি কি শিখবেন:

• অপরিবর্তনীয় Red Hat Enterprise Linux CoreOS
• ওপেনশিফট সার্ভিস মেশ
• অপারেটর ফ্রেমওয়ার্ক
• Knative কাঠামো

উত্স: www.habr.com