التهيئة

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

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

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

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

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

تستخدم أوامر التشغيل اللاحقة للنشر في هذه الصفحة وفي العمليات واجهة سطر الأوامر helm. وحده init يتضمن عميل Helm مدمجًا.

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

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

يكتب clicklink clctl init الملف /etc/clicklink/config.yaml. عند إعادة تشغيل init، يُحتفَظ بملف تهيئة موجود ما لم تمرر --force، لذا يمكنك تحرير الملف يدويًا بأمان. بعد التحرير، أعد تشغيل البرامج الخفية ثم تحقّق:

sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor
sudo clicklink clctl preflight

الوضع المُدار

يُشغّل الوضع المُدار المنفّذ، الذي يطبّق على عنقودك دورة حياة الخدمة التي تقودها ClickHouse Cloud. ويقوم init بتفعيله عند التسجيل ويملأ هوية العنقود (انظر تفعيل الوضع المُدار). أما المفاتيح أدناه فهي التي قد تحتاج إلى مراجعتها لاحقًا. ولتغيير الوضعية، أعد تنفيذ init مع --force و--managed أو --no-managed. وكما هو الحال في كل تنفيذ لـ init، يتطلب ذلك نقطة دخول: --handoff إذا احتفظت بالحزمة، أو --enroll مع رمز جديد (انظر إعادة التنفيذ والاسترداد). على جهاز افتراضي، يعطّل --no-managed المنفّذ في التهيئة، لكنه لا يوقف وحدة systemd قيد التشغيل ولا يعطّلها. أوقفها قبل تغيير التهيئة:

sudo systemctl disable --now clicklink-executor

في Kubernetes، اضبط executor.enabled: false في القيم وطبّقها عبر helm upgrade لإزالة Deployment الخاص بالمنفّذ. وفي كلا الهدفين يظل منح العنقود قائمًا إلى أن تقوم بإزالته؛ راجع إيقاف الوضع المُدار.

Kubernetes
جهاز افتراضي يعمل بنظام Linux

يُجهّز init كتلة executor في clicklink-values.yaml انطلاقًا من عنقود EKS الذي يشير إليه سياق kube لديك:

cluster:
  # Service namespaces are <namespacePrefix><service>; must match the
  # prefix you registered.
  namespacePrefix: ns-

executor:
  enabled: true
  pollInterval: 30s
  syncInterval: 30s
  # Local command API, bound to 127.0.0.1 inside the pod only.
  apiPort: 9999
  ports:
    health: 8086
  cluster:
    name: <eks-cluster-name>
    region: us-east-1
    accountId: "123456789012"
    inCluster: true
    # Optional shared data bucket; per-service storage normally arrives
    # with each service, so leave it out unless your account team asks for it.
    # s3_storage:
    #   bucket: <data-bucket>
    #   backup_bucket: <backup-bucket>
  serviceAccount:
    create: false
    name: pcm-executor
  persistence:
    enabled: true
    storageClass: ""
    size: 5Gi
  platformBundleSecret: clicklink-platform-bundle

cluster.namespacePrefix تشترك فيه جميع المكوّنات، وهو البادئة التي يقصر إذن المُنفِّذ (executor) نطاقه عليها. ويعني تغييره بعد التثبيت إعادة تنفيذ منح الإذن.
executor.cluster هو عنقود واحد بالضبط: name وregion وaccountId وinCluster: true، وهو ما يجعل المُنفِّذ يستوثق بهوية ServiceAccount الخاص بالـ pod. أما المفاتيح الأخرى فتُمرَّر إلى المُنفِّذ حرفيًا بصيغة snake_case، مثل s3_storage.
executor.serviceAccount يبقى create: false: إذ يمنح init وصولًا على مستوى العنقود بأكمله إلى ServiceAccount المسمى pcm-executor في نطاق أسماء الـ connector، ويرتبط المخطط به بدلًا من إنشاء حساب جديد غير مرتبط.
executor.persistence يوفّر التخزين الدائم لـ /var/lib/clicklink، حيث يحتفظ المُنفِّذ بقاعدة بيانات الأوامر وسجل الخدمات الخاص به؛ راجع storage.
executor.platformBundleSecret يحدّد اسم الـ Secret الذي يحتوي على تحديث منصة معتمد. والربط اختياري، لذا يبدأ الـ pod عمله قبل أول اعتماد؛ راجع اعتماد تحديث منصة.
executor.ports.health يوفّر /livez و/metrics؛ ولا يوجد منفذ مقاييس منفصل في أي مكوّن.

طبّق التغييرات باستخدام helm upgrade الموضّح في أسطح التهيئة.

