پایگاه دانش

استقرار با Zinnector®: پیوند، بررسی، ارسال

از یک پروژه محلی تا یک سایت زنده: با یک کلید API وارد شوید، پروژه را به یک اسلات میزبانی پیوند دهید، بررسی اولیه‌ای را که PHP، دیسک و WordPress شما را با اسلات مقایسه می‌کند بخوانید و ارسال کنید — به‌علاوه استقرار مجدد، تاریخچه استقرار و گزارش‌های ساخت در صورت بروز مشکل.

هنگامی که یک پروژه به صورت محلی اجرا شد، چهار دستور آن را به یک سایت زنده روی هاستینگ Zinn Digital® منتقل می‌کنند: ورود، پیوند دادن پروژه به یک اسلات هاستینگ، خواندن بررسی‌های پیش‌پرواز (pre-flight)، و ارسال (push). این مقاله تک‌تک آن‌ها، خروجی چاپی آن‌ها و دستورهایی که پس از آن به کارتان می‌آیند — استقرارهای مجدد، تاریخچه استقرار و گزارش‌های ساخت — را شرح می‌دهد.

ورود با یک کلید API

یک کلید در داشبورد در بخش تنظیمات ← کلیدهای API ایجاد کنید، سپس:

zinnector login

کلید در یک اعلان خط فرمان تایپ می‌شود — این کلید هرگز در خط فرمان پذیرفته نمی‌شود، بنابراین امکان ندارد به تاریخچه پوسته (shell) شما یا فهرست فرایندها راه پیدا کند. در CI، آن را از طریق لوله انتقال دهید: echo "$ZINN_API_KEY" | zinnector login --profile ci، یا ZINNECTOR_TOKEN را تنظیم کنید و کلاً از مرحله login صرف‌نظر نمایید. کلید پیش از ذخیره شدن اعتبارسنجی می‌شود، و با حالت دسترسی فایل 600 ذخیره می‌گردد. دستور zinnector whoami --scopes نشان می‌دهد که وارد کدام سازمان شده‌اید و کلید دارای چه مجوزهایی است؛ کلید آزمایشی (sandbox) با عنوان مربوطه مشخص می‌شود.

پیوند دادن پروژه به یک اسلات

zinnector link                                   # pick a site from a list
zinnector link example.com --repo acme/site --branch main

دستور link شناسه سایت را در zinnector.json می‌نویسد و مگر اینکه از آرگومان --no-repo استفاده کنید، مخزن راه دور git پروژه را به سایت روی پلتفرم متصل می‌کند تا یک پوش، آن را مستقر کند. فایل zinnector.json را کامیت کنید: همکاری که مخزن را شبیه‌سازی (clone) می‌کند، سپس بدون نیاز به توضیح اضافه در همان مکان مستقر می‌کند. این فایل حاوی هیچ اطلاعات محرمانه‌ای نیست.

خواندن بررسی‌های پیش‌پرواز

zinnector check

این همان دستوری است که CLI برای آن ایجاد شده است. این دستور پروژه شما را با اسلاتی که قرار است روی آن مستقر شود مقایسه می‌کند و هرگونه عدم تطابق — و هر مقایسه‌ای را که نتوانسته انجام دهد — چاپ می‌کند:

  • نسخه PHP، با اختلاف نسخه اصلی (major) که در سطح بالا درجه‌بندی می‌شود زیرا به‌طور حتم یک سایت را از کار می‌اندازد، و اختلاف نسخه فرعی (minor) که در سطح پایین‌تر درجه‌بندی می‌شود، زیرا طبقه‌بندی همه‌چیز به عنوان حیاتی باعث می‌شود افراد هشدارها را نادیده بگیرند.
  • اینکه آیا اسلات می‌تواند به نسخه‌ای که پروژه را روی آن ساخته‌اید تغییر کند یا خیر، آیا PHP اسلات از پایان عمر مفید خود گذشته است یا خیر، و اینکه آیا سرور نسخه را اعمال کرده یا صرفاً به آن ابلاغ شده است.
  • اندازه و تعداد فایل‌های پروژه شما در مقایسه با فضای خالی واقعی دیسک و inode باقی‌مانده روی اسلات — یک ساختار WordPress ممکن است بسیار پیش از رسیدن به سقف دیسک خود، با کمبود تعداد فایل مجاز مواجه شود.
  • نسخه‌های WordPress در هر دو سمت، اینکه آیا اسلات فرایند راه‌اندازی اولیه را به پایان رسانده است یا خیر، و اینکه آیا یک مخزن متصل است تا به آن ارسال شود یا خیر.

