آزمایشی برای استفاده از GitHub Actions به عنوان یک صفحه کنترل برای PaaS | Mewayz Blog Skip to main content
Hacker News

آزمایشی برای استفاده از GitHub Actions به عنوان یک صفحه کنترل برای PaaS

نظرات

1 min read Via towlion.github.io

Mewayz Team

Editorial Team

Hacker News
<بدن>

یک اتحادیه غیرمنتظره: Git و پلتفرم

دنیای DevOps بر اساس اتوماسیون ساخته شده است. ما استقرار اسکریپت ها را مدیریت می کنیم، زیرساخت ها را به عنوان کد مدیریت می کنیم و تلاش می کنیم تا هر فرآیندی را تکرارپذیر و قابل اعتماد کنیم. در قلب این برای تیم‌های توسعه بی‌شماری، GitHub، پلتفرم فراگیر برای همکاری کد قرار دارد. اما اگر قدرت آن فراتر از کنترل نسخه و CI/CD گسترش یابد، چه؟ این داستان آزمایشی است برای جابجایی مرزهای GitHub Actions، تبدیل آن از یک ارکستراتور ساخت و آزمایش به سیستم عصبی مرکزی - صفحه کنترل - برای کل پلتفرم به عنوان سرویس (PaaS).

تعریف مجدد صفحه کنترل

به طور سنتی، هواپیمای کنترلی PaaS یک نرم‌افزار سفارشی و پیچیده است. این یک مقام مرکزی است که دستورات را دریافت می کند (این را مستقر کنید، آن را مقیاس دهید) و زیرساخت های اساسی را برای تحقق آن هماهنگ می کند. تامین، شبکه، امنیت و مدیریت چرخه حیات را مدیریت می کند. ساخت یک یک کار مهندسی مهم است. فرضیه آزمایش ما ساده بود: آیا می‌توانیم از گردش کار موجود، قدرتمند و آشنای GitHub Actions برای انجام همین وظایف استفاده کنیم؟ به جای نوشتن یک صفحه کنترل یکپارچه، از فایل‌های YAML، درخواست‌های کششی و اکوسیستم رویداد محور قوی GitHub برای مدیریت پلتفرم خود استفاده می‌کنیم.

"قوی ترین ابزار، ابزاری است که تیم شما از قبل می داند که چگونه از آن استفاده کند. با استفاده از GitHub Actions به عنوان صفحه کنترل خود، ما نیازی به ایجاد یک رابط کاربری یا آموزش مفاهیم جدید نداشتیم؛ ما جریان کاری که توسعه دهندگان Git محور دوست دارند را گسترش دادیم."

معماری PaaS مبتنی بر GitHub

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

  • یک برنامه‌نویس یک فهرست راهنمای جدید برای سرویس خود ایجاد می‌کند و یک فایل «mewayz.app.yaml» اضافه می‌کند که نیازهای آن را تعریف می‌کند: CPU، حافظه، متغیرهای محیطی و دامنه.
  • آنها این فایل را commit کرده و یک Pull Request باز می کنند. باز کردن PR یک گردش کار GitHub Actions را راه‌اندازی می‌کند.
  • جریان کاری که به عنوان صفحه کنترل عمل می کند، فایل YAML را تجزیه می کند، پیکربندی را تأیید می کند و تغییرات زیرساخت را به صورت خشک انجام می دهد.
  • هنگامی که PR ادغام شد، یک گردش کار استقرار جداگانه راه اندازی می شود. این گردش کار شامل منطق برقراری ارتباط با APIهای ابری مختلف (Kubernetes، AWS، و غیره) است تا در واقع منابع لازم را فراهم کرده و سرویس را مستقر کند.
  • سپس گردش کار با یک پیوند زنده به سرویس تازه استقرار یافته و تکمیل حلقه، روی commit نظر می دهد.

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

درس هایی از مرز

