عکس فوری

چالش

توسعه نرم افزار منبع باز برای استقرار در معماری Arm64 نیازمند یک محیط CI/CD قوی است. با این حال، از لحاظ تاریخی بین سطوح پشتیبانی از معماری‌های پردازنده‌های Arm64 و x86 سنتی تفاوت وجود داشته است که معمولاً Arm64 در نقطه ضعف قرار دارد. توسعه دهندگان اجزای زیرساخت برای چندین معماری انتظارات خاصی از محیط کار خود دارند:

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

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

پوشش آزمایشی: بنابراین آزمایش‌های مشابه برای کارایی، انطباق و امنیت برای همه پلتفرم‌ها به طور همزمان و بدون تمایز اساسی اعمال می‌شود.

قابلیت نگهداری: توسعه‌دهندگان را قادر می‌سازد تا فرآیندهای یکپارچه‌سازی و توسعه مجدد خود را خودکار کنند تا بدون تغییر برای همه پلتفرم‌ها اعمال شوند.

مدیران محصول برای این مؤلفه‌های مشابه، این الزامات را دارند، به علاوه حداقل دو مورد دیگر:

پوشش پلت فرم: قابلیت، به طوری که مدیران حساب فنی (TAM) ممکن است مهارت ها و آمادگی لازم برای پاسخگویی به نیازهای مشتری را داشته باشند.

ردیف پشتیبانی: توانایی، توانمندسازی TAM و سایر پرسنل IT برای طبقه بندی سطوح پشتیبانی نرم افزاری خود بر اساس توانایی خود برای پاسخگویی به مسائل فوری یا نوظهور مشتری

راه حل

الکس الیس، توسعه‌دهنده متن‌باز، با همکاری Ampere و ارائه‌دهنده زیرساخت Equinix، پلتفرم Actuated CI/CD خود را در اختیار برخی از حیاتی‌ترین پروژه‌های منبع باز در اکوسیستم نرم‌افزاری ابری قرار داد.

Actuated فرآیندهای اتوماسیون خود میزبان GitHub را که توسط مهندسان امنیتی نشان داده شده است به عنوان ذاتاً آسیب پذیر در برابر حملات مخرب دریافت می کند و آنها را در microVM های انتزاعی از اینترنت عمومی اجرا می کند.

پیاده سازی

چندین پروژه منبع باز کلیدی Cloud Native Computing Foundation از یک محیط Actuated برای اجرای همه GitHub Actions خود برای Arm64 استفاده کردند. این محیط مبتنی بر پردازنده های Ampere® Altra® است که با کمک ارائه دهنده زیرساخت Equinix در دسترس قرار گرفته است.

موفقیت این ابتکار در ترغیب GitHub به اجرای پشتیبانی کامل از معماری Arm64 با GitHub Actions بسیار مؤثر بود. اکنون، توسعه‌دهندگانی که فرآیندهای ساخت Arm64 را در محیط‌های شبیه‌سازی QEMU روی معماری‌های x86 اجرا کرده‌اند، می‌توانند آن فرآیندها را به Arm64 روی فلز خالی منتقل کنند.

دونده های خود میزبان برای GitHub Actions در ARM64

GitHub این روزها میزبان پروژه های نرم افزاری است. محبوب‌ترین روشی که پروژه‌های میزبان GitHub، ساخت‌ها و نسخه‌هایی را برای یکپارچگی مداوم تولید می‌کنند، مجموعه ابزار CI داخلی پلتفرم، GitHub Actions است. مهمترین نقشی که پلتفرم GitHub Actions CI/CD ایفا می کند، اتوماسیون خطوط لوله توسعه نرم افزار است.

طرفی که مسئول راه اندازی هر اقدام GitHub است یک دونده است. این عاملی است که روی یک سرور در حال اجراست، منتظر کاری است که انجام دهد و مشتاق انجام آن پس از انجام وظیفه است. کاری از جریان کار به آن داده شده و وظیفه انجام آن داده شده است.

GitHub یک پلت فرم استقرار نرم افزار کامل است. به این ترتیب، دونده های خود را میزبانی می کند که هر کدام با محیط و معماری هدف مشخص شده خود سازگار شده اند. تا همین اواخر، GitHub محیط های میزبانی را برای Arm64 ارائه نمی کرد. پروژه‌هایی که می‌خواستند ساخت‌های بومی Arm64 تولید کنند، یک گزینه داشتند - دونده خود میزبان.

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

