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

আজ আমরা GitOps এর নীতি এবং মডেল সম্পর্কে কথা বলব, সেইসাথে কিভাবে এই মডেলগুলি OpenShift প্ল্যাটফর্মে প্রয়োগ করা হয়। এই বিষয়ে একটি ইন্টারেক্টিভ গাইড উপলব্ধ লিংক.

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

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

GitOps-এর জন্য কোনও একাডেমিক সংজ্ঞা বা অনুমোদিত নিয়ম নেই, শুধুমাত্র নীতিগুলির একটি সেট যার উপর এই অনুশীলনটি তৈরি করা হয়েছে:

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

GitOps নীতি

• সিস্টেম সংজ্ঞা উৎস কোড হিসাবে বর্ণনা করা হয়

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

• সিস্টেমের পছন্দসই অবস্থা এবং কনফিগারেশন Git-এ সেট এবং সংস্করণ করা হয়েছে

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

• কনফিগারেশন পরিবর্তনগুলি পুল অনুরোধের মাধ্যমে স্বয়ংক্রিয়ভাবে প্রয়োগ করা যেতে পারে

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

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

• কনফিগারেশনের অনিয়ন্ত্রিত প্রবাহের সমস্যা সমাধান করা

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

OpenShift-এর জন্য GitOps মডেল

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

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

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

এই মডেলটিকে আগেরটির একটি বৈচিত্র হিসাবে বিবেচনা করা যেতে পারে, যখন আমাদের কাছে "গিট রিপোজিটরি - কুবারনেটস ক্লাস্টার" জোড়াগুলিতে সংস্থানগুলি সিঙ্ক্রোনাইজ করার জন্য এক বা একাধিক কন্ট্রোলার দায়ী থাকে। এখানে পার্থক্য হল যে প্রতিটি পরিচালিত ক্লাস্টারের অগত্যা নিজস্ব পৃথক নিয়ামক নেই। Git - k8s ক্লাস্টার পেয়ারগুলিকে প্রায়শই CRDs (কাস্টম রিসোর্স সংজ্ঞা) হিসাবে সংজ্ঞায়িত করা হয়, যা বর্ণনা করতে পারে কিভাবে কন্ট্রোলারের সিঙ্ক্রোনাইজেশন করা উচিত। এই মডেলের মধ্যে, কন্ট্রোলাররা CRD-এ নির্দিষ্ট করা গিট রিপোজিটরিকে Kubernetes ক্লাস্টার রিসোর্সের সাথে তুলনা করে, যেগুলি CRD-এও নির্দিষ্ট করা আছে এবং তুলনার ফলাফলের উপর ভিত্তি করে উপযুক্ত ক্রিয়া সম্পাদন করে। বিশেষ করে, এই GitOps মডেলটি ArgoCD তে ব্যবহৃত হয়।

OpenShift প্ল্যাটফর্মে GitOps

মাল্টি-ক্লাস্টার কুবারনেটস অবকাঠামোর প্রশাসন

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

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

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

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

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

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

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

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

OpenShift GitOps কেস ব্যবহার করুন

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

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

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

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

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

প্রশাসক তখনই পক্ষে থাকবে যখন OpenShift GitOps নিজেই প্রকৃত কনফিগারেশন এবং রিপোজিটরিতে নির্দিষ্ট করা পার্থক্যগুলির বিষয়ে শনাক্ত করে এবং সতর্ক করে, যাতে তারা দ্রুত প্রবাহে সাড়া দিতে পারে।

4. কনফিগারেশন ড্রিফট সম্পর্কে বিজ্ঞপ্তি

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

5. প্রবাহিত করার সময় কনফিগারেশনের ম্যানুয়াল সিঙ্ক্রোনাইজেশন

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

6. প্রবাহিত করার সময় কনফিগারেশনের অটো-সিঙ্ক্রোনাইজেশন

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

7. বেশ কয়েকটি ক্লাস্টার - একটি সংগ্রহস্থল

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

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

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

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

• সমস্ত উৎপাদন ক্লাস্টারে সাধারণ কনফিগার।
• সিস্টেম এক্স ক্লাস্টারের জন্য কনফিগার।
• X সিস্টেম উৎপাদন ক্লাস্টারের জন্য কনফিগার।

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

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

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

অ্যাডমিনিস্ট্রেটর নির্দিষ্ট বৈশিষ্ট্যের সাথে ক্লাস্টারে নির্দিষ্ট কনফিগারেশনের অ্যাপ্লিকেশন বা অ-অ্যাপ্লিকেশনের শর্ত সেট করতে পারেন।

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

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

OpenShift প্ল্যাটফর্মে GitOps টুল

আর্গোসিডি

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

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

প্রবাহ

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

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

OpenShift এ ArgoCD ইনস্টল করা হচ্ছে

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

OpenShift 4 প্ল্যাটফর্মে ArgoCD স্থাপন করতে, ক্লাস্টার প্রশাসক হিসাবে এই পদক্ষেপগুলি অনুসরণ করুন:

OpenShift প্ল্যাটফর্মে 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}')

আরগোসিডি সার্ভারের উন্নতি যাতে এটি ওপেনশিফট রুট দ্বারা দেখা যায়

# 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, আজ আমরা আপনাকে দেখাব কিভাবে একটি হস্তশিল্পিত অ্যাপ্লিকেশন এবং এর সংস্থানগুলিকে একটি প্রক্রিয়ায় রূপান্তর করা যায় যেখানে সবকিছু 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

তাই আমরা একটি হস্তশিল্প অ্যাপ্লিকেশন আছে. এখন এটি প্রাপ্যতা হারানো ছাড়া GitOps ব্যবস্থাপনার অধীনে স্থানান্তর করা প্রয়োজন। সংক্ষেপে, এটি এটি করে:

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

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

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

যদি 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 ফাইলটি সম্পাদনা করা যাক যে ক্ষেত্রটি আর্গো সিডি সিঙ্ক করতে পারে না তা সরাতে।

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 মোতায়েন করেছেন (এটি কীভাবে করবেন - পূর্ববর্তী দেখুন পোস্ট) অতএব, আমরা আর্গো সিডিতে আমাদের তৈরি করা সংগ্রহস্থল যোগ করব, আমাদের উদাহরণ থেকে অ্যাপ্লিকেশন কোড সহ। শুধু নিশ্চিত করুন যে আপনি সঠিক সংগ্রহস্থলটি নির্দিষ্ট করেছেন যা আপনি আগে তৈরি করেছেন।

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 ইন্টারফেসে আমাদের অ্যাপ্লিকেশনটির স্ট্যাটাস "আউট অফ সিঙ্ক" থাকবে কারণ ArgoCD প্রদান করে এমন কোনো লেবেল নেই।
এই কারণেই যখন আমরা একটু পরে সিঙ্ক্রোনাইজেশন শুরু করি, বস্তুগুলি পুনরায় স্থাপন করা হবে না।

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

argocd app sync simple-app --dry-run

যদি কোনও ত্রুটি না থাকে তবে আপনি সিঙ্ক্রোনাইজেশনে এগিয়ে যেতে পারেন।

argocd app sync simple-app

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

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