السحابة المتعددة: Azure وGCP

أساسيات Microsoft Azure

18 دقيقة الدرس 2 من 28

أساسيات Microsoft Azure

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

التسلسل الهرمي في Azure

يهيكل Azure التأجير من خلال أربعة مستويات متداخلة: Management Groups ← Subscriptions ← Resource Groups ← Resources. كل كائن تنشئه يقع في الجزء السفلي من هذه الشجرة، وكل سياسة أو تعيين RBAC تربطه بأي مستوى يتتالى تلقائيًا نحو الأسفل.

التسلسل الهرمي في Azure: مجموعات الإدارة تحتوي على الاشتراكات، التي تحتوي على مجموعات الموارد، التي تحتوي على الموارد الفردية.

الاشتراكات: حدود الفوترة والحصص

يُعدّ الاشتراك (Subscription) الوحدة الأساسية للفوترة في Azure. كل مورد تنشئه يُحسب على اشتراك واحد بالضبط. لكن الاشتراكات ليست مجرد فواتير — فهي تحمل أيضًا حصص خدمة لكل اشتراك (مثل حدود vCPU لكل منطقة)، وجذور RBAC مستقلة، وفضاءات عناوين شبكات مستقلة.

الأحمال الإنتاجية على نطاق واسع تستخدم اشتراكات متعددة عن قصد: اشتراك لكل بيئة (إنتاج، تجهيز، تطوير)، أو اشتراك لكل وحدة عمل، أو اشتراك لكل نطاق هبوط. هذا يُبقي نطاق الضرر صغيرًا — فتعيين RBAC خاطئ في اشتراك التطوير لا يمكنه لمس موارد الإنتاج في اشتراك مختلف.

نمط Enterprise Landing Zone: يصف إطار عمل Microsoft Cloud Adoption Framework اشتراك "Platform" للشبكات والهوية المشتركة، بالإضافة إلى اشتراك "Application" واحد لكل حمل عمل أو فريق. يتدفق RBAC والسياسات وحوكمة مراكز التكلفة من خلال حدود الاشتراك. على نطاق Microsoft الداخلي، تشغّل الفرق مئات الاشتراكات، ولكل منها مالك مسؤول عن الإنفاق والامتثال.

مجموعات الموارد: وحدات دورة الحياة، لا مجرد مجلدات

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

جمّع حسب دورة حياة التطبيق، لا حسب نوع المورد. ضع VM وكرت الشبكة الخاص به وNSG وقرص المحادثة ومساحة عمل Log Analytics في نفس مجموعة الموارد — فجميعها تُنشر وتُدمر معًا.
لا تجمّع حسب النوع (مثل "جميع حسابات التخزين في مجموعة واحدة"). هذا يجعل الحذف وتحديد التكلفة و RBAC مؤلمة.
لمجموعات الموارد منطقة بيانات وصفية (حيث يُخزَّن سجل المجموعة)، لكن الموارد بداخلها يمكن أن تمتد عبر أي منطقة Azure.

اصطلاح التسمية المستخدم على نطاق المؤسسات: rg-{workload}-{environment}-{short-region}، مثلًا rg-payments-prod-eus (East US) أو rg-payments-prod-weu (West Europe).

فخ إنتاجي — الموارد المهجورة: يمكن نقل الموارد بين مجموعات الموارد، لكن ليس جميع أنواع الموارد تدعم النقل. بعض كائنات الشبكة (مثل VNet مع اتصالات نظير نشطة) لا يمكن نقلها أثناء الاتصال بموارد أخرى. تحقق دائمًا من التوافق باستخدام az resource move --validate-only قبل الترحيل المباشر، وإلا فإنك تخاطر بإطلاق دورة حذف وإعادة إنشاء مع توقف.

ARM: مدير موارد Azure

Azure Resource Manager (ARM) هو مستوى التحكم لكل عملية Azure. سواء نقرت في بوابة Azure، أو شغّلت az CLI، أو استدعيت REST API مباشرةً، أو نشرت Bicep / Terraform — كل طلب يتم مصادقته عبر Azure Active Directory ويُوجَّه بواسطة ARM إلى مزود الموارد المناسب (مثل Microsoft.Compute أو Microsoft.Network). يوفر ARM:

نشر إعلاني ملتزم بالتطابق (Idempotent) — تصف قوالب ARM (JSON) أو Bicep الحالة المطلوبة؛ يحسب ARM الفرق ويطبق فقط ما تغيّر.
تطبيق RBAC — يُفوَّض كل إجراء على مستوى ARM قبل أن يصل إلى مزود الموارد. لا يوجد تجاوز ممكن عبر البوابة.
وسوم (Tags) — وسوم مفتاح/قيمة اعتباطية على أي مورد لتحديد التكلفة ومشغّلات الأتمتة وفحص الامتثال.
أقفال (Locks) — أقفال ReadOnly أو CanNotDelete تُطبَّق على مستوى مجموعة الموارد أو المورد الفردي لمنع التغييرات العرضية على البنية التحتية الإنتاجية.

