🥇 OpenShift کے لیے GitOps کا تعارف

آج ہم GitOps کے اصولوں اور ماڈلز کے بارے میں بات کریں گے، نیز یہ کہ ان ماڈلز کو اوپن شفٹ پلیٹ فارم پر کیسے لاگو کیا جاتا ہے۔ اس موضوع پر ایک انٹرایکٹو گائیڈ دستیاب ہے۔ ссылке по.

مختصر طور پر، GitOps بنیادی ڈھانچے اور ایپلیکیشن کنفیگریشنز کو منظم کرنے کے لیے Git پل کی درخواستوں کو استعمال کرنے کے طریقوں کا ایک مجموعہ ہے۔ GitOps میں Git ذخیرہ کو نظام کی حالت کے بارے میں معلومات کے واحد ذریعہ کے طور پر سمجھا جاتا ہے، اور اس حالت میں کوئی بھی تبدیلی مکمل طور پر قابل شناخت اور قابل سماعت ہے۔

GitOps میں تبدیلی سے باخبر رہنے کا خیال کسی بھی طرح نیا نہیں ہے؛ ایپلیکیشن سورس کوڈ کے ساتھ کام کرتے وقت یہ نقطہ نظر تقریباً عالمی سطح پر استعمال ہوتا رہا ہے۔ GitOps بنیادی ڈھانچے اور ایپلیکیشن کنفیگریشن مینجمنٹ میں اسی طرح کی خصوصیات (جائزہ، پل کی درخواستیں، ٹیگز وغیرہ) کو آسانی سے نافذ کرتا ہے اور اسی طرح کے فوائد فراہم کرتا ہے جیسا کہ سورس کوڈ مینجمنٹ کے معاملے میں ہوتا ہے۔

GitOps کے لیے کوئی علمی تعریف یا قواعد کا منظور شدہ سیٹ نہیں ہے، صرف اصولوں کا ایک مجموعہ جس پر یہ پریکٹس بنائی گئی ہے:

نظام کی وضاحتی تفصیل گٹ ریپوزٹری میں محفوظ کی جاتی ہے (تشکیلات، نگرانی وغیرہ)۔
ریاستی تبدیلیاں پل درخواستوں کے ذریعے کی جاتی ہیں۔
Git push درخواستوں کا استعمال کرتے ہوئے ریپوزٹری میں موجود ڈیٹا کے مطابق چلنے والے سسٹمز کی حالت کو لایا جاتا ہے۔

GitOps اصول

سسٹم کی تعریفیں سورس کوڈ کے طور پر بیان کی جاتی ہیں۔

سسٹمز کنفیگریشن کو کوڈ کے طور پر سمجھا جاتا ہے لہذا اسے Git ریپوزٹری میں اسٹور اور خود بخود ورژن بنایا جاسکتا ہے، جو سچائی کے واحد ذریعہ کے طور پر کام کرتا ہے۔ یہ نقطہ نظر سسٹمز میں رول آؤٹ اور رول بیک تبدیلیوں کو آسان بناتا ہے۔

سسٹمز کی مطلوبہ حالت اور ترتیب گٹ میں سیٹ اور ورژن کی گئی ہے۔

Git میں سسٹمز کی مطلوبہ حالت کو اسٹور اور ورژن بنا کر، ہم سسٹمز اور ایپلیکیشنز میں تبدیلیوں کو آسانی سے رول آؤٹ اور رول بیک کرنے کے قابل ہوتے ہیں۔ ہم کوڈ کی ملکیت کو کنٹرول کرنے اور اس کی صداقت کی تصدیق کے لیے Git کے سیکیورٹی میکانزم کا بھی استعمال کر سکتے ہیں۔

کنفیگریشن تبدیلیاں خود بخود پل کی درخواستوں کے ذریعے لاگو کی جا سکتی ہیں۔

Git پل کی درخواستوں کا استعمال کرتے ہوئے، ہم آسانی سے کنٹرول کر سکتے ہیں کہ ریپوزٹری میں کنفیگریشنز میں تبدیلیاں کیسے لاگو ہوتی ہیں۔ مثال کے طور پر، وہ ٹیم کے دیگر اراکین کو جائزہ لینے یا CI ٹیسٹ وغیرہ کے ذریعے چلائے جا سکتے ہیں۔

