كيفية إنشاء سير عمل هجين بين نظامي التشغيل ويندوز ولينكس في البيئات الحديثة

انتقلت العديد من الشركات من امتلاك نظام تشغيل "مهيمن" واحد إلى التعايش مع أنظمة تشغيل أخرى. خوادم ويندوز، وخوادم لينكس، والأجهزة المادية، والحوسبة السحابية العامة، والبيئات المحلية يحتاجون إلى التواصل فيما بينهم دون إحداث أي خلل. لم يعد السؤال هو ما إذا كان العمل الهجين ممكناً، بل كيف يمكن تنظيم سير العمل هذا لجعله آمناً وقابلاً للتكرار وسهل الصيانة.

عند دمج نظامي التشغيل ويندوز ولينكس، بالإضافة إلى بيئات الحوسبة السحابية المتعددة، فأنت بحاجة إلى أكثر من مجرد برامج نصية جيدة. أنت بحاجة إلى استراتيجية واضحة لـ إنشاء سير عمل هجين بين نظامي التشغيل ويندوز ولينكس التي تدمج الأتمتة والتنسيق والأمان والمراقبة باستخدام المكونات المناسبة: Azure Automation و Hybrid Runbook Worker و Logic Apps في الوضع الهجين و Ansible و AWS Systems Manager وأدوات سطح المكتب مثل WinApps وطبقة التطوير والتعاون الحديثة بالكامل في Microsoft 365 و Windows.

لماذا لم تعد سير العمل الهجينة بين نظامي التشغيل ويندوز ولينكس اختيارية؟

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

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

في هذا السياق، تبرز عدة عناصر أساسية: أتمتة Azure مع عامل التشغيل الهجين Runbook لإضفاء الأتمتة على شبكتك، تطبيقات المنطق في الوضع الهجين لدمج الأنظمة الموزعةAnsible كلغة مشتركة بين Linux و Windows، و AWS Systems Manager للعقد الهجينة، وأدوات مثل WinApps التي تسمح لك باستخدام تطبيقات Windows من أجهزة سطح المكتب التي تعمل بنظام Linux بسلاسة.

التشغيل الآلي الهجين باستخدام Azure Automation و Hybrid Runbook Worker

الركيزة الأولى لإنشاء سير العمل الهجين هي قم بنقل دفاتر تشغيل Azure Automation إلى خوادم Windows وLinux المحلية أو بيئات السحابة الأخرى.وهنا يأتي دور ميزة عامل التشغيل الهجين، والتي تسمح بتشغيل دفاتر التشغيل مباشرة على الأجهزة التي تستضيف هذا الدور.

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

الإضافات مقابل الوكيل الكلاسيكي: طريقتان لتثبيت عامل دفتر التشغيل الهجين

يمكنك اليوم نشر دور مستخدم عامل التشغيل الهجين (Hybrid Runbook Worker) عن طريق منصتان تثبيت متميزتان: تعتمدان على الإضافات وتعتمدان على الوكلاءبعد التثبيت، يكون سلوك تنفيذ دفتر التشغيل هو نفسه، لكن نهج الإضافات يبسط بشكل جذري عملية الإعداد والصيانة.

يعتمد الخيار الكلاسيكي على وكيل تحليلات السجلاتوقد نتج عن ذلك عملية أطول وأكثر عرضة للأخطاء. يتكامل النموذج القائم على الإضافات بشكل أصلي مع إطار عمل إضافات الأجهزة الظاهرية Azure، باستخدام وكيل Azure VM للأجهزة الظاهرية Azure ووكيل Azure Connected Machine للأجهزة غير التابعة لـ Azure، بما في ذلك خوادم Azure Arc وخوادم VMware vSphere لـ Arc.

يمكن لكلا نوعي عامل دفتر التشغيل الهجين العيش في نفس الآلةولا يتعارض التثبيت القائم على الإضافات مع النسخ التي قمت بنشرها بالفعل باستخدام الوكيل التقليدي، مما يسهل عمليات الترحيل التدريجية السلسة.

المزايا الرئيسية للنهج القائم على التمديد

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

