بحث

ia

غوص عميق : توليد مخططات AWS باستخدام وكيل ذكاء اصطناعي و Draw.io MCP

غوص عميق : توليد مخططات AWS باستخدام وكيل ذكاء اصطناعي و Draw.io MCP

للحصول على رؤية واضحة في بنية تحتية، يكون المخطط الجيد دائمًا مرغوبًا. لكن إنشاءه يدويًا يستغرق وقتًا: إيجاد الأيقونات المناسبة، وضع العناصر، رسم الاتصالات… ما يحمسني اليوم هو إمكانية أتمتة كل ذلك باستخدام الذكاء الاصطناعي.

في هذا المقال أريكم أنه من الممكن استخدام وكيل ذكاء اصطناعي مع MCP Draw.io لتوليد مخططات بنية AWS تلقائيًا. أستخدم Claude Code في سياقي، لكن هذه المقاربة تعمل مع أي وكيل متوافق مع MCP.

توليد تلقائي لمخطط AWS باستخدام Claude Code و Draw.io MCP

نقطة الانطلاق : تحديث مخطط قديم

كان لدي بالفعل مقال عن بنية هذه المدونة يعود إلى 2018 مع مخطط تم إنشاؤه يدويًا في Draw.io. البنية لم تتغير كثيرًا منذ ذلك الحين — أضفت بشكل أساسي OAC (Origin Access Control) وCloudFront Function — لكن أيقونات AWS تطورت وأردت تحديث المخطط بأحدث الإصدارات.

أثناء البحث عن حلول لأتمتة ذلك، وجدت خادم Draw.io MCP مع امتداد Chrome الخاص به. جربته… ووجدت أنه رائع لدرجة أني قررت كتابة مقال لمشاركة الفكرة!

MCP Draw.io : التحكم في Draw.io بواسطة الذكاء الاصطناعي

خادم Draw.io MCP الذي أنشأه Ladislav (lgazo) هو خادم MCP (Model Context Protocol) يتيح التحكم في Draw.io برمجيًا. عمليًا، هذا يعني أن وكيل الذكاء الاصطناعي يمكنه إنشاء وتعديل وتنظيم العناصر في مخطط Draw.io.

الأدوات المتاحة

الفئةالأدواتالاستخدام
الفحصget-selected-cell, list-paged-modelقراءة حالة اللوحة (canvas)
الإنشاءadd-rectangle, add-edge, add-cell-of-shapeإضافة عناصر
التعديلedit-cell, edit-edge, set-cell-dataتعديل العناصر الموجودة
المكتبةget-shape-categories, get-shapes-in-categoryاستكشاف الأشكال المتاحة

المتطلبات

لكي يتمكن وكيل الذكاء الاصطناعي من التواصل مع Draw.io، يجب تكوين عنصرين كما هو موضح في توثيق المشروع :

  1. خادم MCP محلي — مكوّن في ملف إعدادات الوكيل لديك (مثال: .mcp.json لـ Claude Code)
  2. امتداد Chrome Draw.io MCP — الذي يصنع الجسر بين خادم MCP وتطبيق Draw.io في المتصفح

بمجرد إعداد هذين العنصرين، يمكن للوكيل التلاعب مباشرة بلوحة Draw.io: إنشاء الأشكال، وضعها، رسم الاتصالات، كل ذلك برمجيًا.

أثناء اختبار MCP Draw.io، لاحظت أنه من الضروري إرشاد الوكيل للحصول على نتيجة مرتبة: عدم اختراع موارد، استخدام أيقونات AWS الصحيحة، احترام تموضع متناسق، تطبيق الألوان حسب الفئة، تجنب HTML في النصوص… لذا قمت بإنشاء مهارة (skill) لـ Claude Code تقوم بترميز هذه القواعد.

إنشاء المهارة /aws-diagram