اور ایک ہی وقت میں، منتظم کے اختیارات کو بائیں اور دائیں تقسیم کرنے کی ضرورت نہیں ہے۔ کنفیگریشن کی تبدیلیوں کا ارتکاب کرنے کے لیے، صارفین کو صرف Git ریپوزٹری میں مناسب اجازتوں کی ضرورت ہوتی ہے جہاں وہ کنفیگریشنز محفوظ ہوں۔

کنفیگریشنز کے بے قابو بہاؤ کے مسئلے کو حل کرنا

ایک بار جب سسٹم کی مطلوبہ حالت گٹ ریپوزٹری میں محفوظ ہوجاتی ہے، تو ہمیں بس ایسا سافٹ ویئر تلاش کرنا ہے جو اس بات کو یقینی بنائے کہ سسٹم کی موجودہ حالت اس کی مطلوبہ حالت سے میل کھاتی ہے۔ اگر ایسا نہیں ہے، تو اس سافٹ ویئر کو چاہیے کہ - ترتیبات پر منحصر ہے - یا تو خود ہی تضاد کو ختم کرے، یا ہمیں کنفیگریشن ڈرفٹ کے بارے میں مطلع کرے۔

OpenShift کے لیے GitOps ماڈلز

آن کلسٹر ریسورس کنسلر

اس ماڈل کے مطابق، کلسٹر میں ایک کنٹرولر ہے جو گٹ ریپوزٹری میں Kubernetes وسائل (YAML فائلوں) کا کلسٹر کے حقیقی وسائل سے موازنہ کرنے کا ذمہ دار ہے۔ اگر تضادات کا پتہ چل جاتا ہے، تو کنٹرولر اطلاعات بھیجتا ہے اور ممکنہ طور پر تضادات کو درست کرنے کے لیے کارروائی کرتا ہے۔ یہ GitOps ماڈل Anthos Config Management اور Weaveworks Flux میں استعمال ہوتا ہے۔

ایکسٹرنل ریسورس کنسلر (پش)

اس ماڈل کو پچھلے ماڈل کے تغیر کے طور پر سمجھا جا سکتا ہے، جب ہمارے پاس "گٹ ریپوزٹری - کبرنیٹس کلسٹر" کے جوڑوں میں وسائل کو ہم آہنگ کرنے کے لیے ایک یا زیادہ کنٹرولرز ذمہ دار ہوتے ہیں۔ یہاں فرق یہ ہے کہ ہر منظم کلسٹر کا اپنا الگ کنٹرولر ضروری نہیں ہے۔ Git - k8s کلسٹر جوڑوں کو اکثر CRDs (حسب ضرورت وسائل کی تعریف) کے طور پر بیان کیا جاتا ہے، جو یہ بیان کر سکتا ہے کہ کنٹرولر کو ہم آہنگی کیسے انجام دینی چاہیے۔ اس ماڈل کے اندر، کنٹرولرز CRD میں متعین Git repository کا موازنہ Kubernetes کلسٹر وسائل سے کرتے ہیں، جو CRD میں بھی متعین ہیں، اور موازنہ کے نتائج کی بنیاد پر مناسب کارروائیاں کرتے ہیں۔ خاص طور پر، یہ GitOps ماڈل ArgoCD میں استعمال ہوتا ہے۔

OpenShift پلیٹ فارم پر GitOps

ملٹی کلسٹر Kubernetes انفراسٹرکچر کی انتظامیہ

Kubernetes کے پھیلاؤ اور ملٹی کلاؤڈ حکمت عملیوں اور ایج کمپیوٹنگ کی بڑھتی ہوئی مقبولیت کے ساتھ، اوپن شفٹ کلسٹرز کی اوسط تعداد فی گاہک بھی بڑھ رہی ہے۔

مثال کے طور پر، ایج کمپیوٹنگ کا استعمال کرتے وقت، ایک گاہک کے کلسٹرز کو سینکڑوں یا اس سے بھی ہزاروں میں تعینات کیا جا سکتا ہے۔ نتیجے کے طور پر، وہ عوامی کلاؤڈ اور آن پرائمیس میں کئی آزاد یا مربوط اوپن شفٹ کلسٹرز کا انتظام کرنے پر مجبور ہے۔

