أتمتة خادم Windows (الجزء 2)

أتمتة Windows باستخدام PowerShell وAutoIT

تثبيت التطبيق

في أتمتة Windows الجزء الأول ناقشنا الأتمتة لبيئة السحابة ونظام التشغيل. في هذه المقالة، سنغطي الأتمتة لتثبيت التطبيق.

التطبيق المعني يتواصل مع أطراف خارجية لأغراض التحليل والمراقبة.

إضافة مرة أخرى الرسم البياني من الجزء 1 من المدونة الذي يشرح التدفق والتفاعل بين المكونات المعنية:

أولاً، جمعنا جميع متطلبات البرامج اللازمة لتثبيت التطبيق.

التحدي هنا كان تثبيت وإعداد الخدمات الإضافية المطلوبة لبنية التطبيق بأكملها. تم ذلك عبر Octopus Deploy باستخدام سكريبتات PowerShell وPython التي تفاعلت مع الحالات وقامت بتثبيت وتكوين جميع الخدمات الإضافية.

ثانياً، قمنا بتثبيت التطبيق وفقًا لدور نسخة Windows باستخدام Octopus. بالإضافة إلى ذلك، كان لدينا بعض الإضافات المطلوبة للتطبيق لتتم أتمتتها أيضًا.

لرصد كامل عملية الأتمتة، أنشأنا نقاط تفتيش داخل خادم Octopus Deploy. تم تكوين نقاط التفتيش هذه لإرسال بيانات، تتضمن معلومات حول تقدم العملية، عبر webhook إلى منصة الدردشة لدينا لتقرير الحالة.

تثبيت التطبيق الآلي باستخدام جلسات تفاعلية

الخطوة التالية كانت أتمتة تثبيت التطبيق المطلوب على الحالات المنشورة المختلفة.

هذا واضح ومباشر في الحالات التي يكون فيها تطبيق Windows المطلوب تثبيته بصيغة .msi، حيث تتوفر خاصية تثبيت التطبيق في الخلفية عبر واجهة سطر الأوامر.

ومع ذلك، بالنسبة لتطبيقات .exe التي عادة لا توفر خيار التثبيت في الخلفية بدون واجهة مستخدم، نحتاج إلى استخدام تطبيق طرف ثالث ولغته البرمجية المقابلة، AutoIT (لغة برمجة مجانية طورتها شركة AutoIt Consulting Ltd).

كما هو موضح في المثال أدناه، قمنا بتحديد مكونات مختلفة داخل نافذة واجهة المستخدم للتطبيق أثناء عملية التثبيت عبر معرفات الحالات، وتفاعلنا معها باستخدام AutoIT.

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

مثال على سكريبت AutoIT

مقتطف الكود أعلاه استخدم لتثبيت تطبيق NTP على أحد مضيفي Windows لدينا.

كما هو مبيّن في كتلة الكود، لكل نافذة تثبيت في العملية، كان علينا تحديد عنوان النافذة (الذي عادة ما يكون متشابهًا لكل النوافذ الخاصة بالواجهات أثناء التثبيت) والعنوان الفرعي أيضًا.

السبب في تحديد تفاصيل كل نافذة بدقة هو توفير توجيهات محددة لعملية الأتمتة للانتظار (باستخدام winwaitactive) حتى تصبح النافذة المناسبة متاحة. بمجرد أن أصبحت النافذة متاحة، كانت الخطوة التالية تحديد عناصر تلك النافذة التي نحتاج للتفاعل معها.

باستخدام الأمر ControlCommand، نوفر المعلومات الخاصة بالمربع الصحيح، ونحدد الإجراء الذي يجب تنفيذه على ذلك الزر.

كما هو موضح أعلاه، "[CLASS:Button; INSTANCE:2]","Check"، هو الأمر لتحديد الزر الذي معرف الحالة الخاص به يساوي 2.
بعد إتمام معالج التثبيت بنجاح، تمكنا من تثبيت NTP وجميع تطبيقات Windows الضرورية على أجهزة Windows لدينا دون أي تدخل بشري.

المعلمات الديناميكية

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

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

كما في المثال أعلاه، يمكنك إضافة بعض المعلمات الإضافية ليكون لدى المستخدم هذه المعلمات مُعبأة في واجهة سطر الأوامر عند تنفيذ السكريبت دون فقد أي معلمة. يتم الإعلان عن هذه المعلمات الإضافية داخل جملة if المناسبة داخل الدالة كما يلي:

لكي تعمل المعلمات الإضافية بشكل صحيح، نحتاج إلى إعلان $parameterAttribute و$attributeCollection و$paramDictionary.
بالنسبة لمتغير $parameterAttribute، فإنه يحمل الصفات المحددة للمعلمات الجديدة. لذا، إذا كانت هناك صفات مختلفة للمعلمات الجديدة، نحتاج إلى إعلان أكثر من صفة واحدة. على سبيل المثال:

في هذا المثال، تعرض الصفة الأولى شيئان: ParameterSetName ومفتاح Mandatory (صحيح أو خطأ). في هذه الحالة، كان لدينا معلمة جديدة لم تكن ضمن ParameterSetName، ولم تكن Mandatory، ولهذا أضفنا $parameterAttribute1. بعد ذلك، كان علينا إنشاء مجموعة صفات لإضافتها إلى المعلمات وأخيرًا لإنشاء وإرجاع ما نسميه قاموس المعلمات. وفقًا لمثال الصفة، بما أننا كان لدينا صفتان مختلفتان، احتجنا إلى مجموعتين، كما هو موضح أدناه:

بعد ذلك أعلنا القاموس نفسه، أضفنا كل معلمة، وعيننا المجموعة الصحيحة.

في هذه الحالة، ستكون $dynParam1 ضرورية مع اسم مجموعة المعلمات “Network”، بينما $dynParam2 لن تكون لها أي قيود ويمكن تخطيها. أخيرًا، لإرجاع المعلمات الجديدة، نحتاج إلى إضافتها إلى القاموس. للقيام بذلك، نضيفها فقط كما يلي:

علاوة على ذلك، نستورد إعدادات مخصصة محددة باستخدام ملفات JSON الديناميكية المطورة ضمن PowerShell. لعمل ذلك، تم استخدام دالة ضمن السكريبت التي بنت تكوين JSON حسب المعلمات.

تم ذلك أساسًا بدمج الأجزاء المتغيرة من تكوين JSON حسب نوع الخادم، وتغيير IP، وما إلى ذلك.

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

لتجاوز ذلك، يتم تصدير التكوين قبل تشغيل سكريبت إنشاء JSON وداخل السكريبت، نستخدم Get-Content للملف مع تاريخ التعديل الأخير داخل مسار التصدير، ونضع هذه البيانات في متغير للتعامل معها كما لو كانت حمولة JSON من API.

من السطر الأخير في السكريبت، قمنا بتصفية ملف JSON باستخدام المعلمات $type و$serverid المعطاة من المستخدم للحصول على تفاصيل الخادم الصحيحة، ومن ثم استدعائها لاحقًا بالطريقة التالية حسب المعلومات التي يحتويها ملف JSON.

تابعوا منشورنا التالي في المدونة، الذي يناقش التنفيذ غير المعتمد على السحابة باستخدام Terraform وPowerShell.

المراجع

• توثيق AutoIT
• معلمات PowerShell المتقدمة/الديناميكية

أنظمة تشغيل Windows