مهارة Claude Code هي ملف Markdown يحدد سير عمل وقواعد. عند استدعاء /aws-diagram، يقوم Claude Code بتحميل هذه التعليمات وتطبيقها تلقائيًا.

سير العمل

تتبع المهارة عملية من 4 خطوات:

  1. قراءة كود البنية التحتية (Terraform, CloudFormation)
  2. استخراج موارد AWS وعلاقاتها
  3. بناء المخطط باستخدام أيقونات AWS الرسمية
  4. إضافة الاتصالات مع تسميات وصفية
📄 مقتطف من المهارة : سير العمل
## Workflow

1. **Read infrastructure code** (Terraform, CloudFormation, etc.)
2. **Extract AWS resources** and their relationships
3. **Build diagram** with official AWS icons
4. **Add connections** with descriptive labels

القواعد الحرجة

اضطررت إلى ترميز عدة قواعد هامة في المهارة:

1. عدم اختراع الموارد أبدًا

كان هذا الفخ الرئيسي. نماذج اللغة الكبيرة تميل إلى “إكمال” ما يبدو منطقيًا لها. “هناك CloudFront، إذًا يجب أن يكون هناك Lambda@Edge…” — لا! يجب أن يمثل المخطط بالضبط ما هو موجود في الكود، لا أكثر.

📄 مقتطف من المهارة : عدم اختراع
### NEVER invent resources

**Only diagram what actually exists in the infrastructure code.**

| Situation                  | Wrong                                         | Correct                                      |
| -------------------------- | --------------------------------------------- | -------------------------------------------- |
| No Lambda in Terraform     | Add Lambda@Edge because "it would make sense" | Don't add Lambda                             |
| CloudFront Function exists | Use Lambda icon                               | Use CloudFront icon with "CF Function" label |
| No WAF configured          | Add WAF for "security"                        | Don't add WAF                                |

2. المستخدمون من خارجيين

المستخدمون “Users” ليسوا موارد AWS. يجب أن يظهروا خارج مجموعة سحابة AWS.

📄 مقتطف من المهارة : المستخدمون خارجيون
### Users OUTSIDE the AWS Cloud

**Users are NOT AWS resources.** They represent external actors.

WRONG:
┌─────────────────────────────────┐
│ AWS Cloud │
│ [Users] → [Route53] → [CF] │ ❌ Users inside cloud
└─────────────────────────────────┘

CORRECT:
[Users] → ┌─────────────────────────┐
│ AWS Cloud │
│ [Route53] → [CF] → [S3] │ ✅ Users outside
└─────────────────────────┘

3. لا HTML في النصوص

Draw.io لا يعرض HTML. إذا كتبت text: "S3<br>Private"، فسترى حرفيًا <br> في المخطط.

📄 مقتطف من المهارة : لا HTML
### NEVER use HTML in text parameters

Draw.io does NOT render HTML tags in text fields. They display as raw text.

**FORBIDDEN (will show ugly raw HTML):**

text: "S3 Bucket<br>Private" ❌ Shows "<br>" literally
text: "Route 53&nbsp;DNS" ❌ Shows "&nbsp;" literally
text: "<font color='red'>ACM</font>" ❌ Shows raw HTML tags

**CORRECT (clean text):**

text: "S3 Bucket" ✅ Single line, clean
text: "Route 53" ✅ Service name only
text: "ACM" ✅ Simple label

4. تخطيط مسبق لتجنب التصادمات

الحواف (edges) المتقاطعة تجعل المخطط غير مقروء. توصي المهارة بوضع المسار الرئيسي على خط أفقي، والخدمات المساعدة فوقه أو تحته.

📄 مقتطف من المهارة : التخطيط والتصادمات
### Rule 1: Main Flow on a Horizontal Line

Place the primary data flow (request path) on a single horizontal row:

[Entry] → [Service A] → [Service B] → [Service C]
y=300 y=300 y=300 y=300

### Rule 2: Auxiliary Services Above or Below

