ارزیابی خودکار کد با Agent Sandbox در GKE

۱. مقدمه

در این آزمایشگاه کد، شما برنامه Hackathon Judge را روی Google Kubernetes Engine (GKE) مستقر خواهید کرد و از Kubernetes-sigs Agent Sandbox برای اجرای ایمن و مطمئن بارهای کاری agentic استفاده خواهید کرد.

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

کاری که انجام خواهید داد

  • سرویس‌های گوگل کلود هدف را فراهم کنید و APIهای هدف را ایجاد کنید.
  • GKE Autopilot را راه‌اندازی اولیه کنید و CRDهای مربوط به Agent Sandbox، پیکربندی‌های کلاستر و روتر Sandbox را نصب کنید.
  • دروازه‌ی سندباکس (Sandbox Gateway)، الگوی درخواست سندباکس (Sandbox Claim Template) و استخر گرم سندباکس (Sandbox WarmPool) را مستقر کنید.
  • API بک‌اند REST، عامل کارگر ADK Judging و رابط کاربری فرانت‌اند React را مستقر کنید.
  • مسیریابی متعادل‌کننده بار خارجی را سیم‌کشی کنید و به پلتفرم دسترسی داشته باشید تا گردش‌های کاری داوری ایمن و سندباکس‌شده را اجرا کنید.

آنچه نیاز دارید

  • یک مرورگر وب مانند کروم .
  • یک پروژه گوگل کلود با قابلیت پرداخت.

منابع ایجاد شده در این آزمایشگاه کد باید کمتر از ۵ دلار در کل هزینه‌های زمان اجرا هزینه داشته باشند.

۲. مشکل: ارزیابی امن کد غیرقابل اعتماد

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

اجرای مستقیم کد غیرقابل اعتماد روی زیرساخت شما، شما را در معرض خطراتی مانند موارد زیر قرار می‌دهد:

  • تزریق کد : اسکریپت‌های مخرب می‌توانند سعی کنند به داده‌های حساس دسترسی پیدا کنند یا آنها را تغییر دهند.
  • افزایش امتیاز : کد ممکن است تلاش کند تا به صورت غیرمجاز به سایر سیستم‌ها یا منابع شبکه دسترسی پیدا کند.
  • سوء استفاده از منابع : کدهای ضعیف نوشته شده یا حملات انکار سرویس می‌توانند CPU، حافظه یا پهنای باند شبکه را بیش از حد مصرف کنند و بر سایر عملیات تأثیر بگذارند.

برای خودکارسازی داوری هکاتون با هوش مصنوعی، به روشی نیاز داریم که کد ارسالی را در محیطی کاملاً ایزوله از بقیه سیستم و سایر موارد ارسالی اجرا کنیم.

۳. راه حل: GKE Agent Sandbox

GKE Agent Sandbox قابلیتی است که دقیقاً برای همین چالش طراحی شده است. این قابلیت به مدیریت بارهای کاری ایزوله، حالت‌مند و تک‌نسخه‌ای در GKE کمک می‌کند و برای مواردی مانند زمان‌های اجرای عامل هوش مصنوعی که در آن‌ها کد غیرقابل اعتماد باید به صورت ایمن و کارآمد اجرا شود، بهینه شده است.

مزایای کلیدی Agent Sandbox عبارتند از:

  • ایزولاسیون در سطح هسته : با استفاده از فناوری‌هایی مانند gVisor ، ایزولاسیون قوی در سطح هسته را برای کدهای غیرقابل اعتماد فراهم می‌کند و از دسترسی کد به سیستم میزبان یا سایر کانتینرها جلوگیری می‌کند.
  • تأمین زیر-ثانیه : تأمین سریع محیط‌های سندباکس (معمولاً کمتر از ۱ ثانیه) را ارائه می‌دهد، که برای ارزیابی کد بر اساس تقاضا بسیار مهم است.
  • توسعه‌پذیری ابری : از قدرت Kubernetes و زیرساخت مدیریت‌شده‌ی GKE بهره می‌برد.

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

۴. قبل از شروع

شروع پوسته ابری

برای شروع Google Cloud Shell، که از قبل با ابزارهای خط فرمان مورد نیاز برای توسعه‌دهندگان و فضای ابری پیکربندی شده است، روی دکمه زیر کلیک کنید.

