معمارية

​

المكوّنات

يُشغّل ClickHouse Connector ثلاث خدمات خفية، جميعها مدمجة في الملف التنفيذي clicklink:

• المنفّذ: يحتفظ بقناة أوامر صادرة إلى نقطة نهاية الموصّل لديك، ويطبّق أوامر دورة الحياة التي يرسلها ClickHouse Cloud للخدمات التي يديرها في العنقود الخاص بك. وهذه الأوامر هي: الإنشاء، والتوسيع، والإيقاف والتشغيل، وإعادة التشغيل، والنسخ الاحتياطي وحذفه، والحذف، وتحديثات المنصة التي وافقت عليها. وكل إجراء هو استدعاء لواجهة برمجة تطبيقات Kubernetes، فهو لا يفتح أي اتصال بـ ClickHouse ولا يحتفظ بأي بيانات اعتماد لحاوياتك أو لـ IAM. ويعمل في الوضع المُدار فقط.
• الساحب: يقرأ قائمة سماح من جداول نظام ClickHouse على فاصل زمني ثابت ويخزّن النتائج مؤقتًا محليًا، ثم يرسلها إلى نقطة نهاية الموصّل لديك مع البيانات الوصفية للبنية التحتية وحالة الصحة.
• مستكشف الأخطاء ومصلحها: يحتفظ بقناة أوامر صادرة إلى نقطة نهاية الموصّل لديك، ويُجري تشخيصات للقراءة فقط أثناء جلسة دعم نشطة، أما خارج الجلسة فلا يُشغّل أي شيء.

على Kubernetes، ينشر مخطط Helm المسمّى clicklink-connector الخدمات الخفية في مساحة أسماء تختارها (الافتراضية clicklink). والمنفّذ هو Deployment بنسخة واحدة يحتفظ بحالة أوامره على وحدة تخزين دائمة. أما على جهاز افتراضي يعمل بنظام Linux، فتعمل الخدمات الخفية كوحدات systemd باسم clicklink-scraper وclicklink-troubleshooter وclicklink-executor ضمن مستخدم نظام غير مميّز الصلاحيات هو clicklink.

​

الاتصالات

كل اتصال ينشئه الموصّل هو اتصال صادر. وفيما يلي القائمة الكاملة: يحمل كل طلب لواجهة برمجة التطبيقات ترويسة Authorization تتضمن توقيع HMAC-SHA256 على الطريقة والمسار والطابع الزمني وتجزئة للمحتوى. ولا يمكن إعادة إرسال الطلبات أو تعديلها أثناء النقل، حتى داخل قناة TLS. أما في الاتجاه الوارد، فتعرض كل خدمة خفية منفذ حالة محليًا واحدًا: 8082 للساحب، و8084 لمستكشف الأخطاء ومصلحها، و8086 للمنفّذ. ويقدّم هذا المنفذ /livez و/readyz و/healthz ومقاييس Prometheus الخاصة بالخدمة الخفية عبر /metrics؛ ولا يوجد منفذ منفصل للمقاييس. أما واجهة برمجة تطبيقات الأوامر المحلية للمنفّذ فترتبط بواجهة الاسترجاع (loopback) فقط، ولا تعرضها أي خدمة. والمستمع الآخر الوحيد هو بوابة الجلسات الاختيارية؛ راجع جلسات الدعم. ولا تتصل ClickHouse Cloud بأي منها إطلاقًا.

​

دورة حياة الشهادة

يصادق الـ connector على نقطة النهاية الخاصة بك باستخدام شهادة عميل يحصل عليها ويتولى صيانتها بنفسه، وتقدّم الخدمات الخفية الثلاث جميعها الشهادة نفسها.

