🥇معرفی GitOps برای OpenShift

امروز در مورد اصول و مدل های GitOps و همچنین نحوه پیاده سازی این مدل ها در پلتفرم OpenShift صحبت خواهیم کرد. راهنمای تعاملی در مورد این موضوع در دسترس است по ссылке.

به طور خلاصه، GitOps مجموعه ای از روش ها برای استفاده از درخواست های Git pull برای مدیریت زیرساخت ها و تنظیمات برنامه است. مخزن Git در GitOps به عنوان یک منبع اطلاعاتی واحد در مورد وضعیت سیستم در نظر گرفته می شود و هرگونه تغییر در این حالت کاملاً قابل ردیابی و ممیزی است.

ایده ردیابی تغییر در GitOps به هیچ وجه جدید نیست؛ این رویکرد مدتهاست که تقریباً به طور جهانی هنگام کار با کد منبع برنامه استفاده می شود. GitOps به سادگی ویژگی های مشابه (بازبینی، درخواست های کششی، برچسب ها و غیره) را در مدیریت زیرساخت و پیکربندی برنامه پیاده سازی می کند و مزایای مشابهی را در مورد مدیریت کد منبع ارائه می دهد.

هیچ تعریف آکادمیک یا مجموعه قوانین تایید شده ای برای GitOps وجود ندارد، فقط مجموعه ای از اصولی است که این عمل بر اساس آنها ساخته شده است:

توضیحات اعلامی سیستم در مخزن Git (پیکربندی ها، نظارت و غیره) ذخیره می شود.
تغییرات حالت از طریق درخواست های کششی انجام می شود.
وضعیت سیستم های در حال اجرا با استفاده از درخواست های فشار Git با داده های موجود در مخزن هماهنگ می شود.

اصول GitOps

تعاریف سیستم به عنوان کد منبع توصیف می شوند

پیکربندی سیستم به عنوان کد در نظر گرفته می شود، بنابراین می توان آن را ذخیره کرد و به طور خودکار در یک مخزن Git نسخه کرد، که به عنوان یک منبع منفرد حقیقت عمل می کند. این رویکرد، عرضه و بازگرداندن تغییرات در سیستم ها را آسان می کند.

وضعیت و پیکربندی مورد نظر سیستم ها در Git تنظیم و نسخه شده است

با ذخیره و نسخه‌سازی وضعیت مطلوب سیستم‌ها در Git، می‌توانیم به راحتی تغییرات را در سیستم‌ها و برنامه‌ها بازگردانیم و بازگردانیم. همچنین می‌توانیم از مکانیسم‌های امنیتی Git برای کنترل مالکیت کد و تأیید صحت آن استفاده کنیم.

تغییرات پیکربندی را می توان به طور خودکار از طریق درخواست های کششی اعمال کرد

با استفاده از درخواست‌های Git pull، می‌توانیم به راحتی نحوه اعمال تغییرات در پیکربندی‌های موجود در مخزن را کنترل کنیم. به عنوان مثال، می توان آنها را برای بررسی به سایر اعضای تیم داد یا از طریق تست های CI و غیره اجرا کرد.

و در عین حال نیازی به توزیع قدرت های ادمین به چپ و راست نیست. برای انجام تغییرات پیکربندی، کاربران فقط به مجوزهای مناسب در مخزن Git نیاز دارند که در آن پیکربندی‌ها ذخیره می‌شوند.

رفع مشکل رانش کنترل نشده تنظیمات

هنگامی که وضعیت مطلوب سیستم در یک مخزن Git ذخیره می شود، تنها کاری که باید انجام دهیم این است که نرم افزاری را پیدا کنیم که اطمینان حاصل کند که وضعیت فعلی سیستم با وضعیت مطلوب خود مطابقت دارد. اگر اینطور نیست، پس این نرم افزار باید - بسته به تنظیمات - یا به خودی خود اختلاف را از بین ببرد یا ما را در مورد دریفت پیکربندی مطلع کند.

مدل های GitOps برای OpenShift

تطبیق دهنده منابع On-Cluster

