ما المقصود بتحديث المنصة
تتكوّن طبقة المنصة من ثلاثة مكوّنات: وحدة تحكم اللقطات، وClickHouse Operator، وجامعات المراقبة. وتُثبَّت بهذا الترتيب لأن كل مكوّن يعتمد على تعريفات الموارد المخصّصة الخاصة بالمكوّن الذي يسبقه. وتستخدم الخدمات StorageClass باسمgp3-encrypted (وحدات تخزين gp3 مشفّرة) يأتي معها.
حزمة المنصة هي البيان (manifest) الذي تُولّده ClickHouse Cloud لبيئتك. وهي تثبّت إصدارات المخطط (chart) والصورة لتلك المكوّنات وتحدّد اسم السجل (registry) الذي تُسحَب منه. وتُعرَّف كل حزمة بقيمة sha256 لذلك البيان. ترسلها ClickHouse Cloud إلى المُنفِّذ عبر قناة الأوامر، فيُجهّزها المُنفِّذ بانتظار موافقتك.
تُطبَّق الحزمة على نصفين:
- نصف الأذونات هو كل ما يمنح الوصول أو يحدّد شكله: مساحات الأسماء وCustomResourceDefinitions وServiceAccounts وClusterRoles وClusterRoleBindings وRoles وRoleBindings وتهيئات webhook وadmission وPriorityClasses وStorageClass. وأنت وحدك من يطبّقه، باستخدام بيانات اعتمادك، عبر تنفيذ
clicklink clctl platform approve. - نصف عبء العمل هو ما يعمل فعليًا: Deployments وServices وConfigMaps وSecrets وJobs وPodDisruptionBudgets. ويطبّقه المُنفِّذ بهوية مخصّصة باسم
pcm-platformلا تستطيع الكتابة إلا إلى هذه الأنواع، وذلك فقط ما دام الرمز قصير الأجل الذي أنشأته موافقتك صالحًا.
الموافقة على تحديث المنصة
بيانات اعتماد السجل
تعتمد مصادقة السجل على وضع توزيع الصور المسجَّل لبيئتك:- الوصول المباشر إلى سجل ClickHouse. نفّذ الموافقة على جهاز EC2 الافتراضي الخاص بالموصل. يتولى كل من
approveومزامنة المنصة التي يجريها المنفّذ دور ساحب ECR للقراءة فقط الخاص ببيئتك باستخدام بيانات اعتماد من خدمة البيانات الوصفية لمثيل EC2. ويسجّل هذا الدور الدخول إلى سجل المخططات، كما يستخدمه المنفّذ للتحقق من وجود صور المنصة. ولا تُغني ملفات تعريف AWS أو بيانات اعتماد البيئة أو بيانات اعتماد SSO على محطة العمل عن ملف تعريف المثيل. ويبقى ملف kubeconfig هو مصدر بيانات اعتماد مسؤول العنقود المنفصلة التي تطبّق نصف الأذونات. - المخططات في سجل ECR آخر، بما في ذلك مرآتك الخاصة. يستخدم تسجيل الدخول إلى المخطط بيانات اعتماد AWS المتاحة من البيئة للعملية التي تشغّل
approveأو المنفّذ، ويجب أن تمتلك تلك البيانات صلاحية القراءة من ذلك السجل.
1
ابحث عن الحزمة المرحلية
ترسل ClickHouse Cloud كل bundle مقترحة إلى executor أولًا. يجهّزها executor باعتبارها الـ bundle الـ pending ويبلّغ عن قيمة sha256 الخاصة بها في نبضة الاتصال. وتوجد bundle مجهّزة واحدة في كل مرة، إذ يحل أي اقتراح أحدث محلها. ثم يرفض executor عملية المزامنة ويسجّل أمرًا failed تنتهي نتيجته بالأمر الواجب تنفيذه.ينتهي الحقل
result بـ run: clctl platform approve (pending bundle sha <sha256>). أما على Kubernetes فيكون الاستدلال run: clctl platform approve --secret-namespace <connector-namespace> (pending bundle sha <sha256>). وأي عملية إنشاء تصادف تعريف custom resource مفقودًا تتضمّن السطر clctl platform approve نفسه. ويظهر ضمن أمرها الفاشل وضمن الخطأ الذي يطبعه clicklink clctl instances create --wait. كما يُعلمك فريق حسابك عند اقتراح أي تحديث للمنصة.اقرأ الحزمة المُجهَّزة قبل الموافقة عليها، فهي تحتوي على المانيفست وقيمة sha256 الخاصة به.- جهاز افتراضي يعمل بنظام Linux
- Kubernetes
يجهّز المنفّذ الحزمة كملف بجوار حزم الوصول الخاصة به على مضيف الموصّل:
2
تنفيذ الموافقة
approve بدون أي flags يقرأ الحزمة المجهّزة ويحسب قيم hash لها، فتوافق تمامًا على ما استلمه الـ executor. وهو يُصيّر كل مخطط تمامًا كما سيُصيّره الـ executor، ويطبّق شطر الـ permission باستخدام الـ kube context الذي تختاره. كما يُنشئ identity الـ pcm-platform إذا لزم الأمر ويُصدر الـ token الخاص به. ولا يُرسل أي request إلى connector endpoint الخاص بك.يحتاج approve إلى kube context يمتلك صلاحيات cluster-admin على العنقود المُدار (--context <name> إذا كان kubeconfig يحتوي على عدة سياقات) وإلى بيانات اعتماد السجل الخاصة بوضع توزيع الصور في بيئتك. أما --dry-run فيُصيّر شطر الـ permission ويسرده دون تطبيق أو إصدار أي شيء؛ ومع ذلك فهو يحتاج إلى الوصول إلى السجل لتصيير المخططات.- جهاز افتراضي يعمل بنظام Linux
- Kubernetes
نفّذ الأمر على host الـ connector، بصفة root، حيث جهّز الـ executor الحزمة:يكتب
approve الـ token في /etc/clicklink/access/executor/_platform، بجانب باقي credentials الـ executor. وهو يبني الحزمة الجديدة إلى جانب الحزمة الحالية ولا يستبدلها بها إلا بعد أن يصبح الـ token الخاص بها موجودًا، بحيث لا تمسّ عملية approve فاشلة أي token ما يزال صالحًا.3
تأكيد
ينتهي في Kubernetes يظهر سطر ثالث: تتحوّل حالة أحدث أمر
approve بما يلي:Bundle written to Secret <namespace>/<name>; the executor pod sees it once the kubelet refreshes the mount, within about a minute.يعيد ClickHouse Cloud إرسال المزامنة بمجرد أن تُظهر نبضة heartbeat التالية للـ executor الموافقة. وينتظر حتى 20 دقيقة لمزامنة قيد التنفيذ بالفعل، ويتخطى أي executor مضى على آخر نبضة له أكثر من 5 دقائق. وبعد 3 محاولات لحزمة واحدة يتوقف، فيعيد فريق حسابك تشغيلها. ويطبّق الـ executor الجزء الخاص بعبء العمل ويُبلّغ عن المنصة بحالة synced. تابِع اكتمال المزامنة عبر:sync_platform إلى completed. كما يُبلِّغ الـ executor عن حالة المنصّة وإصدارات المكوّنات إلى ClickHouse Cloud مع كل نبضة (heartbeat)، بحيث يرى فريق حسابك النتيجة نفسها.نافذة الموافقة
تُصدر الموافقة رمزًا لهويةpcm-platform، صالحًا لمدة ساعتين افتراضيًا (يمكن تغيير ذلك عبر --ttl). ولا يجدّده المنفّذ مطلقًا. وبمجرد انتهاء صلاحيته، لا يعود بإمكان المنفّذ الوصول إلى طبقة المنصة، ويرفض عملية مزامنة المنصة التالية مع إظهار رسالة الموافقة مجددًا. وهذا سلوك مقصود بالتصميم ولا يعتمد على الاتصال: فالموافقة الممنوحة أثناء عدم اتصال الموصّل تنتهي صلاحيتها وفق ساعتها الخاصة.
نفّذ approve مجددًا في الحالات التالية:
- انتهاء صلاحية الرمز قبل اكتمال المزامنة؛
- اقتراح ClickHouse Cloud حزمة مختلفة. فتجزئة sha256 التي وافقت عليها تُسجَّل على ServiceAccount المسمى
pcm-platform، ويرفض المنفّذ مزامنة أي حزمة أخرى إلى أن توافق عليها؛ - إبلاغ عملية إنشاء خدمة عن تعريف مورد مخصص مفقود.
ما الذي تمنحه الموافقة
أنت من يطبّق نصف الأذونات، ولذلك فهو يحمل صلاحيتك؛ ولا يطبّق المنفّذ أي شيء منه. ويختمapprove هذا النصف ببصمة sha256 الخاصة بالحزمة، ويتحقق المنفّذ، قبل المساس بأي شيء، من أن كل كائن أذونات في الحزمة المُرسلة إليه موجود وموافق عليه.
أما نصف عبء العمل فيطبّقه المنفّذ بهوية pcm-platform. وتستطيع هذه الهوية إنشاء وتحديث Secrets وConfigMaps وServices وDeployments وJobs وPodDisruptionBudgets، داخل مساحات الأسماء المنصّة فقط، وهو ما تفرضه سياسة قبول. كما تستطيع قراءة الكائنات التي تحتاجها لفحصها التمهيدي (البودات والأحداث ومساحات الأسماء وServiceAccounts وأنواع الأذونات المذكورة أعلاه). ولا تستطيع:
- الكتابة إلى أي نوع على نطاق العنقود أو أي كائن RBAC؛
- تنفيذ
escalateأوbindأوimpersonate؛ - إصدار أو تجديد الرمز الخاص بها.
pcm-executor، فهي منفصلة ومحصورة في مساحات الأسماء الخدمات. ولا تستطيع الكتابة إلى مساحات الأسماء المنصّة، غير أن عمليات القراءة الخاصة بها ليست محصورة بحارس البادئة. وللاطلاع على القائمة الكاملة لكلتا الهويتين، راجع نموذج الامتيازات.
إعادة تعيين عنقود اختباري
الأمرclicklink clctl platform reset مخصّص للعناقيد الاختبارية: فهو يزيل تثبيت مكوّنات المنصة بحيث يمكن إجراء تثبيتها الأول من جديد. وقبل إجراء أي تغيير، يسرد عناقيد ClickHouse في مساحات الأسماء التي يملكها هذا الموصل، ويرفض المتابعة إذا كان هناك أي خدمة.
وفي حال كان العنقود فارغًا، يزيل تثبيت إصدارات المنصة بترتيب عكسي لتبعياتها، ثم يحذف حزمة رموز المنصة الخاصة بالـ executor: الدليل المحلي على جهاز افتراضي، أو الـ Secret المحدّد عبر --secret-namespace <connector-namespace> على Kubernetes. أما CustomResourceDefinitions وRBAC وStorageClass فتبقى كما هي. نفّذ approve مرة أخرى قبل مزامنة المنصة التالية.
reset بيان المنصة المُصيَّر كملف (--bundle)، ولا يقرأ الحزمة المُجهَّزة. أما --dry-run فيتحقق من الخدمات ويطبع الخطة دون إجراء أي تغيير على العنقود.