الإعداد الأولي

تنقلك هذه الصفحة من رمز التسجيل إلى موصل متحقَّق منه في الوضع المُدار، حيث يطبّق executor دورة حياة الخدمة التي تديرها ClickHouse Cloud. يُثبَّت موصل على عنقود Kubernetes ‏(Helm) أو جهاز افتراضي يعمل بنظام Linux ‏(systemd). يُعد التسجيل بالرمز المسار القياسي. وعندما لا تستطيع بيئتك الوصول مباشرةً إلى نقطة نهاية موصل الخاصة بك، فراجع عمليات التثبيت المعزولة شبكيًا والمنعكسة. ولمراقبة ClickHouse الذي تشغّله بنفسك، دون executor، مرّر --no-managed.

المتطلبات الأساسية

تسجيل بيئتك

قبل التسجيل، يسجّل فريق الحساب بيئتك ويفعّل الوضع المُدار لمؤسستك. زوّدهم بما يلي:

معرّف حساب AWS، والمنطقة، واسم عنقود EKS
ما إذا كان موصل يعمل على جهاز افتراضي يعمل بنظام Linux أم داخل العنقود
مجموعة العقد المخصّصة لمكوّنات المنصة
بادئة مساحة الأسماء للخدمات (القيمة الافتراضية ns-)
كيفية سحب عنقودك لصور ClickHouse: عبر وصول السجل الذي تهيّئه ClickHouse Cloud لحسابك، أو عبر مرآتك الخاصة

بعدها تُصدر ClickHouse Cloud نقطة نهاية الموصّل الخاصة بك، ورمز تسجيل يُستخدم لمرة واحدة، ومعرّف ARN لمستودع ECR الذي يضم مخطط عنقود ClickHouse (وهو الإدخال chart_repository_arn في جذور Terraform). وفي حالة التثبيت عبر Terraform، تتسلّم في هذه المرحلة أيضًا حزمة المنصة: ففي Helm يطبّقها الأمر clicklink clctl init --managed --from-terraform --platform-bundle، وعلى الجهاز الافتراضي يطبّقها الأمر clicklink clctl platform approve --bundle بعد التسجيل. أمّا أي تثبيت مُدار آخر فيتلقّى حزمته الأولى لاحقًا، إذ يجهّزها المنفّذ ثم تُطبَّق باستخدام clicklink clctl platform approve كما هو موضّح في تحديثات المنصة؛ أمّا التثبيت باستخدام --no-managed فلا يحتاج إلى أي حزمة. ويحدّد هذا الرمز بيئتك، لذا لا يحتاج التسجيل إلى أي معرّف إضافي.

لكل عملية تثبيت

