العمليات

تغطي هذه الصفحة عمليات ما بعد النشر للموصل على كلا هدفي التثبيت. للتثبيت والإعداد الأولي، راجع الإعداد الأولي. أما تشغيل الخدمات نفسها (الإنشاء، والتوسع، والحذف، وتحديثات المنصة) فتتناوله صفحتا الخدمات المُدارة وتحديثات المنصة.

الترقيات

Kubernetes

تستخدم عمليات Kubernetes بعد النشر واجهة سطر الأوامر helm على محطة عملك. لا يتضمن عميل Helm مدمجًا سوى init، لذا ثبّت helm قبل أول ترقية.

رقِّ الإصدار من مستودع المخططات العام باستخدام تراكب القيم الذي أعدّه init:

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm upgrade --install clicklink-connector clicklink-connector \
  --repo https://releases.clicklink.clickhouse.com/charts \
  --version <version> \
  -n "${CONNECTOR_NAMESPACE}" \
  -f clicklink-values.yaml

إصدارات مخطط هي وسوم الإصدار من دون بادئة v (يتوافق مخطط بالإصدار X.Y.Z مع الوسم vX.Y.Z). يشير مخطط المنشور مسبقاً إلى image الحاوية العامة، لذا لا تتطلب عمليات التثبيت والترقية العادية قيماً لـ image. وللاطلاع على القيم الافتراضية لـ مخطط، شغّل helm show values clicklink-connector --repo https://releases.clicklink.clickhouse.com/charts. يعمل المنفّذ بنسخة replica واحدة باستخدام strategy الخاصة بـ Recreate، لذا تؤدي الترقية إلى قطع اتصاله لفترة وجيزة. راجع عندما يكون موصل غير متصل لمعرفة ما يحدث للأوامر خلال تلك المدة. لا يتوفر لعملية التثبيت من مرجع مخطط مباشر (oci:// أو URL أو أرشيف أو دليل محلي) repository يمكن الرجوع إليه لحل المرجع. أعد تشغيل helm upgrade clicklink-connector <same-chart-reference> بالإصدار الجديد بدلاً من ذلك. كما أن إعادة تشغيل init باستخدام واجهة سطر أوامر أحدث توصل إلى الحالة المطلوبة، لكنها تحتاج إلى نقطة دخول: --handoff إذا احتفظت بـ bundle، أو رمز تسجيل جديد مع --force بعد التنظيف الموثّق. ويُعد helm upgrade المذكور أعلاه المسار المعتاد (راجع إعادة التشغيل والتعافي).

Linux VM

أعِد تشغيل برنامج التثبيت على المضيف. إذ سيُنزّل الإصدار الأحدث ويتحقق منه كما فعل أثناء الإعداد الأولي. وسيُنشئ نسخة احتياطية من الملف التنفيذي السابق، ويثبّت وحدات systemd الحالية، مع الاحتفاظ بأنماط الإخفاء وملف البيئة النشطين لديك. ثم أعد تشغيل البرامج الخفية:

curl -fsSL https://releases.clicklink.clickhouse.com/install.sh | sudo bash -s -- --host
sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor

للترقية إلى إصدار محدد بدلًا من أحدث إصدار، أضف --version vX.Y.Z إلى أمر التثبيت.

الحالة الصحية

توفّر كل برنامج خفي نقطة نهاية /livez على منفذ الحالة الصحية الخاص بها. ومؤشر الحالة الصحية هو حقل JSON ‏status في جسم الاستجابة، وليس رمز حالة HTTP. تُوفَّر مقاييس Prometheus على المسار /metrics على المنفذ نفسه؛ ولا يوجد منفذ مقاييس منفصل. المنافذ الافتراضية لكلا الهدفين:

المكوّن	منفذ الحالة الصحية
أداة الكشط	8082
مستكشف الأخطاء ومصلحها	8084
المنفّذ	8086

يوفّر المنفّذ أيضًا واجهة برمجة تطبيقات الأوامر المحلية الخاصة به على 127.0.0.1:9999. وهي لا تتضمن أي مصادقة خاصة بها ولا تُعرَض أبدًا خارج المضيف أو الـpod؛ وتصل إليها أوامر الخدمة clicklink clctl محليًا. عند تمكين جلسات الدعم، تستمع البوابة أيضًا على المنفذ 8443: باستخدام TLS موقّع ذاتيًا على جهاز افتراضي، أو HTTP محلي ضمن الـpod خلف kubectl port-forward، أو Ingress ينهي TLS على Kubernetes. على جهاز افتراضي، شغّل مجموعة الفحوصات الكاملة في أي وقت:

sudo clicklink clctl preflight