طبق این مدل، خوشه دارای یک کنترل‌کننده است که وظیفه مقایسه منابع Kubernetes (فایل‌های YAML) در مخزن Git با منابع واقعی خوشه را بر عهده دارد. در صورت تشخیص مغایرت، کنترل کننده اعلان هایی را ارسال می کند و احتمالاً برای اصلاح مغایرت ها اقدام می کند. این مدل GitOps در Anthos Config Management و Weaveworks Flux استفاده می شود.

تطبیق دهنده منابع خارجی (فشار)

این مدل را می توان به عنوان یک تغییر از مدل قبلی در نظر گرفت، زمانی که یک یا چند کنترل کننده مسئول همگام سازی منابع در جفت "مخزن Git - خوشه Kubernetes" داریم. تفاوت در اینجا این است که هر خوشه مدیریت شده لزوماً کنترل کننده جداگانه خود را ندارد. جفت‌های خوشه‌ای Git - k8s اغلب به‌عنوان CRD (تعریف منابع سفارشی) تعریف می‌شوند، که می‌تواند نحوه انجام همگام‌سازی را توسط کنترل‌کننده توضیح دهد. در این مدل، کنترل‌کننده‌ها مخزن Git مشخص‌شده در CRD را با منابع خوشه Kubernetes که در CRD نیز مشخص شده‌اند، مقایسه می‌کنند و اقدامات مناسب را بر اساس نتایج مقایسه انجام می‌دهند. به طور خاص، این مدل GitOps در ArgoCD استفاده می شود.

GitOps در پلتفرم OpenShift

مدیریت زیرساخت های چند خوشه ای Kubernetes

با گسترش Kubernetes و محبوبیت فزاینده استراتژی‌های چند ابری و محاسبات لبه، میانگین تعداد خوشه‌های OpenShift به ازای هر مشتری نیز در حال افزایش است.

به عنوان مثال، هنگام استفاده از محاسبات لبه، خوشه های یک مشتری را می توان در صدها یا حتی هزاران مستقر کرد. در نتیجه، او مجبور می شود چندین خوشه OpenShift مستقل یا هماهنگ را در ابر عمومی و در محل مدیریت کند.

در این مورد، بسیاری از مشکلات باید حل شوند، به ویژه:

کنترل کنید که خوشه ها در یک حالت یکسان باشند (پیکربندی ها، نظارت، ذخیره سازی و غیره)
خوشه ها را بر اساس یک حالت شناخته شده بازسازی کنید (یا بازیابی کنید).
ایجاد خوشه های جدید بر اساس یک حالت شناخته شده.
تغییرات را در چند خوشه OpenShift اعمال کنید.
بازگرداندن تغییرات در چندین خوشه OpenShift.
پیوند تنظیمات قالب به محیط های مختلف.

تنظیمات برنامه

در طول چرخه عمر خود، برنامه‌ها اغلب از زنجیره‌ای از خوشه‌ها (dev، مرحله، و غیره) عبور می‌کنند و سپس به یک خوشه تولید ختم می‌شوند. علاوه بر این، به دلیل در دسترس بودن و نیازهای مقیاس پذیری، مشتریان اغلب برنامه های کاربردی را در چندین خوشه داخلی یا چندین منطقه از یک پلت فرم ابر عمومی مستقر می کنند.

در این مورد، وظایف زیر باید حل شود:

از حرکت برنامه ها (باینری ها، پیکربندی ها و غیره) بین خوشه ها (dev، مرحله و غیره) اطمینان حاصل کنید.
تغییرات را در برنامه‌ها (باینری، تنظیمات، و غیره) در چندین خوشه OpenShift اعمال کنید.
تغییرات برنامه ها را به حالت شناخته شده قبلی برگردانید.

موارد استفاده OpenShift GitOps

1. اعمال تغییرات از مخزن Git

یک مدیر کلاستر می تواند تنظیمات خوشه OpenShift را در یک مخزن Git ذخیره کند و به طور خودکار آنها را برای ایجاد بدون زحمت خوشه های جدید اعمال کند و آنها را به حالتی مشابه با وضعیت شناخته شده ذخیره شده در مخزن Git برساند.

2. همگام سازی با Secret Manager

مدیر همچنین از توانایی همگام سازی اشیاء مخفی OpenShift با نرم افزارهای مناسب مانند Vault به منظور مدیریت آنها با استفاده از ابزارهایی که مخصوص این کار ایجاد شده است بهره می برد.