الموصل بالإصدار v0.17.0 أو أحدث. لا تحتوي الإصدارات الأقدم على الوضع المُدار ولا على أوامر platform ولا على instances create. ويقدّم المثبّت أحدث إصدار ما لم تمرّر --version.
نقطة نهاية الموصل ورمز التسجيل الخاصان بك، ويُقدَّمان أثناء التسجيل.
حركة الخروج (egress) على المنفذ 443 إلى https://<subdomain>.<connector-domain> وhttps://<subdomain>.enroll.<connector-domain>، إضافة إلى releases.clicklink.clickhouse.com وAmazon ECR Public وقت التثبيت. وفي الوضع المُدار يتصل المنفّذ أيضًا بـ Amazon ECR وSTS عندما تسحب مزامنة أو عملية إنشاء على مستوى المنصة مخططًا (مخطط) من ECR. وإذا تعذّر الوصول إلى أيٍّ من هذه الوجهات، راجع عمليات التثبيت المعزولة شبكيًا والمنعكسة.
عنقود Amazon EKS للوضع المُدار. يرفض init الوضع المُدار على أي عنقود آخر، ويشير إلى --no-managed للتثبيت من دون المنفّذ. ويوفّر Terraform على AWS وحدات جذرية لعنقود جديد وأخرى لعنقود قائم تشغّله بالفعل، إضافة إلى الأمر init الذي يثبّت طبقة المنصة فوقها.
صلاحيات admin على العنقود من أجل الأذونات الخاصة بالمنفّذ. تنشئ هذه الأذونات كلًّا من ClusterRole وClusterRoleBinding وValidatingAdmissionPolicy تحصر المنفّذ ضمن مساحات الأسماء الواقعة تحت prefix الخاص بك. على Kubernetes، يحتاج ملف kubeconfig الذي تشغّل به init إلى هذه الصلاحيات. وعلى جهاز افتراضي، يحتاجها ملف kubeconfig الخاص بالمضيف؛ وإذا لم يكن للمضيف صلاحيات admin، يطبع init الأمر الذي يجب تشغيله من مضيف يمتلكها.
لا وجود لـ ClickHouse بعد. يبدأ التثبيت المُدار من دون أي خدمات؛ أما الخدمات التي ينشئها المنفّذ فتسجّل نفسها تلقائيًا. وفي الوضع المُدار لا يسجّل init أي ClickHouse تشغّله بنفسك (وعلى Kubernetes يرفض --instance و--instance-namespace). ولمراقبة عنقود من هذا النوع، ثبّت نشرًا (deployment) منفصلًا للموصل باستخدام --no-managed. ويتيح --ch-user-suffix للنشرين مشاركة instance واحد من دون تعارض في مستخدمي الموصل. ويحتاج ذلك النشر إلى مستمع native يمكن الوصول إليه، المنفذ الآمن 9440 أو المنفذ بنص صريح 9000، ويُكتشف تلقائيًا على Kubernetes. كما يحتاج إلى وصول ClickHouse admin من أجل التجهيز: مستخدم default بلا كلمة مرور، أو كلمة مرور تُمرَّر عبر --ch-admin-password-stdin أو عند المطالبة بها، أو حقن CR للـ instances المُدارة بواسطة مشغّل.
cosign في أي مكان تنزّل فيه ملفات الإصدار. يتحقق المثبّت دائمًا من قيمة التحقق SHA-256. وعند تثبيت cosign يتحقق أيضًا من توقيع الإصدار، ومع CLICKLINK_REQUIRE_COSIGN=1 يرفض المتابعة من دون cosign.

لعمليات التثبيت على Kubernetes (Helm)

ملف kubeconfig يشير سياقه الحالي إلى عنقود EKS، ويجب أن يمتلك صلاحية إنشاء وقراءة مساحة الأسماء الخاص بالـ موصل، وتطبيق Secrets، وإنشاء ServiceAccounts وRoles وRoleBindings، وتثبيت الـ مخطط، ومنح الـ executor صلاحياته على مستوى العنقود.
بيانات اعتماد AWS على جهاز العمل (عبر البيئة أو profile) تتضمن eks:DescribeCluster وec2:DescribeVpcs. يستخدمها init لقراءة كتل CIDR الخاصة بشبكة VPC لعنقودك من أجل NetworkPolicy. وإذا فشل البحث، يُصدر تحذيرًا ويترك لك تعبئة تلك القائمة.
نطاقات CIDR الواقعة خلف نقطة نهاية الـ موصل لديك، لتمكين NetworkPolicy ذات الرفض الافتراضي في الـ مخطط أثناء التثبيت. وبدونها، يهيّئ init السياسة معطّلة ويعرض كيفية تمكينها لاحقًا.
StorageClass افتراضي، أو صنف تمرّره عبر --storage-class؛ إذ يحتفظ كل من مستكشف الأخطاء ومصلحها والـ executor بالحالة على PersistentVolumeClaims.
صلاحية سحب الصور: يجب أن تكون عُقد العنقود قادرة على سحب صورة ECR العامة، أو نسخة مرآة تستضيفها بنفسك.

للتثبيت على جهاز افتراضي يعمل بنظام Linux (systemd)

أي مضيف Linux يعتمد systemd، بمعمارية amd64 أو arm64. تعمل إصدارات Linux في وضع FIPS.
صلاحية Root للمثبِّت ولـ init.
منافذ متاحة: 8082 و8084 و8086 لفحص الـ health والمقاييس، و9999 على واجهة الاسترجاع (loopback) لواجهة برمجة التطبيقات المحلية الخاصة بـ executor، و8443 عند تفعيل بوابة جلسات الدعم.
صلاحية Admin على خادم واجهة برمجة التطبيقات الخاص بـ Kubernetes للتجهيز ولمنح صلاحيات executor: ملف kubeconfig على المضيف، أو --server و--ca-data، أو عبر الـ prompts. تُربط حزم الوصول (access bundles) بحسابات ServiceAccounts في Kubernetes على كلا الهدفين. وفي الوضع المُدار، يجب أن يشير الـ Context الحالي في kubeconfig إلى عنقود EKS الذي تديره؛ فـ init يرفض منح الصلاحيات عبر أي Context آخر.