فعال کردن APIها

دستور زیر را در Cloud Shell اجرا کنید تا تمام APIهای Google Cloud مورد نیاز برای اجرای پلتفرم فعال شوند:

gcloud services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  pubsub.googleapis.com \
  aiplatform.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com

چرا این APIها را فعال می‌کنیم: سرویس‌های Google Cloud به طور پیش‌فرض غیرفعال هستند تا از دسترسی غیرمجاز و هزینه‌های اضافی جلوگیری شود. ما این APIهای خاص را برای فعال کردن هماهنگی کانتینر (GKE)، ذخیره‌سازی امن کانتینر (Artifact Registry)، بسته‌بندی ساخت بدون سرور (Cloud Build)، صف‌های پیام‌رسانی قابل اعتماد (Pub/Sub)، سرویس‌های مدل هوش مصنوعی (Vertex AI)، پیکربندی پروژه (Cloud Resource Manager & IAM)، تجزیه و تحلیل داده‌های بدون سرور (BigQuery) و اتصال هوش مصنوعی در سطح پایگاه داده (BigQuery Connection) فعال می‌کنیم.

۵. زیرساخت را راه‌اندازی کنید

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

مخزن را کلون کنید

مخزن حاوی تمام سرویس‌های برنامه، اسکریپت‌های راه‌اندازی و اعلان‌های مانیفست Kubernetes را کلون کنید:

git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-2/hackathon-judge
cd codelabs/ai-toolkit-lab-2/hackathon-judge

اجرای اسکریپت استقرار

راه‌اندازی اولیه منابع ابری، مدل‌های پایگاه داده و سیاست‌های اولیه خوشه‌بندی Kubernetes شما توسط اسکریپت deploy.sh خودکار می‌شود.

اسکریپت را اجرا کنید:

./deploy.sh

برای ارائه پیکربندی‌هایی مانند شناسه پروژه فعال و منطقه هدف، دستورالعمل‌های تعاملی پوسته را دنبال کنید. اسکریپت به طور خودکار یک پیکربندی محلی .env ایجاد می‌کند، منابع را متصل می‌کند، تصاویر کانتینر را کامپایل می‌کند و زیرساخت پایه GKE را ثبت می‌کند.

در اینجا عملیات هدف انجام شده توسط اسکریپت آمده است:

۱. تنظیمات پیکربندی محیط

این اسکریپت یک فایل پیکربندی .env برای ذخیره پارامترهای GKE، Pub/Sub، BigQuery و متغیرهای پروژه ایجاد می‌کند. با استفاده از این فایل، تمام تعاریف بعدی مانیفست Kubernetes به صورت پویا پر می‌شوند.

چرا این فایل محیطی را پیکربندی می‌کنیم: فایل .env پارامترهای پیکربندی را متمرکز می‌کند و تضمین می‌کند که مانیفست‌های GKE که ما در مراحل بعدی به صورت دستی اعمال می‌کنیم، از تنظیمات منطقه‌ای، نام پروژه‌ها و منابع یکسانی استفاده کنند و پیکربندی محیطی را به شدت از کد منبع جدا کنند.

۲. پیکربندی رابط خط فرمان گوگل کلود و پروژه هدف

این اسکریپت تأیید می‌کند که ابزارهای gcloud ، bq ، kubectl و envsubst نصب شده‌اند، وضعیت احراز هویت را بررسی می‌کند و اهداف پیکربندی فعال را روی پروژه فعال Google Cloud شما قفل می‌کند.

چرا پروژه فعال را هدف قرار می‌دهیم: تنظیم پروژه هدف فعال مانع از تأثیرگذاری دستورات CLI بر سایر پروژه‌های حساب شما می‌شود و بررسی‌های احراز هویت قبل از اجرا را انجام می‌دهد و اطمینان حاصل می‌کند که دستورات راه‌اندازی در اواسط استقرار به دلیل اعتبارنامه‌های نامعتبر با شکست مواجه نمی‌شوند.

۳. فعال کردن API های Target Google Cloud

این اسکریپت یک بررسی خود-توان (idempotent) برای تأیید و فعال‌سازی APIهای سرویس Google Cloud هدف (GKE، Artifact Registry، Cloud Build، Pub/Sub، Vertex AI، BigQuery و IAM) انجام می‌دهد.

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