يكتب الأمر init كتلة executor في الملف /etc/clicklink/config.yaml استنادًا إلى البيانات الوصفية لنسخة المضيف وملف kubeconfig. أما المفتاحان interval وport فهما قيمتان افتراضيتان يمكنك إضافتهما لتجاوز القيم الأصلية:

# Service namespaces are <namespace_prefix><service>; must match the
# prefix you registered.
namespace_prefix: ns-

executor:
  enabled: true
  cluster:
    name: <eks-cluster-name>
    region: us-east-1
    account_id: "123456789012"
    # Optional shared data bucket; per-service storage normally arrives
    # with each service, so leave it out unless your account team asks for it.
    # s3_storage:
    #   bucket: <data-bucket>
    #   backup_bucket: <backup-bucket>
  poll_interval: 5m
  sync_interval: 30s
  # Local command API, bound to 127.0.0.1 only.
  api_port: 9999
  observability:
    health_port: 8086

namespace_prefix مفتاح عالي المستوى تتشاركه جميع المكوّنات، وهو البادئة التي يقتصر عليها منح (grant) المنفّذ (executor). ويعني تغييره بعد التثبيت إعادة تنفيذ المنح.
executor.cluster عنقود واحد بالضبط. ويصادق المنفّذ باستخدام حزمة الوصول على مستوى العنقود التي ولّدها init ضمن /etc/clicklink/access/executor/_cluster.
poll_interval يحدّد عدد مرّات إعادة محاولة المنفّذ تنفيذ الأوامر التي سجّلها ولم يتمكّن من إكمالها؛ أمّا sync_interval فيحدّد عدد مرّات مواءمة حالة الخدمات المُدارة مع العنقود.
api_port هو واجهة برمجة تطبيقات الأوامر المحلية الخاصة بالمنفّذ. وهي ترتبط بواجهة الاسترجاع (loopback) فقط ولا تتضمّن مصادقة خاصة بها، ولهذا تُنفَّذ أوامر خدمة clicklink clctl على المضيف.
observability.health_port يقدّم /livez و/metrics؛ ولا يوجد منفذ مقاييس منفصل في أي مكوّن.

بعد التحرير، أعد تشغيل المنفّذ وتحقّق:

sudo systemctl restart clicklink-executor
sudo clicklink clctl preflight

إضافة مثيلات ClickHouse أو تغييرها

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

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

أضف المثيل إلى خريطة instances ذات المستوى الأعلى في clicklink-values.yaml (بالحقول نفسها الموجودة في سجل الجهاز الافتراضي). وأضف مساحة اسمه إلى networkPolicy.clickhouseNamespaces، وتتم المطابقة باستخدام التسمية kubernetes.io/metadata.name الخاصة بمساحة الاسم. يعرض المخطط الخريطة داخل ConfigMap باسم clicklink-instance-registry التي يقرأ منها البرنامجان الخفيان. ولا يعمل ذلك إلا عندما تكون executor.enabled بالقيمة false؛ فعند تفعيل المنفّذ يفشل العرض لأن المنفّذ هو مالك تلك ConfigMap.

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

على جهاز افتراضي، توجد المثيلات في ملف السجل /var/lib/clicklink/instances.yaml، وليس في config.yaml حيث يُتجاهل أي مقطع instances:. يملأ init السجل انطلاقًا من --instance، ويلتقط الـ scraper التعديلات من دون إعادة تشغيل. أضف المثيل ضمن خريطة instances: ذات المستوى الأعلى:

instances:
  analytics:
    host: "10.0.12.34"
    port: 9440
    database: "default"
    secure: true
    cluster: "default"

ثم وفّر الوصول لكل مكوّن على المضيف بصفتك root. تكون كلمة مرور المستخدم الإداري إلزامية ما لم تمرّر --ch-user-via cr؛ مرّرها عبر pipe باستخدام --ch-admin-password-stdin. يطبّق كل أمر امتيازات ClickHouse ويعيد تشغيل برنامجه الخفي (يمكنك تخطي إعادة التشغيل باستخدام --skip-restart):

printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl scraper access provision --provider local \
  --instance analytics --server <kubernetes-api-server-url> --ch-admin-password-stdin
printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl troubleshoot access provision --provider local \
  --instance analytics --server <kubernetes-api-server-url> --ch-admin-password-stdin

تعمل أوامر access provision نفسها مع --force على تدوير بيانات اعتماد ClickHouse الخاصة بالمثيل. راجع العمليات.

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

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

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

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

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

يكتب init قائمة السماح إلى /etc/clicklink/allowed-operators.txt، بمعدل عنوان بريد إلكتروني واحد في كل سطر:

oncall@example.com
dba@example.com