على جهاز افتراضي، يُعد --skip-provision السبيل الوحيد لتجاوز اشتراط خادم واجهة برمجة التطبيقات الخاص بـ Kubernetes، وهو مخصص للـ stage فقط. فهو يتخطى تجهيز مستخدم ClickHouse، ومنح صلاحيات executor، وتفعيل الوحدة، والتحقق؛ ولذلك لا ينتج عنه أي موصل قيد التشغيل بمفرده. أما على Kubernetes فيتخطى تجهيز مستخدم ClickHouse فقط. ويبقى منح صلاحيات executor مطبَّقًا، لأن executor الخاص بالمخطط (مخطط) لا يمكنه الجدولة من دون ServiceAccount الممنوح.

التثبيت والتسجيل

احصل على نقطة نهاية الموصل ورمز التسجيل

يوفّر لك فريق حسابك كليهما بمجرد تسجيل بيئتك. وتكون نقطة النهاية بالشكل التالي:

https://<subdomain>.<connector-domain>

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

ثبّت واجهة سطر الأوامر (CLI) وتحقّق من عملها

أمر واحد يثبّت ملفًا تنفيذيًا موثّقًا باسم clicklink. فهو يكتشف منصّتك (macOS أو Linux، amd64 أو arm64)، وينزّل الإصدار الحالي، ويتحقق من قيمة التحقق SHA-256. وإذا كان cosign مثبّتًا، فإنه يتحقق أيضًا من توقيع الإصدار. ويثبّت في /usr/local/bin إن كان قابلًا للكتابة، وإلا ففي ~/.local/bin (أضف هذا المسار إلى PATH إذا لزم الأمر؛ ويمكن تجاوز ذلك عبر --bin-dir). أما للتثبيت على Kubernetes، فشغّل الأمر من أي حاسوب إداري يملك وصولًا إلى العنقود عبر kubeconfig:

curl -fsSL https://releases.clicklink.clickhouse.com/install.sh | bash

للتثبيت على جهاز افتراضي، شغّل البرنامج النصي نفسه على المضيف مع --host. وبعد التحقق من التنزيل، يُنشئ مستخدم النظام clicklink، وأدلة /etc/clicklink و/var/lib/clicklink و/var/log/clicklink، ووحدات systemd للمكوّنات الثلاثة جميعها. كما يهيّئ الملف /etc/clicklink/redaction-patterns.yaml بمجموعة أولية من patterns (مع الإبقاء على الملف الموجود إن وُجد)، بحيث تكون الخطوة التالية هي enrollment:

curl -fsSL https://releases.clicklink.clickhouse.com/install.sh | sudo bash -s -- --host

تقبل كلتا الصيغتين الخيار --version vX.Y.Z لتثبيت إصدار محدد. وإعادة تنفيذ أي منهما آمنة: إذ ينشئ التثبيت على المضيف نسخة احتياطية من الملف الثنائي السابق ويحافظ على التهيئة النشطة لديك. ولفحص البرنامج النصي قبل تشغيله، أو لتنزيل أرشيف الإصدار والتحقق منه بنفسك، راجع التنزيل والتحقق اليدوي.

سجّل الموصل وثبّته

يستهلك init --enroll الرمز الخاص بك، ويحصل على شهادة عميل موقّعة وعلى منحة الـ executor على مستوى العنقود، ثم يثبّت الـ connector ويتحقق منه.في الطرفية، يسأل init: ‏Enable managed mode (ClickHouse manages the lifecycle of ClickHouse services in this cluster)? مع تحديد yes مسبقًا. مرّر --managed لتخطي الـ prompt، أو --no-managed لتثبيت للمراقبة فقط دون الـ executor. أي تثبيت جديد غير تفاعلي دون أيٍّ من هذين الـ flags يترك الوضع المُدار معطّلًا (إعادة التشغيل بـ --force تحافظ على وضعية الإعداد المُستبدَل)، لذا مرّر --managed دائمًا في النصوص البرمجية.

Kubernetes
جهاز Linux افتراضي

من محطة العمل لديك، مع توجيه سياق kube إلى عنقود EKS الخاص بك، شغّل:

clicklink clctl init --enroll https://<subdomain>.<connector-domain> --target helm --managed

