CONTAINER APPS · راهنما
استقرار از Git
به ما یک مخزن گیت که حاوی docker-compose.yml است نشان دهید. آن را کلون میکنیم، ایمیج هر سرویس را روی زیرساخت خودمان میسازیم — به رجیستری کانتینر نیازی ندارید — و کل stack را بههم متصل، روی پلتفرم کانتینر مدیریتشده CDN.com.tr مستقر میکنیم. سریعترین مسیر از «مخزن من» تا «در حال اجرا در production» همین است.
یک مخزن حاوی docker-compose.yml. سرویسهای دارای بخش build: از Dockerfile خودشان ساخته میشوند؛ سرویسهایی که به یک image: عمومی ارجاع میدهند (پایگاهداده، کش، صف) همانطور که هستند استفاده میشوند و بهعنوان افزونه یا اپلیکیشن مدیریتشده متصل میشوند. همین — نیازی به حساب رجیستری، push کردن ایمیج یا تنظیم CI نیست.
۱ · «Deploy from Git» را باز کنید
در حساب CDN خود Platforms → Container Apps را باز کنید، App creation را باز کنید و روی Deploy from Git (کنار Import from Docker Compose) کلیک کنید.
۲ · مخزن خود را وارد کنید
- URL مخزن — آدرس کلون
https://، مثلاًhttps://github.com/your-org/your-app.git. - برنچ — برنچی که استقرار مییابد (پیشفرض
main). - فایل Compose — مسیر فایل compose داخل مخزن (پیشفرض
docker-compose.yml). context های build نسبت به همین فایل حل میشوند، پس compose نگهداریشده در یک زیرپوشه هم بهدرستی کار میکند.
۳ · مخزنهای خصوصی و دسترسی
گیتهاب (توصیهشده): روی «Connect GitHub» کلیک کنید. نصب تککلیکی GitHub App اجازه میدهد مخزنها را از یک منوی کشویی انتخاب کنید — بدون نیاز به ساخت، کپی یا چرخاندن توکن؛ همچنین وبهوکهای استقرار خودکار (مرحله ۵) را نیز فعال میکند. شما دقیقاً مشخص میکنید این اپ کدام مخزنها را ببیند و هر زمان میتوانید آن را در گیتهاب لغو کنید.
بهعنوان جایگزین — یا برای گیتلب — گزینه This is a private repository را علامت بزنید و یک توکن دسترسی جایگذاری کنید. به آن حداقل دسترسی لازم را بدهید:
- گیتهاب — یک Personal Access Token fine-grained محدود به همین یک مخزن با دسترسی Contents: Read-only.
- گیتلب — یک توکن دسترسی پروژه یا شخصی با scope read_repository.
توکن جایگذاریشده فقط برای کلون کردن مخزن شما در طول build استفاده میشود. در طول build فقط بهصورت فقط-نوشتنی ذخیره میشود و هرگز نمایش داده یا دوباره استفاده نمیشود — هر زمان میتوانید آن را لغو کنید.
۴ · ساخت و استقرار
روی Build & deploy کلیک کنید. یک نوار پیشرفت زنده هر مرحله را نشان میدهد:
- خواندن compose — مخزن شما را کلون کرده و فایل compose را تجزیه میکنیم.
- ساخت <سرویس> — ایمیج هر سرویس
build:از Dockerfile آن در یک builder ایزوله ساخته و به رجیستری خصوصی ما push میشود. - در حال استقرار — هر سرویس تبدیل به یک container app میشود، دقیقاً مانند
docker-composeبا نام سرویس به بقیه متصل میشود، و پایگاهدادهها/کشها متصل میگردند.
پس از پایان، سرویسهای رو-به-وب بهطور خودکار روی یک سابدامین آنی <uid>.cdn.com.tr منتشر میشوند (هر زمان میتوانید دامنه خودتان را متصل کنید) — Your apps را باز کنید تا در حال اجرا بودنشان را ببینید.
۵ · اتصال را حفظ کنید — استقرار خودکار و خط لوله استقرار
پیش از استقرار، گزینه «Keep connected — auto-deploy on every push to this branch» را علامت بزنید. از آن پس، هر push به این برنچ بهطور خودکار دوباره ساخته و مستقر میشود — و کارت خط لوله استقرار در Container Apps ظاهر میشود:
- با Enable staging در این کارت، push ها بهجای production یک نسخه آزمایشی Staging (روی URL آزمایشی مخصوص به خودش) مستقر میکنند — production فقط زمانی تغییر میکند که روی Promote کلیک کنید، با امکان بازگردانی تککلیکی.
- این روش توصیهشده برای اجرای یک مخزن متصل است: دیگر خبری از «هر commit، production را دوباره مستقر میکند» نیست.
توضیح کامل: خط لوله استقرار — push → Staging، Promote → Production.
چگونه کار میکند (و چرا امن است)
- ما ایمیجهای شما را میسازیم از روی Dockerfile هایتان — بدون نیاز به حساب رجیستری. build های چندمرحلهای،
target:وbuild.argsرعایت میشوند. - ساخت و اجرای ایزوله. هم build و هم کانتینرهای در حال اجرای شما درون یک sandbox سختشده gVisor اجرا میشوند، جدا از دیگر مشتریان و host.
- کشف سرویس — اپهای داخل حساب شما، دقیقاً مانند compose، با نام سرویس به یکدیگر میرسند. پایگاهدادهها، Redis و NATS بهصورت افزونه مدیریتشده فراهم میشوند.
- با اطمینان منتشر کنید. این را با Blue/Green preprod ترکیب کنید تا پیش از فعالسازی نهایی، یک کپی را روی URL مخصوص به خودش تست کنید.