يتحقق من الإعدادات والملفات وتعارضات المنافذ وإمكانية الوصول عبر الشبكة والاتصال بـ ClickHouse وحالة وحدة systemd ووصول كل مكوّن والقرص وأنماط الإخفاء. وينهي التنفيذ بالرمز 2 إذا فشل أي فحص.

الشهادات

يجدد الموصل شهادة العميل الخاصة به. يتحقق كل من الساحب ومستكشف الأخطاء ومصلحها والمنفّذ من الشهادة الطرفية كل 12 ساعة ويجددها عند تبقي 10 أيام على انتهاء صلاحيتها. يعيد التجديد شهادة طرفية صالحة لمدة 30 يوماً عبر قناة mTLS الحالية الموثقة باستخدام HMAC، لذا لا يلزم اتخاذ أي إجراء من قِبل المشغّل. في Kubernetes، يكتب البرنامج الخفي الشهادة الطرفية المجددة مجدداً في Secret clicklink-mtls؛ وعلى جهاز افتراضي، يكتبها ضمن /etc/clicklink/tls/. لفحص تاريخ انتهاء الصلاحية الحالي:

# Linux VM
sudo openssl x509 -in /etc/clicklink/tls/client.crt -noout -enddate

# Kubernetes
CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
kubectl get secret clicklink-mtls -n "${CONNECTOR_NAMESPACE}" -o jsonpath='{.data.tls\.crt}' \
  | base64 -d | openssl x509 -noout -enddate

تدوير بيانات الاعتماد

بيانات اعتماد واجهة برمجة التطبيقات (HMAC)

اطلب رمز تسجيل جديدًا من فريق حسابك، ثم أعد تشغيل أمر init الأصلي مع --enroll و--force. احتفظ بجميع الرايات الخاصة بالهدف المستخدمة في التثبيت الأول (--target-namespace و--values وأي رايات mirror مثل --chart أو --chart-repo أو --chart-version)، لأن --force يعيد إعداد التهيئة المحفوظة. ينتقل وضع مُدار من التهيئة التي يجري استبدالها، لذا فإن --managed اختياري هنا. في تثبيت default:

# Kubernetes, from your workstation
clicklink clctl init --enroll https://<subdomain>.<connector-domain> --target helm --force

# Linux VM, on the host
sudo clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force

على جهاز افتراضي، يقتصر init على تمكين وبدء الوحدات التي لا تعمل بعد، لذا أعد تشغيل البرامج الخفية بعد التدوير:

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

في Kubernetes، ينشئ init مسبقًا Secretَي clicklink-hmac وclicklink-mtls المُدوَّرين؛ ولا ينشئهما المخطط. ولا يشملهما التعليق التوضيحي لقيمة التحقق الخاص به، لذا تحتفظ وحدات pod قيد التشغيل ببيانات الاعتماد التي بدأت بها. أعد تشغيل كل مكوّن بعد التدوير:

kubectl rollout restart deployment,statefulset -n "${CONNECTOR_NAMESPACE}" \
  -l app.kubernetes.io/part-of=clicklink-connector

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

printf '%s\n' "$ENROLLMENT_TOKEN" "$CH_ADMIN_PASSWORD" | \
  clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force --ch-admin-password-stdin

مستخدمو ClickHouse

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

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
clicklink clctl scraper access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force
clicklink clctl troubleshoot access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force

على جهاز افتراضي، نفِّذها على المضيف مع تمرير كلمة مرور المستخدم الإداري عبر pipe؛ وهناك تكون كلمة المرور إلزامية إلا إذا مرّرت --ch-user-via cr:

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

بالنسبة إلى المثيلات التي يديرها المشغّل، أضف --ch-user-via cr وخيارات اختيار الـpod إلى أيٍّ من الصيغتين؛ راجع مرجع CLI.

شهادة العميل

يُجدَّد تلقائيًا (راجع الشهادات). لاستبدال شهادة سارية فورًا، أعد تشغيل init باستخدام الخيار --force. ثم أعد تشغيل كل مكوّن حتى تقدّم البرامج الخفية الشهادة الطرفية الجديدة: على Kubernetes كما هو موضّح في قسم بيانات اعتماد واجهة برمجة التطبيقات، وعلى الجهاز الافتراضي الوحدات الثلاث.

إعادة التشغيل والاسترداد

