نقل أكثر من اثني عشر تطبيقًا من GCP إلى Azure، خلف نظام هوية واحد
عملية ترحيل استغرقت شهرين، دفع إليها تشديد التحكم في الوصول على مستوى الشركة كلها، ووضعت كل تطبيق على Azure تحت Microsoft Entra ID، معرَّفًا في Pulumi، مع حفظ البيانات السرية في Doppler وKey Vault.
- الشريك
- شركة استشارية متعددة الجنسيات
- المدة
- شهران
- تطبيقات مُرحَّلة
- 12+
- تطبيقات Python نُقلت من GCP إلى Azure App Service
- نظام هوية
- 1
- كل التطبيقات خلف Microsoft Entra ID
- مدة التسليم
- شهران
- التدقيق والتنظيف والترحيل والتسليم
التحدي
كانت الشركة تشدّد التحكم في الوصول على مستوى المؤسسة كلها، وأراد فريق تقنية المعلومات أن تخضع كل التطبيقات الداخلية للهوية والسياسات نفسها التي تحكم Microsoft 365. وكانت تطبيقاتها تعمل على Google Cloud وتُنشر يدويًا، دون بنية تحتية كرمز برمجي، ودون سجل كامل للموارد، وكانت البيانات السرية تُتداول بشكل غير رسمي.
ما بنيناه
تدقيق وتنظيف، ثم ترحيل أكثر من اثني عشر تطبيق Python إلى Azure، وكلها معرَّفة في Pulumi. تعمل التطبيقات في حاويات على Azure App Service مع قواعد بيانات خاصة، وتنتقل البيانات السرية من Doppler إلى Azure Key Vault، ويحمي Cloudflare Access مع Microsoft Entra ID كل تطبيق.
ما تم تسليمه
- كل التطبيقات ضمن النطاق على Azure، معرَّفة بالشيفرة البرمجية ومنشورة عبر CI/CD
- نظام هوية واحد ومجموعة واحدة من سياسات الوصول لكل التطبيقات
- بيانات سرية محفوظة في Doppler وKey Vault بدلًا من تداولها بشكل غير رسمي
نبذة عن الشريك
شريكنا شركة استشارية متعددة الجنسيات يزيد عدد موظفيها على 1,000 موظف، يعملون في عدة مناطق لصالح مؤسسات بارزة. وكان موظفوها يعملون أصلًا في Microsoft 365 ويسجّلون الدخول عبر Microsoft Entra ID. وفي إطار توجه على مستوى الشركة كلها لتشديد التحكم في الوصول، طلب فريق تقنية المعلومات نقل كل تطبيق داخلي إلى Azure، بجوار نظام الهوية ذاك، لتغطيها جميعًا مجموعة واحدة من السياسات وسجل تدقيق واحد.
التحدي
سحابتان ونموذجان للوصول
كانت التطبيقات على Google Cloud خارج سياسات الهوية والوصول المشروط التي تحكم بقية أنظمة الشركة، فكان لا بد من إدارة الوصول إليها ومراجعته بشكل منفصل.
إدارة سحابية مجزأة
أُنشئت الموارد على Google Cloud دون نظام مشترك لتوثيقها وإدارتها، فكان من الصعب معرفة ما هو موجود ولماذا.
بيانات سرية تُتداول بشكل غير رسمي
كانت مفاتيح API وبيانات الاعتماد تُتداول بشكل غير رسمي، وهو خطر كان يكبر مع نمو الفريق.
عمليات نشر يدوية
في غياب البنية التحتية كرمز برمجي وغياب مختص بها، كانت كل بيئة تُعدّ يدويًا، ما أطال المدة اللازمة لبدء المشاريع الجديدة.
تكاليف متصاعدة
تراكمت موارد غير مستخدمة وأخرى مكررة، دون رؤية واضحة لما يرفع الإنفاق.
الأهداف
- إخضاع كل تطبيق داخلي لـ Microsoft Entra ID ولسياسات الوصول في الشركة
- إدارة البنية التحتية بشيفرة يستطيع الفريق الحالي قراءتها وصيانتها
- أتمتة تجهيز البيئات الجديدة
- إزالة عمليات النشر القديمة والموارد غير المستخدمة قبل النقل
- استبدال التداول غير الرسمي للبيانات السرية بإدارة مركزية لها
دورنا
خططت كارسنترك لعمليات التدقيق والتنظيف والترحيل والتسليم ونفذتها على مدى شهرين.
النطاق والجدول الزمني
رحّل المشروع أكثر من اثني عشر تطبيق Python من إعداد على GCP لا يعتمد على الحاويات إلى حاويات على Azure، مع قواعد بياناتها وذاكراتها المؤقتة وطوابير الرسائل الخاصة بها، وكلها تُدار عبر Pulumi. وتم التسليم خلال شهرين.
المنهجية
هوية واحدة لكل شيء
وضع الانتقال إلى Azure كل تطبيق بجوار Microsoft Entra ID. ويستخدم Cloudflare Access نظام Entra ID مزوّدًا للهوية، فتحدد الحسابات والمجموعات وسياسات الوصول المشروط نفسها من يصل إلى كل تطبيق.
بنية تحتية كرمز برمجي بلغة مألوفة
يتيح Pulumi كتابة البنية التحتية بلغة TypeScript، وهي لغة يستخدمها مطورو الشريك أصلًا، فيستطيع الفريق قراءتها ومراجعتها وتوسيعها بعد التسليم.
التنظيف قبل النقل
حدد التدقيق أولًا الموارد المكررة وغير المستخدمة، فلم يُرحَّل إلا ما تدعو إليه الحاجة.
التنفيذ
التدقيق والتنظيف
حُددت موارد GCP المكررة وأُزيلت قبل الترحيل، فلم يُنقل أي مورد غير مستخدم.
الحوسبة والبيانات
وُضع كل تطبيق في حاوية ونُقل إلى Azure App Service. ونُقلت قواعد البيانات إلى Azure Database for PostgreSQL على شبكة افتراضية خاصة، إلى جانب Azure Cache for Redis وService Bus، مع Application Insights للمراقبة.
الوصول
يقع كل تطبيق خلف Cloudflare Access مع Microsoft Entra ID، فيُمنح الوصول حسب المجموعة ويُفحص مقابل سياسات الوصول المشروط في الشركة. ولا يقبل كل App Service حركة البيانات إلا من Cloudflare، ويتحقق من رمز Access، فلا يمكن الوصول إلى أي تطبيق بتجاوزه.
البيانات السرية
مزوّد Pulumi مخصص، مكتوب بلغة TypeScript، يقرأ البيانات السرية من Doppler ويكتبها في Azure Key Vault. وتقرأها التطبيقات عبر مراجع Key Vault، فلا تحمل إعدادات التطبيقات إلا مرجعًا إلى Key Vault، ولا تحمل قيمة البيانات السرية أبدًا.
دمج الواجهات الأمامية
أُدخلت الواجهات الأمامية المستضافة على Vercel في قاعدة شيفرة Pulumi، فأصبحت جميع البيئات تُدار من مكان واحد.
الأتمتة
رُبط Pulumi Cloud بمسارات الإصدار (CI/CD). ويعرض كل طلب دمج خاص بالبنية التحتية معاينة لتغييراته، وتحتاج تغييرات بيئة الإنتاج إلى موافقة.
الأدوات والتقنيات
| الأداة | الغرض |
|---|---|
| Pulumi وPulumi Cloud | البنية التحتية كرمز برمجي وأتمتة النشر |
| Azure App Service | استضافة الحاويات |
| Azure Database for PostgreSQL | قواعد بيانات مُدارة وخاصة |
| Doppler | الإدارة المركزية للبيانات السرية |
| Azure Key Vault | البيانات السرية التي تقرأها التطبيقات |
| Cloudflare Access | وصول قائم على الهوية إلى كل تطبيق |
| Microsoft Entra ID | مزوّد الهوية والوصول المشروط |
| Vercel | استضافة الواجهات الأمامية، بإدارة Pulumi |
ما تم تسليمه
- تطبيقات مُرحَّلة
- 12+
- نظام هوية
- 1
- مراحل الترحيل
- 4
- مدة التسليم
- شهران
- جميع التطبيقات ضمن النطاق تعمل على Azure تحت إدارة Pulumi
- كل تطبيق خلف Microsoft Entra ID وسياسات الوصول في الشركة
- إزالة الموارد السحابية غير المستخدمة والمكررة قبل الترحيل
- إدارة مركزية للبيانات السرية وقراءتها من Key Vault
لماذا يهم ذلك
تبلغ قيمة الانتقال السحابي أقصاها حين يغيّر طريقة حوكمة البيئة التقنية، لا مكان تشغيلها فحسب. ووضع كل تطبيق خلف نظام هوية واحد، معرَّف بالشيفرة البرمجية، يعني أن الوصول يُراجع في مكان واحد، وأن المشروع التالي يبدأ من أساس معروف.
إذا كانت مؤسستكم تواجه تحديًا مشابهًا، يسعدنا أن نناقشه معكم.