اس صورت میں، بہت سے مسائل کو حل کرنا ہوگا، خاص طور پر:

کنٹرول کریں کہ کلسٹرز ایک جیسی حالت میں ہیں (تشکیلات، نگرانی، اسٹوریج، وغیرہ)
معلوم حالت کی بنیاد پر کلسٹرز کو دوبارہ بنائیں (یا بحال کریں)۔
معلوم ریاست کی بنیاد پر نئے کلسٹرز بنائیں۔
متعدد OpenShift کلسٹرز میں تبدیلیوں کو رول آؤٹ کریں۔
متعدد OpenShift کلسٹرز میں تبدیلیوں کو رول بیک کریں۔
ٹیمپلیٹڈ کنفیگریشنز کو مختلف ماحول سے جوڑیں۔

ایپلیکیشن کنفیگریشنز

اپنے لائف سائیکل کے دوران، ایپلی کیشنز اکثر پروڈکشن کلسٹر میں ختم ہونے سے پہلے کلسٹرز (دیو، اسٹیج، وغیرہ) کی ایک زنجیر سے گزرتی ہیں۔ اس کے علاوہ، دستیابی اور اسکیل ایبلٹی کی ضروریات کی وجہ سے، صارفین اکثر ایپلیکیشنز کو ایک سے زیادہ آن پریمیس کلسٹرز یا عوامی کلاؤڈ پلیٹ فارم کے متعدد خطوں میں تعینات کرتے ہیں۔

اس صورت میں، مندرجہ ذیل کاموں کو حل کرنا ہوگا:

کلسٹرز (دیو، اسٹیج، وغیرہ) کے درمیان ایپلیکیشنز (بائنریز، کنفیگرز، وغیرہ) کی نقل و حرکت کو یقینی بنائیں۔
کئی OpenShift کلسٹرز میں ایپلی کیشنز (بائنریز، کنفیگرز، وغیرہ) میں تبدیلیوں کو رول آؤٹ کریں۔
پچھلی معلوم حالت میں ایپلی کیشنز میں تبدیلیوں کو رول بیک کریں۔

OpenShift GitOps استعمال کے کیسز

1. Git ریپوزٹری سے تبدیلیاں لاگو کرنا

ایک کلسٹر ایڈمنسٹریٹر اوپن شفٹ کلسٹر کنفیگریشنز کو گٹ ریپوزٹری میں اسٹور کر سکتا ہے اور انہیں آسانی سے نئے کلسٹرز بنانے کے لیے خود بخود لاگو کر سکتا ہے اور انہیں گٹ ریپوزٹری میں محفوظ کردہ معلوم ریاست کے مماثل حالت میں لا سکتا ہے۔

2. سیکرٹ مینیجر کے ساتھ ہم آہنگی۔

منتظم OpenShift خفیہ اشیاء کو مناسب سافٹ ویئر جیسے Vault کے ساتھ ہم آہنگ کرنے کی صلاحیت سے بھی فائدہ اٹھائے گا تاکہ خاص طور پر اس کے لیے بنائے گئے ٹولز کا استعمال کرتے ہوئے ان کا نظم کیا جا سکے۔

3. بڑھے ہوئے کنفیگریشنز کا کنٹرول

منتظم صرف اس صورت میں حق میں ہوگا جب OpenShift GitOps خود اصلی کنفیگریشنز اور ریپوزٹری میں متعین کردہ تضادات کی نشاندہی کرے اور ان کے بارے میں انتباہ کرے، تاکہ وہ تیزی سے بڑھنے کا جواب دے سکیں۔

4. کنفیگریشن ڈرفٹ کے بارے میں اطلاعات

یہ اس صورت میں کارآمد ہیں جب ایڈمنسٹریٹر اپنے طور پر مناسب اقدامات کرنے کے لیے کنفیگریشن ڈرفٹ کے معاملات کے بارے میں فوری طور پر جاننا چاہتا ہے۔

5. بہتی ہوئی ترتیب کی دستی ہم آہنگی۔

منتظم کو کنفیگریشن ڈرفٹ کی صورت میں OpenShift کلسٹر کو Git repository کے ساتھ مطابقت پذیر کرنے کی اجازت دیتا ہے، تاکہ کلسٹر کو تیزی سے پچھلی معلوم حالت میں واپس کیا جا سکے۔