# --- 1. تسجيل الدخول واختيار الاشتراك الصحيح ---
az login
az account list --output table
az account set --subscription "prod-payments-sub-id"

# --- 2. إنشاء مجموعة موارد بوسوم دورة الحياة ---
az group create \
  --name rg-payments-prod-eus \
  --location eastus \
  --tags environment=prod workload=payments costcenter=CC-2301 managed-by=terraform

# --- 3. التحقق ---
az group show --name rg-payments-prod-eus --output table

# --- 4. تطبيق قفل CanNotDelete ---
az lock create \
  --name lock-rg-payments-prod \
  --resource-group rg-payments-prod-eus \
  --lock-type CanNotDelete \
  --notes "Production RG — lock owned by platform-team"

# --- 5. عرض الأقفال الحالية على المجموعة ---
az lock list --resource-group rg-payments-prod-eus --output table

قوالب ARM وBicep: البنية التحتية كتعليمات برمجية

يقبل ARM قوالب JSON بشكل أصلي، لكن Bicep هي اللغة الحديثة من الدرجة الأولى لـ Azure IaC. تترجم Bicep إلى ARM JSON ولديها تعادل كامل مع ARM API. كما يستهدف Terraform ARM عبر مزود azurerm — تستخدم معظم الفرق الكبيرة Terraform للتنقلية عبر السحب، بينما تستخدم المتاجر الأصلية لـ Azure Bicep للتكامل الأوثق مع Azure DevOps و GitHub Actions.

مثال Bicep بسيط ينشئ حساب تخزين داخل مجموعة موارد موجودة:

// main.bicep — ينشر حساب تخزين في مجموعة موارد موجودة
param location string = resourceGroup().location
param env string = 'prod'
param workload string = 'payments'

var storageAccountName = 'st${workload}${env}${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_ZRS'   // متكرر عبر المناطق — مطلوب لأي تخزين إنتاجي
  }
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
  tags: {
    environment: env
    workload: workload
    'managed-by': 'bicep'
  }
}

output storageId string = storageAccount.id

# نشر قالب Bicep في مجموعة الموارد
az deployment group create \
  --resource-group rg-payments-prod-eus \
  --template-file main.bicep \
  --parameters env=prod workload=payments \
  --confirm-with-what-if    # راجع دائمًا في الإنتاج

RBAC ونموذج تفويض ARM

يُمنح كل مدير أمان (مستخدم، مجموعة، كيان خدمة، هوية مُدارة) دورًا على نطاق. يمكن أن يكون النطاق مجموعة إدارة أو اشتراكًا أو مجموعة موارد أو موردًا فرديًا. تنتقل الأدوار الممنوحة على نطاق أعلى إلى جميع العناصر الفرعية. الأدوار الثلاثة المضمّنة الأكثر استخدامًا:

Owner — تحكم كامل بما في ذلك تعيين RBAC. احتفظ به لأصحاب الاشتراكات فقط.
Contributor — إنشاء الموارد وإدارتها دون القدرة على تعيين الأدوار. استخدمه لكيانات خدمة CI/CD.
Reader — عرض للقراءة فقط. استخدمه للمهندسين المناوبين الذين لا يحتاجون إلى إجراء تغييرات.

الهوية المُدارة بدلًا من كيانات الخدمة: عندما يحتاج كودك البرمجي الذي يعمل داخل Azure (حجرة AKS، تطبيق Function، VM) إلى استدعاء ARM أو خدمات Azure، استخدم Managed Identity بدلًا من كيان خدمة بسر عميل. الهويات المُدارة ليس لها بيانات اعتماد يمكن تسريبها أو تدويرها — يتولى Azure إدارة دورة حياة بيانات الاعتماد تلقائيًا. هذا هو المعيار في كبرى شركات التقنية ويُطبَّق كسياسة في كثير من المؤسسات.

المناطق ومناطق التوفر والنموذج المادي

كل منطقة (Region) في Azure (مثل eastus أو westeurope) هي مجموعة من مراكز البيانات ضمن حدود زمن استجابة محددة. المناطق التي تدعم مناطق التوفر (Availability Zones) لديها ثلاثة مراكز بيانات أو أكثر منفصلة فيزيائيًا بطاقة ومبردات وشبكات مستقلة — تتيح النشرات المنطقية الصمود أمام فقدان مركز بيانات واحد بلا فقدان بيانات وتوقف يكاد يكون صفرًا. انشر دائمًا أحمال العمل الإنتاجية عبر منطقتَي توفر على الأقل. تتيح أزواج المناطق (مثل East US / West US) التكرار الجغرافي للتعافي من الكوارث.

نوع مورد ARM الخاص بـ Microsoft.Resources/resourceGroups عالمي — ليس مرتبطًا بمنطقة توفر. الموارد داخل المجموعة هي ما تعيّنه على المناطق. عند إنشاء مجموعة AKS أو VM Scale Set أو قرص مُدار، حدد المناطق دائمًا بشكل صريح.