ألصق الـ enrollment token في الـ prompt المخفي. يقرأ init اسم العنقود والـ region وحساب AWS من ARN الخاص بـ EKS في السياق الحالي، فلا حاجة لكتابة أي شيء عن العنقود. ثم يطلب منك:

namespace الخاص بالـ connector (الافتراضي clicklink)
StorageClass، فقط عندما لا يحدد العنقود قيمة افتراضية
نطاقات CIDR خلف نقطة نهاية الـ connector لديك، من أجل allowlist الخاص بـ egress في NetworkPolicy (اتركها فارغة لتجهيز السياسة معطّلة)
وضعية جلسة الدعم، وفي حال تفعيلها، allowlist لبريد المشغّلين الإلكتروني

يستهلك init الرمز ويحفظ الـ enrollment bundle باسم handoff.yaml في مجلد العمل. ويجهّز طبقة قيم Helm ‏clicklink-values.yaml مع كتلة executor ونطاقات VPC الخاصة بعنقودك بوصفها نطاقات CIDR لخادم API في NetworkPolicy. وينشئ الـ namespace، ويطبّق الـ Secret ‏clicklink-hmac، وينشئ المفتاح الخاص داخل الـ Secret ‏clicklink-mtls، ويكتب الـ CSR. ويمنح الـ executor وصولًا على مستوى العنقود إلى namespace الخاص بالـ connector، ويجعل ClickHouse Cloud توقّع شهادة العميل. ثم يثبّت إصدار Helm ‏clicklink-connector باستخدام عميل Helm المدمج فيه (دون الحاجة إلى binary الخاص بـ helm) ويتحقق من سلامته.أما في عمليات التشغيل غير التفاعلية، فأجب عن الـ prompts باستخدام الـ flags. استخدم الـ bundle المحفوظ كنقطة دخول، أو مرّر الـ enrollment token إلى --enroll كأول سطر من stdin:

clicklink clctl init --handoff handoff.yaml --target helm --managed \
  --egress-cidrs 203.0.113.0/24 \
  --operators '<operator-email-1>,<operator-email-2>' \
  --storage-class <storage-class>

مرّر --no-gateway بدلًا من --operators لتعطيل جلسات الدعم؛ فالـ flagان متنافيان.

التثبيت بـ --host في الخطوة السابقة أرسى الـ binary، ومستخدم النظام clicklink والمجلدات، ووحدات systemd. سجّل بصلاحيات root:

sudo clicklink clctl init --enroll https://<subdomain>.<connector-domain> --managed

ألصق الـ enrollment token في الـ prompt المخفي. يكتشف init السحابة من البيانات الوصفية للـ instance، ويكتشف عنقود EKS من kubeconfig الخاص بالمضيف. ويأتي الـ region وحساب AWS الخاصان بالعنقود من ARN ذلك العنقود، مع البيانات الوصفية للـ instance كبديل احتياطي. وفي الطرفية يؤكد اسم العنقود الذي عثر عليه (EKS cluster to manage) ولا يطلب اسمًا إلا عندما لا يذكر kubeconfig أي اسم. مرّر --cluster-name لتخطي ذلك الـ prompt. ثم يسأل عن وضعية جلسة الدعم.يستهلك init الرمز ويحفظ الـ enrollment bundle باسم handoff.yaml. ويكتب /etc/clicklink/config.yaml مع كتلة executor، ويثبّت بيانات اعتماد API وسلسلة الـ CA. وينشئ مفتاحًا خاصًا وCSR، ويجعل ClickHouse Cloud توقّع شهادة العميل. وينشئ حزمة وصول الـ executor على مستوى العنقود ضمن /etc/clicklink/access/executor/_cluster ويطبّقها عبر kubeconfig الخاص بالمضيف. ثم يفعّل ويشغّل وحدات clicklink-scraper وclicklink-troubleshooter وclicklink-executor، وينتظر أن تبلّغ كل منها عن جاهزيتها، ثم ينفّذ مجموعة فحوصات ما قبل التشغيل كاملة.

وعند نجاح التحقق من التثبيت، يطبع init ‏Managed mode is on مع الأمر الذي يهيّئ أول خدمة لك. تابع مع إنشاء خدمة.

التحقق من نجاح العملية