6. بہتی ہوئی ترتیب کی خودکار مطابقت پذیری۔

ایڈمنسٹریٹر اوپن شفٹ کلسٹر کو بھی ترتیب دے سکتا ہے تاکہ ریپوزٹری کے ساتھ خود بخود مطابقت پذیر ہو جائے جب کسی بڑھے کا پتہ چل جائے، تاکہ کلسٹر کنفیگریشن ہمیشہ گٹ میں موجود کنفیگریشن سے مماثل ہو۔

7. کئی کلسٹرز - ایک ذخیرہ

ایڈمنسٹریٹر ایک گٹ ریپوزٹری میں کئی مختلف اوپن شفٹ کلسٹرز کی کنفیگریشنز کو اسٹور کر سکتا ہے اور ضرورت کے مطابق انہیں منتخب طور پر لاگو کر سکتا ہے۔

8. کلسٹر کنفیگریشن کا درجہ بندی (وراثت)

ایڈمن ریپوزٹری میں کلسٹر کنفیگریشنز کا درجہ بندی سیٹ کر سکتا ہے (اسٹیج، پروڈ، ایپ پورٹ فولیو وغیرہ۔ وراثت کے ساتھ)۔ دوسرے الفاظ میں، یہ اس بات کا تعین کر سکتا ہے کہ آیا کنفیگریشنز کو ایک یا زیادہ کلسٹرز پر لاگو کیا جانا چاہیے۔

مثال کے طور پر، اگر کوئی ایڈمنسٹریٹر گٹ ریپوزٹری میں درجہ بندی "پروڈکشن کلسٹرز (پروڈ) → سسٹم ایکس کلسٹرز → سسٹم ایکس کے پروڈکشن کلسٹرز" کو سیٹ کرتا ہے، تو سسٹم X کے پروڈکشن کلسٹرز پر درج ذیل کنفیگریشنز کا مجموعہ لاگو ہوتا ہے:

تمام پروڈکشن کلسٹرز کے لیے مشترکہ کنفیگرز۔
سسٹم ایکس کلسٹر کے لیے کنفیگز۔
X سسٹم پروڈکشن کلسٹر کے لیے کنفیگز۔

9. ٹیمپلیٹس اور کنفیگریشن اوور رائیڈز

منتظم وراثت میں ملنے والی ترتیبوں اور ان کی اقدار کے سیٹ کو اوور رائیڈ کر سکتا ہے، مثال کے طور پر، مخصوص کلسٹرز کے لیے کنفیگریشن کو ٹھیک کرنے کے لیے جس پر وہ لاگو کیے جائیں گے۔

10. منتخب کنفیگریشنز، ایپلیکیشن کنفیگریشنز کے لیے شامل اور خارج کریں۔

منتظم مخصوص خصوصیات کے ساتھ کلسٹرز کے لیے مخصوص کنفیگریشنز کے اطلاق یا عدم اطلاق کے لیے شرائط متعین کر سکتا ہے۔

11. ٹیمپلیٹ سپورٹ

ڈیولپرز کو یہ منتخب کرنے کی صلاحیت سے فائدہ ہوگا کہ ہر مخصوص ایپلیکیشن کے لیے موزوں ترین فارمیٹ استعمال کرنے کے لیے ایپلیکیشن کے وسائل کی تعریف کیسے کی جائے گی (ہیلم چارٹ، خالص کبرنیٹس یامل وغیرہ)۔

OpenShift پلیٹ فارم پر GitOps ٹولز

آرگو سی ڈی

ArgoCD ایکسٹرنل ریسورس کنسائل ماڈل کو لاگو کرتا ہے اور کلسٹرز اور گٹ ریپوزٹریز کے درمیان ایک سے کئی رشتوں کو ترتیب دینے کے لیے مرکزی UI پیش کرتا ہے۔ اس پروگرام کے نقصانات میں ArgoCD کام نہ کرنے پر ایپلیکیشنز کا انتظام کرنے میں ناکامی شامل ہے۔

سرکاری ویب سائٹ

بہاؤ