3. کنترل تنظیمات رانش

ادمین تنها در صورتی موافق خواهد بود که خود OpenShift GitOps مغایرت‌های بین پیکربندی‌های واقعی و تنظیمات مشخص‌شده در مخزن را شناسایی کرده و هشدار دهد تا بتوانند به سرعت به دریفت پاسخ دهند.

4. اطلاعیه در مورد رانش پیکربندی

آنها در مواردی مفید هستند که مدیر می خواهد به سرعت در مورد موارد تغییر پیکربندی اطلاعات کسب کند تا به سرعت اقدامات مناسب را به تنهایی انجام دهد.

5. همگام سازی دستی تنظیمات هنگام رانش

به سرپرست اجازه می‌دهد تا خوشه OpenShift را با مخزن Git در صورت جابجایی پیکربندی همگام‌سازی کند تا به سرعت خوشه را به حالت شناخته شده قبلی بازگرداند.

6. همگام سازی خودکار تنظیمات هنگام رانش

مدیر همچنین می‌تواند خوشه OpenShift را به گونه‌ای پیکربندی کند که هنگام شناسایی دریفت، به‌طور خودکار با مخزن همگام شود، به طوری که پیکربندی خوشه همیشه با پیکربندی‌های Git مطابقت داشته باشد.

7. چندین خوشه - یک مخزن

مدیر می‌تواند پیکربندی‌های چند خوشه OpenShift مختلف را در یک مخزن Git ذخیره کند و به صورت انتخابی آنها را در صورت نیاز اعمال کند.

8. سلسله مراتب پیکربندی های خوشه (ارث)

ادمین می تواند سلسله مراتبی از پیکربندی های خوشه ای را در مخزن (stage، prod، نمونه کار برنامه ها و غیره با ارث بری) تنظیم کند. به عبارت دیگر، می تواند تعیین کند که آیا تنظیمات باید برای یک یا چند خوشه اعمال شوند.

به عنوان مثال، اگر یک مدیر سلسله مراتب «خوشه‌های تولید (prod) → خوشه‌های سیستم X → خوشه‌های تولید سیستم X» را در مخزن Git تنظیم کند، ترکیبی از تنظیمات زیر برای خوشه‌های تولید سیستم X اعمال می‌شود:

تنظیمات مشترک برای همه خوشه های تولید.
تنظیمات برای خوشه System X.
تنظیمات برای خوشه تولید سیستم X.

9. الگوها و پیکربندی لغو می شود

مدیر می‌تواند مجموعه‌ای از پیکربندی‌های ارثی و مقادیر آن‌ها را نادیده بگیرد، به‌عنوان مثال، برای تنظیم دقیق پیکربندی برای خوشه‌های خاصی که روی آن‌ها اعمال خواهند شد.

10. شامل و حذف انتخابی برای تنظیمات، تنظیمات برنامه

مدیر می تواند شرایط اعمال یا عدم استفاده از تنظیمات خاص را برای خوشه هایی با ویژگی های خاص تنظیم کند.

11. پشتیبانی از قالب

توسعه دهندگان از توانایی انتخاب نحوه تعریف منابع برنامه (Helm Chart، Kubernetes Yaml خالص و غیره) بهره مند خواهند شد تا از مناسب ترین فرمت برای هر برنامه خاص استفاده کنند.

ابزارهای GitOps در پلتفرم OpenShift

ArgoCD

ArgoCD مدل External Resource Reconcile را پیاده‌سازی می‌کند و یک رابط کاربری متمرکز برای تنظیم روابط یک به چند بین خوشه‌ها و مخازن Git ارائه می‌کند. از معایب این برنامه می توان به عدم توانایی مدیریت برنامه ها در زمانی که ArgoCD کار نمی کند اشاره کرد.

وب سایت رسمی

شار

Flux یک مدل On-Cluster Resource Reconcile را پیاده‌سازی می‌کند و در نتیجه، مدیریت متمرکز مخزن تعریف وجود ندارد، که یک نقطه ضعف است. از سوی دیگر، دقیقاً به دلیل عدم تمرکز، توانایی مدیریت برنامه ها حتی در صورت شکست یک خوشه باقی می ماند.

وب سایت رسمی

نصب ArgoCD در OpenShift