در مورد CNCF، توسعه‌دهندگان از اعتبارات Equinix Metal استفاده کردند و آنها را قادر ساختند تا نمونه‌های فلزی خالی از آنها را به عنوان دونده‌های خود میزبان برای پروژه‌ها فراهم کنند. اما برای یک آزمایشگاه کد که پروژه‌های آن باید 24/7/365 در دسترس سایر توسعه‌دهندگان در سراسر جهان قرار گیرد، امنیت دونده‌های خود میزبان یک چالش را ایجاد می‌کند: طبق مستندات GitHub، هرکسی می‌تواند مخزن پروژه را شبیه‌سازی کند، کارهای Actions را اصلاح کند و به گره runner برای اجرای کارهای دلخواه دسترسی داشته باشد.

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

این یک مشکل ایجاد کرد - هنگام اجرای یک کار CI برای ساخت یا آزمایش نرم افزار، باید یک محیط کنترل شده داشته باشید، به طوری که تنها چیزی که بین اجراها تغییر می کند، نرم افزار است. در مورد دوندگانی که خود میزبان هستند، محیط می تواند در طول زمان تغییر کند. در غیاب فرآیند پاکسازی، این امکان وجود داشت که اجرای یک کار ساخت بر روی یک میزبان، نتایج متفاوتی را در طول زمان ایجاد کند.

یکی از راه هایی که توسعه دهندگان نیاز به رانرهای بومی Arm64 را دور زدند اجرای محیط های مجازی Arm64 بر روی سرورهای x86 با استفاده از شبیه سازی متن باز QEMU بود. محیط‌های شبیه‌سازی‌شده، سربار کارایی زیادی را برای کامپایل‌های نرم‌افزار اضافه می‌کنند، که با کسری از سرعت کامپایل‌ها روی سخت‌افزار بومی و غیر شبیه‌سازی شده اجرا می‌شوند.

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

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

اد ویلمتی
مدیر شریک توسعه دهنده، Equinix

پدیده نابرابری

برخلاف شرکت‌های معمولی، بنیاد محاسبات بومی Cloud تعهد ویژه‌ای برای ساخت اجزای بومی ابری خود برای تمام معماری‌های اصلی پردازنده‌های جهان دارد.

پروژه‌هایی مانند زمان اجرای کانتینر قابل حمل کانتینری، ذخیره‌سازی داده‌های کلید/مقدار etcd، جمع‌آوری داده‌های گزارش روان، ابزار تشخیص تهدید بلادرنگ Falco، و ابزار مشاهده‌پذیری و ابزار دقیق OpenTelemetry، در میان ده‌ها پروژه دیگر، وابستگی‌های حیاتی برای اکوسیستم بومی ابری هستند، و به همین دلیل، باید برای هر دو x86 و Arm66 ساخته شوند.

برای ساخت اجزای زیرساختی سطح پایین با پشتیبانی از Arm64، توسعه دهندگان CNCF نیاز به دسترسی به زیرساخت بومی Arm64 دارند. این بدان معناست که از قضا، آنها به همان دسته از ابزارهایی که سعی در ایجاد آن دارند نیاز دارند.

در ابتدا، Ampere و Equinix با CNCF برای غلبه بر این شکاف‌ها، با اهدای سرورهای مبتنی بر Ampere Altra یا راه‌اندازی گره‌های فلزی برهنه مبتنی بر Altra در تأسیسات Equinix همکاری کردند. جزئیات منابع سرور مبتنی بر Arm64 که Equinix می‌توانست به اشتراک بگذارد، گره‌های فلزی خالی بودند - سیستم 160 هسته‌ای دو سوکت Ampere Altra.

در حالت ایده‌آل، سروری مانند این بین چندین پروژه به اشتراک گذاشته می‌شد، اما در آن زمان این فراتر از قابلیت‌های CNCF بود. این مشکلی است که Ampere و Actuated برای حل CNCF پیشنهاد کردند، با اجازه دادن به پروژه‌های متعدد برای اجرا بر روی تعداد کمتری از هاست‌ها، بنابراین دسترسی آسان به ساخت سرویس‌ها برای پروژه‌های بیشتر، در حالی که سخت‌افزار کمتری مصرف می‌شود، فراهم می‌کنند.

