ما الذي يقوم به الموصّل
ClickHouse Connector هو مكوّن تنشره في بيئتك الخاصة. وهو يتيح لـ ClickHouse Cloud إدارة خدمات ClickHouse ومراقبتها ودعمها ضمن عنقود Kubernetes تقوم بتشغيله. وينشئ الموصّل اتصالات صادرة فقط، ويعمل بهويات نطاقها محصور بتلك الخدمات. ويأتي في ملف تنفيذي واحد،clicklink، يحتوي على الخدمات الخفية وأداة clicklink clctl التي تثبّتها وتشغّلها.
يتألف الموصّل من ثلاثة مكوّنات:
- المنفّذ (executor) يدير دورة حياة الخدمات التي تطلب من ClickHouse إدارتها. فهو ينشئ كل خدمة انطلاقًا من تعريف تقدّمه، ثم يطبّق أوامر التوسيع والإيقاف والتشغيل وإعادة التشغيل والنسخ الاحتياطي والحذف الواردة من ClickHouse Cloud. ويُسمّى تشغيل المنفّذ بالوضع المُدار.
- المُجمِّع (مُجمِّع) يجمع المقاييس من قائمة سماح تضم جداول نظام ClickHouse، إضافة إلى البيانات الوصفية للبنية التحتية وحالة السلامة، ويرسلها إلى ClickHouse Cloud.
- مستكشف الأخطاء ومصلحها (troubleshooter) يتيح لمهندسي دعم ClickHouse إجراء تشخيصات للقراءة فقط أثناء جلسة دعم تفعّلها أنت ويمكنك إنهاؤها في أي وقت.
init عمّا إذا كنت تريد تفعيل الوضع المُدار ويكون الجواب الافتراضي “نعم”؛ أما البرامج النصية فيجب أن تمرّر --managed. ومن دون الوضع المُدار يظل الموصّل يراقب ويدعم العناقيد التي تشغّلها بنفسك؛ راجع التشغيل من دون الوضع المُدار.
كل اتصال ينشئه الموصّل هو اتصال صادر؛ ولا يبادر ClickHouse Cloud أبدًا بفتح اتصال نحو بيئتك. وتسرد صفحة المعمارية كل اتصال وبروتوكوله وطريقة استيثاقه.
متى تستخدمه
انشر الـ موصّل عندما ترغب في أن تتولى ClickHouse Cloud تشغيل خدمات ClickHouse داخل حساب السحابة الخاص بك وفق القيود التالية:- جميع مسارات الوصول تنشأ داخل حدودك؛ ولا توجد أي اتصالات واردة.
- تقتصر عمليات الكتابة إلى العنقود الخاص بك على مساحات أسماء الخدمات التي تديرها ClickHouse، إضافةً إلى الرمز الخاص بالمنفّذ وسجله وشهادته المجددة في مساحة الأسماء الرئيسية الخاصة به. أما مكونات المنصة التي تعتمد عليها تلك الخدمات فلا تتغير إلا بعد موافقتك على كل تحديث.
- تبقى بياناتك داخل حاويات وخلف أدوار IAM تنشئها وتزيلها بنفسك، ولا يحتفظ المنفّذ بأي بيانات اعتماد لحاوياتك أو لأدوار IAM الخاصة بك.
- وصول الدعم محدد بمدة زمنية، أنت من يفعّله، ويمكن إبطاله في أي لحظة. ويُسجَّل كل أمر يُنفَّذ خلال جلسة الدعم في سجل تدقيق تملكه أنت.
كيف يعمل
أثناء عملية الإعداد الأولي، تُسجّل ClickHouse بيئتك وتزوّدك بنقطة نهاية الموصّل الخاصة بك وبرمز تسجيل يُستخدم لمرة واحدة. شغّلclicklink clctl init --enroll مرة واحدة: من محطة عمل لديها وصول عبر kubeconfig في حالة التثبيت على Kubernetes، أو على المضيف في حالة التثبيت على جهاز افتراضي يعمل بنظام Linux. يقوم هذا الأمر باستهلاك الرمز، والحصول على شهادة عميل mTLS، ونشر الخدمات الخفية وتشغيلها، والتحقق من سلامتها.
يؤدي تفعيل الوضع المُدار إلى نشر المنفّذ وتطبيق منح الوصول الخاص به إلى Kubernetes. ومنح الوصول هذا عبارة عن ServiceAccount باسم pcm-executor. وتَحصُر سياسةُ قبولٍ عملياتِ الكتابة الخاصة به ضمن مساحات أسماء الخدمات (بالبادئة ns- افتراضياً). والاستثناءات هي تجديد رمزه الخاص، وConfigMap واحد للسجل، وكذلك — على Kubernetes — شهادة العميل المُجدَّدة في مساحة الأسماء الرئيسية الخاصة به.
يتطلب إنشاء خدمة أمرين. ينشئ clicklink clctl executor prepare حاويات الخدمة ودور IAM الخاص بها باستخدام بيانات اعتماد AWS الخاصة بك، ويعرض كلمة مرور المستخدم default مرة واحدة. ويرسل clicklink clctl instances create تعريف الخدمة إلى ClickHouse Cloud عبر نقطة نهاية الموصّل الخاصة بك. بعد ذلك، تتولى ClickHouse Cloud إدارة الخدمة عبر قناة الأوامر الصادرة للمنفّذ: التوسيع، والإيقاف والتشغيل، وإعادة التشغيل، والنسخ الاحتياطي، وترقيات الإصدارات، وتغييرات التهيئة. راجع الخدمات المُدارة للاطلاع على الشرح.
ويبقى إجراءان من مسؤوليتك. فتحديثات مكوّنات المنصة في عنقودك تنتظر موافقتك؛ راجع تحديثات المنصة. أما حذف خدمة ما فيزيل موارد Kubernetes الخاصة بها فقط؛ في حين تبقى حاوياتها ودور IAM إلى أن تُشغّل clicklink clctl executor teardown.
يقرأ المُجمِّع جداول النظام المُدرجة في قائمة السماح على فاصل زمني ثابت، ويرسل المقاييس والبيانات الوصفية وحالة السلامة إلى نقطة نهاية الموصّل الخاصة بك عبر mTLS. ويُبقي مستكشف الأخطاء ومصلحها قناة أوامر صادرة مفتوحة لا تنقل أي شيء إلى أن تُفعّل جلسة دعم. وتُجدِّد شهادة mTLS نفسها تلقائياً.
التشغيل بدون الوضع المُدار
مرّر--no-managed إلى clicklink clctl init، أو أجب بالنفي عند سؤالك، لتثبيت مُجمِّع ومستكشف الأخطاء ومصلحها فقط. عندها يقوم الـ موصّل بمراقبة ودعم عناقيد ClickHouse التي تشغّلها بنفسك؛ ولا يستطيع ClickHouse إنشاء الخدمات أو تغييرها أو حذفها. ومع ذلك يظل الـ موصّل ينشر نفسه ويجهّز مستخدمي ClickHouse للقراءة فقط وحسابات ServiceAccount؛ راجع نموذج الامتيازات. وهذه أيضًا هي الصيغة المناسبة للأهداف التي لا يغطيها الوضع المُدار. فالوضع المُدار يعمل على Amazon EKS مع تخزين S3، أما إمكانية المراقبة والدعم فيعملان على أي عنقود Kubernetes متوافق أو مضيف Linux.
المتطلبات في لمحة
- هدف للنشر. يحتاج الوضع المُدار إلى عنقود Amazon EKS مع تخزين S3. أما إمكانية المراقبة والدعم وحدهما فيعملان على أي عنقود Kubernetes متوافق (يُثبَّت عبر Helm chart) أو أي مضيف Linux يعتمد systemd، بمعمارية amd64 أو arm64.
- التسجيل من قِبل ClickHouse. تسجّل ClickHouse بيئتك للوضع المُدار وتزوّدك، أثناء الإعداد الأولي، بنقطة نهاية الموصّل الخاصة بك وبرمز تسجيل يُستخدم لمرة واحدة.
- وصول شبكي outbound عبر المنفذ 443 إلى نقطة نهاية الموصّل الخاصة بك وإلى نقطة نهاية enrollment التابعة له، إضافة إلى
releases.clicklink.clickhouse.comوECR Public وقت التثبيت. وتتوفر بدائل air-gapped ومرآة لكل خطوة؛ راجع الإعداد الأولي. في الوضع المُدار، تسحب عُقد العنقود لديك أيضًا صور ClickHouse من السجل المسجَّل بيئتك معه. ويتصل المنفّذ بـ Amazon ECR وSTS عند سحبه chart منصة من ECR. - صلاحيات Admin على العنقود أثناء الإعداد. يطبّق تفعيل الوضع المُدار منح الوصول الخاص بالمنفّذ مرة واحدة: ServiceAccount، وClusterRole المرتبط به، وسياسة قبول التي تحصر عمليات الكتابة الخاصة به في مساحات أسماء الخدمات. كما تجري الموافقة على تحديث المنصة بصلاحيات Admin على العنقود. وعلى كلا هدفَي التثبيت، تُربط access bundles الخاصة بمستكشف الأخطاء ومصلحها بـ ServiceAccounts في Kubernetes. راجع الإعداد الأولي.
- بيانات اعتماد AWS لعمليتَي
prepareوteardown، ووصول إلى السجل لعمليةplatform approve. يجري إنشاء حاويات التخزين ودور IAM الخاصة بالخدمة باستخدام بيانات اعتماد الخاصة بك، وكذلك إزالتها بعد حذف الخدمة. وتُنفَّذ العمليتان على workstation لديك أو على مضيف الموصّل. وللوصول المباشر إلى سجل ClickHouse، تتولى الموافقة على المنصة والمزامنة دور السحب للقراءة فقط عبر ملف تعريف نسخة EC2 VM الخاصة بالموصّل. ولا تحل ملفات تعريف AWS على workstation أو بيانات اعتماد الخاصة بـ SSO محل تلك الهوية. أما سجلات charts الأخرى على ECR فتستخدم بيانات اعتماد AWS المحيطة. راجع بيانات اعتماد السجل. ولا يحتفظ المنفّذ مطلقًا بـ بيانات اعتماد تتيح الوصول إلى حاويات التخزين أو IAM الخاصة بك. فاتصالاته السحابية الوحيدة تتجه إلى Amazon ECR وSTS لسحب الـ charts وفحص صور المنصة. - مستمع ClickHouse أصلي قابل للوصول للعناقيد التي تديرها بنفسك، ويُراقَب عبر تثبيت منفصل للموصّل يعمل دون المنفّذ. يتواصل الـ مُجمِّع ومستكشف الأخطاء ومصلحها مع كل عنقود عبر البروتوكول الأصلي؛ وعلى Kubernetes يكتشفان تلقائيًا الاتصال الآمن (9440) أو plaintext (9000).
- وصول ClickHouse admin أثناء الإعداد للعناقيد التي تديرها بنفسك. ينشئ التجهيز الأولي مستخدمي الموصّل للقراءة فقط. أما كلمة مرور Admin، في حال ضُبطت، فيُطلب إدخالها مرة واحدة ولا تُخزَّن أبدًا.
الخطوات التالية
- الإعداد الأولي: ثبّت الموصل وسجّله في Kubernetes أو على جهاز افتراضي يعمل بنظام Linux.
- الخدمات المُدارة: تمكين الوضع المُدار، وإنشاء خدمة، ومتابعة دورة حياتها وحالتها وحذفها.
- تحديثات المنصة: الموافقة على التغييرات التي تطرأ على مكونات المنصة في عنقودك.
- المعمارية: المكونات، وجميع الاتصالات، ودورة حياة الشهادات، والبيانات التي تغادر بيئتك.
- جلسات الدعم: كيفية تمكين وصول الدعم وتحديد نطاقه وتدقيقه وإلغائه.
- التهيئة والعمليات: الضبط الدقيق والترقيات ومهام اليوم الثاني.
- الأسئلة الشائعة: أسئلة شائعة، بما في ذلك مَن يمكنه تغيير خدماتك، وخروج البيانات، وإلغاء الصلاحيات.