Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs

التهيئة

تتناول هذه الصفحة تغييرات التهيئة التي يُرجّح إجراؤها بعد تثبيت ClickHouse Connector. للاطلاع على كل مفتاح وقيمته الافتراضية ومعناه، راجع مرجع التهيئة؛ ولخيارات سطر الأوامر، راجع مرجع CLI.

واجهات التهيئة

للموصل واجهة تهيئة واحدة لكل هدف تثبيت.

يُنشئ clicklink clctl init تراكب قيم باسم clicklink-values.yaml في دليل العمل، وينشر مخطط clicklink-connector باستخدامه. ويُعد هذا التراكب سجلًا دائمًا لعملية النشر: فعند إعادة تشغيل init، يُحتفَظ به ما لم تمرر --force، لذا تبقى تعديلاتك محفوظة عبر عمليات إعادة التشغيل والاستعادة.

حرّر التراكب، ثم طبّقه:

CONNECTOR_NAMESPACE='clicklink'   # مساحة أسماء الموصل التي اخترتها عند init
CHART_VERSION="$(helm get metadata clicklink-connector -n "${CONNECTOR_NAMESPACE}" | awk '/^VERSION:/{print $2}')"
helm upgrade clicklink-connector clicklink-connector \
  --repo https://releases.clicklink.clickhouse.com/charts \
  --version "${CHART_VERSION}" \
  --namespace "${CONNECTOR_NAMESPACE}" \
  -f clicklink-values.yaml

تعيد هذه الكتلة تطبيق قيمك المعدّلة على إصدار المخطط المثبّت حاليًا، لذا لا يتحول تغيير التهيئة إلى ترقية غير مخططة؛ فالانتقال إلى إصدار جديد خطوة مقصودة موضحة في العمليات. إذا كان التثبيت يستخدم نسخة معكوسة من مستودع المخططات، فاستبدل --repo بمرآتك.