فلوکس آن کلسٹر ریسورس ری کنسائل ماڈل کو لاگو کرتا ہے اور اس کے نتیجے میں ڈیفینیشن ریپوزٹری کا کوئی مرکزی انتظام نہیں ہے، جو کہ ایک کمزور نقطہ ہے۔ دوسری طرف، خاص طور پر مرکزیت کی کمی کی وجہ سے، ایپلی کیشنز کو منظم کرنے کی صلاحیت باقی رہتی ہے چاہے ایک کلسٹر ناکام ہو جائے۔

سرکاری ویب سائٹ

OpenShift پر ArgoCD انسٹال کرنا

ArgoCD ایک بہترین کمانڈ لائن انٹرفیس اور ویب کنسول پیش کرتا ہے، لہذا ہم یہاں Flux اور دیگر متبادلات کا احاطہ نہیں کریں گے۔

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 - کبھی بھی دیر نہیں ہوتی

"ٹرین چلی گئی ہے" - یہ وہ ایسی صورتحال کے بارے میں کہتے ہیں جب کچھ کرنے کا موقع چھوٹ جاتا ہے۔ OpenShift کے معاملے میں، اس ٹھنڈے نئے پلیٹ فارم کو فوری طور پر استعمال کرنا شروع کرنے کی خواہش اکثر راستوں، تعیناتیوں اور دیگر OpenShift اشیاء کے انتظام اور دیکھ بھال کے ساتھ بالکل یہی صورتحال پیدا کرتی ہے۔ لیکن کیا موقع ہمیشہ مکمل طور پر کھو جاتا ہے؟

کے بارے میں مضامین کا سلسلہ جاری ہے۔ 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 کلسٹر (s) میں تمام اشیاء کے بارے میں معلومات کا ایک اور صرف ایک ذریعہ ہے - Git ذخیرہ۔ اگلا، ہم اس بنیاد سے آگے بڑھتے ہیں کہ آپ کی تنظیم پہلے سے ہی ایک Git ذخیرہ استعمال کرتی ہے۔ یہ عوامی یا نجی ہو سکتا ہے، لیکن یہ Kubernetes کلسٹرز کے لیے قابل رسائی ہونا چاہیے۔ یہ وہی ذخیرہ ہو سکتا ہے جیسا کہ ایپلیکیشن کوڈ کے لیے، یا ایک علیحدہ ذخیرہ ہو سکتا ہے جو خاص طور پر تعیناتیوں کے لیے بنایا گیا ہے۔ مخزن میں سخت اجازتیں رکھنے کی سفارش کی جاتی ہے کیونکہ راز، راستے اور دیگر حفاظتی حساس چیزیں وہاں محفوظ کی جائیں گی۔

ہماری مثال میں، ہم GitHub پر ایک نیا عوامی ذخیرہ بنائیں گے۔ آپ اسے جو چاہیں کہہ سکتے ہیں، ہم بلاگ پوسٹ کا نام استعمال کرتے ہیں۔

اگر 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 کو تعینات کر دیا ہے (یہ کیسے کریں - پچھلا دیکھیں پوسٹ)۔ لہذا، ہم 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

ایک بار جب آرگو سی ڈی میں درخواست کی وضاحت ہو جاتی ہے، تو ٹول کٹ پہلے سے تعینات اشیاء کو ذخیرہ میں موجود تعریفوں کے خلاف چیک کرنا شروع کر دیتی ہے۔ ہماری مثال میں، خودکار مطابقت پذیری اور صفائی کو غیر فعال کر دیا گیا ہے، لہذا عناصر ابھی تبدیل نہیں ہوتے ہیں۔ براہ کرم نوٹ کریں کہ آرگو سی ڈی انٹرفیس میں ہماری ایپلیکیشن کی حیثیت "آؤٹ آف سنک" ہوگی کیونکہ ایسا کوئی لیبل نہیں ہے جو آرگو سی ڈی فراہم کرتا ہے۔
یہی وجہ ہے کہ جب ہم تھوڑی دیر بعد ہم آہنگی شروع کرتے ہیں، تو اشیاء کو دوبارہ تعینات نہیں کیا جائے گا۔

اب اس بات کو یقینی بنانے کے لیے ایک ٹیسٹ رن کرتے ہیں کہ ہماری فائلوں میں کوئی خرابی نہیں ہے۔

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

OpenShift کے لیے GitOps کا تعارف