• التسجيل. يُنشئ clicklink clctl init مفتاحًا خاصًا وطلب توقيع شهادة (CSR) محليًا، ويحمل هذا الـ CSR معرّف مؤسستك كاسم شائع (common name) ومضيف نقطة النهاية الخاصة بك بوصفه الـ DNS SAN الوحيد. ولا يغادر المفتاح الخاص بيئتك مطلقًا.
• الإصدار الأول. يرسل init الـ CSR إلى نقطة نهاية توقيع التسجيل على /v1/pcm/cert/sign، بمصادقة عبر HMAC. وإذا كانت لدى مؤسستك شهادة سارية بالفعل، فإن نقطة النهاية ترفض الطلب برمز 409، وعندئذٍ تعرض الـ CLI كيفية إتمام العملية بالشهادة الحالية أو استبدالها باستخدام --force.
• التجديد التلقائي. تتحقق الخدمات الخفية الثلاث من مدة صلاحية الشهادة كل 12 ساعة، وبمجرد أن تتبقى 10 أيام تطلب شهادة مجددة صالحة لمدة 30 يومًا عبر /v1/pcm/cert/renew (mTLS إضافة إلى HMAC). في Kubernetes، تُكتب الشهادة المجددة مجددًا في الـ Secret المسمى clicklink-mtls عبر grant لـ RBAC مقيّد بالاسم المطابق تمامًا؛ أما على الجهاز الافتراضي فتكتبها كل خدمة خفية في /etc/clicklink/tls. ولا يتطلب التجديد أي إجراء من المشغّل.

يتحقق الـ connector من شهادة خادم نقطة النهاية الخاصة بك مقابل متجر الثقة الخاص بالنظام. وعند ضبط api.tls.ca_file (على الجهاز الافتراضي) أو api.tls.caFile (في Helm)، تُلحَق سلسلة الـ CA المأخوذة من حزمة التسجيل الخاصة بك بتلك الجذور.

​

تدفق البيانات

​

ما الذي يغادر بيئتك

• المقاييس من جداول النظام المدرجة في قائمة السماح. تتضمن المجموعة الافتراضية للساحب metric_log وasynchronous_metric_log وtables وwarnings وserver_settings. وقائمة السماح إعداد صريح؛ ولا يقرأ الساحب أي شيء خارجها.
• بيانات وصفية للبنية التحتية. جرد الخدمات والبنية التحتية والنسخ الاحتياطية المتزامن عبر واجهة برمجة التطبيقات. وبالنسبة إلى الخدمة المُدارة، يشمل ذلك حالتها وأعداد النسخ المتماثلة الحالية والمتوقعة وإصدار الخادم العامل وإصدار التهيئة.
• مقاييس الصحة والمقاييس الذاتية. حالة المكوّن والمقاييس التشغيلية الخاصة بالموصل. كما تُبلّغ نبضة المُنفِّذ عمّا إذا كانت قناة أوامره متصلة. وهي تحمل نتيجة آخر تحديث للمنصة، وإصدارات مكوّنات المنصة، وبصمة آخر حزمة طبّقها. وفي التثبيت على آلة افتراضية تضيف ما إذا كانت حزمة الوصول إلى Kubernetes الخاصة بها ok أو expiring أو expired أو غير موجودة.
• نتائج الأوامر. لكل أمر من أوامر دورة الحياة يُنفّذه المُنفِّذ: التقدّم أثناء تقاربه، ثم النجاح أو الفشل مع نص الخطأ عند الفشل.
• تعريفات الخدمات التي ترسلها. يرسل clicklink clctl instances create معرّف بيئتك، والسحابة والمنطقة، واسم الخدمة، وأسماء حاوياتها ومعرّف ARN لدور IAM، ومفتاح عدم التكرار. كما يرسل تجزئتين لكلمة مرور المستخدم default (SHA-256 وSHA-1 المزدوجة).
• مخرجات جلسة الدعم. نتائج عمليات التشخيص للقراءة فقط التي تُجرى خلال جلسة فعّلتها، بعد التنقيح.

​

ما لا يغادر أبداً افتراضياً

