واجهات التهيئة
- Kubernetes
- جهاز Linux افتراضي
يُنشئ حرّر التراكب، ثم طبّقه:تعيد هذه الكتلة تطبيق قيمك المعدّلة على إصدار المخطط المثبّت حاليًا، لذا لا يتحول تغيير التهيئة إلى ترقية غير مخططة؛ فالانتقال إلى إصدار جديد خطوة مقصودة موضحة في العمليات. إذا كان التثبيت يستخدم نسخة معكوسة من مستودع المخططات، فاستبدل
clicklink clctl init تراكب قيم باسم clicklink-values.yaml في دليل العمل، وينشر مخطط clicklink-connector باستخدامه. ويُعد هذا التراكب سجلًا دائمًا لعملية النشر: فعند إعادة تشغيل init، يُحتفَظ به ما لم تمرر --force، لذا تبقى تعديلاتك محفوظة عبر عمليات إعادة التشغيل والاستعادة.تستخدم أوامر التشغيل اللاحقة للنشر في هذه الصفحة وفي العمليات واجهة سطر الأوامر
helm. وحده init يتضمن عميل Helm مدمجًا.--repo بمرآتك.لا يتضمن التثبيت من مرجع مباشر للمخطط (oci:// أو URL أو أرشيف أو دليل محلي، راجع المرايا الخاصة) مستودعًا يمكن الرجوع إليه لحل المرجع. أعد تنفيذ الترقية باستخدام المرجع الذي ثبّت منه:إضافة مثيلات ClickHouse أو تعديلها
instances نقطة نهاية لبروتوكول ClickHouse الأصلي يقرأ منها الموصل: host وport وdatabase وsecure، إضافةً إلى namespace وcluster في Kubernetes. لا تُخزَّن بيانات الاعتماد في التهيئة مطلقًا؛ إذ يستخرج كل مكوّن مستخدم ClickHouse للقراءة فقط من حزمة الوصول التي ينشئها التزويد.
- Kubernetes
- جهاز Linux افتراضي
أضف المثيل إلى خريطتي المكوّنات في وفّر صلاحية القراءة فقط لكل مكوّن من محطة العمل لديك. يطبّق بالنسبة إلى مثيل يديره Operator ولا يتوفر له مستخدم إداري قادر على تنفيذ SQL، استبدل
clicklink-values.yaml، وأضف مساحة اسمه إلى networkPolicy.clickhouseNamespaces (تتم المطابقة باستخدام التسمية kubernetes.io/metadata.name الخاصة بمساحة الاسم):--apply-ch-grants امتيازات ClickHouse المُنشأة داخل الـ pod عبر kubectl exec؛ ومن دونه ينشئ الأمر جانب Kubernetes فقط ويترك ch-grants.sql على القرص لتطبّقه بنفسك. إذا كانت للمستخدم الإداري كلمة مرور، فأضف --ch-admin-password-stdin ومرّر كلمة المرور عبر pipe.--apply-ch-grants بـ --ch-user-via cr (تبقى علامات اختيار الـ pod كما هي)؛ راجع مرجع CLI. ثم اربط زوج Secret وServiceAccount الذي ينشئه كل أمر بخريطة accessBundles المطابقة، وشغّل helm upgrade المعروض أعلاه:قائمة السماح بالمشغّلين
- Kubernetes
- جهاز Linux افتراضي
توجد قائمة السماح في الطبقة المتراكبة وتُحوَّل إلى ConfigMap. لتغييرها، عدّل القائمة وشغّل
helm upgrade:سياسة الشبكة وحركة المرور الصادرة
networkPolicy.enabled: true). لا تصبح كائنات NetworkPolicy نافذة إلا إذا كانت CNI لديك تفرض تطبيقها؛ ومع CNI تفرضها، لن يتمكن الموصل من إرسال أي حركة مرور صادرة حتى تحدد allowEgressCIDRs نطاقات CIDR الخاصة بنقطة نهاية واجهة برمجة تطبيقات الموصل.
apiserverCIDRs: عند تركها فارغة، لا يُصدر المخطط أي قاعدة خروج لخادم API. وعندها تفشل البرامج الخفية في أول طلب لرمز Kubernetes بسبب خطأ في الشبكة، ما يشير إلى ضرورة ضبطها. في Kubernetes المُدار، استخدم نطاقات CIDR لنقاط نهاية خادم API الخاصة بالعنقود.clctl.gateway.jwksEgressCIDRs: عند تمكين بوابة الجلسة، تجلب أداة استكشاف الأخطاء وإصلاحها مفاتيح JWKS الخاصة بموفّر الهوية لديك للتحقق من صحة رموز المشغّلين. ضمن نهج الرفض الافتراضي، يؤدي ترك هذا الحقل فارغًا إلى حظر جميع عمليات التحقق من الرموز:
private.googleapis.com، الذي يشمل موفّر هوية من Google يمكن الوصول إليه عبر Private Google Access. بالنسبة إلى أي موفّر هوية آخر، حدّد نطاق ذلك الموفّر (أو CIDR لخادم الوكيل الصادر الذي يسبقه).
إعدادان إضافيان لـ Ingress: يقيّد metricsScrapeSelector حركة Ingress الخاصة بكشط المقاييس إلى مساحة اسم محددة في Prometheus استنادًا إلى تسمية، بينما يسمح kubeletProbeCIDRs صراحةً بمسبارات السلامة الخاصة بـ kubelet في البيئات التي تتبع سياسة رفض افتراضية صارمة. راجع مرجع التهيئة للاطلاع على القائمة الكاملة للمفاتيح.
أنماط إخفاء المعلومات الحساسة
ipv4 وipv6 وbearer-token وaws-access-key وemail وjwt وssh-private-key وconnection-string-credentials. يمكنك إضافة أنماطك الخاصة في ملف YAML؛ إذ تُطبَّق أنماطك أولًا حسب ترتيبها في الملف، ثم الأنماط المضمّنة. ويستبدل الإدخال الذي يعيد استخدام name لنمط مضمّن ذلك النمط.
يحدّد كل نمط name (مطلوب وفريد)، وregex (مطلوب، بصياغة Go RE2)، وreplace (القيمة الافتراضية [REDACTED]، ويدعم مراجع الالتقاط مثل $1)، وcase_insensitive (القيمة الافتراضية false):
/etc/clicklink/redaction-patterns.yaml؛ وينشئ المثبّت ملفًا افتراضيًا مُعلّقًا ويحافظ على نسختك عبر عمليات الترقية. في Kubernetes، ضع ملف YAML في ConfigMap تحت المفتاح redaction-patterns.yaml واضبط troubleshooter.redaction.patternsConfigMap على اسمه؛ إذ يقوم مخطط بربطه في المسار نفسه.
المرايا الخاصة ونقاط النهاية ضمن الحدود
image.repository إلى صورة موصل عامة متعددة المعماريات وموقّعة باستخدام cosign، لذا لا تتطلب عمليات التثبيت العادية قيمًا للصورة. لفحص الإعدادات الافتراضية المنشورة:
init الخيار --chart إما كاسم مخطط يُحلّ ضمن --chart-repo، أو كمرجع oci:// مباشر، أو URL، أو أرشيف أو دليل محلي. يستخدم --chart-version إصدار CLI نفسه افتراضيًا، بحيث يبقى الملف الثنائي والمخطط متزامنين:
--api-private-ca إلى init: إذ يُهيّئ api.tls.caFile: /etc/clicklink/secrets/mtls/ca.crt، بحيث يُتحقق من نقطة النهاية باستخدام سلسلة CA من حزمة التسجيل بدلاً من جذور النظام. على جهاز افتراضي (VM)، يكون المكافئ هو api.tls.ca_file في /etc/clicklink/config.yaml؛ يثبّت init سلسلة الحزمة في /etc/clicklink/tls/ca.crt، وتُضاف إلى جذور النظام لأغراض التحقق. للتسجيل وتوقيع الشهادات في بيئة معزولة هوائياً بالكامل، راجع الإعداد الأوّلي.
التخزين
- Kubernetes
- جهاز Linux افتراضي
يحتفظ مستكشف الأخطاء وإصلاحها بحالته في PersistentVolumeClaim، بحيث تظل حالة الجلسة وسجل التدقيق محفوظين بعد إعادة جدولة pod:تستخدم
storageClass الفارغة StorageClass الافتراضية للعنقود. وإذا لم يكن للعنقود StorageClass افتراضية، يتطلب init تحديد واحدة عبر الموجّه أو الخيار --storage-class.