Close
بسته
DevOps

Jenkins X چیست؟

1
  • Violet Tech | طراحی وب سایت | وب اپلیکیشن | مجله تکنولوژی

ابزاری که می‌تواند پروژه موجود شما را بگیرد، قالب‌های مرتبط با Kubernetes و تنظیمات کانتینر را اضافه کند، و یک Pipeline آماده برای اجرا CI/CD با استفاده از بهترین اصول GitOps وجود دارد؟
آیا عالی نخواهد بود اگر بتوانیم به همه اینها دست یابیم – بدون سرمایه گذاری در فرآیند پیاده سازی پیچیده، اما در عین حال این قدرت را داشته باشیم که همه اجزا را مطابق با نیازهای خود تغییر دهیم؟
خبر خوب این است که ابزارهایی برای دستیابی به این هدف وجود دارد و Jenkins X یکی از این ابزارها است.

جنکینز ایکس یا Jenkins X چیست؟

Jenkins X CI+CD خودکار را برای Kubernetes با محیط‌های پیش‌نمایش در Pull Requests با استفاده از Tekton به‌عنوان موتور Pipeline اساسی ارائه می‌کند.
جنکینز ایکس به ما اجازه می‌دهد تا با ساده‌سازی فرآیندهای پیچیده در Kubernetes و اکوسیستم آن به مفاهیم ساده‌ای که می‌توان به سرعت از آنها استفاده کرد، از قدرت Kubernetes استفاده کنیم. با هدایت کل چرخه عمر توسعه نرم افزار از GitHub تا Kubernetes به ما کمک می کند.

 

طعم Jenkins X

جنکینز ایکس با دو طعم ارائه می شود:
1. ایستا (منسوخ شده)
2. بدون سرور
هنگامی که Jenkins X برای اولین بار ایجاد شد، Jenkins را نصب می کرد که اکنون با pipeline بدون سرور جایگزین شده است. این نصب «ایستا» جنکینز در حال حاضر منسوخ شده است، بنابراین ما می‌توانیم فقط به Jenkins X بدون سرور فکر کنیم که نسل بعدی Jenkins است که فرآیند CD را بر اساس بهترین شیوه‌های GitOps در Kubernetes بازتعریف می‌کند.

 

آنچه پس از نصب به دست می آوریم:

یک کلاستر Kubernetes
چند محیط وnamespace
چند مخزن git مربوط به محیط ها
ورودی که یک بار متعادل کننده ایجاد می کند که به نوبه خود خدمات داخل خوشه را در معرض دنیای خارجی قرار می دهد
چند چیز دیگر که برای عملکرد کامل فرآیند CD ضروری است
جنکینز ایکس عقیده دارد. این اصول آنچه را که به عنوان “بهترین عمل” در توسعه برنامه در Kubernetes می‌داند، اجرا می‌کند. همه چیز بر اساس GitOps است که امکان سفارشی سازی فرآیند را بر اساس نیاز می دهد. بنابراین در این مرحله می‌توانیم ببینیم که این فقط در مورد CI/CD نیست، بلکه بیشتر از آن است.

 

محیط جنکینز ایکس

پس از نصب، Jenkins X به طور پیش فرض سه محیط را فراهم می کند.

    • Development
    • Staging
    • Production

 

محیط توسعه جایی است که اتفاقات مربوط به ساخت رخ می دهد. اینجاست که اجزایی مانند Prow، Tekton و غیره اجرا می‌شوند تا فرآیند ساخت و ارتقاء را تسهیل کنند.
در محیط استیجینگ به صورت پیش فرض ارتقای خودکار اتفاق می افتد. این بدان معناست که هنگامی که تغییرات ما در برنچ اصلی ادغام شد، ساخته می‌شود، آزمایش می‌شود و سپس به محیط Staging ارتقا می‌یابد تا بتوانیم قبل از دریافت تغییرات در محیط production بررسی کنیم. Jenkins X محیط هایی را با خط مشی تبلیغاتی در اختیار ما قرار می دهد. محیط‌هایی که تبلیغات خودکار را فعال کرده‌اند، پس از ادغام در Master تغییرات را دریافت خواهند کرد.

Kubernetes namespace

هر محیط Jenkins X فضای نام Kubernetes مربوطه را دریافت می کند. با اجرای jx get env می توانیم به راحتی آن را تأیید کنیم.

 

NAME           LABEL          KIND        PROMOTE NAMESPACE     
dev            Development    Development Never   jx           
staging        Staging        Permanent   Auto    jx-staging    
production     Production     Permanent   Manual  jx-production

 

این همان چیزی است که جنکینز ایکس برای ما راه اندازی خواهد کرد

 

 

Jenkins X چیست؟

 

ما می توانیم محیط های پیش نمایش را نیز ببینیم. این یکی زمانی ایجاد می‌شود که ما یک pull request در برابر maser ایجاد می‌کنیم و به ما امکان می‌دهد تغییرات را در یک محیط ایزوله بررسی کنیم که به نوعی طعم یک برنامه واقعی را به ما می‌دهد.

 