این آزمایش موفقیت چشمگیری در اثبات امکان سنجی بود. ما به یک PaaS کاملاً کاربردی و مبتنی بر Git-ops دست یافتیم که در آن هر تغییر قابل ردیابی و برگشت پذیر بود. با این حال، ملاحظات مهمی را نیز آشکار کرد. مدیریت پیچیده ایالت گاهی اوقات مرزهای زیبایی را در یک فایل YAML تغییر می دهد. در حالی که GitHub Actions فوق‌العاده مقیاس‌پذیر است، اما برای پلتفرم‌های مقیاس عظیم، صف‌بندی و زمان اجرای گردش‌های کاری می‌تواند در مقایسه با یک API کنترل هواپیمای اختصاصی و کم تأخیر به یک گلوگاه تبدیل شود. امنیت در درجه اول اهمیت قرار داشت. ما باید اسرار و مجوزها را با دقت مدیریت می‌کردیم تا مطمئن شویم که GitHub Action runner حداقل دسترسی لازم برای انجام وظایف خود را دارد - مفهومی که کاملاً با اصول طراحی ایمن Mewayz مطابقت دارد.

نگاهی اجمالی به آینده Git-Centric

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

💡 DID YOU KNOW?

Mewayz replaces 8+ business tools in one platform

CRM · Invoicing · HR · Projects · Booking · eCommerce · POS · Analytics. Free forever plan available.

Start Free →

سوالات متداول

یک اتحادیه غیرمنتظره: Git و پلتفرم

دنیای DevOps بر اساس اتوماسیون ساخته شده است. ما استقرار اسکریپت ها را مدیریت می کنیم، زیرساخت ها را به عنوان کد مدیریت می کنیم و تلاش می کنیم تا هر فرآیندی را تکرارپذیر و قابل اعتماد کنیم. در قلب این برای تیم‌های توسعه بی‌شماری، GitHub، پلتفرم فراگیر برای همکاری کد قرار دارد. اما اگر قدرت آن فراتر از کنترل نسخه و CI/CD گسترش یابد، چه؟ این داستان آزمایشی است برای جابجایی مرزهای GitHub Actions، تبدیل آن از یک ارکستراتور ساخت و آزمایش به سیستم عصبی مرکزی - صفحه کنترل - برای کل پلتفرم به عنوان سرویس (PaaS).

تعریف مجدد صفحه کنترل

به طور سنتی، هواپیمای کنترلی PaaS یک نرم‌افزار سفارشی و پیچیده است. این یک مقام مرکزی است که دستورات را دریافت می کند (این را مستقر کنید، آن را مقیاس دهید) و زیرساخت های اساسی را برای تحقق آن هماهنگ می کند. تامین، شبکه، امنیت و مدیریت چرخه حیات را مدیریت می کند. ساخت یک یک کار مهندسی مهم است. فرضیه آزمایش ما ساده بود: آیا می‌توانیم از گردش کار موجود، قدرتمند و آشنای GitHub Actions برای انجام همین وظایف استفاده کنیم؟ به جای نوشتن یک صفحه کنترل یکپارچه، از فایل‌های YAML، درخواست‌های کششی و اکوسیستم رویداد محور قوی GitHub برای مدیریت پلتفرم خود استفاده می‌کنیم.

معماری PaaS مبتنی بر GitHub

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

درس هایی از مرز

این آزمایش موفقیت چشمگیری در اثبات امکان سنجی بود. ما به یک PaaS کاملاً کاربردی و مبتنی بر Git-ops دست یافتیم که در آن هر تغییر قابل ردیابی و برگشت پذیر بود. با این حال، ملاحظات مهمی را نیز آشکار کرد. مدیریت پیچیده ایالت گاهی اوقات مرزهای زیبایی را در یک فایل YAML تغییر می دهد. در حالی که GitHub Actions فوق‌العاده مقیاس‌پذیر است، اما برای پلتفرم‌های مقیاس عظیم، صف‌بندی و زمان اجرای گردش‌های کاری می‌تواند در مقایسه با یک API کنترل هواپیمای اختصاصی و کم تأخیر به یک گلوگاه تبدیل شود. امنیت در درجه اول اهمیت قرار داشت. ما باید اسرار و مجوزها را با دقت مدیریت می‌کردیم تا مطمئن شویم که GitHub Action runner حداقل دسترسی لازم برای انجام وظایف خود را دارد - مفهومی که کاملاً با اصول طراحی ایمن Mewayz مطابقت دارد.

نگاهی اجمالی به آینده Git-Centric

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

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

جلوگیری از چندین برنامه را متوقف کنید. Mewayz 208 ابزار را فقط با 49 دلار در ماه ترکیب می کند - از موجودی تا HR، رزرو تا تجزیه و تحلیل. برای شروع نیازی به کارت اعتباری نیست.

Meway را امتحان کنید