OpenShift-এর জন্য GitOps-এর ভূমিকা

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

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

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

গিটঅপ্স-এর কোনো প্রাতিষ্ঠানিক সংজ্ঞা বা নির্দিষ্ট নিয়মকানুন নেই, আছে কেবল কিছু মূলনীতি যা এর অনুশীলনকে পরিচালিত করে:

• সিস্টেমের ঘোষণামূলক বিবরণ গিট রিপোজিটরিতে সংরক্ষিত থাকে (কনফিগারেশন, মনিটরিং, ইত্যাদি)।
• পুল রিকোয়েস্টের মাধ্যমে স্টেটের পরিবর্তন করা হয়।
• গিট পুশ রিকোয়েস্ট ব্যবহার করে চলমান সিস্টেমগুলোর অবস্থা রিপোজিটরির ডেটার সাথে সামঞ্জস্যপূর্ণ করা হয়।

গিটঅপস নীতি

• সিস্টেমের সংজ্ঞাগুলো সোর্স কোড হিসেবে বর্ণনা করা হয়।

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

• সিস্টেমের কাঙ্ক্ষিত অবস্থা ও কনফিগারেশন গিট-এ সংজ্ঞায়িত এবং ভার্সনভুক্ত করা হয়।

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

• পুল রিকোয়েস্ট ব্যবহার করে কনফিগারেশন পরিবর্তনগুলো স্বয়ংক্রিয়ভাবে প্রয়োগ করা যায়।

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

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

• অনিয়ন্ত্রিত কনফিগারেশন ড্রিফটের সমস্যা সমাধান করা

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

ওপেনশিফটের জন্য গিটঅপস মডেল

অন-ক্লাস্টার রিসোর্স রিকনসিলার

এই মডেল অনুসারে, ক্লাস্টারে একটি কন্ট্রোলার থাকে যা গিট রিপোজিটরিতে থাকা কুবারনেটিস রিসোর্স (YAML ফাইল)-এর সাথে প্রকৃত ক্লাস্টার রিসোর্স তুলনা করার দায়িত্বে থাকে। যদি কোনো অমিল ধরা পড়ে, কন্ট্রোলারটি নোটিফিকেশন পাঠায় এবং প্রয়োজনে তা সমাধানের জন্য ব্যবস্থা গ্রহণ করে। এই GitOps মডেলটি Anthos Config Management এবং Weaveworks Flux-এ ব্যবহৃত হয়।

বাহ্যিক সম্পদ সমন্বয়কারী (পুশ)

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

ওপেনশিফট প্ল্যাটফর্মে গিটঅপ্স

একাধিক ক্লাস্টার বিশিষ্ট কুবারনেটিস পরিকাঠামো পরিচালনা করা

Kubernetes-এর ব্যবহার বৃদ্ধি এবং মাল্টি-ক্লাউড কৌশল ও এজ কম্পিউটিং-এর জনপ্রিয়তা বাড়ার সাথে সাথে, গ্রাহকপ্রতি OpenShift ক্লাস্টারের গড় সংখ্যাও বাড়ছে।

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

একই সাথে, অনেক সমস্যার সমাধান করতে হবে, বিশেষ করে:

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

অ্যাপ্লিকেশন কনফিগারেশন

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

এক্ষেত্রে, নিম্নলিখিত কাজগুলো অবশ্যই সমাধান করতে হবে:

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

ওপেনশিফট গিটঅপ্স ব্যবহারের ক্ষেত্রসমূহ

১. গিট রিপোজিটরি থেকে পরিবর্তন প্রয়োগ করা

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

২. সিক্রেট ম্যানেজারের সাথে সিঙ্ক্রোনাইজেশন

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

৩. কনফিগারেশন ড্রিফট নিয়ন্ত্রণ

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

৪. কনফিগারেশন পরিবর্তনের বিজ্ঞপ্তি

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

৫. বিচ্যুতি ঘটলে কনফিগারেশনের ম্যানুয়াল সিঙ্ক্রোনাইজেশন

কনফিগারেশনে কোনো পরিবর্তন ঘটলে, অ্যাডমিনকে ওপেনশিফট ক্লাস্টারকে গিট রিপোজিটরির সাথে সিঙ্ক্রোনাইজ করার সুযোগ দেয়, যাতে ক্লাস্টারটিকে দ্রুত পূর্বের পরিচিত অবস্থায় ফিরিয়ে আনা যায়।

৬. ড্রিফটিং চলাকালীন কনফিগারেশনের স্বয়ংক্রিয় সিঙ্ক্রোনাইজেশন

অ্যাডমিন ওপেনশিফট ক্লাস্টারকে এমনভাবে কনফিগার করতে পারেন, যাতে কনফিগারেশনে কোনো পরিবর্তন (drift) শনাক্ত হলে এটি স্বয়ংক্রিয়ভাবে রিপোজিটরির সাথে সিঙ্ক হয়। এর ফলে ক্লাস্টারের কনফিগারেশন সবসময় গিট-এর কনফিগারেশনের সাথে মিলে যায়।

৭. একাধিক ক্লাস্টার – একটি রিপোজিটরি

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

৮. ক্লাস্টার কনফিগারেশনের ক্রমবিন্যাস (উত্তরাধিকার)

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

উদাহরণস্বরূপ, যদি কোনো অ্যাডমিন একটি গিট রিপোজিটরিতে এই ধরনের একটি স্তরবিন্যাস (হায়ারার্কি) নির্ধারণ করেন: "প্রোডাকশন ক্লাস্টার (prod) → সিস্টেম X ক্লাস্টার → সিস্টেম X প্রোডাকশন ক্লাস্টার", তাহলে সিস্টেম X-এর প্রোডাকশন ক্লাস্টারগুলোর জন্য নিম্নলিখিত কনফিগারেশনগুলো মার্জ করা হয়:

• সকল প্রোডাকশন ক্লাস্টারের জন্য সাধারণ কনফিগারেশন।
• এক্স সিস্টেম ক্লাস্টারের কনফিগারেশনসমূহ।
• এক্স সিস্টেমের প্রোডাকশন ক্লাস্টারের কনফিগারেশনসমূহ।

৯. টেমপ্লেট এবং কনফিগারেশন ওভাররাইড

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

১০. কনফিগারেশন, অ্যাপ্লিকেশন কনফিগারেশনের জন্য নির্বাচিত অন্তর্ভুক্তি এবং বর্জন

প্রশাসক নির্দিষ্ট বৈশিষ্ট্যসম্পন্ন ক্লাস্টারগুলিতে বিশেষ কনফিগারেশন প্রয়োগ করা হবে কি হবে না, তার জন্য শর্ত নির্ধারণ করতে পারেন।

১১. টেমপ্লেট সমর্থন

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

ওপেনশিফট প্ল্যাটফর্মে গিটঅপস টুলস

আর্গোসিডি

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

অফিসিয়াল ওয়েবসাইট

প্রবাহ

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

অফিসিয়াল ওয়েবসাইট

OpenShift-এ ArgoCD ইনস্টল করা

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

OpenShift 4 প্ল্যাটফর্মে ArgoCD স্থাপন করতে, ক্লাস্টার অ্যাডমিনিস্ট্রেটর হিসেবে নিম্নলিখিত ধাপগুলো সম্পন্ন করুন:

ওপেনশিফট প্ল্যাটফর্মে আর্গোসিডি কম্পোনেন্ট স্থাপন করা

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

OpenShift Route-এর কাছে দৃশ্যমান করার জন্য ArgoCD সার্ভার পরিবর্তন করা

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

ArgoCD Cli টুল স্থাপন করা

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

ArgoCD সার্ভার অ্যাডমিন পাসওয়ার্ড পরিবর্তন করা

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

এই ধাপগুলো সম্পন্ন করার পর, আপনি ArgoCD WebUI ওয়েব কনসোল অথবা ArgoCD Cli কমান্ড লাইন টুলের মাধ্যমে ArgoCD সার্ভার নিয়ে কাজ করতে পারবেন।
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

গিটঅপ্স – কখনোই খুব দেরি হয় না

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

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

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

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

• চলুন কোডটির জন্য একটি গিট রিপোজিটরি তৈরি করি।
• আমরা আমাদের বর্তমান অবজেক্টগুলো এক্সপোর্ট করে গিট রিপোজিটরিতে আপলোড করি।
• গিটঅপস টুল নির্বাচন ও স্থাপন করা।
• চলুন আমাদের রিপোজিটরিটি এই টুলকিটে যোগ করি।
• আমরা আমাদের গিটঅপ্স টুলকিটে একটি অ্যাপ্লিকেশন সংজ্ঞায়িত করি।
• আমরা গিটঅপ্স টুল ব্যবহার করে অ্যাপ্লিকেশনটির একটি পরীক্ষামূলক চালনা করি।
• গিটঅপস টুল ব্যবহার করে অবজেক্ট সিঙ্ক্রোনাইজ করা।
• আমরা অবজেক্ট ছাঁটাই এবং স্বয়ংক্রিয় সিঙ্ক্রোনাইজেশন সক্ষম করি।

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

আমাদের উদাহরণে, আমরা গিটহাবে একটি নতুন পাবলিক রিপোজিটরি তৈরি করব। আপনি এটির যেকোনো নাম দিতে পারেন, কিন্তু আমরা 'blogpost' নামটি ব্যবহার করব।

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

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

এবার deployment.yaml ফাইলটি এডিট করে সেই ফিল্ডটি সরিয়ে দিন যা Argo CD সিঙ্ক করতে পারে না।

sed -i '/sgeneration: .*/d' deployment.yaml

আমাদের রাউটটিও পরিবর্তন করতে হবে। প্রথমে, আমরা একটি মাল্টি-লাইন ভেরিয়েবল নির্ধারণ করব, তারপর ingress: null-কে সেই ভেরিয়েবলের বিষয়বস্তু দিয়ে প্রতিস্থাপন করব।

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

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

git commit -am ‘initial commit of objects’
git push origin master

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

argocd repo add https://github.com/cooktheryan/blogpost

এবার অ্যাপ্লিকেশনটি তৈরি করা যাক। অ্যাপ্লিকেশনটি বিভিন্ন ভ্যালু নির্দিষ্ট করে দেয়, যার ফলে GitOps বুঝতে পারে কোন রিপোজিটরি ও পাথ ব্যবহার করতে হবে, অবজেক্ট ম্যানেজমেন্টের জন্য কোন OpenShift প্রয়োজন, কোন নির্দিষ্ট রিপোজিটরি ব্রাঞ্চ দরকার, এবং রিসোর্স অটো-সিঙ্কিং চালু করা উচিত কিনা।

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

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

এখন আমাদের ফাইলগুলোতে কোনো ত্রুটি নেই তা নিশ্চিত করার জন্য একটি পরীক্ষামূলক রান করা যাক।

argocd app sync simple-app --dry-run

যদি কোনো ত্রুটি না থাকে, তাহলে আপনি সিঙ্ক্রোনাইজেশনে অগ্রসর হতে পারেন।

argocd app sync simple-app

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

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

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

argocd app set simple-app --sync-policy automated --auto-prune

সুতরাং, আমরা সফলভাবে এমন একটি অ্যাপ্লিকেশনকে, যেটি শুরুতে GitOps ব্যবহার করত না, GitOps ব্যবস্থাপনার আওতায় নিয়ে এসেছি।

উত্স: www.habr.com