• نص الاستعلام الخام، في مسار السحب. يُستثنى system.query_log من مجموعة السحب الافتراضية لأن أعمدة الاستعلام فيه قد تحمل قيماً حرفية، ومعها معلومات تحديد الهوية الشخصية أو أسراراً. وإعادة إضافته تُعدّ تجاوزاً (override) خاصاً بكل عملية نشر. أما قائمة السماح الافتراضية لجداول الجلسة فتتضمن system.processes، الذي يعرض نص الاستعلامات الجارية؛ راجع جلسات الدعم لتقليصها.
• بيانات جداولك والنسخ الاحتياطية. تبقى في حاويات داخل حسابك. ولا يمتلك المُنفّذ أي بيانات اعتماد لحاوياتك ولا يمكنه قراءتها.
• بيانات الاعتماد. لا يكتب init أي بيانات اعتماد في ملفات التهيئة. ويخزّن ClickHouse تجزئات bcrypt لكلمات مرور مستخدمي الموصّل فقط، وتبقى الأسرار في Kubernetes Secrets أو في ملفات لا يقرأها إلا الجذر على المضيف. أما كلمة مرور المستخدم default للخدمة المُدارة فتُولَّد على جانبك وتُعرض مرة واحدة، ولا يُرسَل سوى تجزئاتها. ولا ينقل أي شيء في مسار السحب أو المزامنة أي بيانات اعتماد.
• مخرجات مستكشف الأخطاء ومصلحها غير المنقّحة. كل ما يعيده مستكشف الأخطاء ومصلحها يمر عبر أنماط الإخفاء (المدمجة بالإضافة إلى أنماطك الخاصة) قبل أن يغادر. راجع جلسات الدعم.

​

حدود الثقة