۴. آماده‌سازی مخزن Docker رجیستری Artifact

این اسکریپت یک مخزن کانتینر داکر به نام hackathon-judge-repo در مکان هدف انتخاب شده فراهم می‌کند.

چرا ما یک مخزن Artifact Registry ایجاد می‌کنیم: کلاسترهای GKE برای دریافت سریع تصاویر برنامه، نیاز به دسترسی ایمن به رجیستری‌های کانتینر خصوصی در همان شبکه منطقه‌ای دارند. Artifact Registry یک میزبان امن و خصوصی برای فهرست‌بندی، اسکن و ذخیره تصاویر کانتینر Docker فراهم می‌کند.

۵. آماده‌سازی خوشه خلبان خودکار GKE

این اسکریپت یک کلاستر Autopilot از موتور کوبرنتیز گوگل (GKE) به نام hackathon-judge-cluster فراهم می‌کند.

چرا ما یک کلاستر GKE Autopilot را مستقر می‌کنیم: GKE Autopilot به طور خودکار مدیریت تأمین گره، مقیاس‌بندی، نظارت بر سلامت و ارتقاء امنیت سیستم عامل میزبان را بر عهده دارد. این یک پلتفرم کانتینر در سطح تولید را برای هماهنگ‌سازی سرویس‌های پایدار ما فراهم می‌کند و به صورت پویا، sandboxهای امن worker را بر اساس تقاضا زمان‌بندی می‌کند.

۶. پیکربندی موضوعات و اشتراک‌های Pub/Sub

این اسکریپت، موضوعات پیام ( judging-tasks و judging-results ) را به همراه worker و API های مربوطه فراهم می‌کند.

چرا ما موضوعات و اشتراک‌های Pub/Sub را پیاده‌سازی می‌کنیم: ارزیابی ارسال کد کند و نیازمند منابع زیادی است. استفاده از معماری صف پیام، API همزمان کاربر-محور را از گره‌های کارگر جدا می‌کند. بخش پشتی API، کارها را به موضوع judging-tasks ارسال می‌کند و عوامل کارگر وظایف را به محض در دسترس بودن دریافت می‌کنند و از مسدود شدن API جلوگیری کرده و قابلیت‌های تلاش مجدد خودکار را فراهم می‌کنند.

۷. پیکربندی مجموعه داده‌ها، جداول و اتصالات هوش مصنوعی BigQuery

این اسکریپت مجموعه داده hackathon_judge را ایجاد می‌کند، طرحواره‌های ساختاری پایگاه داده SQL را اعمال می‌کند، رکوردهای اولیه را بارگذاری می‌کند و نقش‌های هوش مصنوعی و ذخیره‌سازی مورد نیاز را به حساب سرویس اتصال BigQuery ML اعطا می‌کند.

۸. راه‌اندازی ساخت کانتینر با استفاده از Cloud Build

این اسکریپت تعریف cloudbuild.yaml را برای کامپایل رابط کاربری React، سرور Go REST، کارگر ADK پایتون و جعبه شنی FastAPI ما آغاز می‌کند، آنها را در تصاویر کانتینر ایزوله شده با برچسب مخزن فعال Git commit SHA بسته‌بندی کرده و در Artifact Registry ذخیره می‌کند.

۹. ثبت تعاریف منابع سفارشی (CRD) در سندباکس عامل

این اسکریپت جدیدترین Kubernetes-sigs Agent Sandbox Custom Resource Definitions ( manifest.yaml و extensions.yaml ) را دانلود و ثبت می‌کند تا قابلیت‌های اصلی GKE را گسترش دهد.

چرا زیرساخت Agent Sandbox را نصب می‌کنیم: کلاسترهای استاندارد Kubernetes از تخصیص Sandboxهای محافظت‌شده بر اساس تقاضا پشتیبانی نمی‌کنند. ثبت CRDهای Agent Sandbox، صفحه کنترل GKE را گسترش می‌دهد و Kubernetes را قادر می‌سازد تا به صورت بومی، میکرو کانتینرهای امن Sandbox شده را با استفاده از منابع سفارشی (مانند SandboxTemplates و SandboxClaims) هماهنگ کند.

۱۰. پیکربندی فضاهای نام، حساب‌های سرویس و هویت بار کاری

