> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# إعداد مخصص على GCP

> انشر ClickHouse BYOC ضمن شبكة VPC الحالية لديك على GCP

export const Image = ({img, alt, size = "lg", background}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} style={{
    backgroundColor
  }} />
      </Frame>
    </div>;
};

<h2 id="customer-managed-vpc-gcp">
  Customer-managed VPC (BYO-VPC) for GCP
</h2>

إذا كنت تفضّل استخدام شبكة VPC الحالية لنشر ClickHouse BYOC بدلًا من أن يقوم ClickHouse Cloud بتجهيز VPC جديدة، فاتبع الخطوات أدناه. يوفّر هذا النهج قدرًا أكبر من التحكم في تكوين الشبكة، ويتيح لك دمج ClickHouse BYOC ضمن البنية التحتية الحالية لشبكتك.

<Steps>
  <Step title="تكوين شبكة VPC الحالية" id="configure-existing-vpc">
    1. خصّص شبكة فرعية خاصة واحدة على الأقل في [منطقة تدعمها ClickHouse BYOC](/ar/products/cloud/reference/supported-regions) لعنقود ClickHouse Kubernetes (GKE). تأكد من أن الشبكة الفرعية تحتوي على نطاق CIDR لا يقل عن `/24` (على سبيل المثال: 10.0.0.0/24) لتوفير عدد كافٍ من عناوين IP لعُقد عنقود GKE.
    2. داخل الشبكة الفرعية الخاصة، خصّص نطاق IPv4 ثانويًا واحدًا على الأقل لاستخدامه لوحدات Pod في عنقود GKE. يجب أن يكون النطاق الثانوي `/21` على الأقل. لا توفّر النطاقات الأصغر عددًا كافيًا من عناوين IP لوحدات Pod كي يتمكّن عنقود GKE من إكمال عملية التجهيز، وسيفشل إعداد البنية التحتية.
    3. فعّل **Private Google Access** على الشبكة الفرعية. يتيح ذلك لعُقد GKE الوصول إلى واجهات برمجة تطبيقات Google وخدماتها من دون الحاجة إلى عناوين IP خارجية.

    <Note>
      لعرض الخدمات عبر [Private Service Connect](/ar/cloud/reference/byoc/onboarding/network-gcp#setup-psc)، تحتاج أيضًا إلى شبكة فرعية مخصصة بالغرض `PRIVATE_SERVICE_CONNECT` في شبكة VPC هذه. يمكنك إنشاؤها الآن أو لاحقًا، قبل تفعيل private link.
    </Note>

    <Image img="https://mintcdn.com/private-7c7dfe99-parallel-read-in-order-multi-part/xI74_SSNk8kNyW21/images/cloud/reference/byoc-gcp-subnet.webp?fit=max&auto=format&n=xI74_SSNk8kNyW21&q=85&s=1995be1a4ed21c9c69080e6c08af63bd" size="lg" alt="تفاصيل الشبكة الفرعية لـ BYOC على GCP، مع عرض نطاقات IPv4 الأساسية والثانوية وتفعيل Private Google Access" width="2337" height="1573" data-path="images/cloud/reference/byoc-gcp-subnet.webp" />
  </Step>

  <Step title="ضمان اتصال الشبكة" id="ensure-network-connectivity">
    **بوابة Cloud NAT**
    تأكد من نشر [بوابة Cloud NAT](https://cloud.google.com/nat/docs/overview) لـ VPC. فهي توفّر الاتصال الصادر للمثيلات التي لا تملك عناوين IP خارجية، ويعتمد عليها أمران:

    * **Tailscale.** تُسجَّل مكونات ClickHouse BYOC لدى مستوى التحكم الخاص بـ Tailscale، الذي يوفّر شبكة آمنة قائمة على مبدأ انعدام الثقة لعمليات الإدارة الخاصة من دون الحاجة إلى وصول عام وارد.
    * **صور الحاويات.** بعض الصور التي يشغّلها النشر غير منسوخة إلى سجل BYOC، بما في ذلك صور المجتمع، ويتم سحبها من سجلاتها الأصلية.

    لن تُكمل شبكة VPC التي لا تمتلك مسارًا صادرًا عملية التجهيز؛ إذ يتحقق التحقق المسبق من وجود بوابة Cloud NAT تغطي الشبكة. ولا توجد قائمة منشورة واحدة بنقاط النهاية؛ فإذا كانت سياسة شبكتك تتطلب جردًا صريحًا، فتواصل مع الدعم لمراجعة إعدادك.

    **DNS Resolution**
    تأكد من أن VPC لديك تتمتع بآلية DNS resolution تعمل بشكل صحيح، وأنها لا تحجب أسماء DNS القياسية ولا تتداخل معها أو تستبدلها. يعتمد ClickHouse BYOC على DNS لتحليل أسماء خوادم التحكم الخاصة بـ Tailscale ونقاط نهاية خدمة ClickHouse. إذا لم يكن DNS متاحًا أو كان تكوينه غير صحيح، فقد تتعذر خدمات BYOC عن الاتصال أو العمل بشكل صحيح.
  </Step>

  <Step title="إعداد البنية التحتية لـ BYOC" id="set-up-byoc-infrastructure">
    <Note>
      عند النقر على **Set up Infrastructure**، يُجري ClickHouse Cloud تلقائيًا [التحقق المسبق](/ar/products/bring-your-own-cloud/onboarding/standard#preflight-validation) قبل التجهيز. فهو يتحقق من أن حساب خدمة الإدارة لديه الأذونات المطلوبة وأن واجهات برمجة تطبيقات Google Cloud المطلوبة مفعّلة، كما يتحقق من صحة شبكة VPC التي تحضرها بنفسك: من إمكانية تحليل الشبكة والشبكة الفرعية، ومن أن النطاق الأساسي للشبكة الفرعية والنطاق الثانوي لوحدات Pod كبيران بما يكفي، ومن وجود بوابة Cloud NAT تغطي الشبكة. وإذا كان أي عنصر مفقودًا، فسيتوقف الإعداد مع بيان المشكلات المحددة التي يجب إصلاحها.
    </Note>

    في وحدة تحكم ClickHouse Cloud، قم بتكوين ما يلي عند إعداد بنية تحتية جديدة:

    1. ضمن **VPC configuration**، اختر **Use existing VPC**.
    2. أدخل **اسم شبكة VPC**.
    3. أدخل **اسم الشبكة الفرعية** التي خصصتها لـ ClickHouse.
    4. اختياريًا، أدخل **Secondary range names** لتحديد أي من النطاقات الثانوية للشبكة الفرعية يستخدمه GKE لوحدات Pod. اتركه فارغًا لاستخدامها جميعًا؛ ويجب أن يكون كل اسم تُدرجه موجودًا مسبقًا على الشبكة الفرعية.
    5. إذا كانت شبكة VPC لديك موجودة في مشروع مضيف لشبكة Shared VPC، فأدخل **Shared VPC host project ID**. اتركه فارغًا عندما تكون شبكة VPC في المشروع نفسه الذي توجد فيه البنية التحتية. راجع [شبكة Shared VPC من مشروع مضيف](#shared-vpc-host-project) أدناه.
    6. انقر على **Set up Infrastructure** لبدء التجهيز.

    <Image img="https://mintcdn.com/private-7c7dfe99-parallel-read-in-order-multi-part/hGxtP6M6yNwKdumK/images/cloud/reference/byoc-gcp-existing-vpc-ui.webp?fit=max&auto=format&n=hGxtP6M6yNwKdumK&q=85&s=d85067f5aec329bd0aa608db1f536991" size="lg" alt="واجهة إعداد ClickHouse Cloud BYOC مع تحديد Use existing VPC لـ GCP، مع عرض حقول اسم شبكة VPC واسم الشبكة الفرعية وأسماء النطاقات الثانوية ومعرّف المشروع المضيف لشبكة Shared VPC" width="1184" height="1720" data-path="images/cloud/reference/byoc-gcp-existing-vpc-ui.webp" />
  </Step>
</Steps>

<h3 id="shared-vpc-host-project">
  شبكة VPC المشتركة من مشروع مضيف
</h3>

يمكنك تشغيل BYOC في مشروع خدمة على شبكة موجودة في مشروع مضيف منفصل من نوع [Shared VPC](https://cloud.google.com/vpc/docs/shared-vpc)، ما يتيح لك إبقاء إدارة الشبكات مركزية. فشبكة VPC وشبكاتها الفرعية مملوكة للمشروع **المضيف**، بينما تعمل البنية التحتية لـ BYOC في مشروع **خدمة** مرفق به. وتبقى المتطلبات المذكورة أعلاه كما هي؛ غير أنها تنطبق على الشبكة الفرعية في المشروع المضيف.

هناك متطلبان مسبقان خاصان بهذا الإعداد:

* **فعّل المشروع المضيف كمضيف Shared VPC، وأرفق مشروع الخدمة به، قبل أن تبدأ.** كلتا الخطوتين مطلوبة، وهما خطوتان منفصلتان: المشروع الذي ليس مضيف Shared VPC أصلاً يجب تفعيله كمضيف أولاً، وعندئذ فقط يمكن إرفاق مشروع الخدمة. ويشترط عنقود GKE على Shared VPC وجود هذا الإرفاق. أما عملية التحقق المسبق فتقرأ شبكتك وشبكتك الفرعية عبر الأذونات الممنوحة على المشروع المضيف سواء أكان الإرفاق قائماً أم لا، لذا تنجح في الحالتين، ثم يفشل التجهيز لاحقاً عند إنشاء العنقود. وكلتا العمليتين على مستوى المنظمة وينفذهما من يتولى إدارة Shared VPC في منظمتك؛ ولا يمكن لـ Terraform الخاص بالـ onboarding القيام بهما نيابة عنك.
* **شغّل Terraform الخاص بالـ onboarding مع تحديد المشروع المضيف.** مرّر `shared_vpc_host_project_id` و`shared_vpc_host_subnet_region` و`shared_vpc_host_private_subnet_id` إلى [onboarding module](https://github.com/ClickHouse/terraform-byoc-onboarding/tree/main/modules/gcp). والقيمة `shared_vpc_host_private_subnet_id` هي الشبكة الفرعية المضيفة التي تعمل فيها عُقد GKE لديك — تلك التي هيّأتها أعلاه — وليست الشبكة الفرعية الخاصة بـ Private Service Connect الموضحة أدناه. فتوجيهها إلى شبكة PSC الفرعية يضع إذن `roles/compute.networkUser` على الشبكة الفرعية الخاطئة، فيفشل التجهيز عند إنشاء العنقود. ويكتب الاستدعاء الواحد في المشروعين معاً، لذا تحتاج الـ credentials التي تشغّله إلى صلاحيات Admin على IAM في مشروع الخدمة وفي المشروع المضيف.

الأذونات التي تضيفها الوحدة إلى مشروعك المضيف محدودة النطاق، لكنها ليست جميعها للقراءة فقط:

| الإذن على المشروع المضيف | ممنوح لـ | السبب |
| - | - | - |
| `compute.networks.get`، `compute.subnetworks.get`، `compute.subnetworks.use` | حساب خدمة إدارة ClickHouse | قراءة شبكتك وشبكتك الفرعية، والسماح لإرفاق Private Service Connect باستخدام شبكة PSC الفرعية لديك |
| `roles/compute.networkUser` على الشبكة الفرعية للعُقد | حساب خدمة إدارة ClickHouse، ووكيل خدمة GKE في مشروع الخدمة لديك، وحساب خدمة Google APIs في مشروع الخدمة لديك | الهويات الثلاث التي تستخدم الشبكة الفرعية |
| `roles/container.hostServiceAgentUser` | وكيل خدمة GKE في مشروع الخدمة لديك | مطلوب لأي عنقود GKE على Shared VPC |
| `compute.firewalls.create`، `compute.firewalls.delete`، `compute.firewalls.get`، `compute.firewalls.list`، `compute.firewalls.update`، و`compute.networks.updatePolicy` | وكيل خدمة GKE في مشروع الخدمة لديك | في ظل Shared VPC، ينشئ GKE قواعد الـ firewall الخاصة بالعنقود وبموزّع الحمل في المشروع المضيف بدلاً من مشروع الخدمة. وبدون ذلك لا تُنشأ قاعدة فحص السلامة الخاصة بموزّع الحمل الداخلي، وتبقى خلفيات الـ Ingress غير سليمة، ولا يعمل الـ Private Link. وهذا هو البديل الدقيق الموثّق من Google عن منح `roles/compute.securityAdmin`. |

الصف الأخير هو صلاحية الكتابة الوحيدة، وهي ممنوحة لوكيل خدمة GKE في مشروعك أنت لا لـ ClickHouse. فحساب خدمة إدارة ClickHouse لا يكتب أبداً في المشروع المضيف. كما تفعّل الوحدة واجهة `container.googleapis.com` في المشروع المضيف، وهو ما يجهّز وكيل خدمة GKE الخاص بذلك المشروع.

بعد ذلك أدخل المشروع المضيف في حقل **Shared VPC host project ID** الموضّح أعلاه. وإذا أردت استخدام Private Link، فأنشئ شبكة فرعية منفصلة من نوع `PRIVATE_SERVICE_CONNECT` في المشروع المضيف، ضمن الشبكة والمنطقة نفسيهما للشبكة الفرعية للعُقد. فهي توجد إلى جانب الشبكة الفرعية للعُقد ولا تحل محلها، وليست الشبكة الفرعية التي تمرّرها في `shared_vpc_host_private_subnet_id`.