افزودن برنامه های کاربردی به جنکینز ایکس

جنکینز ایکس چگونه کل فرآیند را تنظیم می کند؟

به‌عنوان یک توسعه‌دهنده، ما فقط می‌خواهیم تغییرات خود را به ریپو push کنیم،  باید بررسی شود و پس از ادغام باید ساخته شود، آزمایش شود و به‌صورت خودکار در محیط مرحله‌بندی deploy شود. و Jenkinsx به ما کمک می کند تا کل فرآیند را به این شکل تنظیم کنیم. برای تحقق این امر، جنکینز ایکس باید در مورد پروژه بداند و یک pipeline  ساخت متناظر را راه‌اندازی کند که با کمک وب هوک GitHub راه‌اندازی می‌شود.
جنکینز ایکس دو راه برای تنظیم کل فرآیند دارد:

  1. وارد کردن یک پروژه موجود به جنکینز ایکس
  2. ایجاد یک پروژه شروع سریع با استفاده از بسته های ساخت پیش ساخته که شامل قالب های لازم برای یک زبان و چارچوب خاص است.

 

آنچه پس از وارد کردن/ایجاد پروژه با JenkinsX بدست می آوریم

  1. CD pipeline to Kubernetes cluster
  2. Github webhook
  3. مکانیزمی برای ترویج انتشار در محیط های مختلف
  4. راهی برای بررسی pull request

 

اصول GitOps برای Jenkins X اعمال می شود

Jenkins X بر اساس چیزی به نام اصول GitOps توسعه یافته است. GitOps چیست؟ به طور خلاصه، این روشی برای انجام تحویل مداوم است. همه چیز بر اساس تغییرات در git، مخزن کد منبع defacto اتفاق می افتد. یعنی همه چیز باید در مخزن git وجود داشته باشد. همه چیز به معنای برنامه و کدهای مرتبط با محیط است. زیرساخت و کاربرد باید با نحو اعلانی تعریف شود، نه با دستور. Git باید منبع واحدی از حقیقت برای برنامه و زیرساخت باشد. اگر تغییری در برنامه یا زیرساخت مورد نیاز باشد که باید از طریق push کردن تغییرات به git repo و webhook مربوطه انجام شود، باید ساخت و استقرار را آغاز کند.
حال، این اصل GitOps پاسخی به این سوال است که چرا دو مخزن مجزا برای برنامه و محیط وجود دارد.

 

حال، این اصل GitOps پاسخی به این سوال است که چرا دو مخزن مجزا برای برنامه و محیط وجود دارد.
Viktor Farcic در کتاب خود DevOps 2.6 Toolkit: Jenkins X 10 فرمان GitOps را توضیح داد. این دستورات برای اجرای فرآیند سی دی مبتنی بر GitOps بسیار مهم هستند.

  • Git تنها منبع حقیقت است.
  • همه چیز باید ردیابی شود، هر عملی باید قابل تکرار باشد.
  • ارتباط بین فرآیندها باید ناهمزمان باشد.
    فرآیندها باید تا زمانی که لازم است اجرا شوند، اما نه بیشتر.
  • همه باینری ها باید در رجیستری ها ذخیره شوند.
  • اطلاعات مربوط به همه نسخه ها باید در repos یا branch x محیط خاص ذخیره شود
  • همه چیز باید از همان شیوه های کدنویسی پیروی کند.
  • همه استقرارها باید فاقد قدرت باشند.
  • وب هوک های Git تنها مواردی هستند که مجاز به ایجاد تغییری هستند که در سیستم اعمال می شود.
  • همه ابزارها باید بتوانند از طریق API با یکدیگر صحبت کنند.

 

حال، این دستورات باید شکل بالا را بسیار واضح تر نشان دهد که چرا محیط های مختلف وجود دارد و چرا ساخت و ارتقاء به طور جداگانه انجام می شود و چرا اطلاعات مربوط به انتشار و ارتقاء در git ذخیره می شود.
با توجه به اصول GitOps، ما می توانیم همه چیز را با استفاده از git انجام دهیم، از push کردن تغییرات گرفته تا ارتقاء انتشار به محیط مورد نظر. تنها کاری که باید انجام دهیم این است که یک pull request ایجاد کنیم و تایید و merge کنیم.

خودشه. ساخت، استقرار آزمایشی به طور خودکار توسط Jenkins X انجام می شود.

 

چگونه یک PR ساده و تایید آن PR می تواند به طور خودکار باعث ایجاد و ارتقاء شود
Jenkins X با ایجاد بسته‌ای از componentها و کارکردن آنها به عنوان یک واحد برای پیاده‌سازی CD در Kubernetes، کارهای سنگین زیادی را انجام می‌دهد.
این فرآیند توسط چند مؤلفه را از سطح بالا ایجاد میشود.

  • Prow
  • Jenkins X pipeline operator
  • Tekton

 

 

source : medium

 

 

برچسب‌ها:

پست های مرتبط