این اسکریپت، فضای نام hackathon-judge را فراهم می‌کند، حساب‌های سرویس Kubernetes (KSA) را ثبت می‌کند و نگاشت‌های هویت بار کاری را برای اعطای مجوزهای Google Cloud به پادهای GKE ایجاد می‌کند.

۱۱. استقرار روتر Sandbox

این اسکریپت مانیفست k8s/sandbox_router.yaml را اعمال می‌کند، استقرار و سرویس Sandbox Router را آغاز می‌کند و منتظر می‌ماند تا به وضعیت سالم برسند.

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

۶. پیکربندی Agent Sandbox Gateway، Claims و WarmPool

در این مرحله، شما به صورت دستی Gateway شبکه تخصصی Sandbox را پیکربندی خواهید کرد، الگوی درخواست Sandbox را ثبت می‌کنید و Sandbox WarmPool را برای فعال کردن sandboxing با تأخیر بسیار کم مستقر خواهید کرد.

متغیرهای محیطی منبع

قبل از اعمال قالب‌هایی که به متغیرهای محیطی نیاز دارند، اسکریپت setup-env.sh را سورس کنید تا تمام متغیرهای لازم را تجزیه و به پوسته خود صادر کنید:

source ./setup-env.sh

اعمال دروازه سندباکس

دروازه‌ای را که به‌طور خاص برای مسیریابی ترافیک سندباکس پیکربندی شده است، مستقر کنید:

kubectl apply -f k8s/sandbox-gateway.yaml

چرا ما از دروازه سندباکس (Sandbox Gateway) استفاده می‌کنیم: دروازه سندباکس به عنوان یک کنترل‌کننده ورودی امن و با کارایی بالا عمل می‌کند که منحصراً به مسیریابی سندباکس اختصاص داده شده است. این دروازه، شبکه سندباکس را ایزوله می‌کند و یک هدف محلی امن فراهم می‌کند که به عوامل کاری اجازه می‌دهد تا با سندباکس‌های مورد ادعا ارتباط برقرار کنند، بدون اینکه نقاط پایانی به صورت خارجی در معرض دید قرار گیرند.

الگوی درخواست سندباکس را اعمال کنید

envsubst برای پر کردن تعریف الگوی sandbox با متغیرهای محیطی فعال خود و اعمال آن استفاده کنید:

source ./setup-env.sh
envsubst < k8s/sandbox-claim-template.yaml | kubectl apply -f -

چرا ما از الگوی Sandbox Claim استفاده می‌کنیم: الگوی Sandbox Claim به عنوان پیکربندی طرح اولیه عمل می‌کند و محیط را تعریف می‌کند. این الگو، تصویر کانتینری که باید اجرا شود (از پیش بسته‌بندی شده با ابزارهای توسعه‌دهنده)، پارامترهای محیط (شناسه پروژه GCP)، پورت‌ها و محدودیت‌های منابع (اهداف CPU/Memory) را مشخص می‌کند. این الگو GKE را برای اجرای این نمونه‌های کانتینر با استفاده از gVisor (زمان اجرای gvisor) پیکربندی می‌کند و تضمین می‌کند که کد مشارکت‌کننده غیرقابل اعتماد تحت یک لایه اضافی از جداسازی مجازی‌سازی هسته اجرا شود.

اعمال Sandbox WarmPool

برای پیش‌مقداردهی اولیه‌ی سندباکس‌های در حال اجرا، از Sandbox WarmPool استفاده کنید:

kubectl apply -f k8s/sandbox-warmpool.yaml

تأیید کنید که نمونه‌های آماده به کار استخر گرم با موفقیت شروع به کار کرده‌اند:

kubectl get pods -n hackathon-judge -l app=sandbox

چرا Sandbox WarmPool را مستقر می‌کنیم: آماده‌سازی، زمان‌بندی، دریافت تصاویر و بوت کردن پادهای کانتینر جدید بر اساس تقاضا، سربار راه‌اندازی قابل توجهی را ایجاد می‌کند (زمان شروع سرد بیش از 30 ثانیه). Sandbox WarmPool مجموعه‌ای از پادهای فعال و از پیش گرم شده (5 کپی به طور پیش‌فرض) را در حالت آماده به کار نگه می‌دارد. هنگامی که عامل کارگر درخواست یک محیط ارزیابی را می‌دهد، روتر Sandbox بلافاصله یک پاد از پیش گرم شده در حال اجرا را اختصاص می‌دهد و تأخیرهای راه‌اندازی را به سرعت‌های زیر ثانیه کاهش می‌دهد.

