> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kombify.io/llms.txt
> Use this file to discover all available pages before exploring further.

# أول عملية نشر عبر CLI

> اتبع StackKits CLI من الإعداد المحلي إلى إعداد التطبيقات والاسترداد

يرشدك CLI عبر أوامر منفصلة: احفظ خياراتك، وتحقق منها، وراجع النشر، وطبّقه، وافحص ما لا يزال يحتاج إلى اهتمام. لكل أمر مساعدته الخاصة. ولا يتقدم تلقائياً عبر النشر كله ولا يختار لك kit.

تصف هذه الجولة CLI الأصلي كما يُشحن في [الإصدار العام الحالي](https://github.com/kombifyio/StackKits/releases/latest). يعمل الوضع القياسي (Standard Mode) دون حساب kombify أو Techstack. وتبقى مفاتيح المالك المحلية وأدلة النشر في مساحة عملك.

## اختر نقطة البداية

| المدخل | ما الذي يحدث | تابع مع |
| - | - | - |
| [مثبّت أدوات التشغيل](/ar/guides/stackkits/choosing-a-kit#install-only-the-toolchain) | يثبّت CLI والكتالوج؛ وتهيئ الخدمات وتطبّقها بشكل منفصل. | الخطوة 1 أدناه. |
| [البدء السريع لـ Basement](/ar/stackkits/quickstart) | على خادم Ubuntu مدعوم، يثبّت المتطلبات المسبقة، ويهيّئ مساحة العمل والمالك المحلي، ويطبّق خدمات Basement الافتراضية. | الخطوة 5 أدناه، في `~/my-homelab`. |

شغّل تمهيد Basement فقط على المضيف الذي تنوي إعداده. وللاطلاع الأول على CLI دون تثبيت خدمات، اختر مسار أدوات التشغيل. يمكن لمستخدمي Windows الحصول على CLI من ملف ZIP للإصدار العام؛ لكن هذا لا يجعل Windows هدف تشغيل أصلياً مدعوماً لـ Basement. راجع [مرجع توافق أنظمة التشغيل](/ar/stackkits/reference/os-compatibility) لمعرفة هدف التثبيت.

## 1. افحص CLI وأنشئ مساحة عمل

بعد تثبيت أدوات التشغيل، افتح الطرفية:

```bash theme={null}
stackkit version
stackkit --help
mkdir my-homelab
cd my-homelab
```

تجمع المساعدة الأوامر في الإعداد والعناية المستمرة والمرجع؛ ويسرد [مرجع CLI](/ar/stackkits/reference/cli/overview) كل أمر مع خياراته وأمثلته. احتفظ بمجلد نشر واحد طوال هذه الجولة. استخدم مجلداً جديداً للتجربة بدلاً من استبدال إعداد قائم.

## 2. احفظ خياراتك

لـ Basement Kit بإعداداته الافتراضية في الكتالوج:

```bash theme={null}
stackkit init basement-kit --catalog-defaults --owner-source=local
```

ينشئ `init` الملف `stack-spec.yaml` وحيازة المالك المحلية. ويطبع مسار الإعداد المحفوظ وأمري `validate` و`generate` التاليين. لم يثبّت أي خدمات.

تُسجَّل الإعدادات الافتراضية للكتالوج كخيارات صريحة. ويُطلب الإدخال المطلوب عندما يحتاجه kit المختار. ولإدراج workload الصور الخاص بالـ kit في مساحة عمل جديدة، استخدم الأمر التالي **بدلاً من** أمر init السابق:

```bash theme={null}
stackkit init basement-kit --catalog-defaults --owner-source=local --use-case photos
```

workload الصور اختيار في هذه المرحلة، لا مكتبة صور قيد التشغيل. راجع مسارات التخزين والنطاق والتطبيقات المختارة وإعدادات العقدة في الملف المحفوظ. انظر [إعداد StackSpec](/ar/guides/stackkits/configure-stack-spec).

للسكربتات، أضف `--non-interactive` إلى `init`. عندها يفشل الإدخال المطلوب المفقود بدلاً من طلبه. ولا يوافق هذا الخيار على إجراءات النشر اللاحقة. يوثّق `stackkit init --help` الخيارات المتاحة؛ أما الخيارات الموسومة بأنها للتوافق القديم فهي خارج هذه الجولة الأصلية.

## 3. تحقق وولّد وراجع

```bash theme={null}
stackkit validate
stackkit generate
stackkit plan --json
```

يفحص التحقق الإعداد مقابل عقد الـ kit. ويكتب التوليد ملفات النشر والأدلة. وتتيح لك الخطة فحص الـ workloads المختارة والمسارات والجاهزية قبل تغيير المضيف.

افحص `readiness.generation.status` و`readiness.apply.status`، واقرأ أي عوائق. صحّح الإعداد وولّد مجدداً عند الحاجة. الخطة الجاهزة لا تعني أن التطبيقات تعمل بالفعل.

## 4. افحص الهدف وطبّق

على المضيف الهدف المدعوم، ومع مساحة العمل نفسها:

```bash theme={null}
stackkit prepare
stackkit apply
```

على مسار CLI الأصلي، يفحص `prepare` متطلبات المضيف المسبقة مثل Docker وCompose والتخزين والمنافذ. ولا يثبّت حزم المضيف الناقصة. عالج المتطلبات المُبلَّغ عنها قبل التطبيق.

يغيّر `apply` المضيف. راجع مطالبة الموافقة فيه والتغييرات المقصودة. اتبع [المراجعة والتطبيق والتحقق](/ar/guides/stackkits/review-plan-and-apply) لفحوص دورة الحياة التفصيلية. وإذا استخدمت تمهيد Basement، فقد تم التطبيق الأولي بالفعل؛ فلا تكرره لمجرد إتمام الجولة.

## 5. اكتشف ما هو قابل للاستخدام

```bash theme={null}
stackkit verify --http --json
```

يفحص `verify` مواصفة الـ stack، وحالة النشر، وخدمة Docker، وحاويات StackKit وصحتها، ومع `--http` المسارات من ملخص الوصول المولّد. يحمل كل فحص فاشل سببه. العنوان المُعدّ وحده لا يثبت أن التطبيق يمكن الوصول إليه؛ أما فحص HTTP الناجح فيثبت ذلك.

اتبع دليل إعداد التطبيق عندما يبقى حساب يحتاج إلى ضبط. استخدم `stackkit setup --help` لمعرفة إجراءات الإعداد المدعومة. واختم بفتح التطبيق وتنفيذ مهمة حقيقية صغيرة، مثل إضافة صورة اختبار إلى مكتبة صورك. نجاح تثبيت CLI وحده لا يثبت أن هذه المهمة تعمل.

## 6. الاستئناف وحل المشكلات

عد إلى مجلد النشر نفسه:

```bash theme={null}
stackkit verify --json
stackkit drift detect --json
stackkit logs list --json
stackkit logs get <run-id> --json
```

يفحص `drift detect` بيئة Compose الحية مقابل الخطة المحلولة والملفات المولّدة وأدلة التطبيق الموقّعة دون تغيير أي شيء، ويقرأ `logs get` السجل المهيكل لتشغيل واحد من `logs list`. استخدم السبب المُبلَّغ عنه والإجراء التالي للمتابعة. احتفظ بمساحة العمل عند فشل عملية؛ ولا تبدأ من جديد بـ `init` ولا تعدّل الملفات المولّدة لتجاوز عائق. أبقِ مفاتيح المالك وسجلات الوصول خاصة، وراجع ناتج التشخيص قبل مشاركته.

للعناية المستمرة، استخدم [عمليات اليوم الثاني](/ar/stackkits/reference/day-2-operations) و[النسخ الاحتياطي والاستعادة](/ar/guides/stackkits/back-up-and-restore). واختيار الـ kit وتجربة الإعداد الموجَّهة في Techstack استمرار اختياري؛ ولا يلزمان لسير عمل CLI المحلي هذا.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.