• عملية انضمام أكثر سلاسةلم تعد تعتمد على وكيل تحليلات السجلات لتسجيل العمال، مما يجنبك العمليات متعددة الخطوات والأخطاء الشائعة في عمليات التثبيت اليدوية.
• الإدارة المركزية قابلة للتوسع بالفعلالتكامل المباشر مع هوية Azure Resource Manager (ARM)، مما يتيح إدارة النشر على نطاق واسع باستخدام السياسات، قوالب ARM، Bicep، PowerShell أو CLI.
• المصادقة باستخدام معرف تسجيل الدخول من Microsoftيتم الاستفادة من الهويات المُدارة المُخصصة من قِبل النظام على الأجهزة الافتراضية، بحيث تتم إدارة بيانات الاعتماد بطريقة موحدة وبدون تخزينها كنص عادي في البرامج النصية أو الإعدادات.
• نفس النموذج لـ Azure و Azure Arcتتم إدارة كل من الأجهزة داخل Azure والخوادم الفعلية أو الأجهزة الافتراضية لدى موفري الخدمات الآخرين (عبر Azure Arc). بنفس التجربةهذا يبسط بشكل كبير بيئات الحوسبة السحابية الهجينة والمتعددة.
• طرق متعددة للانضماميمكن تثبيت الدور من بوابة Azure، أو PowerShell، أو Bicep، أو قوالب ARM، أو Azure REST أو CLI، أو مباشرةً من علامة تبويب ملحقات لكل جهاز افتراضي أو خادم مُفعّل بتقنية Arc.
• مراجعة تحديثات الإصدارات الفرعيةبشكل افتراضي، يتم تحديث العمال المستندين إلى الإضافات تلقائيًا إلى الإصدارات الفرعية الجديدة، مما يقلل من عبء الصيانة اللازم للبقاء على اطلاع دائم. إصلاحات وتحسينات أمنيةلكن الإصدارات الرئيسية لا تزال تتطلب تحديثات يدوية.

حدود وتنظيم عمال دليل التشغيل الهجين

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

ينتمي كل مستخدم في برنامج التشغيل الهجين إلى مجموعة مجموعة من العمال التي تحددها عند تثبيته. يمكن لمجموعة استضافة مثيل واحد أو عدة مثيلات لضمان التوافر العالي. يمكن لجهاز واحد فقط إرسال إشارات نبض القلب إلى حساب أتمتةأي أنه لا يمكنك التسجيل كعامل في حسابات متعددة في نفس الوقت.

تم تصميم المجموعات لتقديم التوافر العالي وموازنة الأحمال من خلال توزيع المهام بين أعضائها. يستخدم العمال آلية استطلاع: يستعلم كل عامل نشط عن الخدمة كل 30 ثانية، ويمكنه الحصول على ما يصل إلى 4 مهام في كل "استعلام". إذا تجاوز معدل وصول المهام القدرة الإجمالية للعمال، فقد يتم تعليق بعضهم بسبب خطأ.

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

الإمكانيات وحدود التنفيذ في عامل التشغيل الهجين

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

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

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

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

سيناريوهات نموذجية مع عامل التشغيل الهجين

تجمع حالات الاستخدام الأكثر شيوعًا لـ Hybrid Runbook Worker بين موارد Windows وLinux داخل وخارج Azure، مما يخلق سير عمل هجينًا حقيقيًا:

• إدارة أجهزة الضيوف: تشغيل دفاتر التشغيل مباشرة على الأجهزة الظاهرية Azure أو على الخوادم خارج Azure المسجلة في Azure Arc (بما في ذلك VMware الممكّن لـ Arc)، سواء كانت تعمل بنظام Windows أو Linux.
• التغلب على قيود بيئة الاختباربالنسبة للعمليات التي تتجاوز حد العمل السحابي لمدة ثلاث ساعات، أو تستهلك موارد كثيرة، أو تتطلب صلاحيات مرتفعة، يوفر العاملون الهجينون بيئة أكثر مرونة وبدون تلك القيود.
• متطلبات السيادة والأمنفي المؤسسات التي لا يُسمح فيها بمعالجة بيانات معينة في السحابة، يمكنك الاحتفاظ بها في تحويل الآلات المحلية إلى عمال هجينين وبالتالي الامتثال للوائح الداخلية والخارجية.
• الأتمتة في بيئات الحوسبة السحابية المتعددة والبيئات المحليةما عليك سوى إضافة جهاز مثل Worker لتشغيل الأتمتة على أجهزة أخرى على الشبكة المحلية أو السحابات المختلفة، سواء كانت تعمل بنظامي التشغيل Windows أو Linux.
• الوصول الخاص إلى الخدمات من الشبكات الافتراضيةتشغيل دفاتر التشغيل على خوادم متصلة بشبكة Azure الظاهرية، مع الوصول إلى الخدمات الأخرى بشكل خاص. دون الحاجة إلى فتح اتصالات الإنترنت.