Services that connect TO a main service (not part of the flow) go above or below:

        [Auth]     [Edge Logic]     ← Auxiliary row (y=150)
           \           /
            \         /
             ↓       ↓

[Entry] → [Gateway] → [Compute] → [Storage] ← Main flow (y=300)

5. التعليقات إلى اليمين، ليس أسفل

أيقونات AWS تضع تسميتها تلقائيًا أسفلها. إذا أضفت تعليقات أسفلها أيضًا فستتداخل مع السطر التالي. ضعها على يمين الأيقونة.

📄 مقتطف من المهارة : وضع التعليقات
### Annotation Placement Rules

**CRITICAL: Place annotations to the RIGHT of icons, not below.**

**WRONG - Annotations below icons:**

[CloudFront] [S3]
|
"Cache Policies" ← Overlaps with next row!
"Security Headers"
|
[CloudFront Preview] ← Collision!

**CORRECT - Annotations to the RIGHT:**

[CloudFront] ── "Cache Policies: HTML 0s | Assets 1y"
| "Security: CSP | HSTS"

[CloudFront Preview] ← No collision

نظام الألوان

حددت لوحة ألوان متناسقة مع قواعد AWS:

الفئةاللونالخدمات
الشبكات#8C4FFF (أرجواني)Route53, CloudFront, VPC
التخزين#7AA116 (أخضر)S3, EFS
الأمن#DD344C (أحمر)ACM, IAM, WAF
الحوسبة#ED7100 (برتقالي)Lambda, EC2

لتيارات البيانات، أستخدم ألوانًا حسب البيئة:

  • الإنتاج (Production) : أخضر #4CAF50
  • المعاينة (Preview) : برتقالي #FF9800
  • التكوين (Configuration) : رمادي #AAAAAA (منقط)
📄 مقتطف من المهارة : الألوان والأنماط
### Colors by Category

| Category       | Color               | Services                                   |
| -------------- | ------------------- | ------------------------------------------ |
| **Networking** | `#8C4FFF` (violet)  | Route53, CloudFront, VPC, ELB, API Gateway |
| **Compute**    | `#ED7100` (orange)  | Lambda, EC2, ECS, Fargate                  |
| **Storage**    | `#7AA116` (green)   | S3, EFS, EBS                               |
| **Database**   | `#C925D1` (magenta) | RDS, DynamoDB, ElastiCache                 |
| **Security**   | `#DD344C` (red)     | ACM, IAM, WAF, Cognito                     |
| **General**    | `#232F3D` (gray)    | Users, Generic                             |

### AWS Icon Style Template

sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=<COLOR>;strokeColor=#ffffff;
dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;
fontSize=12;fontStyle=0;aspect=fixed;shape=mxgraph.aws4.resourceIcon;
resIcon=mxgraph.aws4.<SERVICE>;

### Edge Colors by Environment

| Environment   | Color     | Usage                  |
| ------------- | --------- | ---------------------- |
| Production    | `#4CAF50` | Main production flow   |
| Preview       | `#FF9800` | Staging environments   |
| Configuration | `#AAAAAA` | Dashed, non-data links |

تطبيق عملي : البنية jls42.org

لاختبار المهارة، استخدمتها على بنية هذا المدونة.

كود Terraform المحلل

terraform/
├── cloudfront-astro.tf    # Distribution CloudFront prod
├── s3-astro.tf            # Bucket S3 privé avec OAC
├── acm-astro.tf           # Certificat SSL
├── route53.tf             # DNS
└── variables.tf           # Variables

البنية المستخرجة

مكونخدمة AWSالتكوين
DNSRoute 53نطاق jls42.org، 3 دومينات
CDNCloudFrontOAC, دالة CloudFront، سياسات التخزين
التخزينS3دلو خاص، AES256، خاص بـ OAC فقط
TLSACMشهادة us-east-1، تحقق عبر DNS

المخطط المولد

إليك النتيجة النهائية:

بنية AWS لموقع jls42.org مولدة تلقائيًا بنية AWS لموقع jls42.org مولدة تلقائيًا

انطلاقًا من مُطالبة بسيطة باللغة الطبيعية:

«Analyse en profondeur l’infrastructure de ce projet puis réalise un super schéma de l’architecture AWS comme un pro. Juste l’infra de prod, pas preview ni legacy.»

🇸🇦 «حلل بعمق بنية هذا المشروع ثم أنشئ مخططًا رائعًا لبنية AWS كالمحترفين. فقط بنية الإنتاج، لا المعاينة ولا القديمة.»

قام Claude Code أولًا بتحليل ملفات Terraform لتحديد البنية، ثم حمّل المهارة /aws-diagram التي سمحت للتعليمات بـ:

  1. إنشاء المكونات الرئيسية (المستخدمون، Route53، CloudFront، S3، ACM)
  2. إضافة التعليقات التفصيلية (سياسات التخزين المؤقت، رؤوس الأمان، تكوين الدلو…)
  3. رسم الاتصالات مع تسميات (HTTPS، DNS Alias، OAC، شهادة TLS…)
  4. إضافة الخدمات الخارجية (Plausible Analytics، Gandi للبريد الإلكتروني)
  5. توليد وسيلة إيضاح (legend) لكل فئة

كل ذلك مع احترام تخطيط مرتب يتضمن:

  • سحابة AWS بحجم تلقائي (900×420px)
  • المستخدمون إلى يسار السحابة
  • الخدمات الخارجية إلى اليمين
  • وسيلة إيضاح أسفل المخطط

سير العمل الكامل : من Terraform إلى الفيديو

دفعت التجربة أبعد بإنشاء فيديو توضيحي.

التسجيل

سجلت عملية توليد المخطط في الوقت الحقيقي: 4 دقائق و10 ثوانٍ لClaude Code وهو يقرأ Terraform، ينشئ العناصر واحدًا تلو الآخر، ويبني المخطط أمامي.

ما بعد الإنتاج باستخدام FFmpeg

4 دقائق طويلة لعرض توضيحي. استخدمت FFmpeg لإنشاء نسخة مسرّعة بسرعات متغيرة:

الجزءالمحتوىالسرعة
0:00-0:10طلب من Claude توليد المخطط1x
0:10-0:32تحليل كود Terraform15x
0:32-0:35اكتشاف وتشغيل المهارة /aws-diagram تلقائيًا1x
0:35-3:46توليد المخطط في المتصفح15x
3:46-3:56إعادة تموضع التسميات لتحسين العرض1x

النتيجة: فيديو 42 ثانية بدلًا من 4 دقائق، مع الحفاظ على اللحظات الرئيسية بسرعة عادية.

السرد الصوتي مع HeyGen

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

النتيجة النهائية هي الفيديو الذي يمكنكم مشاهدته في أعلى هذا المقال.

مثال ثانٍ : بنية EKS عالية التوافر

لتوضيح مدى فعالية MCP Draw.io، إليكم مثالًا ثانيًا أكثر تعقيدًا: بنية EKS (Elastic Kubernetes Service) عالية التوافر. يقوم MCP بكل عمل الإنشاء في Draw.io — كل ما فعلته أنني قدمت مُطالبة مفصّلة.

هذه المرة، قدمت مُطالبة مفصّلة تصف البنية المطلوبة:

📋 المُطالبة الكاملة لبنية EKS
Architecture EKS Hautement Disponible

Génère un diagramme d'architecture AWS EKS avec les composants suivants :

## Services AWS à inclure

### Externes (gauche du cloud)

- Users (icône utilisateurs générique)

### Networking

- Route 53 (DNS)
- Application Load Balancer (ALB) - dans les subnets publics
- NAT Gateway (3x, un par AZ)
- VPC avec 3 AZ

### Compute (subnets privés)

