امروز، ما کانتینرهای کلودفلر (Cloudflare Containers) را برنامهپذیرتر و برای بارهای کاری ایجنتها بهینهسازی میکنیم. ایجنتها سندباکسها را از پیش مستقر نمیکنند. آنها سندباکسها را بر اساس تقاضا، برای هر کار ایجاد میکنند، انتظار دارند که بلافاصله آماده باشند و بتوانند متوقف و از سر گرفته شوند. بنابراین ما کانتینرها را برای برآورده کردن این الزامات بازمهندسی کردیم: کد شما اکنون میتواند تصویر (Image) و نوع نمونه (Instance Type) هر سندباکس را در زمان اجرا انتخاب کند، کانتینرها ۶ برابر سریعتر شروع به کار میکنند و اسنپشاتهای سیستم فایل در بتای عمومی در دسترس هستند.
برای ممکن ساختن این امر، ما زیرساخت کانتینرها را از پایه دوباره فکر کردهایم. یک سیاست زمانبندی جدید، کنترل هر سندباکس را به کد برنامه منتقل میکند، در حالی که یک زمان اجرای بازطراحیشده، مسیری سریعتر به سمت یک کانتینر در حال اجرا فراهم میکند. در بنچمارک مستقل کمپوتاسدیک (ComputeSDK)، میانگین زمان راهاندازی از کمی بیش از چهار ثانیه به ۶۴۸ میلیثانیه کاهش یافت و در آزمایشهای اولیه خود ما، تست انفجاری با موفقیت صدها هزار کانتینر را در چند ثانیه ایجاد کرد.
همه اینها بر روی چیزی بنا شده است که همیشه کانتینرها را در کلودفلر متمایز کرده است: هر کانتینر شیء بادوام (Durable Object) خاص خود را دریافت میکند، یک کنترلکننده مداوم و برنامهپذیر که درست در کنار آن اجرا میشود و چرخه عمر، ترافیک خروجی و موارد دیگر آن را مدیریت میکند. ما قابلیتهای بیشتری را مستقیماً به API بومی ctx.container میآوریم تا Durable Object بتواند کانتینر خود را بدون یک کلاس پوششدهنده در میان کنترل کند و ما این مدل را به Sandbox SDK 1.0 منتقل میکنیم.
همانطور که اوایل امسال نوشتیم، ایجنت شما به یک کامپیوتر نیاز دارد. این تغییرات کانتینرها را به مکمل بهتری برای Workers، Dynamic Workers و Durable Objects تبدیل میکند زمانی که ایجنتها به یک فضای کاری کامل لینوکس نیاز دارند.
بازاندیشی در زمان اجرای کانتینرها برای ایجنتها
تا به امروز، کانتینرهای کلودفلر حول استقرار برنامهها سازماندهی شده بودند. شما یک تصویر و منابع محاسباتی را در زمان استقرار انتخاب میکنید، آن پیکربندی را در سراسر برنامه پیادهسازی میکنید و آن را به صورت مرکزی مدیریت میکنید. برنامه واحد پیکربندی و استقرار است.
یک فضای کاری ایجنت متفاوت است: در زمان تقاضا، در حالی که ایجنت در حال کار است، ایجاد میشود. کار، تصویر، منابع، ابزارها و سیستم فایل شروع آن را تعیین میکند. ممکن است چند دقیقه وجود داشته باشد، بین درخواستها به خواب برود یا روزها بعد بازیابی شود. آن تصمیمات باید با کد برنامهای که کار را مدیریت میکند زندگی کنند و سندباکس ایجنت باید به سرعت راهاندازی شود، زیرا هر ثانیه از راهاندازی زمانی است که کاربران شما در انتظار سپری میکنند.
ما این الگو را با Base44 در فضاهای کاری ساخت اپلیکیشن و Kilo Code در نشستهای ایجنت ابری دیدهایم. همچنین در ادغامهای ما با Cursor Cloud Agents، Devin Outposts، OpenAI Agents API و Claude Managed Agents ظاهر میشود.
هر یک از این بارهای کاری به چیزی متفاوت از فضای کاری نیاز دارند. ایجنتهای کدنویسی به مخازن، مدیران بسته، کامپایلرها، اجراکنندههای تست و سرورهای توسعه نیاز دارند. ارزیابیها به سندباکسهایی نیاز دارند که از یک حالت شناختهشده شروع شوند. سیستمهای یادگیری تقویتی نیاز به ایجاد، نمرهدهی و بازنشانی تعداد زیادی محیط دارند. کارهای طولانیتر باید فایلهای تولید شده توسط ایجنت را حفظ کنند تا کار بتواند بعداً ادامه یابد.
این الزامات ما را بر آن داشت تا به طور اساسی در نحوه پیکربندی، زمانبندی و ذخیره کانتینرهای کلودفلر تجدیدنظر کنیم. نتیجه یک راه جدید برای پروویژن و زمانبندی کانتینرها است: سیاست زمانبندی durable_object. این به کد شما اجازه میدهد تا تصویر و منابع محاسباتی هر سندباکس را در زمان اجرا انتخاب کند، کانتینرها را بیش از ۶ برابر سریعتر راهاندازی میکند و از اسنپشاتهای سیستم فایل پشتیبانی میکند، بنابراین فضاهای کاری میتوانند ذخیره و بازیابی شوند.
انتخاب سندباکسی که ایجنت شما نیاز دارد، از کد
از همان ابتدا، هر نمونه کانتینر کلودفلر به یک Durable Object متصل بوده است. Durable Object به محیط یک هویت پایدار میدهد و به کد برنامه اجازه میدهد زمان شروع، خواب و توقف آن را کنترل کند. این مدل ثابت کرده است که به ویژه برای سندباکسهای ایجنت مناسب است.
با این حال، تا به امروز، دو تصمیمی که برای یک سندباکس ایجنت بیشترین اهمیت را دارند، در زمان استقرار قفل شده بودند: چه تصویری را اجرا میکند و چه مقدار پردازش دریافت میکند. هر ترکیب از تصویر و نوع نمونه برنامه کانتینرهای خاص خود بود، با فضای نام Durable Object خود، که از قبل با wrangler deploy راهاندازی شده بود.
فرض کنید یک ایجنت به یک سندباکس کوچک Node.js نیاز دارد و دیگری به یک سندباکس بزرگ پایتون برای ساخت نیاز دارد. با رویکرد قبلی ما، این به دو برنامه، دو فضای نام و منطق مسیریابی در Worker شما نیاز داشت تا هر کار را به مسیر درست بفرستد. هر محیط جدید به معنای یک استقرار دیگر بود.
سیاست زمانبندی جدید durable_object این را حذف میکند. تصویر و نوع نمونه اکنون آرگومانهایی هستند که کد شما هنگام شروع سندباکس ارسال میکند. برای انصراف یا پذیرش، سیاست زمانبندی را تنظیم کنید و تصاویری را که Durable Object شما میتواند از بین آنها انتخاب کند اعلام کنید:
استقرارها اکنون فقط کد هستند
انتخاب تصویر در زمان شروع همچنین یکی از دردناکترین بخشهای اجرای کانتینرها را برطرف میکند: استقرارها (Rollouts).
قبل از این، بهروزرسانی یک تصویر به معنای بهروزرسانی کل برنامه بود. شما دورههای مهلت را تنظیم میکنید تا نمونههای در حال اجرا تخلیه شوند، تقسیم درصد را برای جابجایی تدریجی ترافیک تعریف میکنید و با API ما تماس میگیرید تا پیکربندی جدید را فشار دهید. در طول این فرآیند، پلتفرم تصمیم گرفت کدام نمونهها جایگزین شوند و چه زمانی، چه ایجنت در وسط یک کار باشد یا خیر.
با سیاست زمانبندی durable_object، هیچ پیکربندی استقراری وجود ندارد. یک کانتینر میتواند به اجرای تصویری که با آن شروع شده است ادامه دهد تا زمانی که کد شما آن را متوقف کند. دفعه بعد که آن Durable Object یک کانتینر را راهاندازی میکند، از هر تصویری که کد شما انتخاب کند استفاده میکند. این بدان معناست که هر استراتژی استقراری که میخواهید فقط چند خط کد است.
اولین دستورات سریعتر
پیش از این، راهاندازی یک کانتینر مستلزم این بود که هواپیمای کنترل جهانی ما پیکربندی برنامه را حل کند، ظرفیت را پیدا کند و جایگذاری را هماهنگ کند. این مدل برای ناوگانهای در سطح برنامه به خوبی کار میکند، اما ماشینآلات استقرار را در مسیر اولین دستور ایجنت قرار داد.
با سیاست زمانبندی durable_object، تقاضا از Durable Object شروع میشود. زیرساخت کانتینرها که به آن خدمات میدهد، ابتدا به دنبال ظرفیت روی همان دستگاه میگردد، سپس در صورت نیاز جستجو را در همان مکان گسترش میدهد. همچنین میزبانهایی را ترجیح میدهد که از قبل تصویر یا اسنپشات کانتینر را در حافظه محلی خود دارند، بنابراین کانتینر میتواند بدون دانلود کردن آن در ابتدا شروع به کار کند.
ذخیره فضای کاری و بازگشت به آن در زمان دیگر
یک شروع سریع هنوز یک انتظار دیگر را باقی میگذارد: راهاندازی فضای کاری. کلون کردن یک مخزن، نصب وابستگیها و پیکربندی یک ابزار میتواند بسیار طولانیتر از شروع خود کانتینر باشد. همانطور که ایجنت کار میکند، فایلهایی را نیز تولید میکند که میخواهید نگه دارید. تکرار راهاندازی در هر شروع زمان را تلف میکند و از دست دادن تغییرات ایجنت ادامه کار را دشوار میکند.
به همین دلیل است که ما اسنپشاتهای بومی سیستم فایل را به کانتینرها، در بتای عمومی اضافه میکنیم. اسنپشاتها به ایجنت اجازه میدهند کاری را در یک محیط آماده شروع کند، فضای کاری خود را هنگام مکث کار ذخیره کند و آن فایلها را هنگام از سرگیری نشست بازیابی کند.
مزیت Durable Object برای سندباکسهای ایجنت
مسیر زمانبندی سریعتر، انتخاب تصویر در زمان اجرا و اسنپشاتهای سیستم فایل همگی ناشی از یک انتخاب طراحی هستند: تکیه بیشتر بر Durable Object به عنوان کنترلکننده کانتینر متصل به آن.
سیستمهای ایجنت به یک محیط برنامهپذیر و حالتمند در خارج از کانتینر نیاز دارند تا حالت را حفظ کنند، اعتبارنامهها را نگه دارند و چرخه عمر سندباکس را کنترل کنند. شما میتوانید ایجنت را در آنجا اجرا کنید و الگوی «جدا کردن مغز از دست» توصیفشده توسط انتروپیک را دنبال کنید: وقتی ایجنت از سندباکسی که در آن کار میکند جدا است، ایجنت در حالی که سندباکسها و ابزارهایی که میتوانند شروع شوند، متوقف شوند، شکست بخورند یا به طور مستقل جایگزین شوند، در دسترس میماند.
این به چه معناست برای کلاس Container و Sandbox SDK
هنگامی که ما کانتینرها را راهاندازی کردیم، عمدتاً Durable Object را پشت کلاس Container پنهان کردیم. ما میخواستیم سندباکسها آشنا به نظر برسند و با آنچه توسعهدهندگان از پلتفرمهای دیگر انتظار داشتند مطابقت داشته باشند. Sandbox SDK بر روی آن کلاس ساخته شده است و شکافهای واقعی را پر کرد: در آن زمان، زمان اجرا هیچ اجرای دستور بومی، رهگیری درخواست خروجی یا اسنپشات نداشت، بنابراین ما آنها را در فضای کاربر ساختیم.
از آن زمان، فضاهای کاری ایجنت به یکی از بارهای کاری اصلی شکلدهنده کانتینرها تبدیل شدهاند و هزینه آن انتزاع واضح شده است. با پنهان کردن Durable Object، دیدن و ترکیب هویت، حالت و هماهنگی آن را با کانتینری که کنترل میکند برای شما سختتر کردیم.
منبع: blog.cloudflare.com