أتمتة خادم ويندوز (الجزء 1)

الصفحة الرئيسية



Deriv Tech



التعلّم



أتمتة خادم ويندوز (الجزء 1)

March 18, 2024

أتمتة ويندوز باستخدام Terraform و Octopus Deploy

في Deriv، قمنا بدمج منصة MetaTrader 5 (MT5)، المبنية على ويندوز، لتوفير خيارات تداول متقدمة لعملائنا.

كان من المقبول التعامل مع النشر يدويًا عندما كان لدينا عدد محدود من الخوادم المطلوبة لإدارة المنصة.

مع زيادة الشعبية، بسبب العروض التنافسية لـ MT5 من Deriv، أدركنا بسرعة أن تطوير تطبيقاتنا واسعة النطاق والحفاظ عليها على قيد الحياة تضمن العديد من الخطوات.

مع زيادة عدد الخطوات، زادت التعقيدات أيضًا، مما أدى إلى مخاطر أعلى لحدوث أخطاء أو إعدادات خاطئة.

حاليًا، لدينا أكثر من 50 خادم سحابي على AWS لإدارة أجزاء مختلفة من منصة MT5.

الأتمتة هي الحل

تصبح الحاجة لأتمتة العملية الكاملة مهمة بشكل خاص عندما يكون لديك مستوى خدمة SLA يبلغ 99.99% وعندما تمتلك هذا العدد الكبير من الخوادم على بنية تحتية سحابية.

مع التدخل اليدوي، تزيد احتمالات حدوث أخطاء، وتفويت خطوات الإعداد، وعيوب أخرى. لذا تساعد الأتمتة أيضًا في زيادة الموثوقية التشغيلية.

المهمة الحالية

المهمة المقدمة هنا كمثال جيد لأتمتة Windows لإعداد العديد من الحالات السحابية وتحضير البيئة لتطبيق Windows تابع لجهة خارجية.

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

كان مطلبًا آخر دمج التطبيق مع خدمات طرفية متعددة، بما في ذلك المراقبة والتحليلات.

يوضح الرسم البياني أدناه تدفق وتفاعل المكونات المعنية:

بالإضافة إلى ذلك، نريد أن نكون محايدين للسحابة كمؤسسة في Deriv. لتحقيق هذا الهدف، كان لا بد من تلبية النشر الخاص بنا لكل من AWS و GCP.

كيف نصل إلى هناك؟

كانت الخطة هي تنفيذ خط أنابيب CI/CD يدعم بيئة Windows، وخاصة آلية الأتمتة التي تسمح بالنشر والتشغيل المستمر لإعداد Windows المطلوب.

أكثر مما تظهره العين

اكتشفنا أن هذا التحدي له عدة طبقات تتطلب التحليل والأتمتة، مثل بيئة السحابة، ونظام التشغيل، وتركيب التطبيق. في هذه التدوينة، سنناقش طبقة بيئة السحابة بالتفصيل.

بيئة السحابة

قررنا استخدام Terraform لتوفير الحالات السحابية. بدأنا بجمع جميع متطلبات الأجهزة لتطبيقنا. بمجرد جمع متطلبات الموارد والتشغيل لكل دور جهاز، رمزناها كالبنية التحتية ككود (IaC) باستخدام Terraform.

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

من خلال إنشاء الوحدات، لم نعد مجبورين على تعريف موارد متعددة برمجيًا باستخدام أجزاء متكررة من الكود؛ بل كان يكفي تعريف المورد الرئيسي وإنشاء الوحدات حيثما تطلب الأمر.

الموارد التي أنشئت لم تكن فقط عن حالات EC2 ولكن أيضًا عن الشبكات، وقوائم السماح الشبكية، ومجموعات الأمان، وVPCs، وNACL، وغيرها.

تم أيضًا إنشاء قناة اتصال مناسبة للسماح بالتواصل بين المناطق المختلفة باستخدام اتصال VPC peering.

توضيح عملي لـ Terraform

أردنا استخدام AWS كمزود السحابة الخاص بنا واخترنا Octopus Deploy Server كمدير التكوين الخاص بنا.

حددنا الموفرين اللازمين لتوفير وتكوين كل من AWS وOctopus Deploy Server باستخدام Terraform:

AWS
Octopus Deploy

تكوين مزودي Terraform

بالنسبة لكود Terraform، استخدمنا GitHub كمنصة لنظام التحكم في الإصدارات. في الجزء الأول من عملية التوفير، سحب وحدة Terraform الخاصة بنا الموارد المقابلة من مستودع GitHub لبدء حالات AWS.
ويتبع نفس المفهوم لتوفير VPC، والشبكات الفرعية، وجميع مكونات الشبكة.

‍السطر الأخير في نموذج التعليمات البرمجية أعلاه يقوم بتشغيل مقتطف بيانات المستخدم المطلوبة، الأمر الذي يمكّن ويقوم بتكوين اتصال إدارة النظام عن بُعد في ويندوز (WinRM) باستخدام أمر Bash وإضافة وتمكين قواعد جدار الحماية باستخدام برنامج PowerShell. مع تفعيل بروتوكول WinRM، يمكننا الاتصال عن بُعد، عبر الطرفية، بحالة Windows.

مقتطفات WinRM bash وPowerShell

‍بالنسبة لكل مثيل تم إنشاؤه حديثًا، تم تصدير كلمة المرور باستخدام ملف المفتاح الخاص. تم إضافة نفس كلمة المرور كمتغير على Octopus Deploy Server، باستخدام مورد Octopus Deploy المدرج أدناه:

تم سحب كل كلمة مرور باستخدام ملف المفتاح الخاص لحساب AWS ثم تم ترميزها لاحقًا إلى base64 لأسباب السلامة، لتجنب مشاكل مع محارف الهروب.

كانت الخطوة التالية هي إدارة تكامل Terraform مع Octopus Deploy Server لأتمتة الانتقال. لهذا السبب استخدمنا null resources التي تهدف إلى تنفيذ برنامج PowerShell نصي على المضيف.

نظرًا لعدم إمكانية التحكم بتسلسل التنفيذ في Terraform، أخذنا عناية خاصة بإضافة التبعيات بالترتيب الصحيح. في هذا الصدد، تم تنفيذ null resources بشرط الانتهاء مسبقًا من توفير الحالة.

خلال تنفيذ null resources، تم تشغيل برنامج PowerShell نصي على المضيف، مما أدى تلقائيًا إلى تثبيت وتسجيل وكيل Tentacle على الحالة التي تم إنشاؤها حديثًا. تم تنفيذ العملية عبر مكالمة API تجاه Octopus Deploy Server المجهز مسبقًا والمستضاف على طبقة الإدارة الخاصة بنا على AWS.

استخدمنا الموارد المناسبة المقابلة لتكوين Octopus Deploy Server عبر وحدات Terraform. قمنا بتكوين Octopus Deploy Server من خلال إنشاء مستخدمين وأدوارهم، الفرق، البيئات المختلفة، مجموعات المشاريع الجديدة، المشاريع الجديدة، والمساحات الجديدة.

أحد أكثر الموارد فائدة التي استخدمناها هو مورد إنشاء المتغيرات.

‍باستخدام هذه المورد، تمكنّا من التسجيل على خادم Octopus Deploy بجميع عناوين IP العامة والخاصة، أسماء المضيفين، وكلمات المرور للمثيلات التي تم إنشاؤها حديثًا. تم استدعاء نفس المتغيرات لاحقًا ضمن العمليات التي تعمل في Octopus Deploy.

نظام التشغيل

جمعنا جميع المتطلبات المسبقة لنظام التشغيل (OS) لتكوين التطبيق باستخدام سكربتات PowerShell. تم جمع المتطلبات التشغيلية لكي يعمل التطبيق على كل حالة. تم اختبار المتطلبات في البداية لتحسين تخصيص الموارد داخل نظام ويندوز.

تم تنفيذ تكوين كل نظام تشغيل باستخدام مقتطفات PowerShell حتى الانتهاء من جميع خطوات التحسين المطلوبة. النتيجة النهائية لهذه الخطوة كانت سكربت PowerShell شامل قام بتعطيل جميع العمليات غير الضرورية (التي لا يحتاجها التطبيق للتشغيل)، وتنظيف البرامج غير المرغوب فيها من بيئة Windows.