تتقارب عمليات إعادة تشغيل init، لذا تكون إعادة تنفيذ الأمر نفسه دائمًا هي الخطوة الأولى. من دون --force، يُحتفَظ بملف /etc/clicklink/config.yaml الموجود (VM) أو تراكب clicklink-values.yaml (Kubernetes)، ويُعاد استخدام مفتاح العميل الموجود؛ ويستبدل init بيانات الاعتماد وسلسلة CA بصورة ذرية. ويمكن تكرار أوامر الاسترداد التي تطبعها واجهة سطر الأوامر بعد فشل جزئي بأمان. يستبدل --force الإعداد أو التراكب المحتفَظ به، ويُعيد إنشاء مفتاح العميل، ويحل محل شهادة العميل غير منتهية الصلاحية. ولا ينشئ مطلقًا معرّف UUID جديدًا للعنقود، لذا تُحفظ هوية الموصل. ويُحتفظ بوضع مُدار الخاص بالتهيئة المستبدلة في عمليات إعادة التشغيل غير المراقَبة، ويُعرض بوصفه الخيار الافتراضي على الطرفية، ما لم تمرّر --managed أو --no-managed. إذا فشل توقيع الشهادة بعد التدريج، أو أعادت نقطة نهاية التوقيع الرمز 409 لأن شهادة غير منتهية الصلاحية موجودة بالفعل، فلن تحتاج إلى رمز تسجيل جديد أو إصدار ثانٍ. أكمل التثبيت باستخدام المواد الموقَّعة الموجودة بالفعل على القرص:

sudo clicklink clctl init --signed-cert client.crt --chain ca-chain.crt

هذا هو الشكل الخاص بالآلة الافتراضية (يعيد المستخدم الجذر كتابة /etc/clicklink ويدير الخدمات). في Kubernetes، تطبع واجهة سطر الأوامر الصيغة الكاملة، بما في ذلك --target helm و--target-namespace و--values؛ استخدم الأمر المطبوع كما هو. الموصل غير متصل. أثناء تعطل الموصل أو تعذّر الوصول إليه، تستمر الخدمات التي يديرها في العمل. إذ يبقيها ClickHouse Operator في العنقود الخاص بك قيد التشغيل، كما أن المنفّذ ليس ضمن مسار البيانات. تحتاج تغييرات دورة الحياة إلى اتصال المنفّذ، لذا لا يُطبَّق أي منها حتى يعيد الاتصال. وعند إعادة التشغيل، يستعيد المنفّذ الأوامر قيد الإرسال من قاعدة بيانات الأوامر الخاصة به. ويُجاب عن أي أمر تعيد ClickHouse Cloud تسليمه من النتيجة المسجَّلة؛ ولا يُعاد تنفيذ سوى الأمر الفاشل. لمعرفة ما يحدث لأوامر دورة الحياة في حال عدم اتصال أي منفّذ، راجع عندما يكون الموصل غير متصل.

إلغاء التثبيت

احذف كل خدمة مُدارة قبل إلغاء التثبيت، وفقًا لـحذف خدمة، وانتظر اكتمال كل عملية إزالة. فإزالة الـ connector أولاً تترك الخدمات بلا أي مكوّن قادر على إدارة دورة حياتها.

Linux VM

يتوفر uninstall.sh ضمن أرشيف tar الخاص بالإصدار. إذا لم يتبقَّ على المضيف أي أرشيف tar مستخرج، فاجلب أرشيفًا واستخرجه (انظر التنزيل والتحقق اليدويين). شغّل uninstall.sh من الدليل المستخرج:

sudo ./uninstall.sh

يؤدي ذلك إلى إيقاف وتعطيل وحدات clicklink-scraper وclicklink-troubleshooter وclicklink-executor وإزالة وحدات systemd والملف التنفيذي. ويُبقي على ما يلي، بحيث تستخدم إعادة التثبيت لاحقًا التهيئة الحالية:

/etc/clicklink، بما في ذلك حزم وصول المنفّذ ضمن /etc/clicklink/access/executor
/var/lib/clicklink، بما في ذلك قاعدة بيانات أوامر المنفّذ executor.db وسجل الخدمات
/var/log/clicklink
مستخدم clicklink

ولإزالة هذه أيضًا:

sudo ./uninstall.sh --purge

يوجد الامتياز الممنوح للمنفّذ على مستوى العنقود داخل عنقودك، وليس على المضيف. أزِله بصفتك مسؤول العنقود بعد ألّا تبقى أي خدمات مُدارة:

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n clicklink-system

أنشأت الأذونات أيضًا مساحة الأسماء clicklink-system؛ احذفها عندما لا يستخدمها أي شيء آخر.

Kubernetes

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm uninstall clicklink-connector -n "${CONNECTOR_NAMESPACE}"