"OpenTelemetry یک سیستم CI/CD تمام وقت، تمام وقت است. ما توانستیم از زیرساخت [سرور Ampere خود] برای خودمان استفاده کنیم، اما نتوانستیم آن را با منبع باز به اشتراک بگذاریم. ما نمی توانیم GitHub runners را کنار بگذاریم. هنگامی که از صدور گواهینامه توزیع های پایین دستی به مشتریان خود خوشحال شدیم، ما مشکلاتی را در مورد پروژه OpenRM4 ارائه کردیم که ARM6T را پشتیبانی می کند. بالاترین سطح - به این معنی که باید برای هر commit اجرا شود، باید همیشه اجرا شود و بازخورد عالی بود، اما هیچ رانر ARM64 در GitHub وجود ندارد.

آنتوان تولمه
مدیر ارشد مهندسی برای بلاک چین و DLT، Splunk
Maintainer، پروژه OpenTelemetry

در نتیجه در دسترس نبودن پلتفرم‌های آسان Arm64 برای این پروژه‌ها، توسعه‌دهندگان نمی‌دانستند که آیا تغییراتی که انجام می‌دهند باعث ایجاد مشکل در Arm64 می‌شود، زیرا مجموعه‌های آزمایشی به اندازه x86 به دفعات اجرا نمی‌شوند.

از آنجایی که پلتفرم‌های ارکستراسیون کانتینر از جمله پلتفرم‌هایی هستند که برای پشتیبانی از Arm64 توسعه می‌یابند، این پدیده تبدیل به یک چرخه معیوب شد: نسخه‌ها با گذراندن مجموعه‌های آزمایشی یکپارچه‌سازی برای x86 در نظر گرفته شدند، اما نسخه‌های منتشر شده در مجموعه‌های آزمایشی مشابهی که برای Arm64 تصویب می‌شد، در دسترس نبودند.

راه حلی که توسعه دهندگان CNCF کشف خواهند کرد، بسیار کمتر از حد رادیکال یا انقلابی بودن است – در واقع، در عمل بیشتر یک رفع اشکال است. پیاده سازی آن به قدری ساده است که این تفاوت را نه تنها برای CNCF بلکه برای هر توسعه دهنده هر مؤلفه در سطح پلت فرم برای هر معماری کاملاً جبران می کند.

پیشرفت: فعال، به علاوه ویرایش یک خط کد

برای برداشتن اولین قدم به سمت برابری پلتفرم بین x86 و Arm64، Ampere از الکس الیس، خالق سرویسی به نام Actuated کمک گرفت. این محصولی است که کارهای GitHub Actions را در microVMهای ایمن و ایزوله اجرا می‌کند، ابزاری برای دریافت کارهای ساخت از GitHub Actions دارد و به توسعه‌دهندگان امکان مشاهده عملکرد کارهای ساخت خود و بار روی سیستم‌های ساخت مشترک را می‌دهد.

Actuated می‌تواند تمام اجراکننده‌های GitHub Actions موجود CNCF را پس از تغییر یک خط از فایل‌های پیکربندی آن‌ها، به‌علاوه در برخی موارد چسباندن چند قطعه کد - تغییراتی که کمتر از پنج دقیقه طول کشید، اجرا کند. این تغییرات پروژه‌های میزبان GitHub را قادر می‌سازد تا به محیط مبتنی بر microVM Actuated در پردازنده‌های Ampere Altra برای کارهای ساخت خود اشاره کنند.

فالکو واقعاً به رانرهای Arm64 GitHub نیاز داشت تا پشتیبانی خود از معماری را افزایش دهد و پایگاه کاربری خود را افزایش دهد. [Actuated] راه حلی عالی برای ما بود، زیرا به راحتی می توان از آن استفاده کرد و هر باری را از دوش نگهبانان برداشت. به این ترتیب، ما به عنوان نگهبان می توانیم به جای مبارزه با تعمیر و استقرار زیرساخت ها، روی آنچه واقعاً برای پروژه مهم است تمرکز کنیم. مصنوعات برای ARM64، با استفاده از Actuated برای بسیاری از پروژه‌های ما، و بی‌عیب کار می‌کند.»

فدریکو دی پیرو
مهندس ارشد منبع باز، Sysdig
نگهدارنده، پروژه فالکو