- EKS Control Plane (géré par AWS - représenter séparément)
- 3 Node Groups (un par AZ) avec pods à l'intérieur

### Storage

- EFS (stockage partagé cross-AZ)

### Security

- ACM (Certificate Manager)
- IAM (pour Pod Identity / IRSA)

### Observability

- CloudWatch (logs et métriques)

## Connexions à tracer

| Source            | Target      | Label               | Style       |
| ----------------- | ----------- | ------------------- | ----------- |
| Users             | Route 53    | HTTPS               | Solid green |
| Route 53          | ALB         | DNS Alias           | Solid green |
| ALB               | Node Groups | Traffic             | Solid green |
| ACM               | ALB         | TLS                 | Dashed gray |
| Node Groups       | EFS         | NFS Mount           | Solid green |
| EKS Control Plane | Node Groups | kubectl API         | Solid green |
| EKS Control Plane | IAM         | IRSA / Pod Identity | Dashed gray |
| Node Groups       | CloudWatch  | Logs / Metrics      | Dashed gray |

النتيجة المولدة

بنية EKS عالية التوافر مولدة تلقائيًا بنية EKS عالية التوافر مولدة تلقائيًا

يوضح هذا المخطط بنية Kubernetes جاهزة للإنتاج تتضمن:

  • 3 مناطق توفّر (Availability Zones) للقدرة العالية على التوفر
  • بوابات NAT متكررة (واحدة لكل منطقة) للوصول إلى الإنترنت
  • مجموعات عقد موزعة مع الحِاويات (pods) في كل منطقة
  • EFS عبر المناطق للتخزين المشترك الدائم
  • مستوى التحكم المُدار من AWS مفصول بصريًا
  • IRSA (أدوار IAM للحسابات الخدمة) لأمن الحِاويات

فهم MCP Draw.io البنية بشكل صحيح بإنشاء مجموعات VPC وAZ، ووضع بوابات NAT في الشبكات الفرعية العامة ومجموعات العقد في الشبكات الفرعية الخاصة. النتيجة تعطي قاعدة عمل ممتازة لتعديلها لاحقًا حسب التفضيلات البصرية أو تصحيح أي أخطاء — أسرع بكثير من البدء من الصفر.

ما يكشفه هذا المشروع

تُبرز هذه التجربة عدة جوانب من طريقة عملي:

  • أتمتة التوثيق: الكود هو مصدر الحقيقة، ويفترض أن ينبثق عنه المخطط تلقائيًا
  • استخدام الأدوات المناسبة: كان MCP Draw.io هو ما أحتاجه بالضبط، لم أعِد اختراع العجلة
  • ترميز القواعد: تسمح المهارات بالتقاط الخبرة وتجنب الأخطاء الشائعة — قابلة للتطبيق على أي نوع من مخططات Draw.io، ليس فقط AWS
  • الاختبار على الواقع: استخدمت بنيتي الخاصة كتجربة تطبيقية
  • توسيع الاستكشاف: من التوليد التلقائي إلى الفيديو المروي، كل خطوة كانت فرصة للتعلّم

المهارة أصبحت الآن مدمجة في سير عملي. في المرة القادمة التي أعدّل فيها البنية التحتية، سأتمكن من إعادة توليد المخطط بمجرّد مُطالبة بسيطة.

الموارد


إذا كنتم تستخدمون وكيل ترميز متوافق مع MCP ولديكم بنى تحتية لتوثيقها، أشجعكم على تجربة هذه المقاربة. من المُرضي رؤية مخطط مرتب يُبنى تلقائيًا أمام أعينكم.

شكرًا لقراءة المقال، آمل أن يكون قد حفّزكم لتجربة الأمر!

تمت ترجمة هذا المستند من النسخة fr إلى اللغة ar باستخدام نموذج gpt-5-mini. لمزيد من المعلومات حول عملية الترجمة، راجع https://gitlab.com/jls42/ai-powered-markdown-translator