يحمل PersistentVolumeClaim الخاص بالـ المنفّذ التعليق التوضيحي helm.sh/resource-policy: keep، لذا يُبقيه إلغاء التثبيت قائمًا ومعه قاعدة بيانات الأوامر وسجل الخدمات. كذلك فإن الـ Secrets التي أنشأها init، وSecret حزمة المنصة الذي كتبه platform approve، وConfigMap سجل الخدمات الذي يتولاه الـ المنفّذ ليست مملوكة للمخطط، وتبقى هي الأخرى بعد إلغاء التثبيت. احذفها صراحةً. وضمّن زوج Secret الوصول وServiceAccount لكل instance سجّلته بنفسك، ولكل خدمة مُدارة جهّزت لها مستكشف الأخطاء ومصلحها (ويحمل اسم الخدمة). ويغطي --ignore-not-found الكائنات التي لم تُنشأ أصلًا، مثل Secret حزمة المنصة قبل أول موافقة:

kubectl delete pvc -n "${CONNECTOR_NAMESPACE}" -l app.kubernetes.io/instance=clicklink-connector --ignore-not-found
kubectl delete secret clicklink-hmac clicklink-mtls clicklink-platform-bundle -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete configmap clicklink-instance-registry -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete secret -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  clicklink-connector-scraper-access-<instance> \
  clicklink-connector-troubleshooter-access-<instance>
kubectl delete serviceaccount -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  pcm-scraper-<instance> pcm-troubleshooter-<instance>
# Repeat for every ClickHouse namespace that holds an instance you registered yourself;
# a managed service's namespace went away with the service.
for ns in <clickhouse-namespace-1> <clickhouse-namespace-2>; do
  kubectl delete serviceaccount,role,rolebinding -n "${ns}" --ignore-not-found \
    pcm-scraper pcm-troubleshooter
done

طبّق init أذونات المنفّذ على مستوى العنقود بأكمله، وليس المخطط. أزِلها بصفتك مسؤول العنقود بعد ألّا تبقى أي خدمات مُدارة:

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n "${CONNECTOR_NAMESPACE}"

طبقة المنصة

لا يؤدي إلغاء تثبيت الـ موصل إلى إزالة طبقة المنصة. فمساحات أسماء المنصة وأعباء العمل، و RBAC الخاص بـ pcm-platform، وكائنات الـ admission التي ثبّتتها موافقاتك تبقى جميعها في العنقود، وكذلك كل خدمة مُدارة. احذف الخدمات أولًا؛ انظر حذف خدمة. في عنقود اختباري خالٍ من الخدمات، يزيل الأمر clicklink clctl platform reset إصدارات المنصة. أما ما يتركه من CustomResourceDefinitions و RBAC و StorageClass فيلزم حذفه يدويًا؛ انظر إعادة تعيين عنقود اختباري. أما خارج العناقيد الاختبارية، فاتفق على خطة إزالة مع فريق حسابك قبل المساس بطبقة المنصة.

مستخدمو ClickHouse

لا تؤدي إزالة التثبيت من أيٍّ من الهدفين إلى حذف مستخدمي القراءة فقط الذين تم توفيرهم على المثيلات التي سجّلتها بنفسك. احذفهم بصفتك Admin على كل مثيل (وأضف --ch-user-suffix إلى الأسماء إذا كنت قد عيّنت لاحقةً):

DROP USER IF EXISTS pcm_scraper, pcm_troubleshooter;

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

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

Bring Your Own Cloud

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

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

إدارة الوصول

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

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

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

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

الفوترة

الدعم

ClickHouse Private

الترقيات

Kubernetes

Linux VM

الحالة الصحية

الشهادات

تدوير بيانات الاعتماد

بيانات اعتماد واجهة برمجة التطبيقات (HMAC)

مستخدمو ClickHouse

شهادة العميل

إعادة التشغيل والاسترداد

إلغاء التثبيت

Linux VM

Kubernetes

طبقة المنصة

مستخدمو ClickHouse

​الترقيات

​Kubernetes

​Linux VM

​الحالة الصحية

​الشهادات

​تدوير بيانات الاعتماد

​بيانات اعتماد واجهة برمجة التطبيقات (HMAC)

​مستخدمو ClickHouse

​شهادة العميل

​إعادة التشغيل والاسترداد

​إلغاء التثبيت

​Linux VM

​Kubernetes

​طبقة المنصة

​مستخدمو ClickHouse

الترقيات

Kubernetes

Linux VM

الحالة الصحية

الشهادات

تدوير بيانات الاعتماد

بيانات اعتماد واجهة برمجة التطبيقات (HMAC)

مستخدمو ClickHouse

شهادة العميل

إعادة التشغيل والاسترداد

إلغاء التثبيت

Linux VM

Kubernetes

طبقة المنصة

مستخدمو ClickHouse