با مشاهده افزایش تقاضا برای محیط‌های ساخت بومی Arm در سال‌های اخیر، GitHub در ژوئن گذشته در دسترس بودن رانرهای میزبان مبتنی بر Arm64 برای GitHub Actions را در نسخه بتای عمومی اعلام کرد که توسط نمونه‌های محاسباتی Ampere در Microsoft Azure ارائه می‌شود و در ژانویه 2025 با انتشار پیش‌نمایش عمومی رانرهای میزبان رایگان برای ذخیره عمومی.

برای OpenTelemetry، این به معنای پایان بارگذاری شبکه به اندازه 10 برابر پهنای باند اختصاص داده شده آنها است، به دلیل اینکه OpenTelemetry وابستگی‌های دائمی را از مخازن Docker Hub ایجاد می‌کند.

"بله، ما قطعاً چیزهایی را می‌شکستیم. ما خوش شانس بودیم، زیرا Arm runner برای GitHub ارسال شد. ما به دوندگان ARM منتقل شده‌ایم، تا آنجا که می‌توانیم خوشحالیم و دیگر چیزی خراب نمی‌شود."

آنتوان تولمه
مدیر ارشد مهندسی برای بلاک چین و DLT، Splunk
Maintainer، پروژه OpenTelemetry

اکنون برای اولین بار، نگهبانان پروژه می‌توانند به همان اندازه که برای ساخت‌های x86 به ایمنی و امنیت ساخت‌های Arm64 توجه می‌کنند، توجه کنند و بدانند که دیگر به احتمال زیاد با کاهش عملکرد یا جریمه مواجه نمی‌شوند.

"[Actuated] به ما در ساخت‌های CI در ARM64 اطمینان زیادی داد. اگر Arm CI اکنون خراب شود، هیچ راهی وجود ندارد که [درخواست کشش] را ادغام کنیم تا زمانی که دلیل آن را بفهمیم... اکنون اطمینان کامل داریم که [شکست‌های ساخت] مشکلی با سخت‌افزار پوسته‌پوسته نیست [مانند موارد قبل].

فیل استس
مهندس نرم افزار اصلی، AWS
نگهدارنده، پروژه کانتینر

به نوبه خود، اوراکل به سیاست خود مبنی بر اهدای 3 میلیون دلار در سال اعتبارات OCI برای نمونه های Arm64 که توسط Ampere به پروژه های CNCF کمک می کند، ادامه می دهد. این سخاوت، همراه با پایداری جدید پلتفرم‌های Arm64 که توسط Ampere و Equinix کاتالیز شده و توسط Actuated ایجاد شده است، به فروشندگان برجسته زیرساخت‌های ابری از جمله Red Hat، SUSE، Canonical و Mirantis اجازه می‌دهد تا برای مشتریان سازمانی خود که زیرساخت ARM64 را انتخاب می‌کنند، پشتیبانی کامل ارائه دهند.

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

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

تسطیح کردن زمین بازی

در اوایل سال 2023، گزینه‌های کمی برای پروژه‌های میزبان GitHub وجود داشت که می‌خواستند Arm64 را به طور کامل در فرآیندهای ادغام مداوم خود ادغام کنند. از طریق این ابتکار، استفاده از یک راه‌حل نرم‌افزاری نوآورانه از Actuated با CPU‌های Ampere که توسط Equinix میزبانی می‌شوند، سطح پروژه‌های CNCF را کاهش داد تا شروعی به سمت پشتیبانی از ARM64 و x86 باشد.

پروژه‌های اصلی ابری مانند etcd، containerd، Open Telemetry، Falco و دیگران توانستند پشتیبانی خود از ARM64 را افزایش دهند، اجرای CI خود را در زیرساخت اصلی Arm64 تسریع بخشند و از تعداد فزاینده‌ای از کاربران خود که از محاسبات Arm64 در فضای ابری بهره می‌برند، پشتیبانی کنند.

با پایان این پروژه آزمایشی، تعداد گزینه های توسعه دهندگان به طور قابل توجهی افزایش یافته است. CNCF اکنون به پروژه‌های خود توانایی اجرای کارهای GitHub Actions را روی خوشه‌های مدیریت‌شده Kubernetes در OCI، با استفاده از نمونه‌های مجهز به آمپر و کنترلر Actions Runner پروژه GitHub ارائه می‌کند، و با اضافه شدن اجراکننده‌های میزبانی Arm64 به GitHub، هرگز برای پروژه‌ها آسان‌تر نبوده است که به راحتی از این معماری برنامه‌های ابری در حال رشد پشتیبانی کنند.

خبرکاو