নতুন এয়ারলাইনে। একজন স্টুয়ার্ডেস যাত্রীদের কেবিনে প্রবেশ করেন: "আপনি আমাদের নতুন এয়ারলাইনে আছেন। বিমানের নাকে, আমাদের একটি সিনেমা হল আছে। লেজের অংশে - স্লট মেশিনের একটি হল। নীচের ডেকে - একটি সুইমিং পুল। উপরের ডেক - একটি sauna এখন, ভদ্রলোক, আপনার সিটবেল্ট বেঁধে দিন, এবং এই সমস্ত অপ্রয়োজনীয় জিনিস দিয়ে, আমরা খুলে ফেলার চেষ্টা করব। হাই, আমার নাম আন্দ্রি। আমি আমার জীবনের বেশিরভাগ সময় আইটি শিল্পে কাজ করেছি। আমি অবকাঠামো কনফিগারেশন ম্যানেজমেন্ট ইঞ্জিনিয়ারিংয়ের বিবর্তনে খুব আগ্রহী। গত 8 বছর ধরে, আমি এ জড়িত ছিলাম। DevOps- নতুন জনপ্রিয় প্রবণতাগুলির মধ্যে একটি হল এর ধারণা, 2017 সালে Weaveworks-এর সিইও অ্যালেক্সিস রিচার্ডসন প্রবর্তন করেছিলেন। Weaveworks হল একটি বড় প্রাপ্তবয়স্ক কোম্পানি যেটি, 2020 সালে, তার GitOps বিকাশের জন্য 36 মিলিয়নের বেশি বিনিয়োগ সংগ্রহ করেছে। GitOps- আমার আগের নিবন্ধে নিয়ে আলোচনা করেছে। এখন, আমি এই ধারণাটি গ্রহণ করার সময় আপনার জন্য অপেক্ষা করতে পারে এমন অ-স্পষ্ট চ্যালেঞ্জগুলি সম্পর্কে কথা বলার চেষ্টা করতে যাচ্ছি। সংক্ষেপে, GitOps একটি "সিলভার বুলেট" নয়। আপনি সম্ভবত অনেক জটিল সমাধানের সাথে পুনর্গঠন শেষ করবেন। আমি নিজে এই রাস্তায় নেমেছি এবং আপনাকে সবচেয়ে হতাশাজনক সমস্যাগুলি দেখাতে চাই যা আপনি GitOps সম্পর্কে অন্যান্য নিবন্ধ পড়ার সময় দেখতে পান না। আমরা কীভাবে ইলাস্টিক স্ট্যাক থেকে গ্রাফনাতে স্যুইচ করেছি সে সম্পর্কে একটি খরচ-কাটা সাফল্যের গল্প বিষয়বস্তু ওভারভিউ GitOps কি এবং কেন আপনার (না) এটি প্রয়োজন স্নোফ্লেক সার্ভার ইস্যু গিটঅপস - আপনার সমস্ত সমস্যার জন্য একটি প্যানাসিয়া (বা না) হেলমের সাথে ফ্লাক্স ব্যবহার করার যুক্তি কাস্টম ফ্লাক্স সম্পদ GitOps জন্য চেকলিস্ট সত্য ধারণার একক উৎসের লঙ্ঘন ছোট উপসংহার GitOps কি এবং কেন আপনার এটির প্রয়োজন নেই এর ডান মধ্যে ডুব দেওয়া যাক! রাষ্ট্রহীন এবং রাষ্ট্রীয় অবকাঠামো নির্মাণের সবচেয়ে প্রতিশ্রুতিশীল ধারণাটি হল অপরিবর্তনীয় অবকাঠামো। এর মূল ধারণা হল অবকাঠামোকে 2টি মৌলিকভাবে বিভিন্ন অংশে বিভক্ত করা: রাষ্ট্রহীন এবং রাষ্ট্রীয়। অবকাঠামোর রাষ্ট্রহীন অংশ অপরিবর্তনীয় এবং ক্ষমতাহীন। এটি স্টেট জমা করে না (ডেটা সঞ্চয় করে না) বা সঞ্চিত অবস্থার উপর নির্ভর করে এর ক্রিয়াকলাপ পরিবর্তন করে। রাষ্ট্রহীন অংশের উদাহরণে কিছু মৌলিক শিল্পকর্ম, স্ক্রিপ্ট এবং সমাবেশ থাকতে পারে। একটি নিয়ম হিসাবে, আমি এগুলিকে ক্লাউড/ভার্চুয়ালাইজড পরিবেশে বেস ইমেজ থেকে তৈরি করি। এগুলি ভঙ্গুর এবং ক্ষণস্থায়ী: আমি নতুন বেস ইমেজগুলি থেকে দৃষ্টান্তগুলি পুনরায় তৈরি করে অ্যাপ্লিকেশনগুলির নতুন সংস্করণ সরবরাহ করি। স্থায়ী তথ্য রাষ্ট্রীয় অংশে সংরক্ষণ করা হয়. এটি ডেডিকেটেড সার্ভারের সাথে বা কিছু ক্লাউড মেকানিজম (DBaaS, অবজেক্ট বা ব্লক স্টোরেজ) সহ ক্লাসিক্যাল স্কিম দ্বারা উপলব্ধি করা যেতে পারে। এই "চিড়িয়াখানা"কে পরিচালনাযোগ্য করে তুলতে এবং সঠিকভাবে কাজ করতে, আমাদের ইঞ্জিনিয়ারিং এবং DevOps টিমের পাশাপাশি সম্পূর্ণ স্বয়ংক্রিয় বিতরণ পাইপলাইনের মধ্যে সহযোগিতা প্রয়োজন। সিআই অংশ চরম প্রোগ্রামিং একটি চটপটে বিকাশের পদ্ধতিগুলির মধ্যে একটি। এটি অনেক ফিডব্যাক লুপ দ্বারা আলাদা করা হয়, যা আপনাকে ক্লায়েন্টের প্রয়োজনের সাথে সিঙ্ক্রোনাইজেশন বজায় রাখতে দেয়। আমরা CI/CD সিস্টেম ব্যবহার করে ডেলিভারি পাইপলাইনের অটোমেশন বাস্তবায়ন করি। CI (কন্টিনিউয়াস ইন্টিগ্রেশন) শব্দটি 1994 সালে গ্র্যাডি বুচ দ্বারা অফার করা হয়েছিল এবং 1997 সালে কেন্ট বেক এবং রন জেফ্রিস এটিকে চরম প্রোগ্রামিংয়ের শৃঙ্খলায় প্রবর্তন করেছিলেন। CI-তে, আমাদের প্রকল্পের প্রধান কার্য শাখায় যতবার সম্ভব আমাদের পরিবর্তনগুলিকে সংহত করতে হবে। এর জন্য প্রথমত, কাজগুলির আরও দানাদার পচন প্রয়োজন: ছোট পরিবর্তনগুলি আরও পারমাণবিক এবং ট্র্যাক করা, বোঝা এবং একীভূত করা সহজ। দ্বিতীয়ত, আমরা শুধু নতুন করে লিখিত কোড একত্র করতে পারি না। শাখাগুলিকে একত্রিত করার আগে, আমাদের অবশ্যই নিশ্চিত করতে হবে যে আগে কাজ করে এমন কিছুই ভাঙা হয়নি। এটি করার জন্য, অ্যাপ্লিকেশনটি অন্তত তৈরি করা উচিত। পরীক্ষার সাথে কোডটি কভার করাও একটি ভাল ধারণা। এবং এটি সিআই সিস্টেম দ্বারা সম্পাদিত কাজ, যা উন্নয়নে অনেক দূর এগিয়ে গেছে এবং এই পথের মাঝখানে কোথাও সিআই/সিডি সিস্টেমে পরিণত হয়েছে। সিডি অংশ সিডি কি? : মার্টিন ফাউলার 2টি সিডি সংজ্ঞা আলাদা করেছেন ক্রমাগত ডেলিভারি। এটি হল যখন, ক্রমাগত একীকরণ অনুশীলন এবং DevOps সংস্কৃতির সাহায্যে, আপনি আপনার প্রকল্পের প্রধান শাখাকে ক্রমাগত উৎপাদনে নিয়োজিত করার জন্য প্রস্তুত রাখেন। ক্রমাগত স্থাপনা। এটি ক্রমাগত বিতরণ যেখানে মূল শাখায় যা কিছু যায় তা আপনার ক্লাস্টারে, আপনার উত্পাদনে ডাম্প করা হয়। আরো এগিয়ে যাক. স্নোফ্লেক সার্ভার সমস্যা দুর্ভাগ্যবশত, অপরিবর্তনীয় অবকাঠামোর বেশ কিছু সমস্যা রয়েছে। তাদের মধ্যে সিংহের অংশটি কোড (IaC) হিসাবে অবকাঠামোর ধারণা থেকে উত্তরাধিকারসূত্রে প্রাপ্ত। প্রথমত, এটি কনফিগারেশন ড্রিফট। এই শব্দটি পাপেট ল্যাবস (সুপরিচিত পাপেট এসসিএম-এর লেখক) এ জন্মেছিল এবং বলে যে টার্গেট সিস্টেমে সমস্ত পরিবর্তন সিস্টেম কনফিগারেশন ম্যানেজমেন্ট (এসসিএম) এর সাহায্যে করা হয় না। কিছু ম্যানুয়ালি করা হয়, তাদের বাইপাস. এই ধরনের একাধিক পরিবর্তনের প্রক্রিয়ায়, কনফিগারেশন ড্রিফট প্রদর্শিত হয় - SCM-এ বর্ণিত কনফিগারেশন এবং বাস্তব অবস্থার মধ্যে পার্থক্য। এটি একটি অটোমেশন ভয় সর্পিল বাড়ে. যত বেশি ম্যানুয়াল পরিবর্তন করা হবে, একটি SCM স্ক্রিপ্ট চালানোর ফলে রেকর্ড না করা পরিবর্তনগুলি ভাঙার সম্ভাবনা তত বেশি। এটি চালানোর জন্য যত ভয়ঙ্কর হবে, তত বেশি নতুন ম্যানুয়াল সম্পাদনা করা হবে। অবশেষে, এই দুষ্ট ইতিবাচক প্রতিক্রিয়া স্নোফ্লেক সার্ভারগুলির গঠনের দিকে নিয়ে যায়, যা এতটাই অসামঞ্জস্যপূর্ণ হয়ে উঠেছে যে কেউ বুঝতে পারে না ভিতরে কী আছে। ম্যানুয়াল সম্পাদনা করার পরে, নোডটি তুষারপাতের প্রতিটি পৃথক স্নোফ্লেকের মতো অনন্য হয়ে ওঠে। এই ড্রিফ্ট সার্ভারগুলিকে অপরিবর্তনীয় পরিকাঠামোর মধ্যে উচ্চ স্তরে ছেড়ে দেয়: এখন আমরা GCP প্রকল্প/AWS VPC/Kubernetes-cluster-snowflakes সম্পর্কে কথা বলতে পারি। এটি ঘটে কারণ পরিবর্তনের বাস্তবায়ন অপরিবর্তনীয় অবকাঠামোতে নিয়ন্ত্রিত হয় না। তাছাড়া, কেউ জানে না কিভাবে এটি সঠিকভাবে করতে হয়। GitOps - আপনার সমস্ত সমস্যার (বা না) জন্য একটি প্যানেসিয়া এবং তারপরে উইভওয়ার্কস আসে এবং বলে, "বন্ধুরা, আপনার যা দরকার তা আমাদের কাছে আছে - গিটঅপস"। GitOps প্রচার করার জন্য, তারা কেলসি হাইটাওয়ারের মতো একজন হেভিওয়েট নিয়ে এসেছে, যিনি তৈরি করেছেন। তার PR চলাকালীন, তিনি ব্যাপকভাবে বার্তা সম্প্রচার করেন, "মানুষ হও, বি...! স্ক্রিপ্টিং বন্ধ করুন এবং শিপিং শুরু করুন।" এবং তিনি একটি নির্দিষ্ট পরিমাণ বিপণন বাজে কথা বলেন। "কুবারনেটস দ্য হার্ড ওয়ে" গাইড আমার মতে, সবচেয়ে উত্তেজনাপূর্ণ সুবিধা ছিল: উন্নত ধারাবাহিকতা এবং স্থাপনার মানকরণ উন্নত নিরাপত্তা নিশ্চয়তা ত্রুটি থেকে সহজ এবং দ্রুত পুনরুদ্ধার অ্যাক্সেস এবং গোপনীয়তার সহজ ব্যবস্থাপনা স্ব-ডকুমেন্টিং স্থাপন দলের মধ্যে জ্ঞান বিতরণ এবং যে কেউ এই পাঠ্যপুস্তকের স্লাইড জুড়ে GitOps কী তা বের করার চেষ্টা করছে। এর পরে, আমরা GitOps নীতিগুলি খুঁজে পাই, যা সামান্য বর্ধিত IaC নীতিগুলির সাথে সাদৃশ্যপূর্ণ: GitOps ঘোষণামূলক GitOps অ্যাপগুলি সংস্করণযুক্ত এবং অপরিবর্তনীয় GitOps অ্যাপগুলি স্বয়ংক্রিয়ভাবে টানা হয় GitOps অ্যাপগুলি ক্রমাগত মিলিত হয় তবুও, এটি একটি শূন্যস্থানে একটি গোলাকার বর্ণনা, তাই আমরা আমাদের গবেষণা চালিয়ে যাচ্ছি। আমরা GitOps.tech ওয়েবসাইটটি খুঁজে পাই এবং এতে বেশ কয়েকটি গুরুত্বপূর্ণ স্পষ্টীকরণ রয়েছে। প্রথমত, আমরা শিখি যে GitOps হল একটি পরিকাঠামো-সদৃশ কোড CD টুলিং সহ গিট যা স্বয়ংক্রিয়ভাবে পরিকাঠামোতে এটি প্রয়োগ করে। আমাদের GitOps-এর মধ্যে কমপক্ষে 2টি সংগ্রহস্থল থাকতে হবে: অ্যাপ্লিকেশন ভান্ডার। এটি অ্যাপ্লিকেশন সোর্স কোড বর্ণনা করে এবং সেই অ্যাপ্লিকেশনটির স্থাপনার বর্ণনা দেয়। অবকাঠামো ভান্ডার। এটি অবকাঠামো প্রকাশ এবং স্থাপনার পরিবেশ বর্ণনা করে। এছাড়াও, GitOps মতাদর্শে, একটি পুশ-ভিত্তিক পদ্ধতির চেয়ে একটি পুল-ভিত্তিক পদ্ধতিকে অগ্রাধিকার দেওয়া হয়। এটি হেভিওয়েট পুল দানব পাপেট এবং শেফ থেকে লাইটওয়েট পুশ-ভিত্তিক অ্যানসিবল এবং টেরাফর্মে SCM সিস্টেমের বিবর্তনের কিছুটা বিপরীত। এবং যদি GitOps প্রাথমিকভাবে একটি টুলকিট গল্প হয়, তাহলে ওয়েভওয়ার্কস থেকে ফ্লাক্স-ভিত্তিক ধারণা নেওয়া এবং এটিকে ডিকনস্ট্রাক্ট করা অর্থপূর্ণ। ধারণাটির লেখক অবশ্যই একটি রেফারেন্স বাস্তবায়ন করেছেন। ফ্লাক্স এখন সংস্করণ 2 পর্যন্ত এবং স্থাপত্যগতভাবে এমন কন্ট্রোলার রয়েছে যা একটি ক্লাস্টারের মধ্যে কাজ করে: উৎস নিয়ন্ত্রক কাস্টমাইজ কন্ট্রোলার HELM কন্ট্রোলার বিজ্ঞপ্তি নিয়ামক ইমেজ অটোমেশন কন্ট্রোলার এর পরে, আসুন ফ্লাক্স এবং হেলমের সাথে কাজ নিয়ে আলোচনা করি। হেলমের সাথে ফ্লাক্স ব্যবহার করার যুক্তি আমি ফ্লাক্স 2 এ হেলম প্যাকেজ ম্যানেজার ব্যবহার করে একটি অ্যাপ্লিকেশন স্থাপনের উদাহরণটি আরও বর্ণনা করতে যাচ্ছি। কেন? অনুযায়ী, HELM প্যাকেজ ম্যানেজার ছিল সবচেয়ে জনপ্রিয় প্যাকেজিং অ্যাপ্লিকেশন, যার শেয়ার 50%-এর বেশি। CNCF সমীক্ষা 2021 দুর্ভাগ্যবশত, আমি আরও আপ-টু-ডেট ডেটা খুঁজে পাইনি, কিন্তু তারপর থেকে খুব বেশি কিছু পরিবর্তন হয়েছে বলে আমি মনে করি না। সুতরাং, আসুন ফ্লাক্স 2 হেলমের সাথে কীভাবে কাজ করে তার মূল যুক্তির মাধ্যমে চলুন। আমাদের 2টি সংগ্রহস্থল রয়েছে: অ্যাপ্লিকেশন এবং অবকাঠামো। আমরা অ্যাপ্লিকেশন সংগ্রহস্থল থেকে একটি HELM চার্ট এবং ডকার ইমেজ তৈরি করি এবং সেগুলিকে যথাক্রমে হেলম চার্ট সংগ্রহস্থল এবং ডকার রেজিস্ট্রিতে যোগ করি। এর পরে, আমাদের কাছে একটি কুবারনেটস ক্লাস্টার রয়েছে যা ফ্লাক্স কন্ট্রোলার চালায়। আমাদের অ্যাপ্লিকেশন রোল আউট করার জন্য, আমরা কাস্টম রিসোর্স (CR) HelmRelease বর্ণনা করে একটি YAML প্রস্তুত করি এবং এটিকে অবকাঠামো সংগ্রহস্থলে যোগ করি। ফ্লাক্স পেতে সাহায্য করার জন্য, আমরা Kubernetes ক্লাস্টারে একটি CR GitRepository তৈরি করি। সোর্স কন্ট্রোলার এটি দেখে, গিটে যায় এবং এটি ডাউনলোড করে। এই YAML একটি ক্লাস্টারে স্থাপন করতে, আমরা একটি কাস্টমাইজেশন সংস্থান বর্ণনা করি। Kustomize কন্ট্রোলার এটি দেখে, সোর্স কন্ট্রোলারে যায়, YAML পায় এবং ক্লাস্টারে স্থাপন করে। হেলম কন্ট্রোলার দেখেন যে একটি CR HelmRelease ক্লাস্টারে উপস্থিত হয়েছে এবং বর্ণনা করা HELM চার্ট পেতে সোর্স কন্ট্রোলারের কাছে যায়। সোর্স কন্ট্রোলারের জন্য HELM কন্ট্রোলারকে অনুরোধ করা চার্ট দেওয়ার জন্য, আমাদের অবশ্যই CR ক্লাস্টারে একটি HelmRepository তৈরি করতে হবে। হেলম-কন্ট্রোলার সোর্স-কন্ট্রোলার থেকে একটি চার্ট পায়, একটি রিলিজ তৈরি করে এবং এটি ক্লাস্টারে স্থাপন করে। তারপর Kubernetes প্রয়োজনীয় পড তৈরি করে, ডকার রেজিস্ট্রিতে যায় এবং সংশ্লিষ্ট ছবি ডাউনলোড করে। তদনুসারে, আমাদের অ্যাপ্লিকেশনটির একটি নতুন সংস্করণ তৈরি করতে, আমাদের একটি নতুন চিত্র, একটি নতুন হেলমরিলিজ ফাইল এবং সম্ভবত একটি নতুন HELM চার্ট তৈরি করতে হবে৷ তারপরে আমাদের অবশ্যই সেগুলিকে উপযুক্ত সংগ্রহস্থলে রাখতে হবে এবং উপরে বর্ণিত চেইনে ফ্লাক্স কন্ট্রোলারের কাজটি পুনরাবৃত্তি করার জন্য অপেক্ষা করতে হবে। এবং, আমাদের কাজ শেষ করার জন্য, আমরা কোথাও একটি নোটিফিকেশন কন্ট্রোলার রাখি যা আমাদেরকে কী ভুল হতে পারে তা জানিয়ে দেয়। কাস্টম ফ্লাক্স সম্পদ এখন আসুন কাস্টম রিসোর্স নিয়ে আলোচনা করা যাক যা ফ্লাক্স দিয়ে কাজ করে। প্রথমটি হল গিট সংগ্রহস্থল। এখানে আমরা গিট রিপোজিটরির ঠিকানা (লাইন 14) এবং এটি যে শাখাটি দেখায় (লাইন 10) তা নির্দিষ্ট করতে পারি। সুতরাং, আমরা শুধুমাত্র একটি একক শাখা ডাউনলোড করি, সম্পূর্ণ সংগ্রহস্থল নয়। কিন্তু! যেহেতু আমরা দায়িত্বশীল প্রকৌশলী এবং জিরো ট্রাস্ট ধারণাটি মেনে চলার চেষ্টা করি, তাই আমরা সংগ্রহস্থলে অ্যাক্সেস লক করি, কুবারনেটস ক্লাস্টারে একটি কী দিয়ে একটি গোপনীয়তা তৈরি করি এবং এটি ফ্লাক্সকে দিয়ে থাকি যাতে এটি সেখানে যেতে পারে (লাইন 12)। এরপরে কাস্টমাইজেশন। এখানে আমি আপনার দৃষ্টি আকর্ষণ করতে চাই যে Flux থেকে Kustomize কন্ট্রোলার এবং Kubernetes এর লেখকদের থেকে Kustomize দুটি ভিন্ন জিনিস। আমি জানি না কেন এই ধরনের বিভ্রান্তিকর নামকরণ বেছে নেওয়া হয়েছিল, তবে তাদের বিভ্রান্ত না করা গুরুত্বপূর্ণ। কাস্টমাইজেশন হল একটি গিট রিপোজিটরি থেকে একটি ক্লাস্টারে YAML (যেকোনো) স্থাপন করার একটি উপায়। এখানে আমাদের উৎস উল্লেখ করতে হবে যেখান থেকে আমরা এটি রেখেছি (লাইন 12 - উপরে বর্ণিত CR GitRepository-এর নাম), যে ডিরেক্টরি থেকে আমরা YAML গুলি নিয়েছি (লাইন 8), এবং আমরা টার্গেট নেমস্পেস নির্দিষ্ট করতে পারি যেখানে সেগুলি জমা করতে হবে। (লাইন 13)। পরবর্তী হেলম রিলিজ হয়. এখানে আমরা নাম এবং চার্ট সংস্করণ (লাইন 10,11) নির্দিষ্ট করতে পারি। এখানে আপনি পরিবর্তনশীল মান নির্দিষ্ট করুন যাতে হেলম পরিবেশ থেকে পরিবেশে প্রকাশকে কাস্টমাইজ করতে পারে (লাইন 15-19)। এটি একটি অত্যন্ত গুরুত্বপূর্ণ এবং প্রয়োজনীয় বৈশিষ্ট্য, কারণ আপনার পরিবেশ উল্লেখযোগ্যভাবে ভিন্ন হতে পারে। আপনি হেলম চার্ট (লাইন 12, 13, 14) নেওয়ার জন্য উত্সটিও উল্লেখ করুন। এই ক্ষেত্রে, এটি হেলম ভান্ডার। কিন্তু! যেহেতু আমরা এখনও দায়িত্বশীল প্রকৌশলী, তাই আমাদের কাছে হেলম রিপোজিটরিতেও ঘনিষ্ঠ অ্যাক্সেস রয়েছে এবং সেখানে যাওয়ার জন্য ফ্লাক্সকে একটি গোপনীয়তা দেয় (লাইন 7, 8)। GitOps জন্য চেকলিস্ট সুতরাং, আসুন একটু চেকলিস্ট করি যা আমরা এইমাত্র ধরে নিয়েছি। GitOps করা শুরু করার জন্য, আমাদের হঠাৎ করে একগুচ্ছ স্ক্রিপ্ট লিখতে হবে (আমরা মনে রাখি যে অপরিবর্তনীয় পরিকাঠামো সম্পূর্ণরূপে স্বয়ংক্রিয় বিতরণ পাইপলাইন সম্পর্কে)। তাই সবার আগে, আমাদের তৈরি করতে হবে: ডকার রেজিস্ট্রিতে ছবিগুলি তৈরি এবং পুশ করার জন্য স্ক্রিপ্ট ইনফ্রাস্ট্রাকচার গিট রিপোজিটরি পরিকাঠামো জিআইটি সংগ্রহস্থলে CI সিস্টেম অ্যাক্সেসের জন্য অ্যাকাউন্ট HelmRelease ফাইল তৈরি এবং পুশ করার জন্য স্ক্রিপ্ট হেলম রিপোজিটরি হেলম রিপোজিটরিতে CI সিস্টেম অ্যাক্সেসের জন্য অ্যাকাউন্ট হেলম চার্ট তৈরি এবং প্রকাশ করার জন্য স্ক্রিপ্ট` অবকাঠামো সংগ্রহস্থলের জন্য ফ্লাক্স অ্যাকাউন্ট হেলম চার্ট সংগ্রহস্থলের জন্য ফ্লাক্স অ্যাকাউন্ট দারুণ, এখন আপনার কাছে GitOps-এর জন্য একটি চেকলিস্ট আছে। চলো এগোই. সত্য ধারণার একক উৎসের লঙ্ঘন আসুন দেখি আমরা আমাদের হেলম রিলিজের সাথে সাধারণভাবে কী পাই। এটা বেশ স্পষ্ট যে গিট এই বিশেষ ক্ষেত্রে সত্যের একমাত্র উৎস হতে পারে না। আমাদের কাছে কমপক্ষে 2টি সংস্থান রয়েছে, গিটের বাইরে 2টি নিদর্শন রয়েছে, যার উপর এই হেলম রিলিজ নির্ভর করে: হেলম চার্ট (লাইন 8-14) ডকার ইমেজ (লাইন 19) এবং আমরা জিনিসগুলিকে আরও জটিল করতে পারি এবং হেলম চার্ট সংস্করণগুলির পরিসীমা নির্দিষ্ট করতে পারি। এই ক্ষেত্রে, ফ্লাক্স এই সীমার মধ্যে উপস্থিত নতুন হেলম চার্ট নিরীক্ষণ করবে এবং সেট করবে। উপরন্তু, আমাদের কাছে সোর্স কন্ট্রোলারটি S3 বান্ডিল সহ একটি উৎস হিসাবে YAML ব্যবহার করতে পারে। সেখান থেকে, আমরা YAML এবং Helm উভয় চার্ট রাখতে পারি। এছাড়াও, আমাদের কাছে ইমেজ অটোমেশন কন্ট্রোলার রয়েছে যা ডকার রেজিস্ট্রিতে নতুন ছবিগুলিতে নজর রাখতে পারে এবং অবকাঠামো সংগ্রহস্থল সম্পাদনা করতে পারে। কিন্তু আমরা HELM Chart repo-Ops বা Docker registry-Ops চাই না। আমরা যতটা সম্ভব GitOps হতে চাই। তাই আমরা ডকুমেন্টেশন দেখি এবং জিআইটি রিপোজিটরি থেকে আমাদের হেলম চার্ট স্থাপন করার প্রক্রিয়াগুলি সংশোধন করি (আমরা এটি সংরক্ষণ করার জন্য অ্যাপ্লিকেশন সংগ্রহস্থল বেছে নিই)। এটি আমাদের অ্যাপ্লিকেশন সংগ্রহস্থলের জন্য আরেকটি CR GitRepository তৈরি করতে বাধ্য করে, এটি অ্যাক্সেস করার জন্য Flux-এর জন্য একটি অ্যাকাউন্ট এবং কী দিয়ে একটি গোপনীয়তা তৈরি করে৷ একই সময়ে, আমরা কোনোভাবেই ডকার ইমেজের উপর জটিল নির্ভরতার সমস্যার সমাধান করি না। ছোট উপসংহার আমার মনে হয় আজকের জন্য এটাই যথেষ্ট। 2 ভাগে, আমি আপনাকে বলব এই নেকত্বের কী সমস্যা রয়েছে। আমি আলোচনা করব: একাধিক পরিবেশের সমস্যা থেকে মান গোপন সমস্যা CI Ops বনাম GitOps নিরাপত্তা রোলব্যাক পদ্ধতি একাধিক ক্লাস্টার সমস্যা কে সত্যিই GitOps প্রয়োজন? আমি এই নিবন্ধটি আপনার জন্য দরকারী ছিল আশা করি!