۷. استقرار اجزای برنامه

با فعال شدن کامل زیرساخت سندباکسینگ امن، اکنون API مرکزی بک‌اند، worker agent، رابط وب React و نگاشت دروازه ورودی را مستقر خواهید کرد.

استقرار بک‌اند

بک‌اند REST API هماهنگ‌کننده را مستقر کنید:

source ./setup-env.sh
envsubst < k8s/backend.yaml | kubectl apply -f -

عامل استقرار

مامور کارگر قضاوت کننده ADK را مستقر کنید: 

source ./setup-env.sh
envsubst < k8s/agent.yaml | kubectl apply -f -

استقرار فرانت‌اند

رابط کاربری وب تعاملی را مستقر کنید: 

source ./setup-env.sh
envsubst < k8s/frontend.yaml | kubectl apply -f -

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

گیت‌وی اصلی را مستقر کنید و مسیرهای HTTP ورودی را که ترافیک کلاینت خارجی را نگاشت می‌کنند، وارد کنید: 

kubectl apply -f k8s/gateway.yaml

چرا ما External Ingress Gateway را پیاده‌سازی می‌کنیم: External Gateway سرویس‌های ما را با استفاده از Kubernetes Gateway API در معرض نمایش قرار می‌دهد. این Gateway یک آدرس IP عمومی با بارگذاری متعادل فراهم می‌کند و مسیرها را بر اساس قوانین مسیر نگاشت می‌کند - درخواست‌های API تحت /api/* را به Go Backend هدایت می‌کند و تمام ترافیک وب کلاینت دیگر ( / ) را به React Frontend نگاشت می‌کند و دسترسی به کلاستر عمومی را تضمین می‌کند.

تأیید انتشارها

اجرای shell را مسدود کنید و منتظر بمانید تا هر سه سرویس اصلی به وضعیت آماده و سالم برای انتشار برسند: 

kubectl rollout status deployment/backend -n hackathon-judge --timeout=300s
kubectl rollout status deployment/agent -n hackathon-judge --timeout=300s
kubectl rollout status deployment/frontend -n hackathon-judge --timeout=300s

۸. تأیید و استفاده از برنامه

دسترسی به رابط کاربری

آدرس IP عمومی خارجی مربوط به دروازه متعادل‌کننده بار اصلی که به تازگی فراهم شده است را دریافت کنید:

برای مشاهده وضعیت ارائه خدمات به صورت بلادرنگ، دستور را با علامت watch ( -w ) اجرا کنید و منتظر بمانید تا یک آدرس IP عمومی در فیلد ADDRESS ثبت شود: 

kubectl get gateway -n hackathon-judge hackathon-judge-gateway -w

وقتی با موفقیت آماده‌سازی انجام شد، باید خروجی مشابه زیر را ببینید: 

NAME                      CLASS    ADDRESS          PROGRAMMED   AGE
hackathon-judge-gateway   gke-l7   34.120.120.120   True         3m

زمانی که یک آدرس IP عمومی معتبر را در ستون ADDRESS مشاهده کردید و وضعیت PROGRAMMED برابر با True بود، Ctrl+C را برای توقف بررسی فشار دهید.

چرا وضعیت Gateway را دریافت می‌کنیم: API مربوط به Gateway، ورودی‌های عمومی را مدیریت می‌کند. بررسی وضعیت Gateway، آدرس IP خارجی عمومی و متعادل‌شده‌ی بار اختصاص داده‌شده توسط متعادل‌کننده‌ی بار سراسری خارجی Google Cloud به کلاستر ما را برمی‌گرداند که نشان‌دهنده‌ی آدرس عمومی پلتفرم ما است.

آدرس IP عمومی اختصاص داده شده را در مرورگر خود باز کنید تا داشبورد Hackathon Judge بارگذاری شود.

ارسال وظایف

  • از رابط کاربری فرانت‌اند برای رفتن به داشبورد استفاده کنید، هکاتون را انتخاب کنید.

داشبورد

  • در هر پروژه‌ای می‌توانید روی Run Agent کلیک کنید تا عامل شروع به ارزیابی کل پروژه بر اساس روبریک کند.

پروژه‌ها

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

پادهای فعال داخل فضای نام hackathon-judge را رصد کنید تا یک پاد جعبه شنی را که به صورت پویا برای اجرای داوری ادعا و آماده شده است، مشاهده کنید: 

kubectl get pods -n hackathon-judge -w

برای مشاهده منطق ارزیابی قضاوت گام به گام ADK، لاگ‌های worker agent pod را بررسی کنید: 

kubectl logs -l app=agent -n hackathon-judge

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

۹. (اختیاری) نحوه‌ی کار این

معماری سندباکس عامل

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

اجرای کد خام کاربر خطرات امنیتی گسترده‌ای از جمله نفوذ به میزبان، اختلال در کانتینرها و دسترسی غیرمجاز به منابع را به همراه دارد. چارچوب GKE Agent Sandbox با هماهنگ‌سازی بارهای کاری ایزوله Sandbox با استفاده از مجازی‌سازی gVisor (runsc) این خطرات را کاهش می‌دهد.

جریان تعامل سیستم

نمودار زیر نحوه ارتباط عناصر مختلف سیستم رویداد محور ما را در طول اجرای داوری امن در محیط سندباکس نشان می‌دهد:

نحوه همکاری ابزارها و اجزای درگیر

  • رابط کاربری React Frontend : یک رابط کاربری تعاملی را ارائه می‌دهد که در آن کاربران مدل‌های معیار را پیکربندی می‌کنند، تیم‌ها را ثبت می‌کنند، URL های پروژه را ارسال می‌کنند و کارت‌های امتیازی درجه‌بندی نهایی، از جمله مغایرت‌های کامل فایل و نظرات مهندسی را بررسی می‌کنند.
  • Go REST Backend API : نقاط پایانی API سراسری را مدیریت می‌کند. این API پیکربندی‌های پروژه را در BigQuery ذخیره می‌کند و کارهای داوری را به Pub/Sub ارسال می‌کند تا خطوط لوله اجرای محاسباتی سنگین را جدا کند.
  • Google Pub/Sub : واسط پیام‌محور که پیام‌های وظیفه را با خیال راحت در صف نگه می‌دارد و ارتباط ناهمزمان بین API و نمونه‌های فعال کارگر را هماهنگ می‌کند.
  • کارگر ADK پایتون (عامل ناظر) : یک کارگر پس‌زمینه که وظایف را از Pub/Sub دریافت می‌کند. این کارگر از کیت توسعه عامل گوگل (ADK) برای شروع یک عامل ناظر سطح بالا استفاده می‌کند که وظیفه هماهنگ‌سازی ارزیابی را بر عهده دارد. ناظر، ابزار اصلی خود، evaluate_repository ، را برای واگذاری تست دستورات خام عمیق فراخوانی می‌کند.
  • روتر و دروازه‌ی سندباکس (GKE Control Plane) : یک دروازه‌ی کنترل داخلی که تعاریف استاندارد منابع سفارشی سندباکس ( SandboxClaims ، SandboxTemplates ) را ثبت می‌کند. این دروازه، شبکه‌های GKE را برای تخصیص و ایمن‌سازی پادها هماهنگ می‌کند و جریان‌های اتصال را به کلاینت‌های کارگر بازمی‌گرداند.
  • Sandbox WarmPool : برای جلوگیری از زمان طولانی راه‌اندازی کانتینر GKE ("شروع سرد" بیش از 30 ثانیه)، WarmPool پادهای آماده به کار فعال را حفظ می‌کند. هنگامی که یک Sandbox درخواست می‌شود، روتر بلافاصله آن را در زمان‌های کمتر از ثانیه نگاشت می‌کند، سپس بازیافت را پس از آزادسازی برنامه‌ریزی می‌کند.
  • جداسازی gVisor (runsc) : یک هسته مجازی فضای کاربر که به عنوان یک مرز امن sandboxing عمل می‌کند. این هسته، فراخوانی‌های سیستمی را از فضای کانتینر به هسته‌های گره GKE رهگیری می‌کند و تضمین می‌کند که دستورات خام خطرناک (مانند اسکریپت‌های سیستمی یا تنظیمات بسته) تحت جداسازی مطلق مجازی‌سازی اجرا شوند.
  • FastAPI Sandbox Runtime : یک سرور سبک API پایتون که درون کانتینر sandbox اجرا می‌شود. این سرور، نقاط پایانی امن ( /execute ، /upload ، /download ) را در معرض نمایش قرار می‌دهد که به ابزارهای worker خارجی اجازه می‌دهد فایل‌ها را دستکاری کرده و وظایف shell را اجرا کنند.
  • رابط خط فرمان Gemini ( @google/gemini-cli ) : یک اسکریپت عامل خودکار که درون جعبه شنی نصب شده است. هنگامی که با پرچم زمان اجرای محیط توسعه‌دهنده ( --yolo ) فعال می‌شود، از یک برگه دستورالعمل درجه‌بندی دقیق ( prompt.md ) و تعریف معیارها ( criteria.md ) برای موارد زیر استفاده می‌کند:
    • سلسله مراتب کدبیس را به صورت پویا تجزیه و تحلیل کنید (با استفاده از ابزارهایی مانند tree یا ripgrep ).
    • نصب خودکار نیازمندی‌ها (از طریق دستوراتی مانند npm install ، pip install ، go build ).
    • برای تأیید عملکرد، تست‌های توسعه واقعی (مانند npm test یا pytest ) را اجرا کنید.
    • مدل‌های هوش مصنوعی Vertex (از طریق اعتبارنامه‌های اتصال Workload Identity کانتینر) را فراخوانی کنید تا منطق فایل را ارزیابی کنید، ادعاهای موجود در README را بررسی کنید، ویژگی‌های شبح را شناسایی کنید، مشکلات کیفی را ثبت کنید و یک گزارش کارت امتیازی ساختاریافته در evaluation.json بنویسید.
  • محیط‌های استاندارد توسعه‌دهندگان : node، npm، yarn، pnpm، python، pip، uv، go، gh، git، tree، ripgrep و playwright را در تصویر کانتینر sandbox بسته‌بندی می‌کند و به عامل فرعی خودمختار یک فضای کاری آزمایشی کامل می‌دهد.

۱۰. تمیز کردن

برای جلوگیری از هزینه‌های مداوم برای حساب Google Cloud خود، منابع ایجاد شده در طول این codelab را حذف کنید. 

./destroy.sh

چرا منابع را پاکسازی می‌کنیم: گوگل کلود بر اساس مدل استفاده از منابع، هزینه‌ها را محاسبه می‌کند. منابع فعال مانند خوشه‌های GKE Autopilot، متعادل‌کننده‌های بار شبکه و دیسک‌های پایدار، حتی زمانی که بیکار هستند، هزینه‌های مداومی را متحمل می‌شوند. اجرای این مرحله، فضای نام خوشه را برای پاک کردن اشیاء Kubernetes حذف می‌کند و خود میزبان خوشه GKE Autopilot را نیز حذف می‌کند تا بلافاصله تمام هزینه‌های صورتحساب مربوطه خاتمه یابد.

۱۱. تبریک

تبریک! شما با موفقیت برنامه Hackathon Judge را با Agent Sandbox روی GKE مستقر کردید!

شما یک پلتفرم هوش مصنوعی امن و مدرن مبتنی بر رویداد پیاده‌سازی کرده‌اید که قادر به آزمایش و ارزیابی ارسال‌های کدبیس غیرقابل اعتماد تحت محدودیت‌های امنیتی ایزوله و کانتینر شده است.

آنچه آموخته‌اید

  • زیرساخت GKE : نحوه‌ی تأمین GKE Autopilot و پشتیبانی از سرویس‌های Google Cloud مانند Pub/Sub و BigQuery.
  • پیکربندی Agent Sandbox : نحوه پیکربندی Custom Resource Definitions، SandboxTemplates، SandboxClaims و Sandbox WarmPools با کارایی بالا.
  • استقرار میکروسرویس‌ها : نحوه پیکربندی اتصالات هویت بار کاری و استقرار معماری میکروسرویس‌های چند جزئی (Frontend React، REST Go، Worker ADK Agent و Isolated Sandbox).
  • سندباکسینگ امن : نحوه استفاده از کانتینرهای مجازی gVisor برای اجرای ایمن دستورات شخص ثالث غیرقابل اعتماد روی گره‌های GKE.

مراحل بعدی

اسناد مرجع