لنشر نسخة عامل تشغيل هجينة على نظامي التشغيل ويندوز أو لينكس باستخدام أسلوب الإضافات الجديد، ما عليك سوى اتباع الدليل الموجود في التنفيذ باستخدام الإضافات في Azure Automation، والذي يشرح بالتفصيل استخدام ملحقات الأجهزة الافتراضية وAzure Arc للخوادم.

تخطيط الشبكة وعلامات الخدمة لعامل دفتر التشغيل الهجين

قبل فتح المنافذ بشكل عشوائي، من المستحسن التحقق من تكوين شبكة Azure Automation، حيث يحدد المنافذ وعناوين URL والمتطلبات الأخرى اللازمة لكي يتواصل العمال بشكل صحيح مع الخدمة.

يدعم Azure Automation تسميات خدمة الشبكة الافتراضيةبدءًا من علامة GuestAndHybridManagement. بدلاً من سرد نطاقات IP محددة في قواعد NSG أو Azure Firewall، يمكنك استخدام هذه العلامة مباشرةً في مصدر أو وجهة القواعد للسماح أو منع حركة المرور إلى خدمة التشغيل الآلي.

يشمل وسم GuestAndHybridManagement عناوين IP المستخدمة، على سبيل المثال، لـ إطلاق روابط الويب من داخل شبكة افتراضية أو السماح لوكلاء Hybrid Runbook Worker وState Configuration بالتواصل مع Azure Automation. لا يسمح هذا بفرض قيود جغرافية، ولكنه يُبسط إدارة أمان الشبكة بشكل كبير.

دعم حمولات IL5 في Azure Government

إذا كنت تعمل بمتطلبات أمنية عالية للغاية، فإن خدمة Azure Automation تدعم ذلك. أحمال العمل ذات التأثير من المستوى 5 (IL5) في Azure Government استخدام عامل التشغيل الهجين في تكوينين:

• الآلات الافتراضية المعزولة التي تستهلك مضيفًا ماديًا كاملًا، مما يوفر مستوى العزل المطلوب بواسطة IL5.
• مضيف Azure المخصصحيث يتم تشغيل جهاز افتراضي واحد أو أكثر على خوادم فعلية مخصصة لاشتراكك، مما يضمن عزلًا على مستوى الأجهزة.

تطبيقات Azure Logic Apps (القياسية) في الوضع المختلط لتدفقات Windows-Linux

يُعد نموذج [اسم النموذج] عنصرًا أساسيًا آخر لإنشاء سير عمل هجين بين نظامي التشغيل ويندوز ولينكس. تطبيق هجين لتطبيقات Azure Logic Apps (القياسية)يتيح لك هذا الخيار إنشاء واستضافة حلول التكامل في بيئات متصلة جزئيًا تتطلب معالجة وتخزينًا محليًا بالإضافة إلى الوصول إلى شبكة داخلية.

في هذا النموذج، يتم استضافة وقت تشغيل Logic Apps في بنيتك التحتية كجزء من ملحق تطبيقات حاويات Azure، يمكن أن تتواجد على الأنظمة المحلية أو السحابات الخاصة أو السحابات العامة، وتتصل بخوادم Windows وLinux أو خدمات SaaS.

القيود الحالية للنموذج الهجين لتطبيقات المنطق

عند العمل في الوضع الهجين مع Logic Apps Standard، يجب مراعاة بعض القيود:

• إنه متاح فقط في مناطق معينة من Azure (وسط وشرق الولايات المتحدة، شرق آسيا، جنوب شرق آسيا، وسط السويد، جنوب المملكة المتحدة، أوروبا الغربية، غرب الولايات المتحدة، من بين أمور أخرى مدرجة في الوثائق الرسمية).
• في وضع الاتصال الجزئي، قد يظل وقت التشغيل يمكن فصل الاتصال لمدة تصل إلى 24 ساعة مع الاحتفاظ بسجلات البياناتبعد تلك الفترة، قد تُفقد السجلات.
• لا تدعم النسخة الهجينة العديد من ميزات Logic Apps Standard أحادية المستأجر، مثل: فتحات التنفيذ، تتبع عمليات الأعمال، صحة الموارد في البوابة أو المصادقة باستخدام الهويات المُدارة لعمليات موصل معينة في مجموعات Kubernetes المُمكّنة بواسطة Azure Arc.
• بعض المحفزات القائمة على الوظائف (مثل Blob أو Cosmos DB أو Event Hubsيتطلب ذلك تكوين سلسلة اتصال حساب التخزين في متغير التطبيق AzureWebJobsStorageإما في بوابة Azure أو في ملف local.settings.json الخاص بمشروع Logic Apps في VS Code.

المتطلبات الأساسية للتنفيذ الهجين

لإعداد سير عمل هجين باستخدام Logic Apps Standard، ستحتاج، بالإضافة إلى اشتراك Azure، إلى سلسلة من الموارد المحلية على نفس الشبكة:

• Un مجموعة خدمات Azure Kubernetes متصلة بـ Azure Arc، والتي ستعمل كمنصة تنفيذ لحاويات تطبيقات المنطق.
• ل قاعدة بيانات SQL محلية لتخزين سجل التنفيذ والمدخلات والمخرجات الخاصة بسير العمل.
• Un مشاركة الملفات عبر بروتوكول SMB لتخزين العناصر المستخدمة في التدفقات.

لتطوير ونشر هذه العمليات، من الشائع استخدام Visual Studio Code مع ملحق Azure Logic Apps (قياسي)مما يسهل التحرير والاختبار والنشر على البيئة الهجينة التي قمت بإعدادها.

التحكم في الإصدارات، والقياس عن بُعد، والتوسع في تطبيقات Logic Apps الهجينة

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

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

أما فيما يتعلق بالموارد، فيمكنك تعديلها من خلال بوابة Azure. الذاكرة ووحدة المعالجة المركزية الافتراضية يتم تخصيصها لحاوية تطبيق المنطق القياسي. يُسمح بتغيير عدد أنوية وحدة المعالجة المركزية (على سبيل المثال، من 0,25 إلى 2 وحدة معالجة مركزية افتراضية) والذاكرة (على سبيل المثال، من 0,1 إلى 4 جيجابايت)، مما يؤثر بشكل مباشر على كل من أداء التدفق والفواتير.

يمكنك أيضًا تحديد مقياس النسخ يتم إنشاء هذا النظام استجابةً لأحداث التشغيل. يتم تحديد الحد الأدنى والحد الأقصى لعدد النسخ المتماثلة (حتى 1000 نسخة)، كما تتم إدارة قواعد التوسع الأكثر تقدمًا من خلال تطبيقات حاويات Azure، مما يسمح بالتكيف الديناميكي مع ذروات التحميل في تدفقات التكامل التي تؤثر على أنظمة Windows وLinux.

الإدخال والمصادقة والأسرار في البيئات الهجينة

يمكن عرض Logic Apps Standard على الويب العام، أو شبكة افتراضية، أو تطبيقات Logic الأخرى من نفس البيئة من خلال تكوين خيار الدخول، تتولى Azure تطبيق قواعد توجيه حركة مرور HTTP أو TCP الواردة دون الحاجة إلى توفير موازنات تحميل إضافية أو عناوين IP عامة يدويًا.

في مجموعات Kubernetes المُفعّلة بتقنية Azure Arc، لا يمكن استخدام الهويات المُدارة بشكل أصلي في مصادقة اتصال واجهة برمجة التطبيقات المُدارة. بدلاً من ذلك، يجب عليك إنشاء تسجيل تطبيق مايكروسوفت، أدخل المعرف واستخدمها كأساس للروابط:

• يمكنك إنشاء تطبيق وجمع البيانات من خلال بوابة Azure أو واجهة سطر أوامر Azure. clientId و tenantId و objectId و clientSecret.
• ثم تضيف هذه القيم كما يلي متغيرات البيئة في مورد Logic Apps Standard (على سبيل المثال، WORKFLOWAPP_AAD_CLIENTID، WORKFLOWAPP_AAD_OBJECTID، WORKFLOWAPP_AAD_TENANTID، WORKFLOWAPP_AAD_CLIENTSECRET).
• يمكنك اختيارياً تخزين clientId و clientSecret كـ أسرار المورد نفسه ثم قم بالإشارة إليها من متغيرات البيئة لمزيد من الأمان.

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

المشاكل الشائعة والحلول في تطبيقات المنطق الهجينة

في البيئات الهجينة، قد تظهر مفاجآت في أي وقت. ولتشخيص مشاكل تكوين البيئة أو عمليات النشر الفاشلة من البوابة، تنشر مايكروسوفت دليلًا إرشاديًا. ملف PowerShell النصي troubleshoot.ps1 في مستودع Logic Apps الرسمي الذي يستعرض نقاط الفشل النموذجية.

في مجموعات Kubernetes المتصلة بـ Azure Arc، أنماط استخدام مرتفع للذاكرةفي هذه الحالات، يُنصح بتوسيع نطاق مجموعات العقد أفقيًا أو تمكين قابلية التوسع التلقائي للمجموعة.

إذا لم يبدأ تطبيق Logic App بشكل صحيح، فمن المستحسن التحقق من حالة المورد من بوابة Azure، وإذا كان هناك خطأ، فاسحب من استخدم kubectl للتحقق من الحاوياتتشير رسائل مثل "عدد كبير جدًا من الحاويات" إلى عدم كفاية سعة العقدة، بينما تشير التحذيرات المتعلقة بمطالبات وحدات التخزين الدائمة غير المرتبطة عادةً إلى وجود مشاكل في برنامج تشغيل SMB CSIفي هذه الحالة، يعد تثبيت برنامج تشغيل smb.csi.k8s.io باستخدام Helm الخطوة الضرورية قبل المتابعة.

أتمتة موحدة باستخدام Ansible لأنظمة التشغيل Windows و Linux

بالإضافة إلى نظام Azure البيئي، فإن استخدام نهج قوي للغاية لسير العمل الهجين بين Windows وLinux هو منصة ريد هات للأتمتة Ansible (AAP) كلغة موحدة. يزيل Ansible الفصل التاريخي بين نصوص bash في Linux و PowerShell أو المهام المجدولة في Windows.

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

على سبيل المثال، يمكنك تثبيت Apache على خوادم Red Hat في ملف تشغيل واحد و IIS على أجهزة ويندوزابدأ تشغيل الخدمات وقم بتمكينها عند بدء التشغيل، باستخدام شروط تعتمد على نوع نظام التشغيل. يتضمن التنفيذ بشكل أساسي تشغيل ملف Ansible على قائمة الخوادم التي تجمع بين كلا النوعين.

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

مدير أنظمة AWS في بيئات لينكس-ويندوز الهجينة والمتعددة السحابات

إذا كان جزء من بيئتك الهجينة موجودًا على AWS، فإن مدير الأنظمة هو عنصر آخر يجب مراعاته. تنسيق سير العمل عبر عقد Windows و Linux والتي ليست بالضرورة مثيلات EC2. يكمن المفتاح في وكيل SSM، الذي يمكنك تثبيته على أجهزة Linux وWindows خارج EC2 باستخدام عملية تنشيط هجينة.

أثناء التفعيل، معرّف التفعيل ورمز تُستخدم هذه المعلومات المرتبطة بحساب AWS الخاص بك لتسجيل كل جهاز كعقدة مُدارة. في نظام Linux، يقوم الأمر ssm-setup-cli بتنزيل وتثبيت الوكيل، ثم إيقافه، وتسجيل المثيل؛ ومنذ ذلك الحين، يصبح عقدة مُدارة، بمعرف يبدأ عادةً بـ "my-" لتمييزه عن مثيلات EC2.

بمجرد دمجها، يمكنك تنفيذ الأوامر عن بُعد، ونشر التحديثات، وتطبيق الإعدادات أو حتى استخدام مدير التغيير والقدرات الأخرى (مع الأخذ في الاعتبار أن بعضها، مثل لوحة معلومات CloudWatch لمدير الأنظمة، قد أعلنت عن تواريخ إيقافها).

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

إذا كنت بحاجة إلى إلغاء تسجيل عقدة Linux وإعادة تسجيلها، فهناك عملية DeregisterManagedInstance في واجهة سطر أوامر AWS، وبعد ذلك يُنصح بتنظيف الإدخالات مثل ترتيب استهلاك الهوية قم بتشغيل خيار -register -clear الخاص بالوكيل وفقًا لنوع التثبيت في ملف amazon-ssm-agent.json.

فيما يتعلق بالمشاكل النموذجية، فإن البرامج مثل انتهت مهلة التسليم قد يكون هذا السلوك متوقعًا عند تغيير مُعرّف الجهاز أثناء تثبيت برنامج عبر حسابات متعددة. تشير رسائل الخطأ المتعلقة بـ `FingerprintDoesNotMatch` إلى مُعرّفات أجهزة لا تُحفظ بعد إعادة التشغيل، ويمكن حل هذه المشكلة بفرض إنشاء مُعرّفات الأجهزة وحفظها في نظام لينكس.

تطبيقات ويندوز مدمجة في أجهزة سطح المكتب التي تعمل بنظام لينكس باستخدام WinApps

لا يقتصر الأمر على عمليات الواجهة الخلفية فقط: فالعديد من سير العمل الهجين بين ويندوز ولينكس يؤثر بشكل مباشر على تجربة المستخدم. WinApps هي أداة مفتوحة المصدر تسمح تشغيل تطبيقات ويندوز الأصلية من أجهزة سطح المكتب التي تعمل بنظام جنو/لينكس (KDE، GNOME، XFCE) كما لو كانت تطبيقات محلية.

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

أبسط طريقة لنشر تطبيقات ويندوز هي من خلال عامل في حوض السفنباستخدام الصورة المتاحة للجمهور، والاستفادة من المكون الإضافي WorkflowUIPlugin في ComfyUI عند دمج هذا التكامل مع إنشاء المحتوى أو سير عمل الذكاء الاصطناعي، يمكن للشركات المتخصصة المساعدة في تحديد البنى التي تستهلك فيها أجهزة سطح المكتب التي تعمل بنظام Linux تطبيقات Windows المستضافة في السحابة (AWS، Azure) مع الحفاظ على عناصر التحكم المركزية في الوصول والأمن السيبراني والمراقبة.

العمل الهجين، والتعاون، والتطوير الحديث على Microsoft 365 وWindows

لا توجد عمليات سير العمل الهجينة بين نظامي التشغيل ويندوز ولينكس بمعزل عن المستخدمين؛ بل هي مرتبطة بهم ارتباطًا وثيقًا. كيف يتعاون الفريق، ويتبادل المعلومات، ويطور التطبيقاتأصبح Microsoft 365، وتحديداً Teams، بمثابة "الطبقة التنظيمية" للعديد من الشركات، حيث يعمل ملايين المستخدمين عن بعد وفي الوضع الهجين.

تشير مايكروسوفت إلى العديد من هذه الحلول تطبيقات التعاونتطبيقات تُعطي الأولوية للتعاون المتزامن وغير المتزامن، من خلال الاجتماعات والدردشة والتأليف المشترك للمستندات وأتمتة عمليات الأعمال، وكل ذلك مُدمج في واجهة واحدة. بالنسبة للمطورين، يُتيح هذا فرصة إنشاء تطبيقات تعمل بسلاسة على أنظمة التشغيل Windows و macOS والويب و iOS و Android و Linux.

توفر Teams واجهات برمجة التطبيقات ونقاط التوسعة لـ تطبيقات اجتماعات محسّنة (تكامل المرحلة المشتركة، أحداث بدء/انتهاء الاجتماع، مشاهد مخصصة في وضع المؤتمر، واجهات برمجة تطبيقات الوسائط مع موافقة خاصة بالموارد) ويتكامل مع خدمات اتصالات Azure للسماح لمستخدمي Teams بالتفاعل مع العملاء الخارجيين من خلال تطبيقات الصوت والفيديو والدردشة المخصصة.

علاوة على ذلك، يجري تشجيع التعاون متعدد المنصات مع مكونات السوائل في Teams (جداول وقوائم وكتل قابلة للتعديل في الوقت الفعلي، ويمكن مشاركتها أيضًا مع Outlook وOffice)، بالإضافة إلى ملحقات رسائل قابلة لإعادة الاستخدام في Outlook وTeams. وتُكمّل منصة Power Platform (Power Apps وPower Automate وPower Virtual Agents) هذا النظام البيئي بروبوتات وتدفقات منخفضة التعليمات البرمجية يمكن نشرها على Teams.

لتسهيل حياة المطورين، تقدم مايكروسوفت مجموعة أدوات Teams لـ Visual Studio و VS Codeمع تبسيط المصادقة واستخدام Graph، والتكامل مع Azure Functions وSPFx، وبوابة مطوري Teams حيث يمكنك تسجيل التطبيقات وتكوينها وإدارتها في وحدة تحكم مركزية، بما في ذلك جوانب مثل خطط SaaS وتحليلات الاستخدام.

البيانات والأمان وقابلية التوسع مع Microsoft Graph وأنظمة Windows الحديثة

في الخلفية، تستند العديد من هذه التجارب التعاونية إلى Microsoft Graphمما يتيح الوصول إلى الاتصالات والمحتوى وبيانات الأشخاص مع ضوابط الخصوصية والأمان المدعومة من Azure AD. وتشمل الإمكانيات الجديدة ما يلي: تقييم الوصول المستمر فهي تسمح بإلغاء الرموز المميزة بشكل فوري في مواجهة الأحداث الحرجة، كما توفر طرق المصادقة وواجهات برمجة تطبيقات الهويات الخارجية مزيدًا من التحكم في من يصل إلى ماذا.

بالنسبة لأولئك الذين يحتاجون إلى إدخال البيانات إلى Microsoft 365، موصلات Microsoft Graph تتيح هذه الأدوات فهرسة مصادر خارجية مثل Jira أو Confluence، وإثراء ملفات تعريف المستخدمين، والمشاركة في تجارب مثل بحث Microsoft أو الاكتشاف الإلكتروني. في الوقت نفسه، يُمكّن اتصال بيانات Microsoft Graph من تصدير مجموعات بيانات الإنتاجية إلى Azure لإجراء تحليلات متقدمة أو تدريب نماذج الذكاء الاصطناعي.

في مجال تطبيقات سطح المكتب، مشروع ريونيون (الذي أصبح الآن جزءًا من استراتيجية تحديث تطبيقات ويندوزبفضل WinUI 3 و WebView 2، ودعم .NET 5 وإصدارات Windows 10 من 1809، فإنه يساعد التطبيقات الجديدة والحالية على الاستفادة بشكل أفضل من أجهزة Windows، مع التكامل أيضًا مع الخدمات السحابية.

أدوات مثل نوافذ الطرفية (قابل للتكوين كطرفية افتراضية، مع أوضاع مثل Quake) ونظام Windows الفرعي لنظام Linux مع دعم تطبيقات واجهة المستخدم الرسومية يجعل تطوير وإدارة البيئات الهجينة من Windows أكثر ملاءمة، حيث يمزج بين واجهات سطر الأوامر الكلاسيكية وأصداف Linux والأدوات الرسومية في نفس سير العمل.

الاعتبارات النهائية

من ناحية أخرى، يتميز برنامج Power Automate Desktop بقدرات مثل مستشار العمليات إنهم يقدمون تقنية RPA بدون كتابة أكواد في نظام التشغيل Windows 10، مما يسمح بتحديد نقاط الاختناق والمهام المتكررة التي يمكن أتمتتها بسهولة، وغالبًا ما يكون ذلك بالاشتراك مع أنظمة Linux الخلفية أو الخدمات السحابية.

من خلال الجمع بين كل هذه العناصر - Azure Automation وLogic Apps وAnsible وAWS Systems Manager وWinApps وTeams وGraph والتحسينات في Windows وWSL - يصبح من الممكن بناء سير عمل هجين قوي حقًا بين Windows وLinux، حيث الأتمتة والتكامل والأمن والتعاون إنهم ينسقون جهودهم بحيث يتمكن الناس من التركيز على إضافة قيمة وليس على المعاناة مع الأدوات المنفصلة أو العمليات اليدوية الهشة. انشر المعلومات حتى يتمكن المزيد من الناس من التعرف على الموضوع.