• بيئتك هي الحد الفاصل. لا تستقبل ClickHouse Cloud سوى ما يرسله الموصل: عمليات السحب، ونبضات الحياة والحالة، ونتائج الأوامر، وما تُعيده جلسة دعم نشطة. وهي لا تبدأ أي اتصال باتجاه الداخل إطلاقًا.
• بوابة الجلسة ملكك. لا يمكن الوصول إليها إلا من داخل بيئتك (عبر kubectl port-forward على Kubernetes، أو محليًا على جهاز افتراضي) ما لم تختر تعريضها عبر Ingress. ولا تتصل ClickHouse Cloud بها أبدًا.
• الوصول إلى ClickHouse للقراءة فقط. يملك المستخدمان pcm_scraper وpcm_troubleshooter أذونات SELECT لكل جدول على حدة، إضافة إلى إذن READ ON REMOTE الخاص بالساحب (اللازم لـ clusterAllReplicas())، وإذن SYSTEM FLUSH LOGS واحد مخصص للساحب وحده. ولا توجد أي أذونات INSERT أو DDL أو إدارة مستخدمين. أما الـ منفّذ فلا يملك مستخدمًا في ClickHouse. تجد القائمة الكاملة في نموذج الامتيازات.
• لا يستطيع الـ ساحب ولا الـ مستكشف الأخطاء ومصلحها تغيير عنقودك. تأتي صلاحياتهما في RBAC من Roles في مساحتي أسماء الموصل والخدمة. وتمنح تلك الـ Roles أفعالًا للقراءة فقط على موارد أحمال العمل، ووصولًا بالاسم المحدد إلى Secrets الخاصة بالموصل نفسه. ولا يوجد أي إذن exec أو delete أو patch.
• يغيّر الـ منفّذ حالة العنقود في مساحات أسماء الخدمات بهوية pcm-executor. فهو يُنشئ ويحذف مساحات الأسماء التي تحمل بادئة الخدمة (ns- افتراضيًا)، ويحذف الـ pods لإعادة تشغيلها. وداخل تلك المساحات يكتب كائنات ClickHouseCluster وBackup وScalingOverride، وكذلك Secrets وServiceAccounts وServices التي تحتاجها الخدمة. كما يكتب Role وRoleBinding اللذين يمنحان الـ ساحب صلاحية القراءة. وتمنع ValidatingAdmissionPolicy أي عملية كتابة من حساب الخدمة ذاك خارج نطاق البادئة. أما الاستثناءات، وجميعها في مساحة أسمائه الأصلية، فهي تجديد رمزه الخاص، وConfigMap المسمى clicklink-instance-registry، وعلى Kubernetes شهادة العميل المجددة في Secret الخاصة بـ mTLS. وتفشل السياسة إلى وضع الرفض عند تعذّر تقييمها. ولا تعمل مرحلة admission على عمليات القراءة، لذا فإن قراءاته لتلك العائلات من الموارد ليست محصورة بالبادئة.
• لا يغيّر الـ منفّذ مساحات أسماء المنصة إلا بهوية pcm-platform، وأثناء تحديث وافقت عليه. يُصدر الأمر clicklink clctl platform approve رمزًا لتلك الهوية صالحًا لمدة ساعتين، ولا يُجدَّد أبدًا. وبه يستطيع الـ منفّذ الكتابة إلى Deployments وServices وConfigMaps وSecrets وJobs وPodDisruptionBudgets فقط. أما مساحات الأسماء وCRDs وServiceAccounts وRBAC وتهيئات webhook وadmission وPriorityClasses وStorageClass فتُطبَّق ببيانات اعتمادك أنت أثناء الموافقة. راجع تحديثات المنصة.
• لا يحمل الـ منفّذ أي بيانات اعتماد لحاوياتك أو لـ IAM. يُنشئ الأمر clicklink clctl executor prepare حاويتي البيانات والنسخ الاحتياطي للخدمة ودور IAM الخاص بها. ويحذفها الأمر clicklink clctl executor teardown. وكلاهما يعمل ببيانات اعتمادك. ولا يثق الدور إلا في pods تلك الخدمة، لذا لا يستطيع الـ منفّذ ولا ClickHouse تقلّده. واستدعاءاته السحابية الوحيدة تتجه إلى Amazon ECR وSTS. فهو يسجّل الدخول إلى السجل عندما تسحب عملية مزامنة منصة أو إنشاء مخططًا. وأثناء تحديث المنصة يتحقق من الصور باستخدام دور السحب للقراءة فقط.
• سياسة الشبكة. على Kubernetes يُنشئ المخطط سياسة NetworkPolicy بالرفض الافتراضي لكل خدمة خفية. ولا يُسمح بحركة الـ egress إلا إلى DNS، ونطاقات CIDR التي تحددها لنقطة نهاية الموصل، ونطاقات CIDR الخاصة بخادم واجهة برمجة تطبيقات Kubernetes. كما تسمح سياستا الـ ساحب والـ مستكشف الأخطاء ومصلحها بخدمات ClickHouse في مساحات الأسماء التي يديرها الـ منفّذ (والمحددة بالعلامة التي يضعها عليها) أو التي تسردها أنت بالاسم. أما سياسة الـ منفّذ فلا تتضمن أي قاعدة خاصة بـ ClickHouse. وإذا كانت مخططات حزمة المنصة موجودة في Amazon ECR، فأضِف نطاقات ECR وSTS (أو مرآة السجل الخاصة بك) إلى allowEgressCIDRs. فبدونها لا تستطيع المزامنة سحب المخططات في ظل CNI يفرض السياسات. ومن دون CNI يفرض السياسات تبقى السياسة بلا أثر. راجع التهيئة.
• تحصين المضيف على الأجهزة الافتراضية. تعمل الوحدات بهوية مستخدم نظام غير قابل لتسجيل الدخول، مع ProtectSystem=strict وNoNewPrivileges ومسارات تهيئة للقراءة فقط ووضع FIPS مُمكَّنًا.

للاطلاع على الأذونات الدقيقة للموصل وقواعد RBAC الخاصة به، راجع مرجع نموذج الامتيازات. أما إذا كانت ClickHouse هي من يوفّر العنقود ويشغّله بنفسها، فإن نموذج الثقة يختلف؛ راجع صفحتَي معمارية BYOC وامتيازات BYOC.