ArgoCD یک رابط خط فرمان و کنسول وب عالی را ارائه می دهد، بنابراین ما Flux و سایر جایگزین ها را در اینجا پوشش نمی دهیم.

برای استقرار ArgoCD در پلتفرم OpenShift 4، این مراحل را به عنوان مدیر کلاستر دنبال کنید:

استقرار اجزای ArgoCD در پلتفرم OpenShift

# 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}')

بهبود سرور ArgoCD به طوری که می توان آن را با مسیر OpenShift مشاهده کرد

# 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 Tool

# 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 Server کار کنید.
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 برای کد ایجاد کنید.
ما اشیاء فعلی خود را صادر می کنیم و آنها را در مخزن Git آپلود می کنیم.
انتخاب و استقرار ابزارهای GitOps
ما مخزن خود را به این جعبه ابزار اضافه می کنیم.
ما برنامه را در جعبه ابزار GitOps خود تعریف می کنیم.
ما یک اجرای آزمایشی برنامه را با استفاده از جعبه ابزار GitOps انجام می دهیم.
ما اشیاء را با استفاده از جعبه ابزار GitOps همگام می کنیم.
هرس و همگام سازی خودکار اشیاء را فعال کنید.

همانطور که قبلاً در مورد قبلی ذکر شد مقاله، در GitOps یک و تنها یک منبع اطلاعاتی در مورد تمام اشیاء در خوشه(های) Kubernetes وجود دارد - مخزن Git. در مرحله بعد، از این فرض که سازمان شما قبلاً از یک مخزن Git استفاده می کند، ادامه می دهیم. می تواند عمومی یا خصوصی باشد، اما باید برای خوشه های Kubernetes قابل دسترسی باشد. این می تواند همان مخزن کد برنامه یا یک مخزن جداگانه باشد که به طور خاص برای استقرار ایجاد شده است. توصیه می شود مجوزهای سختگیرانه در مخزن داشته باشید زیرا اسرار، مسیرها و سایر موارد حساس به امنیت در آنجا ذخیره می شوند.

در مثال خود، یک مخزن عمومی جدید در GitHub ایجاد خواهیم کرد. شما می توانید آن را هر چه دوست دارید صدا کنید، ما از نام وبلاگ پست استفاده می کنیم.

اگر فایل های شی YAML به صورت محلی یا در Git ذخیره نشده اند، باید از باینری های oc یا kubectl استفاده کنید. در تصویر زیر ما از YAML برای فضای نام، استقرار، سرویس و مسیر خود درخواست می کنیم. قبل از این، ما مخزن جدید ایجاد شده و cd را در آن کلون کردیم.

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 است. پس از آن این مخزن تنها منبع اطلاعات می شود و هرگونه تغییر دستی در اشیا باید اکیداً ممنوع شود.

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

علاوه بر این، ما از این واقعیت پیروی می کنیم که شما قبلاً ArgoCD را مستقر کرده اید (نحوه انجام این کار - قبل را ببینید ارسال). بنابراین، ما مخزنی که ایجاد کرده‌ایم را به CD Argo اضافه می‌کنیم که حاوی کد برنامه از مثال خود است. فقط مطمئن شوید که مخزن دقیقی که قبلا ایجاد کرده اید را مشخص کرده اید.

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 وضعیت برنامه ما "خارج از همگام سازی" خواهد بود زیرا هیچ برچسبی که ArgoCD ارائه می دهد وجود ندارد.
به همین دلیل است که وقتی کمی دیرتر همگام سازی را شروع می کنیم، اشیاء مجدداً مستقر نمی شوند.

حالا بیایید یک اجرای آزمایشی انجام دهیم تا مطمئن شویم هیچ خطایی در فایل های ما وجود ندارد.

argocd app sync simple-app --dry-run

اگر خطایی وجود نداشته باشد، می توانید به همگام سازی ادامه دهید.

argocd app sync simple-app

پس از اجرای دستور argocd get در اپلیکیشن خود، باید ببینیم که وضعیت اپلیکیشن به Healthy یا Synced تغییر کرده است. این بدان معنی است که همه منابع موجود در مخزن Git اکنون با منابعی مطابقت دارند که قبلاً مستقر شده اند.

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

معرفی GitOps برای OpenShift