CONTAINER APPS · راهنما

استقرار از Git

به ما یک مخزن گیت که حاوی docker-compose.yml است نشان دهید. آن را کلون می‌کنیم، ایمیج هر سرویس را روی زیرساخت خودمان می‌سازیم — به رجیستری کانتینر نیازی ندارید — و کل stack را به‌هم متصل، روی پلتفرم کانتینر مدیریت‌شده CDN.com.tr مستقر می‌کنیم. سریع‌ترین مسیر از «مخزن من» تا «در حال اجرا در production» همین است.

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

یک مخزن حاوی docker-compose.yml — یا فقط یک Dockerfile. سرویس‌های دارای بخش build: از Dockerfile خودشان ساخته می‌شوند؛ سرویس‌هایی که به یک image: عمومی ارجاع می‌دهند (پایگاه‌داده، کش، صف) همان‌طور که هستند استفاده می‌شوند و به‌عنوان افزونه یا اپلیکیشن مدیریت‌شده متصل می‌شوند. مخزنی که فایل compose ندارد ولی Dockerfile دارد (در ریشه، یا در پوشهٔ مسیر compose که وارد می‌کنید) به‌صورت یک اپلیکیشن واحد که از همان Dockerfile ساخته می‌شود مستقر می‌شود و روی پورت خط EXPOSE آن گوش می‌دهد (اگر نباشد 8080). همین — نیازی به حساب رجیستری، push کردن ایمیج یا تنظیم CI نیست.

1 · «Deploy from Git» را باز کنید

در حساب CDN خود Platforms → Container Apps را باز کنید، App creation را باز کنید و روی Deploy from Git (کنار Import from Docker Compose) کلیک کنید.

پنل Deploy from Git با فیلدهای مخزن، برنچ، مسیر compose و توکن دسترسی برای مخزن خصوصی — پنل Deploy from Git: URL مخزن، برنچ، مسیر فایل compose و — برای مخزن‌های خصوصی — فیلد توکن دسترسی فقط-نوشتنی با راهنمایی حداقل-دسترسی.

2 · مخزن خود را وارد کنید

URL مخزن — آدرس کلون https://، مثلاً https://github.com/your-org/your-app.git.
برنچ — برنچی که استقرار می‌یابد (پیش‌فرض main).
فایل Compose — مسیر فایل compose داخل مخزن (پیش‌فرض docker-compose.yml). context های build نسبت به همین فایل حل می‌شوند، پس compose نگه‌داری‌شده در یک زیرپوشه هم به‌درستی کار می‌کند. آنجا فایل compose نیست؟ به‌جای آن Dockerfile همان پوشه یا ریشهٔ مخزن استفاده می‌شود.

3 · مخزن‌های خصوصی و دسترسی

گیت‌هاب (توصیه‌شده): روی «Connect GitHub» کلیک کنید. نصب تک‌کلیکی GitHub App اجازه می‌دهد مخزن‌ها را از یک منوی کشویی انتخاب کنید — بدون نیاز به ساخت، کپی یا چرخاندن توکن؛ همچنین وب‌هوک‌های استقرار خودکار (مرحله 5) را نیز فعال می‌کند. شما دقیقاً مشخص می‌کنید این اپ کدام مخزن‌ها را ببیند و هر زمان می‌توانید آن را در گیت‌هاب لغو کنید.

به‌عنوان جایگزین — یا برای گیت‌لب — گزینه This is a private repository را علامت بزنید و یک توکن دسترسی جای‌گذاری کنید. به آن حداقل دسترسی لازم را بدهید:

گیت‌هاب — یک Personal Access Token fine-grained محدود به همین یک مخزن با دسترسی Contents: Read-only.
گیت‌لب — یک توکن دسترسی پروژه یا شخصی با scope read_repository.

توکن جای‌گذاری‌شده فقط برای کلون کردن مخزن شما در طول build استفاده می‌شود. در طول build فقط به‌صورت فقط-نوشتنی ذخیره می‌شود و هرگز نمایش داده یا دوباره استفاده نمی‌شود — هر زمان می‌توانید آن را لغو کنید.

4 · ساخت و استقرار

روی Build & deploy کلیک کنید. یک نوار پیشرفت زنده هر مرحله را نشان می‌دهد:

خواندن compose — مخزن شما را کلون کرده و فایل compose را تجزیه می‌کنیم.
ساخت <سرویس> — ایمیج هر سرویس build: از Dockerfile آن در یک builder ایزوله ساخته و به رجیستری خصوصی ما push می‌شود.
در حال استقرار — هر سرویس تبدیل به یک container app می‌شود، دقیقاً مانند docker-compose با نام سرویس به بقیه متصل می‌شود، و پایگاه‌داده‌ها/کش‌ها متصل می‌گردند.

پس از پایان، سرویس‌های رو-به-وب به‌طور خودکار روی یک ساب‌دامین آنی <uid>.cdn.com.tr منتشر می‌شوند (هر زمان می‌توانید دامنه خودتان را متصل کنید) — Your apps را باز کنید تا در حال اجرا بودنشان را ببینید.

5 · اتصال را حفظ کنید — استقرار خودکار و خط لوله استقرار

پیش از استقرار، گزینه «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 رعایت می‌شوند؛ ${VAR} در build.args از متغیرهای محیطی اپلیکیشن پر می‌شود و همهٔ متغیرهای NEXT_PUBLIC_* به build داده می‌شوند، تا اپلیکیشن Next.js آن‌ها را هنگام next build داشته باشد. secret ها هرگز به build داده نمی‌شوند — آرگومان‌های build داخل ایمیج می‌مانند.
ساخت و اجرای ایزوله. هم build و هم کانتینرهای در حال اجرای شما درون یک sandbox سخت‌شده gVisor اجرا می‌شوند، جدا از دیگر مشتریان و host.
کشف سرویس — اپ‌های داخل حساب شما، دقیقاً مانند compose، با نام سرویس به یکدیگر می‌رسند. پایگاه‌داده‌ها، Redis و NATS به‌صورت افزونه مدیریت‌شده فراهم می‌شوند.
با اطمینان منتشر کنید. این را با Blue/Green preprod ترکیب کنید تا پیش از فعال‌سازی نهایی، یک کپی را روی URL مخصوص به خودش تست کنید.