لا يتضمن التثبيت من مرجع مباشر للمخطط (oci:// أو URL أو أرشيف أو دليل محلي، راجع المرايا الخاصة) مستودعًا يمكن الرجوع إليه لحل المرجع. أعد تنفيذ الترقية باستخدام المرجع الذي ثبّت منه:

helm upgrade clicklink-connector <same-chart-reference> \
  --version "${CHART_VERSION}" \
  -n "${CONNECTOR_NAMESPACE}" \
  -f clicklink-values.yaml

إضافة مثيلات ClickHouse أو تعديلها

يحدّد كل إدخال ضمن instances نقطة نهاية لبروتوكول ClickHouse الأصلي يقرأ منها الموصل: host وport وdatabase وsecure، إضافةً إلى namespace وcluster في Kubernetes. لا تُخزَّن بيانات الاعتماد في التهيئة مطلقًا؛ إذ يستخرج كل مكوّن مستخدم ClickHouse للقراءة فقط من حزمة الوصول التي ينشئها التزويد.

أضف المثيل إلى خريطتي المكوّنات في clicklink-values.yaml، وأضف مساحة اسمه إلى networkPolicy.clickhouseNamespaces (تتم المطابقة باستخدام التسمية kubernetes.io/metadata.name الخاصة بمساحة الاسم):

scraper:
  instances:
    analytics:
      host: "clickhouse-analytics.clickhouse.svc.cluster.local"
      port: 9440
      database: "default"
      secure: true
      namespace: "clickhouse"
      cluster: "default"

troubleshooter:
  instances:
    analytics:
      host: "clickhouse-analytics.clickhouse.svc.cluster.local"
      port: 9440
      database: "default"
      secure: true
      namespace: "clickhouse"
      cluster: "default"

networkPolicy:
  clickhouseNamespaces:
    - "clickhouse"

وفّر صلاحية القراءة فقط لكل مكوّن من محطة العمل لديك. يطبّق --apply-ch-grants امتيازات ClickHouse المُنشأة داخل الـ pod عبر kubectl exec؛ ومن دونه ينشئ الأمر جانب Kubernetes فقط ويترك ch-grants.sql على القرص لتطبّقه بنفسك. إذا كانت للمستخدم الإداري كلمة مرور، فأضف --ch-admin-password-stdin ومرّر كلمة المرور عبر pipe.

CONNECTOR_NAMESPACE='clicklink'   # مساحة اسم الموصل التي اخترتها عند التهيئة
clicklink clctl scraper access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance analytics --instance-namespace clickhouse \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace clickhouse
clicklink clctl troubleshoot access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance analytics --instance-namespace clickhouse \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace clickhouse

بالنسبة إلى مثيل يديره Operator ولا يتوفر له مستخدم إداري قادر على تنفيذ SQL، استبدل --apply-ch-grants بـ --ch-user-via cr (تبقى علامات اختيار الـ pod كما هي)؛ راجع مرجع CLI. ثم اربط زوج Secret وServiceAccount الذي ينشئه كل أمر بخريطة accessBundles المطابقة، وشغّل helm upgrade المعروض أعلاه:

scraper:
  accessBundles:
    analytics:
      secretName: clicklink-connector-scraper-access-analytics
      serviceAccountName: pcm-scraper-analytics

troubleshooter:
  accessBundles:
    analytics:
      secretName: clicklink-connector-troubleshooter-access-analytics
      serviceAccountName: pcm-troubleshooter-analytics

قائمة السماح بالمشغّلين

تتحكم قائمة سماح لعناوين البريد الإلكتروني للمشغّلين في الوصول إلى الجلسات المُدارة عبر Gateway: يجب أن يتضمن كل طلب إلى بوابة الجلسة رمز OIDC ID قصير الأجل، ويكون عنوان البريد الإلكتروني المُثبَت فيه مدرجًا في القائمة. تؤدي قائمة السماح الفارغة إلى إغلاق البوابة، لذا لن يتمكن أحد من فتح جلسة عبرها. على جهاز افتراضي، يمكن للمستخدم الجذر على المضيف أيضًا إدارة الجلسات مباشرةً من خلال ملف الجلسة المحلي؛ إذ تحكم قائمة السماح مسار البوابة فقط. راجع جلسات الدعم للاطلاع على نموذج الثقة الكامل.

توجد قائمة السماح في الطبقة المتراكبة وتُحوَّل إلى ConfigMap. لتغييرها، عدّل القائمة وشغّل helm upgrade:

clctl:
  gateway:
    enabled: true
    allowedOperators:
      - "oncall@example.com"
      - "dba@example.com"

سياسة الشبكة وحركة المرور الصادرة

في Kubernetes، يوفّر المخطط كائن NetworkPolicy يمنع حركة المرور افتراضيًا، مع قائمة سماح لحركة المرور الصادرة (networkPolicy.enabled: true). لا تصبح كائنات NetworkPolicy نافذة إلا إذا كانت CNI لديك تفرض تطبيقها؛ ومع CNI تفرضها، لن يتمكن الموصل من إرسال أي حركة مرور صادرة حتى تحدد allowEgressCIDRs نطاقات CIDR الخاصة بنقطة نهاية واجهة برمجة تطبيقات الموصل.

networkPolicy:
  enabled: true
  # CIDRs behind your connector API endpoint. Required under an enforcing CNI.
  allowEgressCIDRs:
    - "203.0.113.0/24"
  # Ports opened to allowEgressCIDRs.
  allowEgressPorts:
    - 443
  # Namespaces of your ClickHouse Services, matched by the
  # kubernetes.io/metadata.name label. Empty allows no in-cluster
  # ClickHouse access.
  clickhouseNamespaces:
    - "clickhouse"
  # Kubernetes API server CIDRs. On managed Kubernetes the API server sits
  # outside the cluster network, so it cannot be matched with a selector.
  apiserverCIDRs:
    - "172.16.0.0/28"

تتطلب قاعدتان اهتمامًا خاصًا:

  • apiserverCIDRs: عند تركها فارغة، لا يُصدر المخطط أي قاعدة خروج لخادم API. وعندها تفشل البرامج الخفية في أول طلب لرمز Kubernetes بسبب خطأ في الشبكة، ما يشير إلى ضرورة ضبطها. في Kubernetes المُدار، استخدم نطاقات CIDR لنقاط نهاية خادم API الخاصة بالعنقود.
  • clctl.gateway.jwksEgressCIDRs: عند تمكين بوابة الجلسة، تجلب أداة استكشاف الأخطاء وإصلاحها مفاتيح JWKS الخاصة بموفّر الهوية لديك للتحقق من صحة رموز المشغّلين. ضمن نهج الرفض الافتراضي، يؤدي ترك هذا الحقل فارغًا إلى حظر جميع عمليات التحقق من الرموز:
clctl:
  gateway:
    jwksEgressCIDRs:
      - "199.36.153.8/30"

المثال هو النطاق 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):