تعيد البوابة قراءة الملف عند الطلب التالي بعد مرور 30 ثانية على آخر قراءة، لذا تسري التعديلات دون إعادة تشغيل.

سياسة الشبكة وحركة الخروج (egress)

على Kubernetes، يأتي المخطط مزوّدًا بكائن NetworkPolicy افتراضي يرفض كل الحركة، مع allowlist لحركة الخروج. ولا تصبح كائنات NetworkPolicy سارية المفعول إلا إذا كان الـ CNI لديك يفرضها. وفي ظل CNI يفرض السياسات، يقتصر الوصول على DNS العنقود ومساحات أسماء ClickHouse Service إلى أن تُملأ قائمتا CIDR معًا. وحتى ذلك الحين، لا يملك الموصل أي حركة خروج نحو نقطة نهاية الموصل أو خادم API الخاص بـ Kubernetes. ولا يهيّئ init السياسة في حالة enabled إلا عندما يعرف نطاقات CIDR الواقعة خلف نقطة نهاية الموصل لديك.

networkPolicy:
  enabled: true
  # CIDRs behind your connector endpoint (--egress-cidrs at init).
  allowEgressCIDRs:
    - "203.0.113.0/24"
  # Ports opened to allowEgressCIDRs.
  allowEgressPorts:
    - 443
  # Namespaces of ClickHouse you run yourself, matched by the
  # kubernetes.io/metadata.name label. Namespaces the executor creates
  # are admitted by the label it stamps on them and need no entry here.
  clickhouseNamespaces: []
  # Kubernetes API server CIDRs: your cluster VPC's ranges, staged by init
  # from the EKS cluster. Never the API server's own addresses, which
  # change over the cluster's life.
  apiserverCIDRs:
    - "10.0.0.0/16"

تأتي قائمتا CIDR من مصدرين مختلفين:

allowEgressCIDRs أنت من يوفّرها: وهي النطاقات الواقعة خلف نقطة نهاية الموصل الخاصة بك، وتُحدَّد عند التثبيت عبر --egress-cidrs أو عند المطالبة. وتحتاج إليها جميع المكوّنات للوصول إلى نقطة نهاية الموصل الخاصة بك. وفي الوضع المُدار، عندما تكون مخططات المنصة موجودة في Amazon ECR، أضف نطاقات ECR وSTS الخاصة بمنطقتك (أو نطاق mirror الخاص بك). فمن دونها تفشل عمليات سحب مخططات المنفّذ بموجب السياسة.
apiserverCIDRs يشتقّها init في الوضع المُدار من شبكة VPC الخاصة بعنقود EKS (eks:DescribeCluster وec2:DescribeVpcs). فكل مكوّن يُصدر طلبات رموز Kubernetes، ويدير المنفّذ الخدمات عبر واجهة برمجة التطبيقات، ولذلك تُحجب جميعها في ظل CNI يفرض السياسات إلى أن تُضبط هذه القائمة. وإذا فشل الـ lookup، يُصدر init تحذيرًا ويترك القائمة فارغة لتملأها بكتل CIDR الخاصة بشبكة VPC لديك.

تُحدَّد مساحات أسماء الخدمة بطريقتين. فالمساحات التي ينشئها المنفّذ تحمل الوسم clicklink.clickhouse.com/managed-by: executor، وتسمح بها السياسة استنادًا إلى هذا الوسم، ولذلك يمكن في التثبيت المُدار ترك clickhouseNamespaces فارغة. أما المساحات المنشأة خارج المنفّذ، لأجل ClickHouse الذي تشغّله بنفسك، فهي وحدها التي يلزم إدراجها بالاسم. تفعيل السياسة لاحقًا. إذا تخطّيت نطاقات CIDR الخاصة بنقطة النهاية عند التثبيت، فسيهيّئ init القيمة enabled: false مع allowEgressCIDRs: [] ويطبع الخطوة اللازمة لإتمام الأمر. وبمجرد معرفتك بنطاقات CIDR، اضبط enabled: true وallowEgressCIDRs في clicklink-values.yaml، وتأكد من أن apiserverCIDRs يحتوي على نطاقات شبكة VPC لديك، ثم نفّذ helm upgrade الموضّح في أسطح التهيئة. وعند تفعيل بوابة الجلسة، تبرز قاعدة خروج إضافية مهمة: clctl.gateway.jwksEgressCIDRs. إذ يجلب مستكشف الأخطاء ومصلحها JWKS الخاص بمزوّد الهوية لديك للتحقق من operator tokens، ولذلك فإن ترك القائمة فارغة في ظل الرفض الافتراضي يحجب كل عمليات التحقق من الرموز:

clctl:
  gateway:
    jwksEgressCIDRs:
      - "199.36.153.8/30"