يتحقق init من صحة التثبيت قبل أن يبلّغ عن النجاح. على Kubernetes، يستطلع نقطة النهاية /livez لكل مكوّن مُفعّل، بما في ذلك المنفّذ (executor)، لمدة تصل إلى خمس دقائق. وعند تفعيل بوابة جلسات الدعم، يشترط أيضًا أن ترد البوابة على الفحوص غير المصادَق عليها بالرمز 401. أما على الجهاز الافتراضي، فينتظر /livez الخاص بكل برنامج خفي، ثم يشغّل مجموعة فحوص Preflight الكاملة. وتفحص هذه المجموعة الإعدادات والملفات وتعارضات المنافذ وإمكانية الوصول عبر الشبكة والاتصال بـ ClickHouse وحالة وحدات systemd للوحدات الثلاث جميعها، وصلاحيات الوصول لكل مكوّن، والقرص، وأنماط الإخفاء.للتأكد يدويًا على Kubernetes:

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
kubectl get pods -n "${CONNECTOR_NAMESPACE}"

يجب أن تكون جميع pods الخاصة بالـ connector في حالة Running وجاهزة: الـ scraper، ومستكشف الأخطاء ومصلحها، والـ executor.للتحقق يدويًا على جهاز افتراضي:

sudo clicklink clctl preflight

ينتهي بالرمز 0 عند نجاح جميع الفحوصات، وبالرمز 2 في حال وجود أي فشل، ويطبع الفحوصات الفاشلة.

تنظيف

تتيح حزمة التسجيل handoff.yaml (بوضع 0600، في دليل العمل) لعمليات إعادة التشغيل والاسترداد أثناء التثبيت أن تمضي دون الحاجة إلى رمز ثانٍ. وهي تحتوي على سر واجهة برمجة التطبيقات الخاص بالموصّل كنص صريح، لذا احذفها بمجرد التحقق من نجاح التثبيت:

rm handoff.yaml        # workstation (Kubernetes installs)
sudo rm handoff.yaml   # VM host (init ran as root, so the file is root-owned)

يحتفظ الـ connector قيد التشغيل بنسخته الخاصة من الـ credentials؛ فعمليات الترقية وتغييرات التهيئة لا تحتاج إلى هذا الملف إطلاقًا. وإذا احتجت لاحقًا إلى تنفيذ init مجددًا، فاطلب enrollment token جديدًا من فريق حسابك ثم نفّذ init --enroll --force.

عمليات التثبيت المعزولة شبكيًا والمنعكسة

يمكن نقل جزأين مستقلين خارج النطاق، تبعًا لما يمكن لبيئتك الوصول إليه. لا يحتاج executor إلى أي شيء إضافي؛ فهو يصادق باستخدام شهادة العميل نفسها وبيانات اعتماد واجهة برمجة التطبيقات نفسها التي تستخدمها المكوّنات الأخرى. وتمنحه صلاحيته على مستوى العنقود عبر kubeconfig الخاص بك، لا عبر الشبكة. تسليم الحزمة. إذا كنت تفضّل عدم استبدال رمز عبر الإنترنت، فيمكن لفريق حسابك تسليم حزمة التسجيل مباشرةً أثناء عملية التهيئة؛ شغّل clicklink clctl init --handoff <bundle-file> بدلًا من --enroll. ولا يحلّ --handoff إلا محل استبدال الرمز وحده. أما توقيع الشهادة فيتم عبر نقطة نهاية التسجيل، لذا لا تستخدم --handoff بمفرده إلا عندما تكون تلك النقطة قابلة للوصول من المكان الذي تشغّل منه init. توقيع الشهادة خارج النطاق. عندما تكون نقطة نهاية التسجيل غير قابلة للوصول من المكان الذي تشغّل منه init، أضف --no-auto-sign: فيهيّئ init كل شيء ويكتب clicklink.csr. أرسل طلب توقيع الشهادة إلى فريق حسابك، ثم أكمل التثبيت بالشهادة والسلسلة المُعادتين. على جهاز افتراضي، شغّل sudo clicklink clctl init --signed-cert client.crt --chain ca-chain.crt. وعلى Kubernetes، شغّل

clicklink clctl init --signed-cert client.crt --chain ca-chain.crt --target helm --target-namespace <connector-namespace> --values clicklink-values.yaml