version: 1
patterns:
  - name: internal-hostname
    regex: '\b[a-z0-9-]+\.corp\.example\.com\b'
    replace: '[REDACTED:internal-host]'

  # Reusing a built-in name replaces the built-in pattern.
  - name: ipv4
    regex: '\b(?:\d{1,3}\.){3}\d{1,3}\b'
    replace: '[REDACTED:ip]'

على جهاز افتراضي، يوجد الملف في /etc/clicklink/redaction-patterns.yaml؛ وينشئ المثبّت ملفًا افتراضيًا مُعلّقًا ويحافظ على نسختك عبر عمليات الترقية. في Kubernetes، ضع ملف YAML في ConfigMap تحت المفتاح redaction-patterns.yaml واضبط troubleshooter.redaction.patternsConfigMap على اسمه؛ إذ يقوم مخطط بربطه في المسار نفسه.

المرايا الخاصة ونقاط النهاية ضمن الحدود

يُعيّن المخطط المنشور مسبقًا image.repository إلى صورة موصل عامة متعددة المعماريات وموقّعة باستخدام cosign، لذا لا تتطلب عمليات التثبيت العادية قيمًا للصورة. لفحص الإعدادات الافتراضية المنشورة:

CLICKLINK_VERSION="$(curl -fsSL https://releases.clicklink.clickhouse.com/latest-version.txt)"
helm show values clicklink-connector \
  --repo https://releases.clicklink.clickhouse.com/charts \
  --version "${CLICKLINK_VERSION#v}"

للسحب عبر السجل الخاص بك، استبدل المستودع في التراكب:

image:
  repository: "registry.example.com/mirrors/clicklink"

لتثبيت المخطط نفسه من مرآة، يقبل init الخيار --chart إما كاسم مخطط يُحلّ ضمن --chart-repo، أو كمرجع oci:// مباشر، أو URL، أو أرشيف أو دليل محلي. يستخدم --chart-version إصدار CLI نفسه افتراضيًا، بحيث يبقى الملف الثنائي والمخطط متزامنين:

clicklink clctl init --handoff handoff.yaml --target helm \
  --chart oci://registry.example.com/charts/clicklink-connector

عندما تكون نقطة نهاية واجهة برمجة تطبيقات الموصل خلف مرجع تصديق خاص (CA) ضمن نطاقك، مرّر --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، وتُضاف إلى جذور النظام لأغراض التحقق. للتسجيل وتوقيع الشهادات في بيئة معزولة هوائياً بالكامل، راجع الإعداد الأوّلي.

التخزين

يحتفظ مستكشف الأخطاء وإصلاحها بحالته في PersistentVolumeClaim، بحيث تظل حالة الجلسة وسجل التدقيق محفوظين بعد إعادة جدولة pod:

persistence:
  enabled: true
  storageClass: "gp3"
  size: 5Gi

تستخدم storageClass الفارغة StorageClass الافتراضية للعنقود. وإذا لم يكن للعنقود StorageClass افتراضية، يتطلب init تحديد واحدة عبر الموجّه أو الخيار --storage-class.

Navigation