المثال هنا هو نطاق private.googleapis.com، الذي يغطي مزوّد هوية من Google يتم الوصول إليه عبر Private Google Access. أما لأي مزوّد هوية آخر، فحدّد نطاقه، أو نطاق CIDR الخاص بوسيط الخروج (egress) الذي يتوسّطه. يتبقى مفتاحان للدخول: metricsScrapeSelector الذي يقصر دخول سحب المقاييس على مساحة أسماء واحدة لـ 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. ويهيّئ المثبّت الملف بمجموعة أولية من الأنماط النشطة (مفاتيح واجهات برمجة التطبيقات لأطراف خارجية، ومفاتيح AWS السرية، وما إلى ذلك). يمكنك تقليص هذه المجموعة أو توسيعها؛ ويحافظ المثبّت على نسختك عبر عمليات الترقية. في Kubernetes، ضع ملف YAML في ConfigMap تحت المفتاح redaction-patterns.yaml واضبط troubleshooter.redaction.patternsConfigMap على اسمه؛ إذ يقوم مخطط بربطه في المسار نفسه.

يرفض مستكشف الأخطاء وإصلاحها البدء إذا كان ملف الأنماط موجودًا لكنه غير صالح، ويسجل الإدخال المسبّب للمشكلة. أما الملف المهيّأ غير الموجود فيؤدي فقط إلى تسجيل تحذير واستخدام الأنماط المضمّنة. يتحقق clicklink clctl preflight من صحة الملف، لذا شغّله قبل إعادة تشغيل البرنامج الخفي.

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

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

clicklink clctl init --handoff handoff.yaml --target helm --managed \
  --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، ويلحقها الموصل بجذور النظام بالطريقة نفسها. للتسجيل وتوقيع الشهادات في بيئة معزولة هوائياً بالكامل، راجع الإعداد الأوّلي.

التخزين

Kubernetes
جهاز افتراضي يعمل بنظام Linux

يحتفظ مكوّنان بحالتهما على PersistentVolumeClaims. فمطالبة مستكشف الأخطاء ومصلحها تحتفظ بحالة الجلسة وسجل التدقيق:

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

أما مطالبة المنفّذ فتحتفظ بقاعدة بيانات الأوامر الخاصة به وبسجل الخدمات التي يديرها:

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

يضبط init كلتا قيمتَي storageClass على الفئة التي اخترتها. وتؤدي قيمة storageClass الفارغة إلى استخدام StorageClass الافتراضية للعنقود؛ وإذا لم يحدد العنقود فئة افتراضية، يطلب init تحديد واحدة عبر الموجّه أو عبر --storage-class. وتحمل مطالبة المنفّذ التعليق التوضيحي helm.sh/resource-policy: keep، لذا يتركها helm uninstall في مكانها؛ راجع إلغاء التثبيت.

يخزّن الساحب المقاييس مؤقتًا في /var/lib/clicklink/buffer لضمان التسليم مرة واحدة على الأقل عند تعذّر الوصول إلى نقطة نهاية الموصّل لديك. وهو يحتفظ بها افتراضيًا لمدة تصل إلى 168 ساعة أو بحجم يصل إلى 1024 ميغابايت، ويرفعها بمعدل يصل إلى 1 ميغابايت/ثانية:

scraper:
  buffer:
    path: /var/lib/clicklink/buffer
    retention: 168h
    max_size_mb: 1024

ويحتفظ المنفّذ بقاعدة بيانات الأوامر الخاصة به في /var/lib/clicklink/executor.db وبسجل الخدمات في /var/lib/clicklink/instances.yaml. ويبقى كلاهما بعد عمليات إعادة التشغيل والترقيات، كما يحافظ عليهما uninstall.sh ما لم تمرّر --purge.ويتضمّن clicklink clctl preflight فحوصًا للقرص تشمل دليل المخزن المؤقت و/var/log.

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

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

Bring Your Own Cloud

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

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

إدارة الوصول

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

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

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

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

الفوترة

الدعم

ClickHouse Private

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

الوضع المُدار

إضافة مثيلات ClickHouse أو تغييرها

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

سياسة الشبكة وحركة الخروج (egress)

أنماط إخفاء المعلومات الحساسة

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

التخزين

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

​الوضع المُدار

​إضافة مثيلات ClickHouse أو تغييرها

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

​سياسة الشبكة وحركة الخروج (egress)

​أنماط إخفاء المعلومات الحساسة

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

​التخزين

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

الوضع المُدار

إضافة مثيلات ClickHouse أو تغييرها

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

سياسة الشبكة وحركة الخروج (egress)

أنماط إخفاء المعلومات الحساسة

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

التخزين