؛ وتطبع العملية المهيّأة تسلسلًا مكافئًا من kubectl patch وhelm upgrade --install. ولا ينتقل سوى طلب توقيع الشهادة؛ أما المفتاح الخاص فلا يغادر بيئتك أبدًا. على Kubernetes، يقبل --chart اسم مخطط يُحدَّد عبر --chart-repo، أو مرجع oci://، أو URL مباشرًا، أو أرشيفًا أو دليلًا محليًا. وتكون القيمة الافتراضية لـ --chart-version هي إصدار واجهة سطر الأوامر نفسه، بحيث ينتقل الملف التنفيذي والمخطط معًا. ولتقديم الصور من سجلّك الخاص، انسخ صورة الحاوية واضبط image.repository في طبقة القيم. وإذا كان مسار الخروج لديك يقدّم جهة إصدار شهادات خاصة إلى connector، فمرّر --api-private-ca. فيتحقق connector بعدها من نقطة نهاية connector لديك مقابل جذور النظام إضافةً إلى سلسلة جهة إصدار الشهادات المأخوذة من حزمة التسجيل. ويعمل المثبّت من مرآة أيضًا: استضف ملفات الإصدار وinstall.sh على مرآتك الخاصة وأشِر إليها باستخدام CLICKLINK_MIRROR_URL.

التنزيل والتحقق يدويًا

إذا كنت تفضّل عدم تمرير المُثبِّت عبر pipe، فاجلب الإصدار وتحقّق منه بنفسك. تكتشف الكتلة نظامك الأساسي ومعماريته؛ شغّلها كما هي على macOS أو Linux، سواء كان amd64 أو arm64:

CLICKLINK_VERSION="$(curl -fsSL https://releases.clicklink.clickhouse.com/latest-version.txt)"
# Or pin a specific release: CLICKLINK_VERSION='v0.17.0'
CLICKLINK_TARBALL="clicklink-${CLICKLINK_VERSION}-$(uname -s | tr '[:upper:]' '[:lower:]')-$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/').tar.gz"
for suffix in '' .sha256 .sig .crt; do
  curl -fsSLO "https://releases.clicklink.clickhouse.com/${CLICKLINK_TARBALL}${suffix}"
done
if command -v sha256sum >/dev/null; then
  sha256sum -c "${CLICKLINK_TARBALL}.sha256"
else
  shasum -a 256 -c "${CLICKLINK_TARBALL}.sha256"
fi

تحقق من صحة التوقيع باستخدام cosign قبل استخراج أي ملفات:

cosign verify-blob \
  --certificate "${CLICKLINK_TARBALL}.crt" \
  --signature "${CLICKLINK_TARBALL}.sig" \
  --certificate-identity-regexp "^https://github\.com/ClickHouse/data-plane-clicklink/\.github/workflows/release\.yaml@refs/tags/v" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  "${CLICKLINK_TARBALL}"

على محطة عمل (في عمليات تثبيت Kubernetes)، فك ضغط أرشيف tarball وثبّت الملف التنفيذي:

tar -xzf "${CLICKLINK_TARBALL}"
sudo install -m 0755 clicklink /usr/local/bin/clicklink

على جهاز افتراضي، استخرج أرشيف tarball وشغّل sudo ./install.sh من الدليل المستخرج. وإلى جانب ملفات الإصدار الخاصة به، يُجري التثبيت نفسه على المضيف كما يفعل الخيار --host.

إذا فشل شيء ما

أعد تنفيذ الأمر نفسه. فالأمر init متكافئ الاستدعاء: إذ تؤدي إعادة تنفيذه إلى الوصول إلى الحالة نفسها، مع الحفاظ على الإعداد الحالي والملفات المُجهَّزة، وتخطّي ما اكتمل من عمل. وعندما تفشل إحدى الخطوات في منتصفها، تطبع واجهة سطر الأوامر أوامر الاستعادة الدقيقة، وهي آمنة للتكرار. إذا رُفض التسجيل، فهذا يعني أن الرمز قد استُخدم بالفعل، أو أنه غير صالح أو منتهي الصلاحية. في حالة الرمز المُستخدَم، أعد التنفيذ مع --handoff handoff.yaml، وهو ملف يبقى موجودًا حتى خطوة التنظيف. وإلا فاطلب رمزًا جديدًا من فريق حسابك. وإذا فشل التسجيل بسبب خطأ في النقل، فأعد تنفيذ الأمر نفسه. ورفض إعادة التنفيذ يعني أن المحاولة الأولى استهلكت الرمز، لذا اطلب رمزًا جديدًا. إذا رُفض الوضع المُدار لأن العنقود ليس EKS، فأعد التنفيذ مع --no-managed للتثبيت دون executor. وعلى جهاز افتراضي، يُرفض أيضًا ملف kubeconfig الذي يشير سياقه الحالي إلى موضع آخر: بدّل السياق باستخدام kubectl config use-context ثم أعد التنفيذ. إذا تعذّر تطبيق صلاحية الـ executor:

على جهاز افتراضي، لا يفشل الأمر init، بل يجهّز الحزمة ويطبع تحذيرًا يتضمن الأمر الدقيق الواجب تنفيذه من ملف kubeconfig يملك صلاحيات admin على العنقود. ويُبلّغ فحص ما قبل التشغيل التحققي عن حالة الـ executor كما هي. نفّذ الأمر المطبوع، ثم أعد تنفيذ أمر init نفسه للتحقق:

sudo env KUBECONFIG=<path> clicklink clctl executor access apply --cluster --config /etc/clicklink/config.yaml

على Kubernetes، يؤدي رفض منح الصلاحية إلى إيقاف init قبل نشر المخطط (مخطط)، لأن executor يرتبط بـ ServiceAccount الممنوح ولا يمكنه البدء بدونه. ويُحتفظ بطبقة التهيئة المُجهَّزة (overlay) وبـ Secrets وCSR، ويطبع init الأمرين اللذين يجب تنفيذهما من مضيف يملك صلاحيات إدارة العنقود. نفّذهما، ثم أعد تشغيل الأمر init نفسه للمتابعة:

clicklink clctl executor access grant --cluster --sa-namespace <connector-namespace> --server <kubernetes-api-server-url> --output-dir <dir>
clicklink clctl executor access apply --cluster --output-dir <dir>

--force هو إعادة تعيين صريحة؛ ولا تحتاج إعادة المحاولة الروتينية إليه. فهو يستبدل الإعداد المحفوظ أو طبقة القيم المُعدِّلة، ويعيد توليد مفتاح العميل، ويستبدل شهادة عميل لم تنتهِ صلاحيتها بعد (وورود الرمز 409 من نقطة نهاية التوقيع يعني أن هناك شهادة موجودة بالفعل). وهو يحفظ معرّف UUID الخاص بعنقود الـ موصل ووضعه في نمط Managed. وتُبقي عمليات إعادة التشغيل غير التفاعلية على هذا الوضع، وعلى الطرفية يكون الـ prompt مضبوطًا عليه افتراضيًا، ما لم تمرّر --managed أو --no-managed. استخدم --force لتدوير بيانات الاعتماد أو استبدال شهادة؛ وراجع العمليات للاطلاع على النموذج الكامل لإعادة التشغيل والاستعادة.

بدء الاستخدام

الخدمات والبنية التحتية

Bring Your Own Cloud

البيانات والتكاملات

الاتصال وتنفيذ الاستعلامات

إدارة الوصول

الأمان والامتثال

المراقبة والنسخ الاحتياطية

أدوات الذكاء الاصطناعي والوكلاء

واجهة برمجة تطبيقات Cloud

الفوترة

الدعم

ClickHouse Private

المتطلبات الأساسية

تسجيل بيئتك

لكل عملية تثبيت

لعمليات التثبيت على Kubernetes (Helm)

للتثبيت على جهاز افتراضي يعمل بنظام Linux (systemd)

التثبيت والتسجيل

عمليات التثبيت المعزولة شبكيًا والمنعكسة

التنزيل والتحقق يدويًا

إذا فشل شيء ما

​المتطلبات الأساسية

​تسجيل بيئتك

​لكل عملية تثبيت

​لعمليات التثبيت على Kubernetes (Helm)

​للتثبيت على جهاز افتراضي يعمل بنظام Linux (systemd)

​التثبيت والتسجيل

​عمليات التثبيت المعزولة شبكيًا والمنعكسة

​التنزيل والتحقق يدويًا

​إذا فشل شيء ما

المتطلبات الأساسية

تسجيل بيئتك

لكل عملية تثبيت

لعمليات التثبيت على Kubernetes (Helm)

للتثبيت على جهاز افتراضي يعمل بنظام Linux (systemd)

التثبيت والتسجيل

عمليات التثبيت المعزولة شبكيًا والمنعكسة

التنزيل والتحقق يدويًا

إذا فشل شيء ما