این دستور هشدار می‌دهد؛ هرگز عملیات را مسدود نمی‌کند. هر نتیجه‌ای با دستور zinnector push --force قابل لغو و نادیده‌گیری است، زیرا شما اطلاعاتی درباره سایت خود دارید که یک بررسی‌کننده ندارد. مقایسه‌ای که امکان انجام آن وجود نداشته، به عنوان نامشخص گزارش می‌شود و هرگز به عنوان قبولی ثبت نمی‌گردد، و خلاصه گزارش همیشه تعداد آن‌ها را اعلام می‌کند. به طور پیش‌فرض نسخه محلی PHP همان موردی است که در zinnector.json اعلام شده است؛ گزینه --probe محیط اجرای محلی را بوت کرده و در عوض آن را اندازه می‌گیرد. گزینه --strict در مواجهه با موارد نامشخص نیز با کد غیر صفر خارج می‌شود، که دقیقاً همان چیزی است که یک دروازه بررسی CI نیاز دارد.

پوش (Push)

zinnector push

دستور push بررسی‌های پیش‌پرواز را اجرا می‌کند، کامیت‌های شما را پوش می‌کند، استقرار را آغاز کرده و آن را تا پایان نظارت می‌کند و وضعیت نهایی و کامیت مستقر شده را چاپ می‌نماید. گزینه --dry-run همه کارها را به جز استقرار انجام می‌دهد؛ گزینه --no-wait آن را شروع کرده و بلافاصله خارج می‌شود؛ گزینه --no-git بدون ارسال مجدد، هر آنچه را که پلتفرم از قبل دارد مستقر می‌کند. اگر کامیت مستقر شده با آنچه تازه پوش شده است مطابقت نداشته باشد، این موضوع را اعلام می‌کند.

در صورت بروز مشکل

zinnector deploys example.com        # deploy history — status, commit, trigger, message
zinnector logs example.com --build   # the build log of the most recent deploy
zinnector logs example.com --error   # the site's error log
zinnector deploy example.com         # redeploy what the platform already has
zinnector ai "why is my deploy failing?"

دستور zinnector ai روی پلتفرم بر اساس حساب کاربری خود شما اجرا می‌شود، بنابراین می‌تواند همان تاریخچه استقرار و گزارش‌ها را ببیند. از داخل یک پروژه، این دستور ساختار پروژه — نام پوشه‌ها، نسخه‌ها و شناسه سایت — را ارسال می‌کند و هرگز محتویات فایل‌ها را ارسال نمی‌نماید.

موارد مرتبط

تمام اسناد توسعه‌دهنده →

جدیدترین‌های وبلاگ

آنچه درباره میزبانی وب، سئو و مدیریت سایت‌ها در مقیاس بزرگ نوشته‌ایم.

سئو و لینک‌سازی از لایه میزبانی: دیدگاه یک اپراتور در سال ۲۰۲۶

چگونه هاستینگ در سال ۲۰۲۶ بر ایندکس شدن و انتقال اعتبار لینک تأثیر می‌گذارد: حفظ صفحات در ایندکس، ارزیابی دامنه‌های قدیمی قبل از راه‌اندازی سایت روی آن‌ها، لینک‌سازی بدون ردپای سئو، و رویکردی واقع‌بینانه درباره اینکه زیرساخت چه کارهایی را می‌تواند و چه کارهایی را نمی‌تواند برای سئو انجام دهد.

خواندن مطلب ←

سریع و امن کردن WordPress: چک‌لیست عملکرد و افزونه‌ها

یک چک‌لیست کاربردی برای WordPress سریع و ایمن: کش کردن در سطح سرور، کش اشیاء به ازای هر سایت، تعداد اندک افزونه‌هایی که ارزش استفاده دارند، به‌روز نگه داشتن بسته نرم‌افزاری، و برگه های WooCommerce که هرگز نباید آن‌ها را کش کنید.

خواندن مطلب ←

نحوه انتخاب هاست مدیریت‌شده وب در سال ۲۰۲۶: راهنمای خریدار

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

خواندن مطلب ←

وبلاگ را بخوانید ←

هنوز به مشکل برخورده‌اید؟

پشتیبانی در تمامی پلن‌ها گنجانده شده است، میز خدمت 24 ساعت در روز باز است و می‌توانید به هر یک از زبان‌های 58 ما برای ما بنویسید؛ ما به زبان شما پاسخ می‌دهیم.

تماس با پشتیبانی → همه مقاله‌ها →