جنو نانو GNU Nano هو محرر نصوص لأنظمة التشغيل التي تشبه نظام التشغيل يونكس أو بيئات التشغيل التي تستخدم سطر الأوامر كواجهة للإدخال، طُرح لأول مرة عام 1999 بواسطة Chris Allegretta وهو يحاكي محرر النصوص بيكو Pico.

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

اختصارات لوحة المفاتيح الشائعة لمحرر النصوص نانو Nano

عند العمل مع أي أداة من أدوات سطر الأوامر، فلا بد من معرفة معظم اختصارات الأوامر، لأن ذلك يسرع من تنفيذ تلك الأوامر، وبالتالي سنبدأ بمعرفة أهم الاختصارات لمحرر النصوص نانو Nano من خلال القائمة التالية:

البداية مع محرر النصوص نانو Nano

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

1. التعرف على الواجهة

سيظهر لنا الخرج التالي عند فتح محرر النصوص نانو Nano عن طريق فتح نافذة الطرفية وكتابة الأمر nano فيها كما في الشكل:

تظهر الاختصارات المهمة لمحرر النصوص نانو Nano في أسفل الشاشة عند تشغيل محرر النصوص نانو nano، سواءً كان ذلك مع تحميل ملف أو بدون تحميل للرجوع اليها بسرعة ولسهولة استخدامها.

يستخدم محرر النصوص نانو nano رمزين مرتبطين لكل اختصار، وذلك بخلاف محررات واجهة المستخدم الرسومية GUI والتي تعرض الرمز مباشرةً كما يلي:

• الرمز ^ وهو الرمز الأساسي الذي يشير إلى المفتاح CTRL
• الرمز M والمعروف باسم مفتاح الوصف meta key ويشير إلى المفتاح ALT

وبالتالي إذا أردنا استخدام الاختصار G^ فلا بد من الضغط على CTRL+G؛ أما عندما نريد استخدام الاختصار M-A، فسيتوجب علينا الضغط على ALT+A.

2. فتح أو إنشاء الملفات باستخدام محرر النصوص نانو Nano

لفتح ملف باستخدام محرر النصوص نانو nano، كل ما علينا فعله هو كتابة الأمر nano ثم إتباعه باسم الملف `nano .

على سبيل المثال إذا أردنا فتح الملف mylogs.log بمحرر النصوص نانو nano، فيكفي كتابة الأمر التالي:

nano mylogs.log

أما إذا كان الملف غير موجود وأردنا إنشاء ملف جديد باستخدام محرر النصوص نانو nano والكتابة فيه، فيجب علينا كتابة اسم الملف غير الموجود بعد الأمر nano، وسيفتح لنا ملف فارغ يمكننا إجراء التغييرات التي نريدها فيه <nano  <NewFile. على سبيل المثال، يمكننا إنشاء ملف جديد باسم unknown.txt وكتابة بعض الأسطر فيه ثم نحفظ التغييرات كما يلي:

nano <NewFile>

من ناحية أخرى، إذا لم نرد إضافة اسم للملف في البداية، معناها يمكننا إنشاء ملف فارغ بدون اسم عن طريق تنفيذ الأمر nano في محرر النصوص nano، ومن ثم كتابة الأسطر التي نريد فيه؛ وعندما نرغب في إغلاق الملف، سيطلب منا المحرر إدخال اسم للملف.

على سبيل المثال، سنكتب رسالة تهنئة في محرر النصوص نانو nano ثم نحفظ الملف باسم Hello.txt كما في الشكل:

3. التنقل ضمن الملف

يمكن التنقل ضمن محرر النصوص نانو Nano عن طريق مفاتيح الأسهم على عكس محررات النصوص المتقدمة مثل محرر النصوص فيم Vim، وفيما يلي بعض النصائح والملاحظات من أجل التنقل ضمن الملف بسرعة أكبر:

• الضغط \ + ALT للذهاب إلى بداية الملف
• الضغط / + ALT للذهاب إلى نهاية الملف

يمكن أيضًا القفز إلى سطر محدد من خلال الضغط على _ + CTRL وإدخال رقم السطر الذي نريد كما في الشكل:

4. عمليات القص والنسخ واللصق في محرر النصوص نانو Nano

يمكن في حال استخدامنا لبيئة سطح المكتب اختيار النص باستخدام الفأرة والضغط على Ctrl + Shift + C لنسخ النص المحدد ومن ثم لصقه باستخدام Ctrl + Shift + V.

ولكن ما الحل إذا كنا لا نملك واجهة مستخدم رسومية GUI أو كنا نريد قص النص؟ بإمكاننا هنا ببساطة قص أو نسخ النص ولصقه في محرر النصوص نانو nano واستخدام الاختصارات، ولكن ذلك بعد تحديد النص المطلوب.

من أجل تحديد النص، سنستخدم مفاتيح التنقل للوصول إلى نقطة البداية التي نريد تحديد النص منها، ثم نضغط على الاختصار Alt + A لوضع علامة التحديد، ومن ثمة نستخدم مفاتيح التنقل لتحديد النص الذي نريد قصه أو نسخه كما هو موضح بالشكل التالي:

نستطيع بعد تحديد النص القيام بأحد الأمرين:

• الضغط Alt + 6 لنسخ النص المحدد
• الضغط Ctrl + K لقص النص المحدد
• وبعد قص أو نسخ النص، نضغط Ctrl + U للصق النص.

يمكننا على سبيل المثال لصق النص المنسوخ في نهاية الملف كما في الشكل:

5. حذف أسطر في محرر النصوص نانو Nano

لا يوجد خيار محدد لحذف النصوص أو الأسطر في محرر النصوص نانو Nano للأسف، ولكن يمكننا استخدام الطرق التالية للحصول على نفس النتيجة في المحرر:

1. استخدام زر التراجع backspace عدة مرات لحذف النصوص أو الأسطر
2. استخدام قص الأسطر بالضغط على الاختصار Ctrl + K

تُعَد عملية قص الأسطر هي الخيار الأفضل لحذف النص أو الأسطر، وذلك لأن عملية اللصق لا تحدث كثيرًا، وهي الطريقة الأكثر فعالية لحذف النصوص.

يمكننا تحديد عدة أسطر أو كلمات لقصها من أجل التخلص منها (حذفها) من خلال استخدام مفاتيح الأسهم كما يلي:

1. الانتقال باستخدام مفاتيح الأسهم إلى النقطة التي تريد حذف الأسطر ابتداءً منها
2. الضغط على الاختصار Alt + A لوضع العلامة
3. الضغط على الاختصار / + ALT للإنتقال إلى نهاية الملف
4. الضغط على الاختصار Ctrl + K لقص النص المحدد

6. التراجع والإعادة

تشير عملية التراجع Undo إلى العدول عن آخر عملية قام بها المستخدم، بينما تشير عملية الإعادة Redo إلى تكرار آخر عملية تم التراجع عنها.

يمكننا استخدام الاختصارات التالية للقيام بعملية التراجع أو الإعادة في محرر النصوص نانو Nano:

• للتراجع عن آخر عملية، نستخدم الاختصار Alt + U
• لتكرار أو إعادة آخر عملية تم التراجع عنها، نستخدم الاختصار Alt + E

سنحذف في المثال التالي سطرًا معينًا من الملف ثم نتراجع عن عملية الحذف، ثم نعيد عملية الحذف مرةً أخرى كما يلي:

7. البحث والاستبدال

تتم عملية البحث والاستبدال في محرر النصوص نانو Nano باستخدام ثلاث خطوات بسيطة جدًا وهي:

1. الضغط Ctrl + R ثم كتابة الكلمة أو المصطلح الذي نريد البحث عنه ثم نضغط Enter
2. ندخل الكلمة الجديدة المراد الاستبدال بها
3. ستظهر الكلمات المطابقة واحدةً تلو الأخرى وسيسألنا إذا كنا نريد استبدالها أم لا، وللقيام بعمليات الاستبدال دفعةً واحدة، سنضغط على الرمز A.

سنستبدل في المثال التالي الكلمة quick بالكلمة lazy كما في الشكل:

8. الحفظ والخروج من محرر النصوص نانو Nano

تتم عملية الحفظ والخروج من محرر النصوص نانو Nano بطريقة سهلة للغاية وعن طريق خطوتين فقط هما:

1. الضغط على الاختصار Ctrl + O لحفظ التغييرات
2. الضغط على الاختصار Ctrl + X للخروج من محرر النصوص

ملاحظة: يمكن الخروج من محرر النصوص نانو Nano بدون حفظ التغييرات، وذلك بالضغط مباشرةً على الاختصار Ctrl + X، ومن ثم الضغط على المفتاح N.

عند الضغط على الاختصار Ctrl + O لحفظ التغييرات، سيسألنا المحرر عما إذا كنا نريد حفظ تلك التغييرات باسم الملف نفسه أو باسم ملف مختلف، لذا يمكن انتقاء أحد الخيارين ثم الضغط المفتاح Enter لحفظ التغييرات.

هناك ميزة أخرى رائعة في محرر النصوص نانو Nano، وهي الطريقة التي يخبرنا بها بالتغييرات التي لم تُحفظ بعد، حيث ستظهر علامة النجمة * بجانب اسم الملف كما في الشكل:

بعد الانتهاء من ذلك، سنضغط على الاختصار Ctrl + X للخروج من محرر النصوص نانو Nano.

إذا رغبنا في الخروج من محرر النصوص نانو nano بدون حفظ التغييرات، سنتبع الخطوات البسيطة التالية:

1. الضغط على الاختصار Ctrl + X
2. الضغط على الاختصار N للخروج من محرر النصوص نانو Nano بدون حفظ التغييرات

9. طريقة الحصول على المساعدة من محرر النصوص نانو Nano

تُعَد عملية المساعدة في محرر النصوص نانو nano مفيدةً جدًا في الأوقات الصعبة التي لا تعرف فيها ماذا تفعل، وكل ما علينا القيام به هو الضغط على الاختصار Ctrl + G وسيحضر لنا قائمةً بجميع الاختصارات المتوفرة في محرر النصوص نانو nano مع وصف بسيط لها كما في الشكل:

الخلاصة

بهذا نكون قد تعرفنا على الأوامر الأساسية لمحرر النصوص نانو Nano. نتمنى لكم الاستفادة الجيدة من هذا المقال، وفي حال كان لديكم أي تساؤل يمكن تركه في قسم التعليقات أسفل المقال أو كتابته في قسم الأسئلة والأجوبة في الأكاديمية.

ترجمة وبتصرف للمقال Nano Editor Basic Commands لكاتبه Sagar Sharma.

اقرأ أيضًا

• مقارنة بين محرر النصوص فيم Vim ونانو Nano
• معالجة النصوص على RedHat Enterprise Linux: تحريرها بـ Nano و Vim والبحث فيها بـ grep
• تعرف على محرر النصوص فيم Vim

أصبح اعتماد منهجية DevOps هو الحل البديهي لتحسين البرامج البطيئة وغير الناجحة وأتمتة المهام اليدوية. ولذلك، سنشرح في هذا المقال ما هي منهجية عمل إنتاج البرمجيات في DevOps أو ما يُعرف بمصطلح DevOps pipeline وما هي خطوات إنشائها.

مقدمة عن منهجية DevOps وخطوط التكامل والتسليم المستمر CI/CD

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

هناك بعض الأدوات الضرورية لتحقيق بيئة DevOps، لكن المفتاح الرئيسي هو إنشاء منهجية عمل Pipeline يُطبّق فيها التكامل المستمر والنشر المستمر CI/CD، بحيث تحتوي على مراحل مختلفة مثل مرحلة التطوير DEV، والتكامل INT، والاختبار TST، والتحقق من الجودة QA، واختبار قبول المستخدم UAT، والتحضير STG، والانتاج PROD؛ وتؤتمت فيها المهام اليدوية، لكي يستطيع المطورون العمل بمرونة وكتابة شيفرة عالية الجودة، والنشر مرات عديدة.

يقدّم هذا المقال طريقةً مكونةً من خمس خطوات لإنشاء منهجية عمل لإنتاج البرمجيات بأسلوب DevOps باستخدام أدوات مفتوحة المصدر، مثل ماهو موضح في الصورة التالية:

1. استخدام اُطر عمل التكامل والنشر المستمر CI/CD

أول ما نحتاج إليه هو إحدى أدوات التكامل والنشر المستمر CI/CD، ويُنصح لهذا الغرض باستخدام أداة جنكينز Jenkins، وهي أداة مفتوحة المصدر ومبنية على لغة جافا Java وترخيص MIT، وهي ما ساهم في نشر منهجية DevOps لتصبح المعيار الأساسي.

ولتبسيط الأمر، يمكننا تخيل أن أداة Jenkins هي جهاز تحكم عن بعد يمكنه التخاطب مع خدمات وأدوات عدة المختلفة وإدارتها، وهي عديمة النفع بمفردها، ولكنها تصير أكثر قوةً عند استخدامها مع أدوات وخدمات مختلفة. وهي واحدة من العديد من أدوات CI/CD مفتوحة المصدر التي يمكن الاستفادة منها لإنشاء منهجية عمل DevOps.

فيما يلي بعض الأدوات الأخرى:

توضح الصورة التالية سير عمليات DevOps باستخدام أدوات التكامل والنشر المستمر CI/CD:

وبهذا تكون قد أصبحت لدينا أداة CI/CD قيد التشغيل في مضيفنا المحلي، ولكن لا يمكن الاستفادة منها في شيء الآن. سنتابع شرح باقي الخطوات كي نتعلم كيفية استخدام الأدوات لبناء منهجية عمل DevOps.

2. إدارة الشيفرة المصدرية Source Code Management

إن أفضل وأسهل طريقة للتأكد من أن أدوات CI/CD تعمل جيدًا هي استخدامها مع إحدى أدوات إدارة الشفرة المصدرية Source Code Management أو اختصارًا: SCM، وذلك لأن الشيفرة التي نكتبها عند تطوير تطبيق ما باستخدام إحدى لغات البرمجة مثل لغة جافا Java أو بايثون Python أو C++‎ أو لغة جو Go، أو جافاسكربت Javascript، أو غيرها، يطلق عليها اسم الشيفرة المصدرية Source Code.

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

هنا علينا استخدام أدوات إدارة الشيفرة المصدرية SCM التي تساعد في تخزين الشيفرة في مستودعات، والتحكم في إصدار الشيفرة، والتنسيق بين أعضاء المشروع.

ثمة أدوات عدة لإدارة الشيفرة المصدرية، لكن غيت Git أفضلها، وفيما يلي ذكر لأدوات أخرى مفتوحة المصدر:

توضح الصورة الآتية كيف تبدو منهجية عمل DevOps عند استخدام إحدى أدوات إدارة الشيفرة المصدرية SCM:

وكما هو واضح، يمكن لأداة التكامل والنشر المستمر CI/CD أتمتة التعديلات على الشيفرة المصدرية وتسهيل التعاون بين أعضاء الفريق. وسنتعرف في باقي الخطوات على كيفية الاستفادة من ذلك في تطبيق عملي حتى يتمكن العديد من الناس من استخدامه.

3. إنشاء أداة لأتمتة عمليات بناء الشيفرة

يمكن الآن الإطلاع على تعديلات الشيفرة وإضافة تعديلاتنا، كما يمكن التعاون مع مطورين آخرين في كتابة الشيفرة. للتأكيد، يجب علينا تجميع التطبيق قبل ذلك ووضعه في تنسيق حزمة قابلة للنشر أو تشغيله كملف قابل للتنفيذ Executable لجعله تطبيق ويب. يمكننا ملاحظة أن لغات البرمجة المُفسَّرة مثل جافاسكربت JavaScript أو PHP لا تحتاج إلى تجميع Compilation، وهنا علينا استخدام إحدى أدوات أتمتة عمليات بناء البرامج Build Automation Tool، والتي تهدف إلى إنشاء شيفرة مصدرية بتنسيق معين، وأتمتة عمليات تنظيف الشيفرة وتجميعها واختبارها ونشرها في موقع معين.

تختلف أدوات البناء وفقًا للغة البرمجة، وفيما يلي بعض الأدوات الشائعة مفتوحة المصدر:

يمكننا الآن إضافة ملفات إعدادات أداة أتمتة بناء الشيفرة إلى أداة إدارة الشيفرة المصدرية SCM وستتولى أداة التكامل والنشر المستمر CI/CD أمر بنائها.

4. اختيار خادم تطبيقات الويب

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

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

بعد تحديد خادم الويب المناسب، نستطيع القول أنه قد أصبحت لدينا منهجية عمل DevOps شبه مُعَدّة للاستخدام.

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

5. اختبار تغطية الشيفرة Code Testing Coverage

قد يكون اختبار الشيفرة أمرًا مرهقًا ولكنه ضروري ويجب إجراؤه باكرًا لاكتشاف الأخطاء ورفع جودة الشيفرة وضمان رضا العملاء؛ ولكن توجد أدوات عدة مفتوحة المصدر لاختبار الشيفرة وتحسين جودتها, ويمكن توصيل معظم أدوات التكامل والنشر المستمر CI/CD مع أدوات الاختبار وأتمتة العملية.

أُطُر اختبار الشيفرة البرمجية Code Test Frameworks

هناك نوعان من أدوات اختبار الشيفرة، هما:

1. أُطُر اختبار الشيفرة البرمجية Code test framework: وتساعد في كتابة الاختبارات وتشغيلها
2. أدوات تحسين الجودة Code Quality Suggestion Tools: وتقدم اقتراحات تساعد على تحسين جودة الشيفرة البرمجية

في الآتي جدول مكون من أهم أُطُر الاختبار:

أما عن أدوات تحسين الجودة Code Quality Suggestion Tools، فيمكن ذكر الأدوات الآتية:

وكما نلاحظ، معظم الأدوات والأطر التي ذكرناها مكتوبة بلغة جافا، أو بايثون، أو جافا سكربت؛ أما لغتا C++‎ وC#‎ فهما من لغات البرمجة الخاصة Proprietary لكن المُترجِم المستخدم لترجمتهما GCC مفتوح المصدر.

والآن بعد تطبيق أدوات اختبار التغطية، يجب أن يكون لدينا منهجية عمل DevOps تشبه المنهجية الموضحة في بداية مقالنا.

خطوات إضافية لتحسين المنهجية

سنوضح فيما يلي بعض الخطوات الإضافية التي يمكن القيام بها لتحسين منهجية عمل DevOps الخاصة بنا.

استخدام الحاويات Containers

ذكرنا سابقًا أن بإمكاننا استضافة خادم التطبيقات على آلة افتراضية أو خادم، كما يمكن استخدام الحاويات containers أيضًا.

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

توجد خيارات مختلفة للحاويات، لكن دوكر Docker وكوبرنيتس Kubernetes هما الأكثر شيوعًا.

أدوات الأتمتة الوسيطة Middleware automation tools

تركز منهجية عمل DevOps التي نفّذناه على إنشاء تطبيق ونشره بصورة تعاونية، ولكن هناك أمور أخرى عدّة يمكننا تنفيذها باستخدام أدوات DevOps، وأحدها هو الاستفادة من أدوات إدارة البنية التحتية باستخدام الشيفرة Infrastructure as Code واختصارًا IaC، والتي تُعرف أيضًا باسم أدوات الأتمتة الوسيطة.

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

وفيما يلي بعض أدوات الأتمتة الوسيطة مفتوحة المصدر:

الخلاصة

تعلّمنا في هذا المقال كيفية إنشاء منهجية عمل لإنتاج البرمجيات بأسلوب DevOps باستخدام أدوات مفتوحة المصدر، وتعرفنا على أشهر أدوات التكامل والنشر المستمر CI/CD مفتوحة المصدر وأدوات إدارة الشيفرة المصدرية واختبارها، ويمكنك من الآن بدء تجربة إنشاء منهجية DevOps لمشروعك البرمجي الحقيقي.

ترجمة، وبتصرّف، للمقال A beginner's guide to building DevOps pipelines with open source tools لكاتبه Bryant Son.

اقرأ أيضًا

• دليل المبتدئين في مجال DevOps وأهم ممارساته وأدواته
• المدخل الشامل لتعلم DevOps
• ما هي الغاية من DevOps؟
• أفضل 5 لغات برمجة لـ DevOps

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

سنلقي الضوء في مقالنا هذا على مفهوم تخصص DevOps وأهميته، ونستعرض أساليبه، وأطر عمله، وأدواته.

ما هو تخصص DevOps

لا يوجد تعريف واحد لمصطلح DevOps، لكن يمكن أن نعُدّه إطار عمل يضمن التعاون بين فرق التطوير Development المسؤولة عن كتابة الشيفرة البرمجية للتطبيق، وفرق العمليات Operations المسؤولة عن نشر الشيفرات والبرامج في بيئات الإنتاج بسرعة وبطريقة مؤتمتة Automated وقابلة للتكرار أي يمكن تشغيلها عدة مرات دون مشكلات.

ومصطلح DevOps هو دمج لكلمتي تطوير Development وعمليات Operations. وهو تقنية مهمة جدًا تساعد على زيادة سرعة تسليم التطبيقات والخدمات، وتتيح للمؤسسات خدمة عملائها بكفاءة أعلى، وتزيد قدرتها على المنافسة في السوق.

يركّز منهج DevOps على نشر ثقافة التوافق بين فرق التطوير وفرق تقنية المعلومات وتحسين التواصل والتعاون بينهما، ويولد تطبيق ممارسات DevOps في المؤسسة قيمة مستمرة للعملاء، ويعتمد على ثلاث ركائز أساسية هي الأشخاص People، والعمليات Processes، والأدوات Tools. فالأشخاص هم الذين يقومون بالعمل، والعمليات هي الطريقة التي ينجز بها العمل، أما الأدوات فهي البرامج التي تساعد على تنفيذ العمل بشكل أسرع وأسهل من خلال الأتمتة والتي سنوضحها بمزيد من التفصيل لاحقًا.

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

التحديات التي يواجهها فريق التطوير

يكون المطورون متحمسين عادةً ومستعدين لتبني أساليب وتقنيات جديدة لحل المشكلات، لكنهم قد يواجهون التحديات التالية:

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

التحديات التي يواجهها فريق العمليات

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

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

كيف تعالج منهجية DevOps تحديات فريقي التطوير والعمليات

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

ولتحقيق هذه الأهداف يجب على الشركات تحقيق التالي:

• تقليل احتمالية فشل الإصدارات الجديدة بجعل كل تحديث أصغر وأسهل في الاختبار
• زيادة وتيرة النشر عن طريق إطلاق نسخ محدثة بوتيرة أسرع وبشكل منتظم
• تقصير وقت التعافي MTTR في حال حدوث خلل بعد نشر إصدار جديد، لتعود الخدمة لطبيعتها بسرعة
• تسريع وقت التسليم Lead Time، أي تقليل المدة بين اكتشاف المشكلة وإطلاق الإصلاح الخاص بها

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

يهتم نهج DevOps بمعالجة مجموعة متنوعة من المشكلات التي تنتج عن المنهجيات السابقة، بما في ذلك:

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

مقارنة بين منهجية أجايل Agile و DevOps وتقنية Waterfall التقليدية

تُقارَن DevOps مع المنهجيات الأخرى في مجال تقنية المعلومات، ولا سيّما منهجيّتي أجايل Agile والشلال Waterfall.

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

والآن لنقارن بين منهجية الشلال أو تدفق المياه Waterfall التقليدية ومنهجية DevOps لفهم الفوائد التي تقدمها DevOps. سنفترض أن لدينا السيناريو التالي:

لدينا تطبيق سيُشغَّل بعد أربعة أسابيع، واكتملت عملية كتابة الشيفرة بنسبة 85%، وبدأت عملية شراء الخوادم التي ستُرفع الشيفرة البرمجية عليها.

يوضّح الجدول التالي الفروقات بين تطبيق المنهجيتين في هذه الحالة:

دورة حياة المشاريع في DevOps

سنستعرض فيما يلي بعض الممارسات الشائعة في منهجية DevOps.

التخطيط المستمر Continuous Planning

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

التطوير التعاوني Collaborative Development

تتيح عملية التطوير التعاوني Collaborative Development إمكانية التعاون بين الفريق التجاري وفريق التطوير وفريق الاختبار المنتشرين في مناطق مختلفة لتقديم برامج ذات جودة عالية باستمرار، ويتضمن ذلك تطوير منصات متعددة، ودعم البرمجة متعددة اللغات، وإنشاء قصص المستخدمين، ووضع الأفكار، وإدارة دورة حياة المشروع.

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

الاختبار المستمر Continuous Testing

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

تخفّض هذه الميزات تكلفة توفير بيئات الاختبار وصيانتها، وتقصّر المدة اللازمة لإتمام دورات الاختبار من خلال إتاحة اختبار التكامل في وقت مبكر من دورة حياة المشروع.

الإصدار المستمر Continuous Release والنشر المستمر Continuous Deployment

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

تلعب الأتمتة دورًا رئيسيًا في ضمان إصدار البرنامج بتكرار وموثوقية؛ إذ إن أحد الأهداف الرئيسية هو أتمتة العمليات اليدوية مثل عملية بناء التطبيقات والانحدار Regression والنشر وتوفير البنية التحتية.

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

المراقبة المستمرة Continuous Monitoring

توفر المراقبة المستمرة إمكانية إعداد التقارير على مستوى المؤسسة، ويساعد ذلك فرق التطوير على الإطلاع على أداء التطبيقات ومدى توفرها في بيئة الإنتاج، قبل نشرها.

تُعَدّ التقييمات والآراء Feedback التي توفرها المراقبة المستمرة في مراحل مبكّرة ذات أهمية كبيرة في خفض الأخطاء وتوجيه المشاريع في الاتجاه الصحيح. وغالبًا ما تتضمن هذه المرحلة أدوات المراقبة التي تكشف عن المقاييس المتعلقة بأداء التطبيق.

المراجعة والتقييم والتحسين Optimization

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

فوائد تطبيق منهجية DevOps في بيئة العمل

يؤمّن تطبيق منهجية DevOps بيئة عمل يتعاون فيها فريق التطوير وفريق إدارة البرمجيات ويعملان كفريق واحد لتحقيق أهداف مشتركة. ويتميز ذلك بتنفيذ التكامل المستمر والتسليم المستمر CI/CD، مما يتيح إصدار البرامج بسرعة وأخطاء أقل ويعود علينا بجملة من الفوائد تشمل:

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

مبادئ DevOps

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

ومن أهم هذه المبادئ نذكر:

1. التطوير والاختبار في بيئة شبيهة ببيئة الإنتاج

الهدف من هذا المبدأ هو السماح لفرق التطوير وفرق ضمان الجودة Quality Assurance -أو اختصارًا QA- بتطوير البرمجيات واختبارها في بيئات قريبة من بيئات الإنتاج Production Systems، كي يعاينوا أداء التطبيقات قبل أن تصبح جاهزة للنشر.

يجب أن يتعرض التطبيق لأنظمة شبيهة بالإنتاج في وقت مبكر قدر الإمكان من دورة حياته لمعالجة الأمور التالية:

• اختبار التطبيق في بيئة قريبة من البيئة الفعلية
• السماح باختبار عمليات تسليم التطبيق والتحقق من صحته مقدمًا
• تمكين فريق العمليات من اختبار أداء البيئة عند نشر التطبيق في مرحلة مبكرة من دورة حياته وتعديل البيئة بما يناسب التطبيق

2. النشر باستخدام عمليات موثوقة وقابلة للتكرار

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

3. مراقبة الجودة التشغيلية Operational Quality

تُجيد المؤسسات مراقبة أداء التطبيقات في بيئة الإنتاج لأن لديها أدوات لمراقبة المقاييس ومؤشرات الأداء الرئيسية KPIs في الوقت الفعلي. ويُطبَق هذا المبدأ في وقت مبكر من دورة حياة التطبيق، مما يضمن أن الاختبارات الآلية تراقب السمات الوظيفية وغير الوظيفية للتطبيق في وقت مبكر.

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

4. جمع تقييمات وآراء موسعة حول التطبيق

إن أحد أهداف عمليات DevOps هو تمكين المؤسسات من التفاعل وإجراء التغييرات بسرعة أكبر. يتطلب تحقيق هذا الهدف في مجال تسليم البرمجيات جمع تقييمات وآراء Feedback مبكرة، ومن ثم التعلم بسرعة من كل إجراء.

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

قائمة بأهم أدوات DevOps

من أهم أدوات DevOps مفتوحة المصدر في مجال تطوير البرمجيات وإدارة العمليات نذكر الآتي:

أهم أدوات عملية التطوير Development

• مرحلة التخطيط: أداة Kanboard وWekan وأنا وGitLab وTuleap و Redmine وبدائل جيرا JIRA مثل Mattermost و Roit.im و IRC.
• مرحلة كتابة الشيفرة: غيت Git و Gerrit و Bugzilla و جينكينز Jenkins.
• مرحلة بناء التطبيق: Apache Maven و Gradle و Apache Ant و Packer
• مرحلة الاختبار: JUnit و Cucumbe و Selenium و Apache JMeter

أهم أدوات عملية إدارة العمليات Operations

• مرحلة الإصدار والنشر والتشغيل: Kubernetes و Nomad و جينكينز Jenkins و Zuul و Spinnaker و Ansible و Apache ZooKeeper و etcd و Netflix Archaius و Terrafo
• مرحلة المراقبة: Prometheus و Nagios و InfluxDB و Fluentd وكما هو موضح، فقد دمجنا مرحلة التشغيل الأخيرة مع مرحلتي الإصدار والنشر بسبب تشابه أدواتها.

الخاتمة

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

ترجمة، وبتصرّف، للمقال A beginner's guide to everything DevOps لكاتبه Sameer S Paradkar.

اقرأ أيضًا

• المدخل الشامل لتعلم DevOps
• كيفية تحقيق نهج DevSecOps بنجاح
• دليلك الشامل عن النشر المستمر Continuous Delivery
• دليل المبتدئين لمنهجية أجايل Agile
• ما هو إطار عمل تطوير البرمجيات المرن Lean Software Development

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

ما هو نظام تشغيل لينكس؟

يعد لينكس نظام تشغيل مفتوح المصدر طوره المبرمج الأمريكي لينوس بنديكت تورڤالدس Linus Benedict Torvalds ليكون شبيهًا لنظام يونكس UNIX-Like ومتعدد التوزيعات، فمن أشهر توزيعاته دبيان Debian، وأوبونتو Ubuntu، وفيدورا Fedora، كما تتوفر توزيعات لينكس مدفوعة أيضًا وأشهرها ريد هات إنتربرايز لينكس Red Hat Enterprise Linux وسينت أو إس CentOS.

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

لماذا نستخدم لينكس عند تطوير التطبيقات؟

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

1. لينكس مجاني ومفتوح المصدر

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

2. يدعم لينكس قابلية التوسع

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

3. لينكس نظام تشغيل مستقر

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

4. يتميز لينكس بالأمان الشديد

يجب أن يكون الأمان على رأس أولويات كل فريق تطوير تطبيقات، ويُعرف لينكس بأنه واحد من أكثر أنظمة التشغيل أمانًا، ما يضمن لنا أمان تطبيقاتنا وبياناتنا، علاوةً على ذلك يمكننا تحسين أمانه باستخدام خادم خاص افتراضي Virtual Private Server (VPS)، ما يعزل التطبيق والبيانات الخاصة بنا عن تطبيقات وبيانات سائر المستخدمين، فإن كان لدينا مشكلة أمنية في تطبيقنا فلن تؤثر على الآخرين، وكذلك إن كان لدى الآخرين مشكلات أمنية في تطبيقاتهم فلن تؤثر على أمان تطبيقنا وبياناتنا.

5. تتعدد توزيعات نظام تشغيل لينكس

تتوفر توزيعات عديدة ومتنوعة من نظام تشغيل لينكس Linux، فسنجد حتمًا التوزيعة المناسبة لاحتياجات مشروعنا، فمثلًا تتناسب توزيعة أوبونتو Ubuntu مع المطورين المبتدئين، وذلك لتوافر واجهة رسومية سهلة الاستخدام فيها، بينما قد تلائم توزيعة دبيان Debian الفئة الخبيرة من المطورين نظرًا لتعدد مميزاتها وحزم البرمجيات التي تدعمها التوزيعة.

6. يدعم لينكس مختلف أنواع التطبيقات

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

7. يدعم لينكس مجموعة واسعة من لغات البرمجة

يدعم نظام لينكس جميع لغات البرمجة المستخدمة في تطوير البرمجيات تقريبًا، مثل: لغة بايثون ولغة جافا ولغة ++C، كما يدعم أكثر من مصرف Compiler لكل لغة، ما يعطينا مرونة في اختيار لغة البرمجة المفضلة لنا لتطوير التطبيقات.

8. يحظى لينكس بشهرة كبيرة ومجتمع واسع

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

9. يدعم لينكس مختلف محررات الأكواد

أيًا كانت تفضيلاتنا الشخصية فلا بد أن نجد محرر أكواد مناسبًا لنا ومدعومًا من نظام تشغيل لينكس، فمثلًا إن أردنا محرر نصوص بسيطًا وسهل الاستخدام فيمكن استخدام محرر Gedit، وفي حال كنا نفضل استخدام بيئة تطوير متكاملة فيمكننا الاختيار بين مجموعة واسعة من بيئات التطوير مثل NetBeans أو Eclipse أو IntelliJ IDEA.

10. يتميز لينكس بالمرونة

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

أمثلة على تطبيقات ناجحة تستخدم لينكس

قد تراود البعض منا شكوك حول نظام تشغيل لينكس وكفاءته، لكونه لا يحظى بشعارات برَّاقة، ولكنَّ لينكس قد أثبت كفاءته واعتماديته عبر السنين، وهناك تطبيقات شهيرة ومميزة استخدم مطوروها نظام تشغيل لينكس لتطويرها وتشغيلها، نذكر لكم منها:

سكايب Skype

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

ستيم Steam

يعد ستيم أكبر متجر إلكتروني لبيع الألعاب الرقمية، وما كان هذا المتجر الإلكتروني المميز ليبرز لولا نظام تشغيل لينكس.

دروب بوكس Dropbox

لا بد أن أي شخص يستخدم منصات التخزين السحابي لتخزين ملفاته يعرف جيدًا برنامج دروب بوكس ويعرف مكانته وأصالته بين سائر منصات التخزين السحابي؛ وقد استُخدِم نظام تشغيل لينكس عند تطوير دروب بوكس أيضًا.

الخاتمة

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

ترجمة -وبتصرف- لمقال Top 10 Benefits of Linux for App Development لكاتبه Janus Atienza

اقرأ أيضًا

• تعرف على نظام لينكس Linux وأبرز مميزاته وعيوبه
• كيف تختار توزيعة لينكس المناسبة لك؟
• دليلك الشامل إلى برمجة التطبيقات
• كيفية تحزيم وتوزيع تطبيقات بايثون

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

تحدث كل من (دايفيد فارلي) و(جيز هامبل) في عام 2010 في كتابهما التسليم المستمر (Continuous Delivery) عن التصدير المستمر للبرمجيات، إذ ستجد في كتابهما عدة ممارسات لا تزال صالحة في يومنا هذا. إذًا، فالتسليم المستمر Continuous Delivery ليس مفهومًا جديدًا، لكن العديد من المؤسسات لا تزال لا تجيد تطبيقه.

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

ما هو النشر المستمر CD

الغرض من النشر هو استخدامه كطريقة للحصول على آراء العملاء، إذ ستحصد أكبر قدر ممكن من تعليقات العملاء عند كل نشر. لكن، للحصول على تعليقات قيّمة، يجب أن تأخذها من مستخدمي برامجك. ولذلك، تحتاج إلى إصدار التحديثات في بيئة الإنتاج production environment. وهذا هو جوهرالنشر المستمر Continuous Deployment أي نشر التعليمات البرمجية في بيئة الإنتاج بصورة آمنة ومستمرة وآلية ومؤتمتة دون الحاجة لإجراء أي تحقق يدوي.

ملاحظة: بيئة الانتاج هي مكان نشر التطبيق وجعله متاحًا للمستخدمين، كمثال عليها Play Store أو الموقع الخاص بشركة ما بحيث ترفع تطبيقها عليه على سبيل المثال.

قد يخطر في ذهنك أن هذا المفهوم غير مُستَخدَم على أرض الواقع وأنه مفهوم نظري وحسب، لكن تطبق الشركات الكبرى كشركة نتفليكس Netflix وايتسي Etsy وتسلا Tesla مفهوم النشر المستمر لنشر التحديثات البرمجية لتطبيقاتها المختلفة، فعند نشر التحديثات البرمجية تحصل الشركات على آراء المستخدمين بعد الاستخدام الفعلي، وتترجمها إلى خدمات أو تستخدمها لتطوير منتجاتها. وهذا هو الفرق الأساسي بين التسليم المستمر Continuous Delivery والنشر المستمر Continuous Deployment.

ما الفرق بين النشر المستمر والتسليم المستمر

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

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

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

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

ما سبب أهمية التكامل المستمر

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

• يبنى البرنامج من فرع واحد من مجلد الشيفرة البرمجية code repository.
• يستخدم خط التجزئة مجموعة اختبارات مؤتمتة وموثوقة.
• إذا فشل بناء البرنامج، تتوقف عملية التكامل وتُلغى التعديلات.

وبهذه الطريقة، تحرص على أن جميع التعديلات مؤهلة للإصدار، حتى لو أجلت الإصدار إلى وقت آخر أو منصة آخرى. لكن القاعدة الأهم هي إجراء اختبارات مؤتمتة موثوق بها. كما ستحتاج إلى إجراء اختبارات سريعة وتعمل بالتوازي، واختبارات لجميع السيناريوهات المهمة في تطبيقك، مثل اختبار المسار السعيد happy path test، واختبار للبيانات التي عطلت الإنتاج سابقًا، واختبار إدخال بيانات غير صحيحة. لا تحتاج إلى الحصول على درجة تغطية الشيفرة code coverage بنسبة 100%، ولكن يجب عليك زيادة عدد الاختبارات التي تجريها تدريجيًا قبل الإعلان عن جاهزية التعديلات البرمجية.

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

كيفية تطبيق النشر المستمر

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

إن إدارة الميزات Feature Management تُعد مفيدة للغاية، إذ يمكنك أن تفعّل التحديثات البرمجية للعملاء بنقرة واحدة. وبهذه الطريقة، تجعل الشيفرة البرمجية جاهزة للإصدار حتى لو لم تكن مكتملة. إذ يمكنك تفعيل ميزة ما لكي تختبرها، أو تفعيلها في جزء معين من الشيفرة لإجراء اختبارات ألف/باء أو A/B tests وأي اختبار آخر. فكل ذلك متاح بالإضافة إلى الحصول على آراء العملاء القيمة فورًا، وإنتاج برامج أفضل مع كل إصدار.

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

الخاتمة

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

لا يمكنك تطبيق النشر المستمر بين عشية وضحاها، إذ إنه ثمة سلسلة من الخطوات التي عليك اتباعها أولاً. وترتيب هذه الخطوات هو كالتالي: التكامل المستمر، ثم التسليم المستمر، ثم النشر المستمر. كما يمكنك التدرب في بيئة التطوير أو الاختبار، وليس ضروريًا أن تبدأ في بيئة الإنتاج، ولكن عليك أن تحدد ما تريد إنجازه، مثلًا هل تريد تحقيق وقت تسويق قصير Time To Market، أم تريد تحقيق مدة توريد Lead Time قصيرة، أم تريد إجراء المزيد من التجارب.

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

وإذا كان لديك من الاستفسارات حول ما ورد في مقالنا، أو أردت الحصول على الدعم والمساعدة أضف سؤالك في قسم التعليقات أسفل المقال، أو اكتبه في قسم الأسئلة والأجوبة في أكاديمية حسوب.

ترجمة -وبتصرف- للمقال What Is Continuous Deployment? A Complete Explanation من موقع Cloudbees.

اقرأ أيضًا

• مدخل إلى التكامل المستمر والنشر المستمر CI/CD
• أفضل ممارسات منهج التكامل المستمر والتسليم المستمر CI/CD
• إعداد التكامل المستمر والنشر المستمر باستخدام الخدمتين CircleCI وCoveralls
• التكامل المستمر: تثبيت Concourse CI على أوبنتو
• محاكاة عقلية DevOps

تعد الصور ذات الصيغ التالية JPG و PNG و GIF إحدى أكثر صيغ الصور الشائعة منذ التسعينات. لكن، بخلاف صور JPG و PNG، فإن صور GIF تحتوى على إطارات متعددة من الرسوم المتحركة، وهي منتشرة انتشارًا واسعًا في شبكة الإنترنت.

تعد صور GIF أو نسق الرسومات المتبادلة تقنيةً قديمةً وقد أصبحت أقل فاعلية من تضمين مقاطع الفيديو الويب، لأن معظم فيديوهات الويب تستخدم تقنيات ضغط حديثة وبرامج ترميز Codecs أحدث من المستخدمة في الصور المتحركة GIF.

تُستخدم برامج الترميز Codecs (أو المرمازات) لترميز مقاطع الفيديو وفك ترميزها، وتحتوي معظم المنصات على عتاديات مخصصة لتشغيل برامج الترميز هذه. أما ملفات GIF، يُفَك ترميزها مباشرةً باستخدام وحدة المعالجة المركزية CPU، حيث إن حمل وحدة المعالجة المركزية اللازم لمعالجة ملف GIF منخفض الدقة ذو إطارات متحركة قليلة لا يكاد يذكر، ولكن يمكنك من الناحية الفنية إنشاء ملف GIF بدقة ومعدل إطارات مماثل لمقاطع فيديوهات YouTube، وسوف تتفاجأ بعدد موارد النظام التي يستهلكها ذلك.

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

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

المتطلبات

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

الخطوة الأولى: تثبيت الأدوات ffmpeg وGifski وGifsicle

ستحتاج إلى ثلاثة أدوات كي تستطيع متابعة خطوات هذا المقال. أول أداة ستحتاجها هي ffmpeg التي سنستخدمها لقص الفيديو والتعديل عليه، ثم سنستخدم Gifski لإنشاء صور GIF، و Gifsicle لتحسين الصور والتعديل عليها.

ستجد هذه الأدوات متاحة في أغلب المنصات. كلا الأداتان ffmpeg و gifsicle متاحتان في مستودعات أوبنتو، ويمكنك تنزيلها باستخدام مدير الحزم apt. أولًا، حَدّث الحزم باستخدام الأمر apt update:

sudo apt update

ثم ثبت حزمتي ffmpeg و gifsicle باستخدام الأمر apt install:

sudo apt install ffmpeg gifsicle

أما الأداة الثالثة gifski فهي متاحة بواسطة Homebrew ويمكنك تثبيتها بواسطة الأمر brew install:

brew install gifski

قد يستغرق ذلك بضع دقائق لأن Homebrew سيثبت بعض الاعتماديات dependencies. والآن، بعد أن ثبّت جميع الأدوات اللازمة على جهازك، عليك اختيار فيديو لإنشاء صورة GIF منه.

الخطوة الثانية: تنزيل وفحص ملف الفيديو

بإمكانك إنشاء صورة GIF من أي مقطع فيديو على جهازك، أو يمكنك استخدام الفيديو التعريفي بمنصة تطبيقات DigitalOcean. لتنزيل نسخة من الفيديو من باستخدم الأمر curl:

curl -O https://deved-images.nyc3.digitaloceanspaces.com/gif-cli/app-platform.webm

curl هي إحدى أدوات سطر الأوامر تخولك من إنشاء مختلف طلبات الويب web request، مثلًا عند استخدام الراية -o مع عنوان URL فهذا يوّجه curl إلى تنزيل ملف من الإنترنت وتخزينه على جهازك بنفس الاسم. والآن، بعد أن أصبح عندك نسخةً من الفيديو على جهازك، بإمكانك التحقق من بياناته الوصفية metadata لأن ذلك مفيد عند إنشاء صورة GIF ذات جودة عالية.

بعد تثبيت الأداة ffmpeg يمكنك استخدام الأمر ffprobe الذي يسمح لك التحقق من الدقة resolution، ومعدل الإطارات framerate، والمعلومات الأخرى في ملفات الوسائط. استعرض هذه المعلومات باستخدام الأمر ffprobe على الفيديو app-platform.webm الذي نزلته:

ffprobe app-platform.webm

ستحصل على الخرج التالي:

Output
…
Input #0, matroska,webm, from 'app-platform.webm':
  Metadata:
    ENCODER         : Lavf59.27.100
  Duration: 00:01:59.04, start: -0.007000, bitrate: 1362 kb/s
  Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn (default)
    Metadata:
      DURATION        : 00:01:59.000000000
  Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      DURATION        : 00:01:59.041000000

يعرض الخرج التدفقات Streams الموجودة في الملف (عادةً فيديو واحد ودفق صوتي واحد على الأقل)، بالإضافة إلى معدل العينات sample rate، وبرامج الترميز Codecs، والخصائص الأخرى للتدفقات. لاحظ أن المعلومات المظللة في الخرج تدلنا أن الفيديو مرمز بدقة 1080 بكسل، ويُشَغل بمعدل 25 إطارًا في الثانية، كما أن طوله دقيقتين تقريبًا، وهو طويل جدًا بالنسبة لصورة GIF واحدة!

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

الخطوة الثالثة، قص مقطع من الفيديو

الآن أصبح لديك مقطع فيديو مدته دقيقتان وأصبحت تعرف خصائصه. قبل تحويله إلى صورة GIF عليك تقصير الفيديو،. ولا يُستحسن تشغيل مقطع الفيديو في الطرفية، لذا شاهد الفيديو على YouTube لتختار المقطع الذي تريده. اخترنا في مقالنا المقطع من الثانية 00:00:09 إلى الثانية 00:00:12، مما ينتج لدينا مقطعًا متحركًا سلسًا على النحو التالي:

يمكنك قص الفيديو app-platform.webm باستخدام الأداة ffmpeg كالتالي:

ffmpeg -ss 00:00:09 -to 00:00:12 -i app-platform.webm -c copy clip.webm

إليك الشرح التفصيلي للأمر السابق:

• يعبر الجزء الأول -ss 00:00:09 -to 00:00:12 عن كيفية فهم ffmpeg للشيفرة الزمنية، من نقطة البدء إلى نقطة النهاية. كما يمكنك القص اعتمادًا على المدة أو أجزاء من الثانية.
• الجزء -i app-platform.webm هو مسار الفيديو مسبوقًا بـ -i.
• نحدد بعد الجزء -c copy مرماز فيديو الخرج أو الصوت للأداة ffmpeg، واستخدمنا للأمر copy بدلًا عن برنامج ترميز كي نحصل على الفيديو الجديد بسرعة، وبدون ترميز، ولنتفادى انخفاض دقة الفيديو. وبما أننا سننشأ صورة GIF فلا بأس إن حافظنا على نفس الصيغة في ملف الخرج لتوفير الوقت، لأننا سنحول الفيديو الناتج إلى صورة متحركة.
• الجزء clip.webm هو مسار الفيديو الناتج. ستحصل بعدها على فيديو مدته ثلاث ثواني باسم clip.webm، ويمكنك التأكد من حجمة باستخدام
  الأمر ls -lh:

ls -lh clip.webm

ستحصل على النتيجة التالية:

Output
-rw-r--r-- 1 sammy sammy 600K Nov 16 14:27 clip.webm

لاحظ أن حجم ثلاث ثوانٍ من مقطع الفيديو هو 600K، بامكانك استخدام هذا الحجم كمرجع للمقارنة عندما تنشأ صورة GIF في الخطوة التالية.

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

الخطوة الرابعة، تحويل الفيديو إلى صورة GIF

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

لدينا عدة خيارات لإنشاء صور GIF في سطر الأوامر، يمكننا استخدام ffmpeg لوحدها لكن صيغة أوامرها صعبة الفهم والتغيير:

ffmpeg -filter_complex "[0:v] fps=12,scale=w=540:h=-1,split [a][b];[a] palettegen [p];[b][p] paletteuse" -i clip.webm ffmpeg-sample.gif

لاحظ أننا في مثالنا قلصنا الدقة ومعدل الإطارات إلى النصف، لنحصل على معدل إطارات 12fps ودقة بمقدار 540p بكسل، وتعد هذه بدايةً جيدة بالنسبة لصور GIF لأنها تعامل معاملة الصور العادية، إذ تُنَزل بالكامل عند تحميل صفحة ويب، بخلاف مقاطع الفيديو التي لا تُحَمّل تدريجيًا بدقة أقل.

يمكنك استخدام شبكات توزيع المحتوى CDN لتحسين تسليم الأصول الثابتة للموقع مثل الصور، ولكن يجب أن تتفادى عرض الصور الضخمة دون هدف محدد. ولذا يجب ألا تنشأ صور GIF ذات حجم أعلى من 3 ميغا بايت، والآن، لنتحقق من حجم الصورة التي أنشأتها بواسطة الأمر ls -lh:

ls -lh ffmpeg-sample.gif

وستحصل على الخرج التالي:

-rw-r--r-- 1 sammy sammy 2.0M Nov 16 14:28 ffmpeg-sample.gif

أنشأنا بهذه الطريقة صورة GIF حجمها 2 ميغا بايت. لكن يمكننا الحصول على نتيجة أفضل باستخدام صياغة برمجية أقل تعقيدًا بواسطة gifski:

gifski --fps 12 --width 540 -o gifski-sample.gif clip.webm

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

ls -lh gifski-sample.gif

لتحصل على الخرج التالي:

-rw-r--r-- 1 sammy sammy 1.3M Nov 16 14:33 gifski-sample.gif

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

gifski --fps 25 --width 1080 -o gifski-high.gif clip.webm

تحقق من حجم الملف الناتج:

ls -lh gifski-high.gif

الخرج
-rw-r--r-- 1 sammy sammy 6.9M Nov 16 14:37 gifski-high.gif

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

الخطوة الخامسة: تحسين صورة GIF والتحقق منها وعرضها

سنستخدم الأداة gifsicle في الخطوة الأخيرة من مقالنا لتحسين جودة صورة GIF

إذ إن ميزات استخدام gifsicle مع ملفات GIF تشابه ميزات استخدام ffmpegمع ملفات الصوت والفيديو وتمكننا من فعل أي شيء نرغبه، ولكن استخدامها قد يكون معقدًا جدًا. ولذلك، سنستخدم gifski لإنشاء صور GIF، وسنركز على بعض أوامر gifsicle لتحسين الصور أو معالجتها. أولًا، شَغّل أمر تحسين gifsicle القياسي:

gifsicle -O3 --lossy=80 --colors 256 gifski-sample.gif -o optimized.gif

لاحظ أننا في الأمر السابق طبقنا الخيار الثالث -O3 للحصول على أفضل تحسين، وطبقنا الخيار lossy 80-- لتحديد نسبة 20% كالحد الأقصى المسموح به لانخفاض الجودة عن الملف الأصلي، واخترنا --colors 256 لتطبيق 256 لون كحد أقصى في الصورة الناتجة.

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

والآن، تحقق من حجم الصورة المحسنة optimized.gif:

ls -lh optimized.gif

وستحصل على الخرج التالي:

-rw-r--r-- 1 sammy sammy 935K Nov 16 14:44 optimized.gif

لاحظ أن الخطوة الأخيرة خفضت حجم الملف بنجاح إلى 935 كيلو بايت أي أكثر من حجم الفيديو الأصلي بقليل، وهو حجم مقبول لصورة متحركة. وهي نفس الصورة التي عرضناها سابقًا في مقالنا. يمكنك الاطلاع على دليل Gifsicle للتعرف على الطرق الأخرى لمعالجة صور GIF. على سبيل المثال، يمكنك "تقسيم" ملف GIF إلى ملفات صور متعددة، واحد لكل إطار رسوم متحرك باستخدام الأمر التالي:

gifsicle --explode optimized.gif

الذي ينشأ عدة ملفات اسمائها على نسق optimized.gif.000، optimized.gif.001 وهكذا، لكل صورة. استخدم الأمر ls -lh لعرض ملفات الصور:

ls -lh optimized*

لتحصل على الخرج التالي:

-rw-r--r-- 1 sammy sammy 935K Nov 16 14:46 optimized.gif
-rw-r--r-- 1 sammy sammy  20K Nov 16 14:54 optimized.gif.000
-rw-r--r-- 1 sammy sammy  17K Nov 16 14:54 optimized.gif.001
-rw-r--r-- 1 sammy sammy  22K Nov 16 14:54 optimized.gif.002
-rw-r--r-- 1 sammy sammy  22K Nov 16 14:54 optimized.gif.003
…

كما يمكنك تدوير الصورة باستخدام خيار التدوير بمقدار 90 درجة --rotate-90 أو 180 درجة --rotate-180:

gifsicle --rotate-90 optimized.gif -o rotated.gif

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

الخاتمة

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

والآن، أنشأ صور GIF وطبق ما تعلمناه في مقالنا هذا. وفي حال كان لديك مزيد من الاستفسارات حول ما ورد في المقال، أو أردت الحصول على الدعم والمساعدة أضف سؤالك في قسم الأسئلة والأجوبة في أكاديمية حسوب.

ترجمة -وبتصرف- للمقال How To Make and Optimize GIFs on the Command Line.

اقرأ أيضًا

• نصائح لإنشاء صور GIF دائمة الحركة
• كيف تنشئ صورًا متحركة بصيغة GIF من مجموعة صور PNG باستخدام ImageMagick وسطر الأوامر
• 10 أدوات وتطبيقات مجانية تسهل عليك تحسين الصور
• البحث عن الملفات والمجلدات على لينكس باستخدام الأمر find

يتطور مع الوقت مفهومنا لتوزيع المسؤوليات بين أعضاء الفرق المسؤولة عن تطوير المنتجات الرقمية، فسواءً كنت مبرمجًا أو مدير أنظمة قد تستفيد من تطبيق ممارسات DevOps أي إدارة العمليات Development Operations) لتحسين المنتج النهائي ولتطوير طريقة عملك ورفع الإنتاجية.

في هذا المدخل الشامل ستتعرف المبادئ الأساسية لممارسات DevOps وخارطة الطريق لتعلم DevOps هذا المجال الشيق واحترافه.

ما هو DevOps؟

كلمة DevOps هي اختصار لكلمتي التطوير Development، والعمليات Operations وتشير إلى الممارسات التي تهدف لدعم تطوير وتشغيل المنتجات الرقمية بمختلف أنواعها، سواءً لتسريع عملية التطوير أو لرفع جودة المنتج وصولًا لتسهيل عملية تشغيله ونشره وتوصيله للمستخدمين ثم مراقبة أدائه الفعلي وعمله، حيث كانت هذه الأعمال والمسؤوليات سابقًا موزعة على فريقين منفصلين -سنتعرف عليهما في الفقرة التالية- ما أثر على كفاءة عمل هذه الفرق وخلق مشاكل سنتعرف عليها في الفقرات القادمة.

قد تتساءل، ما هي وظيفة DevOps ومن هما فريق التطوير وفريق العمليات؟

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

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

لماذا أتعلم DevOps؟

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

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

وللاطلاع أكثر على أهداف DevOps يمكنك قراءة مقال ما هي الغاية من DevOps؟.

تعلم DevOps: الأساسيات

سواء كنت ضمن فريق المطورين أو العمليات وتتبع ممارسات DevOps هناك بعض الأساسيات الواجب على كلا الفريقين الاطلاع عليها وتعلمها لزيادة سهولة التعاون والتواصل مع الفريق الآخر ومناقشة حلول المشكلات، يمكنك التعرف أكثر على استراتيجية DevOps من مقال ما المقصود بـ DevOps؟، والاطلاع على نموذج التفكير الذي ولّد تلك الممارسات على من مقال محاكاة عقلية DevOps.

انضم لاحقًا مفهوم الأمان Security إلى ممارسات DevOps ليصبح مجموع تلك الممارسات مجتمعة تُعرف باسم DevSecOps (اختصارًا لعبارة Development Security Operations)، فبدلًا من النظر إلى نواحي الأمان للتطبيق كمرحلة أخيرة دُمج ذلك المفهوم منذ بداية عملية التطوير، كالاهتمام بطرق الاستيثاق من مستخدمي البرنامج أو تشفير البيانات المُخزنة وضمان تواصل البرنامج بقنوات مشُفرة مع الخدمات الأخرى لحماية البيانات المرسلة وغيرها من الممارسات التي يمكنك القراءة عنها وعن المفهوم بشكل عام من سلسلة مقالات تعرف على devopssec والبدء بالمقال ما هي DevSecOps؟.

البنية التحتية

البنية التحتية infrastructure هي مجموع المكونات الفيزيائية والافتراضية التي تدعم تطوير ونشر وعمل التطبيقات البرمجية، وتتألف المكونات الفيزيائية من الخوادم التي سنتعرف عليها في الفقرة التالية، وأجهزة التشبيك وأجهزة تخزين البيانات وكل الأجهزة الفيزيائية الداخلة في عمل التطبيقات البرمجية، والمكونات الافتراضية هي البرمجيات التي يتعامل معها التطبيق أو يعتمد عليها، لذا فالبنية التحتية هي جزء أساسي من ممارسات DevOps، فهي تخدم عملية التطوير والنشر والتوسيع للتطبيق.

أساسيات الشبكات

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

يوجد عدة أنواع من الشبكات سواء من ناحية مكان تلك الأجهزة كالشبكات المحلية LAN أو الواسعة WAN كشبكة الانترنت، كما يوجد العديد من التجهيزات الخاصة بالوصل بين الأجهزة كالمبدلات Switches والموجّهات Routers، وطريقة الوصول للأجهزة عبر الشبكة تتبع عدة بروتوكولات أشهرها بروتوكول IP (اختصارًا لبروتوكول الإنترنت Internet Protocol) والذي يحدد عنوانًا مميزًا لكل جهاز على الشبكة يمكن الأجهزة من التخاطب فيما بينها، ويمكنك التعرف على أساسيات أخرى والقراءة أكثر عن الأفكار المذكورة في مجال شبكات الحاسوب من سلسلة مقالات أساسيات الشبكات.

أساسيات الخوادم

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

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

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

وظيفة الخوادم

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

لغات البرمجة في الخوادم

تقتصر عملية تنفيذ الأوامر يدويًا ضمن الخادم على المهام البسيطة والتي تُنفذ لمرة واحدة عادةً، لكن أتمتة العمليات على الخادم تتطلب كتابة برامج تعيد تنفيذ المهام المتكررة، ومن تلك اللغات باش Bash وبايثون Python وروبي Ruby وغو Go وغيرها من اللغات والتي يمكنك التعرف عليها وعلى وظيفتها ضمن الخادم من مقال أفضل 5 لغات برمجة لـ DevOps.

خوادم الويب

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

خوادم قواعد البيانات

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

أنواع خوادم أخرى: SSH و Mail و Reverse Proxy

إن أردت تعلم DevOps فستحتاج إلى التعامل مع العديد من الخوادم الأخرى، أشهرها خادم SSH والتي تسمح لك بالدخول إلى سطر الأوامر لخادم بطريقة آمنة ويمكنك التعرف عليه أكثر من مقال العمل مع خواديم SSH: العملاء والمفاتيح، وقد يحتاج تطبيقك لإرسال البريد الإلكتروني حيث تفوّض خادم إرسال البريد الإلكتروني Mail Server بتلك العملية، وقد تحتاج أحيانًا لتوزيع الطلبات القادمة إلى خادم معين على عدة خوادم من نفس النوع لتخفيف الحمل عليها، هنا يأتي دور خادم الوكيل العكسي Revese Proxy Server لإدارة التواصل بين العميل وعدة خوادم أخرى، ومن أشهر الخوادم لذلك هي Apache و Nginx.

نظام تشغيل لينكس

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

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

أساسيات سطر الأوامر

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

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

تعلم DevOps: التعمق في المجال

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

الخوادم الافتراضية Virtual Servers والحاويات Containers

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

الحوسبة الافتراضية VM

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

الخوادم الافتراضية VPS

الخادم الافتراضي الخاص VPS (اختصارًا للعبارة Virtual Private Server) هو بيئة افتراضية معزولة خاصة على جهاز فيزيائي معين، ليبدو كأنه خادم منفصل معزول ببيئة وعتاد خاص، بينما قد تتشارك عدة خوادم افتراضية الجهاز نفسه، يفيد ذلك في تقسيم الجهاز الواحد إلى عدة أجهزة منعزلة لاستضافة الخدمات المختلفة أو لتوزيعها على مستخدمين مختلفين.

الحاويات containers

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

دوكر Docker

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

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

تعتبر دوكر من أشهر منصات إدارة وتشغيل الحاويات وتخدم في معظم ممارسات DevOps سواء من قبل فريق التطوير وخصوصًا من قبل فريق العمليات، وفي أيّ فريق كنت من المهم التعرف على تلك المنصة والتعامل معها ويمكنك البدء بقراءة مقال تعرف على Docker وبمشاهدة فيديو ما هي تقنية Docker؟.

كوبرنيتيز Kubernetes

توفر منصة كوبرنيتيز Kubernetes (أو اختصارًا K8s) أدوات قوية تختص في إدارة الحاويات وأتمتة عمليات النشر والتوسيع لها سواء ضمن كانت على خادم واحد أو عدة خوادم موزعة، وتوفر أيضًا أدوات أخرى لتوزيع الأحمال بين الحاويات أو لنشر التحديثات عليها مع الحفاظ على استمرار عمل تلك الخدمات، حيث يركز على مهام النشر والتشغيل للخدمات ضمن ممارسات DevOps، لذا وخصوصًا إذا كنت ضمن فريق العمليات من الضروري التعرف على هذه المنصة ويمكنك البدء بقراءة مقال مدخل إلى Kubernetes.

دوكر سوارم Docker Swarm

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

مراقبة الخوادم والتسجيل

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

مراقبة الخوادم

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

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

أشهر أدوات المراقبة

توفر أنظمة التشغيل بعض الأدوات المفيدة في مراقبة النظام والبرامج العاملة ضمنه والموارد، وتوجد بعض الأدوات والخدمات الخارجية التي تساعد في مراقبة عدة خوادم معًا:

• أدوات نظام تشغيل لينكس، أشهرها الأداة top والتي تفيد في معاينة استهلاك كل إجرائية process تعمل حاليًا من موارد الحاسوب، وهي الموجودة افتراضيًا ضمن جميع توزيعات لينكس، وفي حال أردت تفاصيل أكثر يوجد أداة شبيهة بها تدعى htop تعرض لك معلومات مفصلة إضافية، يمكنك التعرف على تلك الأدوات وأخرى متوفرة في لينكس من مقال 4 أدوات مفتوحة المصدر من أجل مراقبة نظام لينكس.
• أدوات Elastic وهي حزمة متكاملة لمراقبة سجلات التطبيقات والأداء للخوادم وتعد من أشهر الأدوات استخدامًا.
• أداة Prometheus لتجميع بيانات المراقبة من مختلف المصادر وتخزينها ضمن قاعدة بيانات بتسلسل حدوثها الزمني، ما يمكننا من الاستعلام عن كل تلك البيانات بطريقة سهلة من مصدر واحد، وتوفر هذه الأداة العديد من المزايا المهمة لعملية المراقبة كإرسال التحذيرات بناءًا على البيانات الواردة وغيرها.
• أداة Grafana والتي توفر لوحة لمراقبة البيانات تحوي مخططات بيانية بالعديد من الأشكال والصيغ وأدوات سهلة للاستعلام عن البيانات الواردة من مختلف المصادر التي يمكن ربطها مع هذه الأداة مثل أداة Prometheus وغيرها.
• الأداة Checkmk لمراقبة الخوادم والتطبيقات، حيث يتوفر نسخة مفتوحة المصدر منها يمكنك تشغيلها مجانًا، وللتعرف على الأداة وطريقة تثبيتها وإعدادها يمكنك مراجعة المقال مراقبة خادم لينكس باستخدام أداة Checkmk.

توضح الصورة التالية نموذجًا عن عمل أداة Grafana:

أتمتة سير العمل عبر CI/CD

تركز ممارسات DevOps على أتمتة العمليات المتكررة ابتداءً بالعمليات المساعدة لتطوير البرمجيات وصولًا لعمليات النشر، تدخل أنشطة CI/CD كجزء أساسي في ممارسات DevOps وهي ما سنتعرف عليه في الفقرة التالية.

التكامل المستمر والنشر المستمر CI/CD

التكامل المستمر والنشر المستمر CI/CD (اختصارًا للعبارة Continuous Integration/Continuous Delivery) تدخل في صلب ممارسات DevOps حيث:

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

يمكنك التعرف أكثر على تلك العمليات من مقال مدخل إلى التكامل المستمر والنشر المستمر CI/CD، وبمتابعة الفيديو التالي:

كيف نستعمل Jenkins

جنكيز Jenkins هو أحد الأدوات التي تساعد في إنشاء خط pipeline للتكامل والنشر المستمر وأتمتمه جميع العمليات الخاصة بهما، حيث توفر تكاملًا مع العديد من الخدمات الأخرى باستخدام الإضافات plugins، فبدئًا من التكامل مع مستودع الشيفرة المصدرية للبرنامج سواء Github أو Gitlab وصولًا لتحضير بيئات الاختبار والنشر وتنفيذ أوامر المختلفة ضمنها، ويمكنك التعرف على طريقة تثبيته وإعداده من مقال تثبيت Jenkins على أوبنتو 18.04.

أتمتة الخوادم والبنية التحتية

تصل ممارسات DevOps في أتمتة وتسريع وتسهيل عمليات النشر وإدارة البنية التحتية إلى أتمتة إنشاء البنية التحتية نفسها ولا تصبح مهمة إدارة شكل البنية التحتية مقتصرًا على فريق العمليات، بل يمكن حتى لفريق التطوير المشاركة بتوصيف البنية التحتية التي يلزمها البرنامج قيد التطوير، من هنا نشأت عدة ممارسات منها توصيف البنية التحتية ضمن الشيفرة المصدرية نفسها، فيُضاف ملف خاص ضمن الشيفرة المصدرية للبرنامج يوصّف ما يحتاجه من بنية تحتية، وفي مرحلة النشر تتولى برمجيات خاصة ترجمة ملفات التوصيف تلك إلى عمليات إنشاء وإعداد البنية التحتية لها من خوادم، وتستخدم عملية الأتمتة تلك خصوصًا في البيئة السحابية، ومن الأدوات الشهيرة لذلك Terraform و Puppet و Ansible.

Terraform

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

Puppet

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

وتعمل أداة Puppet، وفق أسلوب خادم-عميل، أي أنك تحتاج لتثبيت برمجية على كل خادم تريد إدارته ليتواصل بدوره مع أداة Puppet لاستقبال أوامر المهام التي تريد تنفيذها على تلك الخوادم.

ويمكنك التعرف عليها أكثر من سلسلة مقالات استخدام puppet لإدارة الخواديم.

Ansible

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

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

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

خارطة طريق تعلم DevOps

إليك خارطة طريق كاملة من الدخول في مجال DevOps حتى احترافه، ومهما كان دورك في عملية صناعة البرمجيات ستستفيد من بعض أو كل هذه المجالات في تطوير كفاءة وسرعة عملك:

سوق العمل

لديك عدة خيارات وتخصصات عمل في مجال DevOps، كلها تتعلق بالممارسات التي ذكرناها من إدارة للبنية التحتية إلى تطوير أدوات تساعد الفرق التي تعمل على تطوير المنتج ومنها:

• مهندس DevOps: ستكون مسؤولًا عن التخطيط والتطوير للأدوات المستخدمة في ممارسات DevOps، مثلًا قد يطلب منك تجهيز آلية للاختبار والتوصيل المستمر CI/CD، أو الإشراف على عمليات الأتمتة الخاصة بإصدار نسخ جديدة من المنتج، أو تجهيز نظام مراقبة أداء وأخطاء للمنتج تساعد فرق التطوير والعمليات وحتى الإدارة.
• مهندس نظم سحابية Cloud Engineer: ستكون مسؤولًا عن إدارة وتطوير الخوادم في بنية سحابية خدمةً للمنتج الرقمي، وإيجاد حلول للمشاكل التقنية التي قد تحدث، كتوسيع النظام حسب الحاجة وزيادة وثوقية وأمان ومرونة النظام بشكل عام، أو قد يطلب منك نقل نظام من استضافة عادية على خادم واحد إلى نظام سحابي للاستفادة من مزاياه، أو تقديم الاستشارات والحلول المتعلقة بتخطيط وإدارة البنية التحتية لنظام ما.

ختامًا

تعرفنا في هذا الدليل على مفهوم DevOps والممارسات المتعلقة به، كما تعرفنا على الأساسيات المتعلقة به من بنية تحتية وخوادم بأنواعها، والتقنيات المستخدمة كالخوادم الافتراضية والحاويات وأشهر أدوات إنشاءها وإدارتها، كما تعرفنا على عدة أدوات وتقنيات تفيد في أتمتة مختلف المهام في عملية تطوير المنتج الرقمي، كأدوات أتمتة سير عملية التطوير والتوصيل عبر CI/CD وصولًا لأتمتة تحضير وتجهيز البنية التحتية اللازمة للتشغيل.

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

اقرأ أيضًا

• لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم
• تحليل حمض DevOps النووي
• محاكاة عقلية DevOps

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

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

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

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

• استقلالية المطور: تعمل الفرق الصغيرة بالتوازي، ويمكنها تكرار دورات التطوير development cycles أسرع من الفرق الكبيرة.
• العزل والمرونة: فإذا توقف أحد المكونات نعزله لفترة قصيرة، بينما تستمر باقي مكونات التطبيق بعملها.
• قابلية التوسع: تستهلك المكونات الأصغر موارد أقل، ويمكن توسيع نطاقها لتلبية تزايد الطلب على هذا المكون فقط.
• أتمتة دورة الحياة: من السهل ملاءمة المكونات الفردية في أنابيب التسليم المستمر وسيناريوهات النشر المعقدة، وهذا غير ممكن في نظام المعمارية المتراصة.
• العلاقة بالعمل: تُقَسم بنى الخدمات المصغرة على طول حدود مجال العمل، مما يزيد الاستقلالية والفهم في المؤسسة.

يعتمد التعريف الشائع للخدمات المصغرة على كل خدمة صغيرة توفر الواجهة البرمجية للتطبيقات API مثل نقطة وصول، وتكون REST API غالبًا عديمة الحالة stateless، ويمكن الوصول إليها عبر بروتوكول HTTPS تمامًا مثل صفحة الويب القياسية، وتعدّ هذه الطريقة سهلةً للمطورين؛ لأنها لا تتطلب إلا أدوات ودوال يعرفها الكثير منهم.

هل مفهوم الخدمات المصغرة حديث؟

إن فكرة فصل التطبيقات إلى أجزاء أصغر ليست جديدةً، حيث تناولت نماذج برمجة أخرى هذا المفهوم، مثل مفهوم البنية الخدمية Service-oriented architecture، والتي تختصر إلى SOA، ومع ذلك أدت التطورات التكنولوجية الحديثة المرتبطة بالتوقعات المتزايدة "للتجارب الرقمية" إلى ظهور جيل جديد من أدوات وتقنيات التطوير المستخدمة لتلبية متطلبات التطبيقات التجارية الحديثة.

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

أهمية المصدر المفتوح للخدمات المصغرة

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

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

الارتباط بين الحاويات والخدمات المصغرة

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

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

تنسيق الخدمات المصغرة

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

يمكن استخدام المنصة مثل خدمة Platform as a service، والتي تختصر إلى PaaS، والتي تتيح للمطورين التركيز على كتابة التعليمات البرمجية عن طريق تجريد بعض تقنيات التنسيق الأساسية، أي تضمين الميزات الأساسية لهذه التقنيات، كما تسمح لهم باختيار مكونات مفتوحة المصدر جاهزة لأجزاء معينة من التطبيق بسهولة، مثل محرك تخزين قاعدة البيانات، أو خدمة التسجيل أو خادم التكامل المستمر أو خادم الويب، ولإدارة مكونات التطبيق مباشرةً تستخدم بعض أنظمة PaaS، مثل OpenShift، مشاريع أولية مثل Docker و Kubernetes، بينما يحاول البعض الآخر إعادة تنفيذ أدوات الإدارة بأنفسهم.

ماذا عن التطبيقات الحالية؟

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

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

ترجمة -وبتصرف- للمقال ?What are microservices من موقعopensource.com

اقرأ أيضًا

• حماية الخدمات المصغّرة عن طريق DevOps
• مقدمة في بناء تطبيقات الويب باستخدام إطار العمل Angular وقاعدة بيانات Firestore
• مدخل إلى تطبيقات الويب التقدمية PWA

يميل الكثير من الناس لإهمال جانبٍ معيّن من عملية تطوير البرمجيات، ألا وهو كيفية ترخيص البرنامج، حيث تُملي رخصة البرنامج كيفية استعمال وتوزيع الشيفرة المصدرية بواسطة المُرخّص لهم -أي المستخدمين-، وهذا من شأنه أن يؤثر بشدة على حجم تبنّي الحلّ التقني. تُباع معظم البرامج باستخدام رخصة احتكارية تسمح للناشر أو المطوّر بالاحتفاظ بكامل الحقوق الفكرية للبرنامج.

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

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

لمحة تاريخية

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

كان التعامل مع الحواسيب في هذه الفترة لمعظم الأشخاص مقتصرًا على أهدافٍ أكاديميّة أو بحثيّة. ومعنى هذا، أن موارد الحوسبة كانت تُشارَك أغلب الأحيان، وكان تغيير البرمجيات لخلق طرق أكثر فاعليّةً ووثوقيّةً لسير العمل مرحّبًا به للغاية. طوّر مشروع المارد Genie في جامعة كاليفورنيا بيركلي مثلًا، نظام تشغيل بيركلي لمشاركة الوقت؛ وهو نظام تشغيل بُنيَ من الصفر عن طريق التعديل على الشيفرة المصدرية لحاسوب SDS 930.

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

بدايات البرمجيات الحرة

كانت حركة البرمجيات الحرة Free Software Movement بالمعظم وليدة أفكار شخصٍ واحد هو ريتشارد ستالمان؛ حيث بدأ ستالمان دراساته في علوم الحاسوب بدايات السبعينيّات، وذلك قبل ولادة البرامج الاحتكاريّة بفترة قصيرة، وعملَ باحثًا في مختبرات جامعة ماساتشوستس للذكاء الاصطناعي في بدايات الثمانينيّات. كان ستالمان يُكِنّ كثيرًا من الإحباط اتجاه انتشار البرمجيات الاحتكارية بصفته عضوًا في مجتمع القرصنة الأكاديمي لما يقارب القرن، ورأى أن انتشارها ينتهك حق الناس في ابتكار وتحسين برمجياتٍ موجودة.

أطلق ستالمان في عام 1983 مشروعًا سمّاه باسم مشروع جنو GNU في سبيل إنشاء نظام تشغيل متكامل يسمح لمستخدميه برؤية وتعديل ومشاركة الشيفرة المصدريّة. حدّد ستالمان أهدافه من هذا المشروع في بيان جنو، والذي ذكر فيه بأنّ الرخص الاحتكارية تعيق تطوير البرمجيّات التي يقودها المجتمع، وهذا يؤدي بدوره إلى ركود الابتكار ويعيق تقدُّم التقنية.

يضيف هذا الأمر وفقًا لستالمان، عبئًا غير عادل على المستخدمين والمطوّرين الذين أمكنهم عوضًا عن ذلك تعديل الشيفرة البرمجيّة لتلائم حاجاتهم، أو تغييرها لتُستخدَم في غرضٍ جديد. لقد نُظِرَ إلى مشروع جنو على أنه استجابةً للبرمجيات الاحتكارية وتذكيرًا للناس بالعصر الذي سبقها، وذلك عندما كانت الشيفرة المصدريّة للبرمجيات تُشارَك بحريّة بهدف تطوير البرمجيات التعاوني.

بنى ستالمان في عام 1985 مؤسسة البرمجيات الحرّة، أو كما تُعرف باسم Free Softwar ،Foundation -أو اختصارًا FSS-، معتمدًا على مشروع جنو حجرًا للأساس، وهي مؤسسةٌ غير ربحية هدفها نشر ثقافة البرمجيات الحرة للعامّة. كما طور ستالمان فيما بعد رخصة جنو العموميّة GPL؛ وهي رخصة برمجيات تمنح الحق للمستخدم بتشغيل الشيفرة المصدرية ورؤيتها ومشاركتها بحرية مطلقة.

اعتمادًا على تعريف مؤسسة البرمجيات الحرة، يجب أن تتضمَن أي برمجيّة الحريات الأربع التالية لمستخدميها لتُصنّف برمجيّةً حرة:

• حرية تشغيل البرنامج متى أراد المستخدم، ولأي غرض.
• حرية معرفة طريقة عمل البرنامج، وتغييرها بناءً على رغبة المستخدم، فالوصول للشيفرة المصدرية هو شرطٌ مسبق لهذه الحرية.
• حرية توزيع نسخةٍ من الشيفرة المصدريّة لمعارفك.
• حرية توزيع نسخ من برنامجك المعدّل للآخرين؛ إذ يمكنك بفعل هذا إتاحة الفرصة لكامل المجتمع بالاستفادة من تعديلاتك. ويُعَد الوصول للشيفرة المصدرية شرطًا مسبقًا لهذه الحرية أيضًا.

تعد مؤسسة البرمجيات الحرّة أي برمجيةٍ تخفق بتحقيق هذه الحريات الأربع برمجيّةً غير حرّة، وبذلك غير أخلاقيّة.

ولادة البرمجيات مفتوحة المصدر

اختار ستالمان مصطلح "البرمجيات الحرّة" للدلالة على المبدأ الذي ينصّ على حرية تعديل الشيفرة المصدرية، ومشاركتها لأي برنامجٍ من مستخدميه وفق رغبتهم. خلقت هذه التسمية كثيرًا من الخلط لدى الناس على مرور السنوات، لاعتقادهم بأنّ البرمجيات الحرة هي البرامج التي يمكنهم الحصول عليها مجانًا دون دفع أي مقابل مادّي؛ وذلك نظرًا لازدواجية معنى كلمة Free، فهي تعني حرّ ومجاني في الوقت ذاته حسب السياق. توضّح مؤسسة البرمجيات الحرة هذا الخلط بالمعاني بواسطة مقولتها "فكّر بالكلمة بسياق حرية الرأي، وليس بسياق مشروبٍ مجاني".

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

الكاتدرائية والبازار

كتب إريك ريموند في عام 1997 -وهو مطوّرٌ ومناصرٌ للبرمجيات الحرة-، مقالًا بعنوان الكاتدرائية والبازار The Cathedral and the Bazaar؛ وهي مقالةٌ شهيرة توازن بين نمطين من أنماط تطوير البرمجيات المُستخدمة في تطوير مختلف مشاريع البرمجيات الحرّة. ترمز الكاتدرائية هنا للنمط الهرمي في تطوير البرمجيات، إذ تطور مجموعةٌ معينةٌ من المطورين البرمجيات، مثل عملية تطوير محرّر النصوص إيماكس Emacs على نظام جنو؛ بينما يرمز البازار لنمط التطوير المتمثّل بنشر الشيفرة المصدرية للعموم وتطويرها علنيًا، مثل عملية تطوير نواة لينكس.

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

عُقب الأفكار التي طرحها ريموند في مقالته الكاتدرائية والبازار، أطلقت شركة نتسكيب Netscape الشيفرة المصدريّة لمتصفح الويب الخاص بها المسمى بالمتواصل Communicator مجانًا ومفتوح المصدر للعموم في عام 1998؛ وسيشكّل هذا المتصفح أساس متصفح موزيلا فيرفكس 1.0 لاحقًا. فكّرت مجموعةٌ من مناصري البرمجيات الحرّة، متضمنةً ريموند ولينوس تورفالدس وفيل زيمرمان وآخرون، بإعادة تسويق حركة البرمجيات الحرة، وصرف تركيزها بعيدًا عن الدوافع الفلسفيّة والأخلاقية، مستلهمين ذلك من تجرِبة Netscape والإمكانية التجارية التي أتيحت لها بعد هذه العملية. اختارت هذه المجموعة تسمية "مفتوح المصدر" للدلالة على البرمجيات المشاركة مجانًا، آملين أن تظهر هذه التسمية الفائدة المضافة من نمط تطوير البرمجيات الاجتماعي والتعاوني.

بعد ذلك بوقت وجيز، أوجد كلٌّ من ريموند وبروس بيرنز مبادرة المصدر المفتوح Open Source Initiative -أو اختصارًا OSI-، لتشجيع استخدام التسمية الجديدة ونشر مبادئ البرمجيات مفتوحة المصدر، إذ طوّرت هذه المبادرة تعريف المصدر المفتوح؛ وهي لائحةٌ من عشرة مبادئ تصف معايير رخصة أي برمجية لتعدّ مفتوحة المصدر، وهي:

1. حرية إعادة التوزيع: يجب ألّا تمنع الرخصة أي طرفٍ من بيع أو منح البرمجيّة، مثل إضافةٍ لبرمجية أكبر منها تحتوي برمجياتٍ من مصادرٍ متعددة.
2. الشيفرة المصدرية: يجب أن يحتوي البرنامج على الشيفرة المصدرية، وأن يسمح بتوزيع البرنامج مثل شيفرة مصدريّة أو إصدار مُجمّع.
3. الأعمال المشتقة: يجب أن تسمح الرخصة بالتعديل وإنشاء برمجيات مشتقة، وأن تسمح بتوزيعها تحت شروط رخصة البرنامج الأصلي ذاتها.
4. الحفاظ على الشيفرة المصدرية للمؤلّف: يجوز للرخصة أن تمنع توزيع البرامج المعدّلة المبنية على الشيفرة المصدرية الأصل، وذلك في حالة سماح الرخصة بتوزيع ملفات الترقيع patch files مع الشيفرة المصدرية الأصل بهدف تعديل البرنامج بعد تجميعه Compiling.
5. يُمنَع التمييز ضدّ شخص ما أو مجموعة من الأشخاص: على الرخصة ألّا تميّز بين الأشخاص أو مجموعة من الأشخاص.
6. يُمنَع التمييز ضد مجال أو مهنة معيّنة: يجب ألا تمنع الرخصة أي أحدٍ من استخدام البرنامج بحرية بهدف توظيفه في أي مجال أو غرض.
7. توزيع الرخصة: يجب أن تُطبّق الحقوق الموجودة على رخصة البرنامج الأصلية على جميع البرامج المشتقة دون الحاجة لتضمين رخصة إضافية من الموزّعين.
8. لا ينبغي للرخصة أن تكون مخصصة لمنتج معين: لا يشترط على الحقوق المُضمّنة في برنامجٍ ما أن تكون فعالةً بحالة كان جزءًا من برنامج معين فقط.
9. لا ينبغي على الرخصة أن تضع قيودًا على برمجياتٍ أخرى: يجب ألّا تضع الرخصة قيودًا على برنامج معيّن مُوزعٍ مع البرنامج المرخّص.
10. على الرخصة أن تكون محايدة: لا يجوز أن تستند الرخصة على أي تقنيةٍ فردية أو نمط واجهة مستخدم.

الاختلافات بين البرمجيات الحرة ومفتوحة المصدر

يُعد الفرق بين مصطلح "البرمجيات الحرة" و"البرمجيات مفتوحة المصدر" ضئيلًا في العموم، ويأتي الاختلاف بالتسمية من فروقات فلسفيّة. تقول مبادرة المصدر المفتوح، أن كلا المصطلحين يعنيان الأمر ذاته، ويمكن استخدامهما بالتبادل في أي سياق كان. يفضّل مصطلح "مفتوح المصدر" ببساطة، لأنّه يُعتقد أنه المصطلح الأفضل الذي يظهر طبيعة البرمجيات ونوايا مؤلّفيها في كيفية استخدامها.

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

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

أسماء بديلة

ظهرت على مرّ السنوات كثيرٌ من التسميات الأخرى في سعيٍ منها لحسم الخلاف؛ منها "برمجية حرة ومفتوحة المصدر Free and Open-source Software" -أو اختصارًا FOSS-، وهي واحدةٌ من أكثر التسميات استخدامًا، وتُعد تسميةً وسيطةً بين الطرفين. اكتسبت التسمية "برمجية حرة Libre Software" (إذ تأتي كلمة Libre من كلمة حرية Liberty)، أنصارًا هي الأخرى وأصبحت الكلمة FLOSS رائجةً أيضًا.

تجدر الإشارة هنا إلى أنّ البرمجيات الحرة ومفتوحة المصدر مختلفةٌ كليًّا عن البرمجيات التي تنتمي للملكية العامة Public Domain؛ إذ تستمد البرمجيات الحرة ومفتوحة المصدر حرياتها من ترخيصها؛ بينما تستمد برمجيات الملكية العامة بعضًا من هذه الحريات من خلال الوقوع خارج نظام الترخيص. الفارق الواضح هنا هو أنه من الواجب توزيع كلٍّ من البرمجيات الحرة ومفتوحة المصدر تحت رخصة FOSS؛ بينما لا تخضع برمجيات الملكية العامة للشرط ذاته.

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

الخاتمة

يُستخدم كلا المصطلحين "برمجيات حرة" و"برمجيات مفتوحة المصدر" في معظم السياقات للدلالة على الشيء ذاته. وينبع تفضيل استخدام مصطلحٍ دونًا عن الآخر من اختلافٍ فلسفي بسيط؛ ولكن قد يصبح الفرق مهمًا بالنسبة للمطورين الذين يطوّرون برامجًا ويطلقونها للعالم، أو للنشطاء الذين يسعون لتغيير طريقة تفاعل الناس مع التقنية. بالتالي من المهم جدًا النظر للسلبيات والإيجابيات لمختلف الرُخَص والمتضمّنة الرُخَص الاحتكاريّة قبل نشر أيّ برنامج، واختيار الرُخصة المُثلى التي تناسب احتياجات الناشر.

إن كنتَ مهتمًّا بقراءة مزيدٍ من التفاصيل عن مختلف الرخص المناسبة لمشروعك القادم، تقدّم مؤسسة البرمجيات الحرة لائحةً من الرُخَص تبيّن تفاصيل كلّ من الرخص الحرّة وغير الحرّة. كما قد تكون صفحة الرخص والمعايير على موقع مبادرة المصدر المفتوح مفيدةً لك.

ترجمة -وبتصرف- للمقال The Difference Between Free and Open-Source Software لصاحبه Mark Drake.

اقرأ أيضًا

• ما المقصود بمصطلح مفتوح المصدر (open source)؟
• تعلم البرمجة
• تعرف على أنواع التراخيص الحرة التي تسمح لك ببيع المواد بشكل تجاري

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

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

لحل هذه المشاكل وُضِع نهج DevSecOps، حيث أنّ غايته الأساسية هي تأكيد فكرة أن الجميع في الفريق مسؤولون عن أمن المشروع، بحيث يكون التفكير بالقضايا المتعلقة بالأمن في كل مراحل حياة المشروع.

إجرائية DevSecOps

يبين الشكل 1 الآلية التي كانت متّبعةً في تطبيق مفاهيم الأمن ضمن عملية التطوير قبل ظهور نهجي DevOps و DevSecOps، فمن الواضح أن التفكير بالأمن لم يكن من أولويات فريق التطوير لأنّه يحدث في المراحل النهائية، أي عند البدء بتسليم المشروع، أينما تكون البرمجيات قد قُبِلت للدخول في مرحلة الإنتاج Production.

Michael Calizo

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

Michael Calizo, CC BY-SA 4.0

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

يعمل نهج DevSecOps على تضمين الأمن ضمن دورة حياة تطوير النظام ويُعاد تطوير المفاهيم الخاصة بالأمن مع كل دورة من دورات تطوير المنتج

Michael Calizo, CC BY-SA 4.0

عوائق تبني نهج DevSecOps

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

• استخدام عملية DevOps أو DevSecOps من مزود خارجي: يعني ذلك أنّ المفاهيم والعمليات المستخدمة تدور حول منتج ما يقدّمه المزود الخارجي ولن تستطيع المؤسسة لبناء المقاربة لأنها محدودة بما يقدمه المزود.
• توتر المدراء: يعاني المدراء من التخوف المستمر وخصوصًا عند تبني أي تقنية أو نهج جديد، بحيث يؤثر هذا الخوف والتوتر على قدرة المدير على اتخاذ القرار الصحيح.
• تجنّب محاولة إصلاح أي شيء ليس معطّلًا بالكامل: يميل معظم مدراء تقنيات المعلومات إلى تجنّب إجراء أية تغييرات في الخدمات التي تعمل حتى ولو وُجدت فيها عدة مشاكل طالما أن بعض نتائجها صحيحة. وفي بعض الأحيان، حتى مع نجاح النهج الجديد يميل مدراء تقنيات المعلومات إلى المحافظة على المنتج القديم والإجراءات التي أنتجته.
• تأثير نتفليكس Netflix وأوبر Uber: نجحت كل من شركتي نتفليكس ةأوبر بتطبيق نهج DevSecOps بنجاح، وتعمل العديد من الشركات على تقليدهم، ومع ذلك تفشل معظم هذه الشركات بسبب الاختلاف بين ثقافة هذه الشركات وثقافة بقية الشركات.
• قلة القياس: يجب أن تتم عملية قياس التحول ضمن المؤسسة أثناء تنبي نهج DevOps أو DevOpsSec، فهي من أهم المقاييس التي ينظُر إليها الأداء في عملية تسليم البرمجية أو الأداء العام للمؤسسة.
• الأمن المقاس بقوائم التحقق: يتبع فريق الأمن ما يعرف بقائمة التحقق، وهي تتضمن الخطوات التقليدية ذاتها في كل مرة. وانطلاقًا من ذلك ظهرت مقاربة "as code"، والتي تتطلب أن يتعلّم مختصو الأمن البرمجة وأن يتجنبوا الطرائق التقليدية لتطبيق الأمن ضمن المؤسسة.
• اعتبار فريق الأمن كفريق خاص: تظهر هذه المشكلة عندما يكون فريق الأمن مفصولًا عن فريق التطوير والتشغيل، مما يدفعهم إلى صرف الكثير من وقت فريق أمن المعلومات في مراجعة ومحاولة تحسين عمل الفريقين عوضًا عن تواجدهم إلى جانبهم أثناء عملية التطوير.

كيفية تبني نهج DevSecOps بنجاح

يُعَد تبني نهج DevSecOps أمرًا صعبًا، ولكن نظرًا للفوائد الكبيرة، يمكن العمل على تجنب العوائق التي أصبحت معروفةً جيدًا، وتُعَد ثقافة الأمن العائق الأكبر، فلكي تنجح هذه الثقافة ضمن المؤسسة يجب أن يكون تبنيها من أعلى هرم المؤسسة، ومن ثم تعميم هذه الثقافة على الموظفين.

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

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

• مهلة التغيير.
• وتيرة تركيب النظام.
• الزمن الوسطي للاستعادة.
• معدل فشل التغييرات.

تُعَد هذه المعايير أساسيةً عند التعرف على عملية ما ومحاولة تحديد جوانبها التي تحتاج تحسينًا. تسمى هذه المنهجية بالتحول المقاد بالأحداث Event-Driven Transformation، وتفيد في تحديد ما إذا كانت عملية تبني النهج الجديد ناجحةً أم فاشلة.

الاستنتاجات

يسمح تبني نهج DevOps - عندما يُتبنّى بطريقة صحيحة - للمؤسسة بتسليم المنتجات البرمجية بسرعة عالية، مما يُكسبها العديد من المزايا موازنةً بمنافسيها، حيث يحتاج تبني نهج DevOps وDevSecOps ما يأتي:

• تغيير الثقافات في المؤسسة.
• اقتناع الإدارة التنفيذية بالتغيير.
• مشاركة القادة والمتحمسين للنهج الجديد في عملية التبني.
• فرق متعددة الوظائف.
• بعض المؤشرات القابلة للقياس.

وبالتالي يُعَد تبني الثقافة السليمة الخطوة الأساسية لتبني نهج DevSecOps بطريقة صحيحة.

ترجمة -وبتصرف- للمقال How to adopt DevSecOps successfully لصاحبه Mike Calizo.

اقرأ أيضًا

• ما هي DevSecOps؟
• خمس طرق يغيّر بها مفهوم DevSecOps منظومتك الأمنية
• ثلاث خطوات لتأمين DevOps مفتوح المصدر
• ما المقصود بـ DevOps؟
• سلسلة تعرف على DevOps

يزداد كل يوم عدد المشاريع البرمجيّة المبنيّة بواسطة فرق تعمل من مناطق جغرافيّة مختلفة، وعلى الرغم من مميزات هذه الطريقة، إلا أن هذه الفرق تحتاج في بعض الحالات لربط حواسيبها مع بعضها البعض عبر الإنترنت والتعامل معها على أنها في نفس المكان، فعلى سبيل المثال، قد تستخدم أنظمة الموزّعة مثل Kubernetes أو تبني تطبيقًا معقدًا ذا خدمات متعدّدة وفي بعض الأحيان، سترّفع من الإنتاجية لو كان يمكنك التعامل مع الأجهزة على أن كل واحدة منها بجانب الأخرى لكي لا تتعرّض لخطر تعريض الخدمات غير جاهزة إلى الأنترنت، ويمكنك تحقيق هذا النموذج عن طريق شبكات المعرّفة بالبرمجيات Software-Defined Networking (أي SDN) التي تعتبر تكنولوجيا جديدة تسمح بإنشاء شبكة حيويّة مبنيّة بشكل كامل على البرمجيات.

سنستخدم في هذا الدرس ZeroTier One وهو تطبيق مفتوح المصدر يستخدم آخر تكنولوجيات SDN للسماح للمستخدمين بإنشاء شبكات محميّة وقابلة للإدارة والتعامل مع الأجهزة المتصلة على أنها في نفس المكان الفيزيائي. يوفّر لك تطبيق ZeroTier طرفيّة (console) للويب لإدارة الشبكة وتطبيقات الأطراف (endpoint) للعملاء، فهي تكنولوجيات مشفّرة ند للند، أي أنها بخلاف حلول VPN التقليديّة، فلا تحتاج عند الإتصالات المرور إلى خادم مركزي أو موجّه، فالرسائل ترسل مباشرةً من جهاز إلى آخر ونتيجة لذلك فهي فعالة جدا وتضمن الحد الأدنى من وقت الاستجابة.

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

في هذا الدرس، ستربط عميل وخادم معًا في شبكة نقطة-إلى-نقطة (point-to-point) بسيطة، وبما أن الشبكات المعرّفة بالبرمجيات لا تستخدم تصميم العميل/الخادم التقليدي، فلا يوجد خادم VPN مركزي للتثبيت والإعداد، فيبسّط هذا نشر الأداة وإضافة أي عقد إضافيّة. وبمجرّد تأسيس الاتصال، ستحصل على فرصة استخدام قدرات VPN ZeroTier عن طريق استخدام بعض وظائف لينكس الذكيّة للسماح لحركة الحزم بمغادرة شبكة ZeroTier من خادمك وإرشاد العميل لإرسال حركة حزمه إلى ذلك الاتجاه.

المتطلبات الأساسيّة

قبل البدء، سنحتاج إلى هذه المتطلبات:

• خادم أبونتو 18.04، وستحتاج على هذا الخادم، مستخدم عادي مع صلاحيات sudo والتي يمكنك إعدادها عن طريق درس إعداد خادم أبنتو 18.04.
• حساب على ZeroTier One والذي يمكنك إعداده عن طريق الذهاب إلى My ZeroTier، النسخة المجانيّة من هذه الخدمة تفي بالغرض في هذا الدرس.
• حاسوب محلي للانضمام إلى SDN كعميل. في الأمثلة في هذا الدرس، ستجد أن كل من الخادم والحاسوب المحلي يعملان على نظام لينكس أوبنتو لكن يمكنك استخدام أي نظام تشغيل موجود على صفحة ZeroTier.

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

الخطوة الأولى - إنشاء شبكة معرفة بالبرمجيات باستخدام ZeroTier One

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

سجّل دخولك على حساب ZeroTier، ثم أضغط على Networks في أعلى الشاشة، ومن ثم على Create. سيظهر لك اسم شبكة مولّد بشكل آلي، اضغط عليه لرؤية شاشة إعدادات الشبكة، تذكّر معّرف الشبكة Network ID الملوّن بالأصفر لأننا سنحتاجه في وقت لاحق.

إذا أردت، يمكنك تغيير اسم الشبكة إلى اسم آخر أو إضافة تعليق، وسيُحفظ أي تغيير ويطبّق بشكل آلي.

بعد ذلك اختر أي نطاق عناوين IPv4 سيتعامل معه SDN، على الجانب الأيمن من الشاشة في المساحة المسماة IPv4 Auto-Assign، اختر نطاق عناوين التي ستستخدمُه العقد الخاصة بك، بالنسبة لهذا الدرس، يمكنك اختيار أي مجال، ولكنك تأكد من اختيار Auto-Assign from Range.

تأكد من بقاء Access Control في الجانب الأيسر على قيمة Certificate ‏(Private Network)، يضمن هذا أنه يمكن للأجهزة المخوّلة فقط الاتصال بشبكتك، وليس أي شخص لديه معرّف الشبكة الخاص بك.

ستبدو الإعدادات كالتالي عند الإنتهاء منها:

في هذه المرحلة، أنهيّت أساس شبكة معرّفة بالبرمجيات، في الخطوة القادمة، سنثبّت برنامج ZeroTier على خادمك وأجهزة العميل للسماح لهم بالاتصال بـ SDN الخاص بك.

الخطوة الثانية - تثبيت عميل ZeroTier One على خادمك والحاسوب المحلي

بما أن ZeroTier One يعتبر برنامجًا جديدًا، فهو غير موجود في مستودعات برامج أوبنتو، ولهذا السبب، يوفّر ZeroTier سكربت التثبيت والذي سيُستخدم لتثبيت البرنامج و يحتوي على سكربت توقيع-GPG، أي سيتأكد من أن الشيفرة البرمجيّة التي ستثبتها منشورة بواسطة ZeroTier.

curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61' | gpg --import && if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi

يملك هذا السكربت أربعة أجزاء أساسية وهذا تفسير كل جزء منها:

curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61'

سيستدعي هذا الجزء مفتاح ZeroTier العام من `MIT.

gpg --import

يضيف هذا القسم مفتاح العام لـ ZeroTier إلى سلسلة المفاتيح المحلية للتخويلات للوثوق في الحزم التي ترغب في تثبيتها. الجزء التالي من الأمر سيُنفّذ فقط إذا انتهى استدعاء GPG بنجاح.

if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z"

يمكنك ترجمة هذا القسم إلى : إذا كان سكربت التثبيت الموقّع بالتشفير منزّل من ZeroTier.com ومّر من GPG ولن يعترض عليه على انه غير موقّع من ZeroTier، اعرض هذه المعلومة على الشاشة.

sudo bash; fi

يأخذ هذا القسم السكربت المتحقق منه في ويٌنفّذه قبل الانتهاء.

تحذير: لا تنزّل شيء من الانترنت وتربطه ببرنامج آخر إلا لو تأكدت منه من مصدر موثوق. يمكنك فحص الشيفرة المصدرية لبرنامج ZeroTier على صفحة GitHub الخاصة بالمشروع إذا رغبت في ذلك.

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

بمجرّد أن ينتهي السكربت من العمل، ستجد سطرين مشابهين للسطرين التاليين، سجّل عنوان ZeroTier (بدون الأقواس المعقوفة) واسم النظام الذي ولّد هذا العنوان لأنك ستحتاجهم فيما بعد:

*** Waiting for identity generation...

*** Success! You are ZeroTier address [ 916af8664d ].

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

الخطوة الثالثة - الانضمام إلى شبكة ZeroTier الخاصة بك

بعد تشغيل برنامج ZeroTier على كل من الخادم والعميل، أنت الآن مستعد لتوصيلهم إلى الشبكة التي أنشأتها في طرفيّة ويب ZeroTier.

استخدم الأمر التالي لتوجيه العميل الخاص بك لطلب الوصول إلى شبكة ZeroTier عن طريق المنصة الخاصة بهم، سيُرفض الطلب الأول للعميل وسيبقى معلّقًا، لكننا سنصلح ذلك بعد لحظات. تأكد من استبدال NetworkID بمعرّف الشبكة الذي سجلناه سابقًا في نافذة إعداد الشبكة.

sudo zerotier-cli join NetworkID

ستكون النتيجة كالتالي:

200 join OK

ستحصل على رسالة 200 join OK لتأكيد أن خدمة ZeroTier قد اشتغلت على خادمك، وإذا لم تحصل على هذه الرسالة، تأكد من معرّف الشبكة الذي أدخلته.

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

في العمود الأول Auth?‎، ضع إشارة على المربع لتخويلهم للانضمام إلى الشبكة، سيخصص متحكم ZeroTier عنوان IP للخادم وللعميل من النطاق الذي اخترته سابقا لاستخدامهم في المرة القادمة عند استدعاء SDN.

يحتاج تخصيص عناوين IP بعض الوقت، في أثناء انتظار انتهاء العملية، يمكنك توفير Short Name و Description للعقد في قسم Members. وبهذا، ربطت النظامين إلى شبكة المعرّف بالبرمجيات الخاصة بك.

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

الخطوة الرابعة - التحقق من الاتصال

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

من الطرق السهلة لإيجاد عنوان IP الخاص بـ ZeroTier لكل جهاز هو النظر إلى قسم Members في طرفيّة ويب ZeroTier، ربما ستحتاج إلى تحديث الصفحة بعد التخويل للخادم والعميل قبل ظهور عناوين IP الخاصة بهم، وبدلًا من ذلك، توجد طريقة أخرى لفعل هذا وذلك عن طريق استخدام سطر أوامر لينكس لإيجاد هذه العناوين، استخدم الأمر التالي على كِلا الجهازين، عنوان IP الأول الذي يظهر في القائمة هو الذي سنستخدمه، في المثال أدناه، العنوان هو 203.0.113.0.

ip addr sh zt0 | grep 'inet'

ستكون المخرجات كالتالي:

inet 203.0.113.0/24 brd 203.0.255.255 scope global zt0
inet6 fc63:b4a9:3507:6649:9d52::1/40 scope global
inet6 fe80::28e4:7eff:fe38:8318/64 scope link

لتجربة الاتصال بين الأجهزة، استخدم الأمر ping من أحد الأجهزة متبوع باسم عنوان IP الآخر، فعلى سبيل المثال، على جهاز العميل:

ping your_server_ip

وعلى الخادم:

ping your_client_ip

إذا عادت نتيجة من الجهاز الآخر (كما هو موضّح في المخرجات أسفله)، فإن كلا العقدين يتواصلان عبر SDN بنجاح.

PING 203.0.113.0 (203.0.113.0) 56(84) bytes of data.
64 bytes from 203.0.113.0: icmp_seq=1 ttl=64 time=0.054 ms
64 bytes from 203.0.113.0: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 203.0.113.0: icmp_seq=3 ttl=64 time=0.043 ms

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

والآن، بعد أن تأكدت من أن الخادم والعميل يمكنهم التواصل مع بعضهم البعض، واصل القراءة لتتعلم كيف يمكنك ضبط الشبكة لتوفير بوابة خروج (exit gateway) وبناء VPN خاص بك.

الخطوة الخامسة - تفعيل قدرات VPN الخاصة بـ ZeroTier

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

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

تفعيل ترجمة عنوان الشبكة وإعادة توجيه عنوان IP

ترجمة عنوان الشبكة (Network Address Translation) والذي يعرف بـ "NAT"، هي طريقة تمكّن الموجّه (router) من قبول الحزم في واجهة واحدة موسومة بعنوان IP المرسل ومن ثم تبديل ذلك العنوان بعنوان الموجّه. يحفظ سجل هذا التبادل في ذاكرة الموجّه بحيث عند عودة الحزم في الاتجاه المعاكس، يمكن للموجّه ترجمة عنوان IP مرّة أخرى إلى عنوانه الأصلي. يستخدم NAT في العادة للسماح لعدة حواسيب للعمل باستخدام عنوان IP واحد ظاهر للعموم، والذي هو مفيد بالنسبة لخدمة VPN، ومثال على NAT، الموجه المنزلي الذي يقدمه لك مزوّد خدمة الإنترنت لتتصل جميع الأجهزة في منزلك بالإنترنت. فيشترك حاسوبك وهاتفك وأجهزتك اللوحية في نفس عنوان IP لشبكة الأنترنت، لأن الموجّه يستخدم NAT.

عن رغم من أن الموجه هو من يقوم بـ NAT، فيمكن للخادم فعل ذلك أيضًا، وعن طريق هذه الخطوة، ستستفيد من هذه الوظيفة في خادم ZeroTier لتفعيل قدرات VPN.

إن عملية إعادة توجيه عنوان IP ‏(IP forwarding) هي وظيفة يقوم بها الموجّه أو الخادم لتوجيه حركة الحزم من واجهة إلى أخرى إذا كانت عناوين IP في مناطق مختلفة. إذا كان الموجّه متّصل بشبكتين، فيسمح إعادة توجيه عنوان IP بتوجيه الحزم فيما بينهم. يبدو هذا سهلًا، لكن قد تواجه صعوبات في تطبيقه، أما في هذا الدرس، فمجرّد تعديل بضعة ملفات إعداد.

بتفعيل إعادة توجيه IP، ستصل حركة الحزم للـ VPN من عميلك في شبكة ZeroTier إلى واجهة ZeroTier للخادم، وبدون هذه الإعدادات، ستحذف نواة لينكس (افتراضيًا) أي حزم تصل لواجهة ليست لها، وهذا هو سلوكها الافتراضي، لأنه في العادة أي حزم تصل إلى واجهة لديها عنوان وصول شبكة أخرى قد تكون بسبب خطأ من الموجه في الشبكة.

اعتبر إعادة توجيه عنوان IP على أنه إعلام نواة لينكس أنه يمكن إعادة توجيه الحزم بين الواجهات، فالوضع الافتراضي هو 0 أي مغلق، والذي ستحوله إلى 1 أي مفعّل.

شغّل الأمر التالي لرؤية الإعدادات الحالية:

sudo sysctl net.ipv4.ip_forward

ستبدو المخرجات كالتالي:

net.ipv4.ip_forward = 0

لتفعيل إعادة توجيه عنوان IP، عدّل على ملف ‎/etc/sysctl.conf في خادمك وأضف السطر المطلوب، يسمح هذا الملف للمدراء بتجاوز إعدادات النواة الافتراضية وسيظّل يعمل دائما حتى بعد إعادة التشغيل لذلك لا تقلق بشأن إعداده مرّة أخرى. استخدم nano أو محرر النصوص المفضّل لديك لإضافة السطر التالي إلى نهاية الملف:

sudo nano /etc/sysctl.conf

ثم أضف السطر التالي:

. . .
net.ipv4.ip_forward = 1

اغلق الملف بعد حفظه ثم شغّل الأمر التالي لإعلام النواة بالتغييرات.

sudo sysctl -p

سيتبني الخادم أي تغييرات في الإعدادات من الملف وسيطبقها فورا دون الحاجة إلى إعادة التشغيل، شغل نفس الأمر الذي كتبناه سابقا وستجد أن إعادة توجيه IP مفعّل.

sudo sysctl net.ipv4.ip_forward

ستكون المخرجات كالتالي:

net.ipv4.ip_forward = 1

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

لإضافة هذه القواعد من سطر الأوامر، ستحتاج أولًا إلى معرفة أسماء التي أعطاها أوبنتو لكل من واجهة ZeroTier وواجهة إثرنت Ethernet للإنترنت العادي، سيكونان في العادة zt0 و eth0 لكن ليس دائمًا.

لإيجاد أسماء هذه الواجهات، استخدم الأمر ip link show، هذه الأداة هي جزء من iproute2 وهي مجموعة من أدوات مساحة المستخدم والتي تأتي مثبتة في أبنتو بشكل افتراضي:

ip link show

في مخرجات هذا الأمر، ستجد أسماء الواجهة بجانب الأرقام التي تعرّف الواجهة في القائمة، إذا وجدّت أسماء مختلفة عن الموجودة في المثال، فاستخدمها في بقيّة الدرس:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 72:2d:7e:6f:5e:08 brd ff:ff:ff:ff:ff:ff
3: zt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether be:82:8f:f3:b4:cd brd ff:ff:ff:ff:ff:ff

وبعد ذلك استخدم iptables لتفعيل ترجمة عناوين الشبكة (Network-Address-Translation) وعمليّة تنكر IP ‏(IP masquerading):

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

اسمح بتوجيه حركة الحزم وراقب الاتصالات النشطة:

sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

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

sudo iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT

من المهم تذكّر أن قواعد iptables التي وضعتها لهذا الخادم لا تبقى عند إعادة التشغيل، ستحتاج إلى حفظ هذه القواعد لإعادتها في حالة إعادة تشغيل الخادم، شغّل الأوامر في الأسفل وسترى كيف يمكنك بشكل مختصر حفظ قواعد IPv4 الحاليّة (IPv6 غير مطلوبة في الوقت الحالي):

sudo apt-get install iptables-persistent

sudo netfilter-persistent save

بعد تنفيذ الأمر sudo netfilter-persistent save من الأفضل إعادة تشغيل الخادم للتأكد من أن القواعد قد حفظت بشكل صحيح، وأسهل طريقة للتأكد من ذلك هو عن طريق تشغيل sudo iptables-save والذي سيعرض الإعداد الموجود حاليًا في ذاكرة إلى الطرفية. إذا رأيت قواعد مشابهة للقواعد في الأسفل بغض النظر عن التنكر، إعادة التوجيه IP وواجهة zt0، فإنها حفظت بشكل صحيح.

sudo iptables-save

المخرجات:

# Generated by iptables-save v1.6.0 on Tue Apr 17 21:43:08 2018
. . .
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
. . .
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i zt0 -o eth0 -j ACCEPT
COMMIT
. . .

بعد تطبيق هذه القواعد على الخادم، يمكنك الآن نقل الحزم بين شبكة ZeroTier والانترنت العام، ومع ذلك، لن يعمل VPN إلا لو أُعلمت شبكة ZeroTier نفسها أن الخادم جاهز لاستخدامه كبوابة خروج (gateway).

تفعيل خادمك لإدارة التوجيه العمومي (Global Route)

من أجل أن يتمكن خادمك من معالجة حركة الحزم من أي عميل، يجب أن تتأكد من معرفة العملاء الآخرين في شبكة ZeroTier كيف يرسلون حركة الحزم له، وذلك عن طريق إعداد توجيه عمومي (Global Route) في طرفيّة ZeroTier، يعرّف الأشخاص المختصين في شبكات الحاسوب بالتوجيه الافتراضي (Default Route)، وتعني أين سيرسل كل عميل حركة الحزم الافتراضية، على سبيل المثال، منع توجيه حركة الحزم لمناطق أخرى محددّة.

اذهب إلى أعلى يمين صفحة شبكات ZeroTier وأضف موجّه جديد بمعاملات التالية، يمكنك إيجاد عنوان IP ZeroTier لخادمك في قسم Members من صفحة إعدادات شبكة ZeroTier، وفي حقل network/bits، أضف 0.0.0.0/0 وفي حقل (LAN)، أدخل عنوان IP خادم ZeroTier.

بعد اضافة هذه التفاصيل، اضغط على رمز "+" وسترى ظهور قاعدة جديدة أسفل القاعدة الموجودة، وسترى كرة برتقالية للإعلام بأنه توجيه عمومي.

لم يتبقى سوى إعداد العملاء قبل أن يعمل VPN.

إعداد عملاء لينكس

ملاحظة: الأوامر الموجودة في هذا القسم تطبّق فقط على عملاء لينكس، بالنسبة إلى تعليمات إعداد عملاء ويندوز وmacOS فستجدها في القسم القادم.

إذا كان العميل يعمل بنظام لينكس، فستحتاج إلى القيام بتغييرات يدوية في ملف ‎/etc/sysctl.conf . هذه الإعدادات مطلوبة لتغيير معلومات النواة حول مسار العودة المقبول من حركة حزم العميل، وبسبب الطريقة التي أُعدّ به ZeroTier VPN، فحركة الحزم القادمة من خادمك إلى عميلك قد تظهر أنها تأتي من عنوان شبكة مختلف عن الذي أرسلت إليه، وبشكل افتراضي، سترى نواة لينكس أنها غير صالحة وستحذفها، لذلك من الضروري تغيير هذا السلوك.

افتح ملف ‎/etc/sysctl.conf على جهاز العميل:

sudo nano /etc/sysctl.conf

وأضف السطر التالي:

. . .

net.ipv4.conf.all.rp_filter=2

أغلق الملف بعد حفظه وشغّل الأمر التالي لتطبيق التغييرات:

sudo sysctl -p

بعد ذلك، اخبر برنامج عميل ZeroTier أن الشبكة مسموح لها بحمل حركة الحزم الافتراضيّة، أي أنه سيعدّل على توجيه العميل، ويجب تفعيلها بشكل يدوي لأن الأمر حساس، سيعرض هذا الأمر هيكل الإعدادات، تأكد من أن allowDefault=1 في الأعلى:

sudo zerotier-cli set NetworkID allowDefault=1

إذا أردت في أي وقت ايقاف استخدام ZeroTier كـ VPN مع إبقاء حركة الحزم داخله، أعد قيمة allowDefault إلى 0:

sudo zerotier-cli set NetworkID allowDefault=0

في كل مرة تعيد تشغيل جهاز العميل، ستعود قيمة allowDefault=1 إلى 0 فتذكّر إعادة تنفيذها من أجل تفعيل وظيفة VPN.

تعمل خدمة ZeroTier بشكل افتراضي عند التشغيل لكل من عميل لينكس والخادم، وإذا لم ترغب بهذا، فيمكنك إيقاف تشغيلها عند اقلاع الحاسوب عن طريق الأمر التالي:

sudo systemctl disable zerotier-one

إذا أردت استخدام نظام تشغيل آخر على شبكة ZeroTier فأقرأ القسم التالي، وخلاف لذلك انتقل إلى القسم الذي بعده.

إعداد عملاء لا يعملون بنظام لينكس

لا يقتصر عمل برنامج عميل ZeroTier على نظام لينكس فقط، فيمكن دعم حتى الهواتف الذكية، فالبرنامج متوفّر لأنظمة ويندوز وmacOS وأندرويد وiOS و حتى أنظمة التشغيل المتخصصة كنظام QNAP و Synology و WesternDigital NAS.

لضم عملاء يعملون بأنظمة macOS وويندوز إلى الشبكة، شغّل أداة ZeroTier (والتي ثبتها في الخطوة 1) ومن ثم أدخل NetworkID في الحقل قبل أن تضغط على Join. تذكر بأن تعود إلى طرفيّة ZeroTier لاختيار زر Allow لتخويل النظام الجديد إلى شبكتك.

تأكد من وضع اشارة على المربع المسمى Route all traffic through ZeroTier، وإذا لم تفعل ذلك، فالعملاء سيرتبطون بشبكة ZeroTier لكن لن يتمكنوا من ارسال حركة حزم الإنترنت عبرها.

استخدم أداة للتأكد من عنوان IP مثل ICanHazIP للتأكد من أن الحزم تظهر إلى الإنترنت من خلال عنوان IP الخادم، وللتأكد من ذلك، أضف عنوان URL التالي إلى شريط عنوان متصفحك، وسيظهر لك هذا الموقع عنوان IP الذي يراه الخادم (وبقيّة الانترنت) للوصول إلى الموقع: http://icanhazip.com.

وبانتهاء هذه الخطوات، يمكنك بدء استخدام VPN الخاص بك كما تريد، القسم الاختياري التالي سيغطي ميّزة قواعد التدفق (flow rules) الموجودة في ZeroTier SDN، لكنها ليست مطلوبة لعمل وظيفة VPN.

الخطوة السادسة - إدارة التدفق (اختياري)

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

هذه القدرة مهمة للغاية ويسري مفعولها بشكل فوري تقريبًا، لأن أي تغييرات على جدول التدفّق ترسل إلى أعضاء الشبكة ويسري مفعولها بعد لحظات. لتعديل قواعد التدفّق، إذهب إلى واجهة مستخدم ويب ZeroTier، واضغط على تبويب Networking، وانزل قليلا إلى الأسفل حتى ترى مربع يسمى Flow Rules (والذي سيتوسع)، ويفتح هذا حقل نصي حيث يمكنك إضافة القواعد التي ترغب بها. ستجد كتيّب كامل مع طرفيّة ZeroTier في المربع الذي أسفل مربع ادخال Flow Rules ويسمى Rules Engine Help.

وإليك بعض الأمثلة لقواعد ستساعدك على اكتشاف هذه الوظيفة.

لحظر أي حركة حزم ملزمة لخادم DNS جوجل 8.8.8.8، أضف هذه القاعدة:

drop
    ipdest 8.8.8.8/32
;

لإعادة توجيه أي حركة حزم ملزمة لخادم DNS جوجل العامل إلى إحدى عقد ZeroTier، أضف القاعدة التالية، يمكن أن يكون هذا بمثابة اختبارًا ممتازًا لتجاوز عمليات بحث (lookups) DNS:

redirect NetworkID
    ipdest 8.8.8.8/32
;

إذا كان لشبكتك متطلبات حماية خاصة، يمكنك إزالة أي نشاط على منافذ FTP و Telnet و HTTP غير المشفّر عن طريق اضافة هذه القاعدة:

drop
    dport 80,23,21,20
;

عندما تنتهي من إضافة قواعد التدفّق، اضغط على زر Save Changes وسيسجّل ZeroTier التغييرات.

خاتمة

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

لتلخيص الأمر، لقد تعلمت كيفية استخدام ZeroTier كموفّر SDN، بالإضافة إلى إعداد وربط العقد إلى الشبكة، ولقد علمك عنصر VPN كيف يعمل التوجيه وكيف تعمل الشبكة، وسيسمح لك هذا الدرس باستخدام تكنولوجيا التحكم بالتدفّق.

والآن بعد أن أضفنا شبكة نقطة-إلى-نقطة، يمكنك جمعها مع تكنولوجيا أخرى مثل مشاركة الملفات، وإذا كان لديك NAS أو خادم ملفات في البيت فيمكنك ربطه بـ ZeroTier واستخدامه. إذا أردت مشاركته مع أصدقائك، فيمكنك أن تفسّر لهم كيف ينضمون إلى شبكة ZeroTier الخاصة بك.

ترجمة -وبتصرف- للمقال Getting Started with Software-Defined Networking and Creating a VPN with ZeroTier One لصاحبه Sam Cater

غالبًا ما تشكّل الخطوط مشكلةً للعديد من مستخدمي الحاسوب، فهل سبق لك مثلًا وأن صَممت منشورًا رائعًا، وعند أخذك للملف للطباعة في مكان ما وجدت أنّ جميع عناوين تصميمك تحولت إلى خط Arial لأن تلك الطابعة لا تملك الخط المزخرف الجميل الذي استخدمته في التصميم؟ بالطبع هناك طرق للحيلولة دون ذلك: يمكنك مثلًا تحويل الكلمات في خطوط معيّنة إلى «مسارات» ( paths)، أو تجميع الخطوط في PDF، أو تجميع الخطوط مفتوحة المصدر مع ملفات التصميم خاصتك، أو - على الأقل – تسجيل قائمة الخطوط المطلوبة. ومع ذلك لا تزال هذه تُعدّ مشكلة لأننا بشر وننسى.

يواجه الويب ذات النوع من المشاكل. حتى وإن كان لديك فهمًا لأساسيات CSS، فمن المحتمل أنك رأيت نوعًا من التصاريح كهذا:

h1 { font-family: "Times New Roman", Times, serif; }

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

خطوط الويب webfonts

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

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

خطوط الويب المُستضافة ذاتيًّا

إنّ أول شيء تحتاجه هو خط مرخّص ترخيصًا مفتوحًا. قد يكون هذا أمرًا مربكًا بعض الشيء إن لم تكن معتادًا على التفكير في تراخيص البرامج المبهمة أو الاهتمام بها، خاصّة أنه يبدو وكأن كل الخطوط مجانيّة. يُدرك عدد قليل جدًا منّا أنّهم يدفعون مالًا من أجل الخطوط، مع العلم أنّ معظم الناس لديهم خطوط مرتفعة الثمن على حواسيبهم. فقد يكون حاسوبك وبفضل اتفاقيات الترخيص قد شُحِن مع خطوط لا يُسمح لك قانونيًا بنسخها وإعادة توزيعها. إنّ بعض الخطوط مثل Arial و Verdana و Calibri و Georgia و Impact و Lucida و Lucida Grande و Times و Times New Roman و Trebuchet و Geneva والعديد من الخطوط الأخرى مملوكة لشركة Microsoft و Apple و Adobe. إذا اشتريت جهاز حاسوب مُثبّت عليه مسبقًا نظام تشغيل Windows أو MacOS، فأنت إذًا تدفع مقابل استخدام حزمة الخطوط المُضمّنة، لكنك لا تملك هذه الخطوط ولا يُسمح لك بتحميلها إلى خادم الويب (ما لم يُذكر خلاف ذلك).

إنّ جنون المصدر المفتوح لحسن الحظ قد وصل إلى عالم الخطوط منذ زمن طويل، وهناك مجموعات ممتازة من الخطوط المرخّصة ترخيصًا مفتوحًا من المنظمات والمشاريع مثل League of Moveable Type وFont Library وOmnibus Type وحتى Google وAdobe.

يمكنك استخدام تنسيقات ملفات الخطوط الأكثر شيوعًا، بما في ذلك TTF و OTF و WOFF و EOT وما إلى ذلك. سأستخدم في هذا المثال الخط Sorts Mill Goudy لأنّه يتضمن إصدار WOFF (تنسيق خط Open Web، طٌوِّر جزئيًا من قبل Mozilla). تعمل التنسيقات الأخرى على أيّة حال بنفس الطريقة.

لنفترض أنّك تريد استخدام الخط Sorts Mill Goudy على صفحة الويب خاصتك:

1. حمّل ملف GoudyStM-webfont.woff إلى خادم الويب الخاص بك:

scp GoudyStM-webfont.woff seth@example.com:~/www/fonts/

قد يوفّر مضيفك أيضًا أداة تحميلٍ رسوميّة من خلال cPanel أو لوحة تحكم ويب مشابهة.

2. أضف قاعدة ‎@font-face مشابهة لما يلي في ملف CSS الخاص بموقعك:

@font-face { 
  font-family: "titlefont"; 
  src: url("../fonts/GoudyStM-webfont.woff"); 
}

قيمة الواصفfont-familyهي تسمية تختارها للخط. إنها اسم أو وصف مألوف للإنسان بغض نظر عمّا تمثله قاعدة ‎@font-face للخط. استَخدمتُ القيمة "titlefont" في هذا المثال لأنني أتصوّر أنّ هذا الخط سيُستخدم للعناوين الرئيسية في موقع وهميّ. يمكنك ببساطة استخدام أيّة قيم أخرى مثل "officialfont" أو "myfont".

قيمة الواصفsrc تُحدَد المسار إلى ملف الخط. يجب أن يكون هذا المسار موافقا لبنية ملف الخادم الخاص بك، لدي في هذا المثال المجلد fonts بجانب المجلد css. قد لا يكون موقعك منظمًا بهذه الطريقة، لذا اضبط المسارات بما يناسبك مع الآخذ بالحسبان أن نقطة واحدة (.) تعني هذا المجلد ونقطتان (..) تعنيان مجلدًا آخرًا للخلف (المجلد الحاوي [الأب] للمجلد الحالي).

3. الآن وبعد تحديد اسم الخط وموقعه، يمكنك استدعائه في أي صنف class من أصناف CSS أو معرّف ID تريده. على سبيل المثال، إذا كنت ترغب في عرض <h1> بخط Sorts Mill Goudy، فعليك جعل قاعدة CSS الخاصّة به تستخدم اسم خطك المخصّص:

h1 { font-family: "titlefont", serif; }

أنت الآن تستخدم وتَستضيف خطوطك الخاصّة.

ترجمة وبتصرف للمقال How to host your own webfonts لصاحبه Seth Kenlon

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

1. BlueHost

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

• استضافة مشتركة - يعدّ خيارًا مناسبًا للمصممين والمدونين الّذين لا يتوقعون ملايين الزيارات شهريًا.
• استضافة VPS والاستضافة المخصصة - تعدّ خيارًا مناسبًا للأعمال الّتي تحتاج المزيد من موارد المخدم. ويوجد خبراء جاهزين لمساعدتك على مدار ساعة وطيلة أيام الأسبوع.
• استضافة الموزّعين - يعدّ هذا الخيار مناسبًا للأشخاص الّذين يعملون في مجال بيع خدمات الاستضافة حيث يمكنك شراؤها واستخدام مساحة التخزين في القرص الصلب المخصصة وعرض النطاق (Bandwidth) لاستضافة مواقع العملاء.

وهذه بعض الميزات فيما يخص خيار المصممين والمدونين وتعرض الشركة العديد من الميزات منها:

• استضافة نطاقات (Domains) بشكل غير محدود.
• مساحة استضافة بشكل غير محدودة.
• شهادة SSL مجانية.
• استقبال 100 دولار أمريكي كهدية من شركة غوغل و100 من شركة مايكروسوفت عند إنفاقك 25 دولار أمريكي في حسابك الجديد على منصاتهم الإعلانية.
• تراسل بيانات بشكل غير محدود.
• حسابات بريد إلكتروني بشكل غير محدود.
• نطاق (Domain) مجاني مخصص.

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

• وحدة معالجة مركزية 4×2.3 غيغا هرتز.
• ذاكرة وصول عشوائي (RAM) بسعة 4 غيغا بايت.
• سعة تخزين 500 غيغا بايت (منسوخة احتياطيًا في حال فشل النسخة الأصلية).
• 5 تيرا بايت عرض النطاق (Bandwidth).
• 3 عناوين IP.
• شهادة SSL مجانية.
• اسم نطاق مجاني.
• دعم فني على مدار الساعة وطيلة أيام الأسبوع.
• ضمان استرداد أموالك خلال 30 يوم.

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

• اسم نطاق مجاني.
• تثبيت تلقائي لمتجر WooCommerce.
• شهادة SSL مجانية.
• تراسل بيانات بشكل غير محدود.
• استقبال 100 دولار أمريكي كهدية من شركة غوغل و100 من شركة مايكروسوفت عند إنفاقك 25 دولار أمريكي في حسابك الجديد على منصاتهم الإعلانية.
• عنوان IP مخصص.

ويمكنك الحصول على الخطة الابتدائية والّتي تأتي مع مميزات أخرى مثل:

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

2. WP Engine

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

جميع الخطط المُقدمة من قبل هذه الشركة تأتي مع ضمان استرداد أموالك بالكامل خلال 60 يومًا إذا لم تعجبك الخدمة أو المنصة وتشمل بعض عروضهم ما يلي:

• النسخ الاحتياطي اليومي.
• استعادة النسخ الاحتياطي بنقرة زر واحدة.
• أمان عالي الجودة.
• تفعيل التخزين المؤقت (Caching) بشكل تلقائي.
• إلغاء الخدمة بشكل مجاني خلال 60 يومًا.

وحاليًا تقدم الشركة خطة للشركات الناشئة بمبلغ 35.00 دولار أمريكي شهريًا وهي تشمل ما يلي:

• تثبيت موقع ووردبريس عدد 1.
• 25000 زيارة للموقع شهريًا.
• تبادل بيانات 50 غيغا بايت.
• سعة التخزين تساوي 10 غيغا بايت.
• أكثر من 35 قالب جاهز للتثبيت.
• بيئة متكاملة لتطوير معتمدة على إطار العمل Genesis.
• دعم فني على مدار الساعة وطيلة أيام الأسبوع.
• قابلية نقل الموقع على إستضافة أخرى.
• إصدار PHP 7.3.
• خوادم موزعة CDN (وهي شبكة توصيل المحتوى تتألف من مجموعة من الخوادم المتزامنة والموزعة على شبكة الانترنت في أماكن جغرافية مختلفة، تحتوي على نسخ من المواقع الّتي تضيفها شركة الإستضافة، وفي حال رغب المستخدم في الوصول لمحتوى على الانترنت مدعوم بهذه الميزة فإن الشبكة ستقوم بارساله لأقرب خادم لموقعة الجغرافي يحتوى على نسخة من المحتوى المطلوب) من أجل سرعة الوصول من كافة المناطق.
• أداة تقيس مدى تفاعل صفحة الويب.

تشمل الخطط الأخرى ما يلي:

• الخطة الاحترافية - تتضمن نفس ميزات الخطة الشخصية مع مزيد من موارد الخادم وتبدأ أسعارها من 99.00 دولار أمريكي شهريًا.
• خطة الأعمال (Business) - تأتي بنفس الميزات مع مزيد من موارد الخادم المتاحة في الخطة الاحترافية وذلك لاستضافة مواقع الأعمال الكبيرة وتبدأ أسعارها 249.00 دولار أمريكي شهريًا.

3. Media Temple

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

يوجد العديد من الخيارات والخطط المتاحة والّتي تختلف من حيث السعر والمميزات والسعة وتوفر كل خطة قابلية الترقية للخطة الأعلى منها وذلك لكي تتناسب مع نمو موقعك وتشمل الخطط الّتي تقدمها هذه الشركة ما يلي:

• خطة الشبكة (Grid): وهي استضافة مشتركة.
• خطة DV Managed.
• خطة DV Developer.
• خطة DV Enterprise.
• خطة Managed WordPress.

وعندما نتحدث عن المصممين والمدونين فإن أفضل خطة تناسبهم هي خطة Grid وهي تتكامل بشكل مثالي مع الووردبريس مع العديد من الفوائد للمبتدئين ومن بعض هذه الميزات:

• استضافة 100 موقع.
• عرض نطاق (Bandwidth) يصل إلى 1 تيرا بايت.
• إمكانية تخزين قواعد البيانات بعدد يصل 100 قاعدة.
• سعة تخزين تصل إلى 20 غيغا بايت.
• 1000 حساب بريد الكتروني.
• تقديم الدعم الفني على مدار الساعة وطيلة أيام الأسبوع وعلى مدار السنة.

كلّ هذه الميزات متوفرة بسعر 20 دولار أمريكي شهريًا. وتعدّ المنصة سهلة الاستخدام ويمكنك ترقية الخطة متى تشاء. وبعض الخطط المطروحة الأخرى مثل خطة المطورين (DV Developer) والّتي تبدأ بمبلغ 30 دولار أمريكي وخطة المدراء (DV Managed) تبدأ بمبلغ 55 دولار شهريًا.

4. Arvixe

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

• الخطط الشخصية
• خطط الأعمال
• خطط الموزّعين

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

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

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

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

• استضافة الأعمال مقابل مبلغ 25 دولار أمريكي شهريًا.
• استضافة الموزّعين مقابل مبلغ 23 دولار أمريكي شهريًا.
• استضافة VPS مقابل مبلغ 43 دولار أمريكي شهريًا.

5. HostGator

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

• استضافة مشتركة.
• استضافة الموزّعين.
• استضافة VPS والخطط المخصصة.

تم تصميمها لتعمل بشكل مثالي مع المبتدئين والمحترفين. وتقدم ميزة نقل الاستضافة بشكل سهل للغاية وعندما تنقل من مضيف إلى شركة HostGator فإنها توفر لك المميزات التالية:

• نقل نطاق مجانًا.
• نقل الملفات مجانًا.
• نقل قاعدة البيانات مجانًا.
• نقل الموقع مجانًا.

تشمل الميزات الّتي تقدمها الشركة لمستخدميها:

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

يمكنك الحصول على كلّ هذه الميزات بسعر 3.96 دولار شهريًا. الخطط الأخرى تتضمن:

• استضافة الموزّعين بمبلغ يبدأ من 19.95 دولار أمريكي شهريًا.
• استضافة مخصصة لمواقع الووردبريس بمبلغ يبدأ من 5.95 دولار أمريكي شهريًا.
• استضافة VPS بمبلغ يبدأ من 29.95 دولارًا أمريكي للشهر الأول.
• خوادم مخصصة تبدأ من 119 دولار أمريكي للشهر الأول. توفر هذه الشركة ضمان وقت تشغيل المخدم بنسبة 99.9 ٪ وضمان استعادة الأموال لمدة 45 يومًا أيضًا.

6. GoDaddy

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

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

ومع ذلك، فإن إدارة ملايين النطاقات تجعل الدعم أبطأ قليلًا ولكن فريق الدعم سريع الاستجابة دائمًا ويتم حل الشكاوى عادةً خلال 24 ساعة فقط. وتشمل الميزات الّتي تقدمها هذه الشركة لكل خطة:

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

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

• يمكنك استضافة موقع ويب فردي بمبلغ 5.99 دولار أمريكي للشهر الأول مع سعة تخزين 100 غيغا بايت
• لاستضافة عدد مواقع غير محدود وبسعة تخزين غير محدودة يجب عليك دفع 7.99 دولار أمريكي للشهر الأول.
• الخطة الأخرى تشمل استضافة مدونة أو موقع ووردبريس يبدأ من 6.99 دولار أمريكي شهريًا.

7. Eleven2

تعدّ هذه الشركة من الشركات الّتي يُنصح بها بسبب جودة الخدمة والدعم والتجهيزات والميزات ووقت التشغيل.وأغلب المصممين والمدونين يفضلون الاستضافة المشتركة بسبب أسعارها المعقولة جدًا.

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

كما أنها توفر ميزة فريدة للدردشة المباشرة الّتي تمكنك من الدردشة مع الخبراء حول مسائل استضافة الموقع الخاص بك وضمان وقت تشغيل المخدم بنسبة 99.9 ٪. إنها بالفعل شركة استضافة مُتقنة. وتقدم هذه الشركة ميزات وفقًا لخططها المختلفة الّتي تكون إما شهرية أو سنوية. تتوفر خطة S-200 القياسية مقابل 7 دولارات أمريكية شهريًا وتشمل:

• مساحة تخزين 250 غيغا بايت.
• عرض نطاق 20 تيرا بايت شهريًا.
• مجالات (Domains) غير محدودة.
• ضبط الإعدادات بشكل فوري.
• عدد قواعد بيانات غير محدود.
• امكانية النسخ الاحتياطي.
• ضمان استرداد الأموال خلال 60 يومًا.

تقدم هذه الشركة العديد من الخطط الأخرى الّتي ستناسب احتياجاتك حتمًا. تشمل الخطط الأخرى:

• خطة S-300 مقابل 14 دولار شهريًا مع سعة تخزين 500 غيغا بايت وعرض النطاق 40 تيرا بايت شهريًا.
• خطة R-100 للبائعين مقابل 13.97 دولار شهريًا مع سعة تخزين 100 غيغا بايت وعرض النطاق 1 تيرا بايت شهريًا.
• خطة R-200 للبائعين مقابل 24.47 دولار شهريًا مع سعة تخزين 200 غيغا بايت وعرض النطاق 2 تيرا بايت شهريًا.
• خطة R-300 للبائعين مقابل 34.97 دولار شهريًا مع سعة تخزين 300 غيغا بايت وعرض النطاق 3 تيرا بايت شهريًا.

تقدم أيضًا الشركة خطة استضافة سحابية والّتي تعدّ من الخطط الرخيصة نسبيًا بالموازنة مع خدمات أمازون السحابية أو خدمات مايكروسوفت. وتقدم الاستضافة السحابية الخدمات التالية:

• منصة سريعة جدًا باستخدام حاويات لينكس مع أقراص صلبة من نوع SSD.
• نسخ احتياطي يومي لضمان عدم خسارة أي جزء من بياناتك.
• فريق من المهندسين يعملون على صيانة الخدمة السحابية لضمان عدم توقفها.
• عدد من المراكز السحابية موزعة على مختلف الدول.
• دعم فني سريع جدًا مع سرعة رد تبلغ 10 دقائق فقط.

تقدم كل هذه الخدمات مقابل 25 دولار شهريًا مع سعة تخزين 125 غيغا بايت وعرض النطاق 10 تيرا بايت شهريًا.

8. Fatcow

تعدّ خيارًا جيدًا للمصممين والمدونين الّذين بحوزتهم رأس مال قليل أو الّذين يطلقون الموقع الإلكتروني لأغراض شخصية.

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

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

• خطة Fatcow.
• استضافة ووردبريس.
• حجز دومين.
• استضافة VPS.
• استضافة مخصصة.
• تسجيل نطاقات.
• مجموعة أيقونات Farm-Fresh.

تشمل الميزات الّتي تقدمها:

• سعة تخزين غير محدودة.
• عرض النطاق غير محدود.
• ضمان التشغيل والمتابعة بنسبة 90%.
• قاعدة بيانات MySQL غير محدودة.
• استضافة نطاقات بشكل غير محدود.
• صندوق بريد نوع POP غير محدود.
• ضمان استرداد المال خلال 30 يوم.
• استقبال 100 دولار أمريكي كهدية من شركة مايكروسوفت و 100 دولار أمريكي من شركة غوغل عند إنفاقك 25 دولار أمريكي في حسابك الجديد على إعلانات غوغل أو مايكروسوفت.

كل هذه الميزات متوفرة بسعر 4.08 دولار أمريكي شهريًا وأما خطة استضافة مواقع الووردبريس فهي بأقل سعر على الإطلاق وهو 3.75 دولار أمريكي شهريًا. وتشمل الخطط الأخرى:

• استضافة خوادم VPS الأساسية وتبدأ من 19.99 دولار أمريكي شهريًا وتأتي مع معالج واحد وذاكرة وصول عشوائي بسعة 1 غيغا بايت وسعة تخزين تبلغ 40 غيغا بايت وعرض النطاق 1 تيرا بايت.
• استضافة خوادم VPS للأعمال وتبدأ من 47.99 دولار أمريكي شهريًا وتأتي مع معالجين وذاكرة وصول عشوائي بسعة 4 غيغا بايت وسعة تخزين تبلغ 90 غيغا بايت وعرض النطاق 3 تيرا بايت.
• استضافة خوادم VPS المثالية وتبدأ من 79.99 دولار أمريكي شهريًا وتأتي مع 4 معالجات وذاكرة وصول عشوائي بسعة 8 غيغا بايت وسعة تخزين تبلغ 120 غيغا بايت وعرض النطاق 4 تيرا بايت.
• استضافة مخصصة تبدأ من 119.99 دولار أمريكي شهريًا وتأتي مع معالجين وذاكرة وصول عشوائي بسعة 4 غيغا بايت وسعة تخزين تبلغ 500 غيغا بايت وعرض النطاق 5 تيرا بايت.

9. InMotion Hosting

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

تتعامل الشركة مع احتياجات العمل المتنامية، من الأعمال التجارية الصغيرة إلى مستوى الشركات. تضمن الشركة سرعة جيدة وخدمة عالية مع مراكز بيانات متعددة. توفر ميزة منطقة السرعة القصوى (Max Speed Zone) لخطط VPS ورجال الأعمال والّتي تمكن المستخدمين القريبين من مراكز البيانات في الشركة الاستمتاع بالتصفح أسرع بست مرات من أي شخص أخر.

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

• استضافة رجال الأعمال.
• استضافة رخيصة.
• استضافة VPS.
• خوادم مخصصة.
• استضافة الموزّعين.

تشمل الميزات الّتي توفرها الشركة:

• سعة التخزين غير محدودة
• عرض النطاق غير محدود.
• باقة مواقع مجانية بأكثر من 400 مواقع مع ميّزة التثبيت بنقرة واحدة.
• أقراص التخزين الصلبة من نوع SSD.
• تقدم لوحة تحكم cPanel & WHM بشكل مجاني.
• إعلانات مجانية بقيمة 150 دولار أمريكي.
• اسم نطاق مجاني.
• ضمان استرداد المال خلال 90 يوم (تشمل خطة استضافة الموزّعين والاستضافة المخصصة والاستضافة المشتركة).

هنالك الكثير من الميزات الأخرى المضمنة في الخطة وهي متاحة مقابل 6.39 دولار أمريكي شهريًا. وتشمل الخطط الأخرى

• استضافة VPS تبدأ من 29.19 دولار أمريكي شهريًا.
• استضافة مخصصة تبدأ من 105.69 دولار أمريكي شهريًا.
• استضافة الموزّعين تبدأ من 15.39 دولار أمريكي شهريًا.

10. TMDHosting

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

وتوفر لك وقت تشغيل مضمون بنسبة 99.9٪ في جميع خطط الاستضافة، وتقدم لك أفضل تجربة استضافة وتضمن لك استرداد أموالك لمدة 30 يومًا في حالة عدم رضاك عن المنصة. توفر الشركة أيضًا استضافة للتطبيقات المفتوحة المصدر بما في ذلك استضافة Joomla، واستضافة Magneto …الخ. الميزة الّتي تتفوق بها هذه الشركة على منافسيها هي دعم العملاء السريع على مدار الساعة وطيلة أيام الأسبوع، وسيتم حل استفساراتك في غضون 15 دقيقة. كما تقدم مساعدة على أعلى مستوى مع أحدث التقنيات المتاحة.

بالنسبة للمبتدئين، تقدم الشركة برامج تعليمية تساعدك خطوة بخطوة في أي مسألة تتعلق باستضافة المواقع. وتقدم العروض الترويجية بشكل يومي والّتي تكون تحديثات على خطط الاستضافة الحالية وتقدمها بأقل الأسعار للعملاء. خدمات الاستضافة الّتي تقدمها الشركة تشمل:

• استضافة المواقع.
• استضافة الموزّعين
• استضافة VPS
• استضافة الخدمات السحابية (Cloud).
• خوادم مخصصة

تشمل الميزات المختلفة الّتي توفرها استضافة الشركة

• اسم نطاق مجاني للأبد.
• خوادم CloudLinux-powered.
• سعة التخزين وعدد زيارات غير محدودة.
• إصدارات PHP متعددة.
• قواعد بيانات MySQL بشكل غير محدود.
• ضمان استعادة المال خلال 60 يوم.

وهنالك عدة ميزات أخرى مع الحزمة. تتوفر خطة استضافة الويب بمبلغ 2.95 دولار أمريكي شهريًا. والخطط أخرى تشمل:

• استضافة الموزّعين تبدأ من 19.95 دولار أمريكي شهريًا مع ضمان استعادة المال خلال 30 يوم.
• استضافة VPS تبدأ من 19.97 دولار أمريكي شهريًا.
• استضافة سحابية تبدأ من 5.95 دولار أمريكي شهريًا.
• خوادم مخصصة تبدأ من 229 دولار أمريكي شهريًا.

ختامًا

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

ترجمة -وبتصرف- للمقال Unbiased Review of the 10 Top Web Hosting Services

إن معظم المؤسسات في هذه الأيام تنتقل من نموذج أعمال المُحسن للموارد والذي يستند إلى النفقات الرأسمالية (CAPEX) إلى نموذج أعمال المُحسن للسوق والذي يستند إلى النفقات التشغيلية (OPEX). ولكن ما الذي يقود هذا التحول؟ في الحقيقة أن الهدف الأساسي من هذا التحول هو تقليل الوقت اللازم للتسوق وإسعاد الزبائن باستمرار عن طريق تقديم قيمة (Value) لهم وتُعرف القيمة بأنها منتج أو خدمة معينة والتي يكون الزبون مستعدًا للدفع مقابلها.

مرحبا بك في التحول الرقمي. هل أنت مستعد لتبني عقلية DevOps في شركتك؟

لقد أشار مدير DevOps السيد Donovan Brown إلى أن DevOps

اقتباس

هي إتحاد الأشخاص والعمليات والمنتجات لتمكين التسليم المستمر لتقديم القيمة للعملاء.

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

ولكوني شخصًا ذو عقلية مرئية (visual-minded)، فقد أنشأت عرضًا تقديميًا يحتوي على صور من أجل مخيم تدريب DevOps العالمي GDBC (Global DevOps Bootcamp) وهذا الحدث السنوي الذي تنسقه المجتمعات المحلية في جميع أنحاء العالم وذلك لخلق بيئة استكشافية وتعاونية لاستعراض مبادئ التحول الرقمي ورؤى DevOps.

دعنا نستكشف سريعًا أربعة من الصور المرجعية (والتي تدعى أيضًا بالصور المرئية والإنفوجرافيك). واذا أردت التعمق أكثر يمكنك مراجعة كتاب The DevOps Handbook، لكُتّابه Gene Kim، و Jez Humble، وPatrick Debois، وJohn Willis.

الممارسات

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

يشجع كبار المختصين في الأداء (Performers) على تعزيز عقلية استسراع النمو، والمكافأة على الابتكار، والتعاون، والتجريب، والتعلم، والتعاطف مع المستخدمين. والسعي لعملية تسليم تطبيقات سريعة الاستجابة، والجدولة المرنة، والتجارب التكرارية. ورصد المشاكل والتعرف عليها وتخفيفها، والقضاء باستمرار على الاختناقات التي تهدر الأداء، وقياس مؤشرات الأداء المهمة وذلك لتحسين المخرجات، مثل معدل فشل التغيير المنخفض (CFR Change Failure Rate)، والوقت الأدنى للاستعادة من الفشل ( Minimal Time To Recover MTTR)، ويجب دومًا أن نحرص على معالجة المشكلات من جذورها. وأخيرًا، لنأتي إلى التكنولوجيا، والتي هي أداة تمكين ستكون محور الصورة التالية.

نلاحظ في هذه الصورة التقنيات التي تركز عليها DevOps:

يقوم نظام التحكم في النُسخ (Version Control System) بإدارة إصدارات التطبيق واعداداته، والبنية الأساسية، وغيرها من الشيفرات البرمجية للتطبيق. وهو يتيح التعاون بين الفِرق ومراقبة الأنشطة مثل عمليات النشر (Deployments). يستخدم كبار المختصين في الأداء نسخ فرعية من التطبيق وذلك لعزل التغييرات قصيرة الأجل ومعاينتها قبل أن يتم دمجها في النسخة الأساسية (Master)، ويستمر مراجعة وتدقيق طلبات الدمج باستمرار ويتم إصدار النُسخ على أساس ذلك.

يجب أن يُنظر للاختبار على أنه نشاط مستمر، وأن يُدمج في مخطط سير العمل للمطور وذلك من أجل تحقيق التكامل المستمر مع التغيّرات (Continuous Integration CI) والتسليم المستمر للتطبيق (Continuous Delivery CD).

يتيح لك التخزين السحابي توفير البنية التحتية اللازمة والفعّالة وذلك للتحرك بأقصى سرعة ممكنة عند الضرورة وذلك تجنبًا للوقت المبذول في بناء البنية التحتية المناسبة للشركة.

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

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

العادات

بناءً على قصة تحوّل 65,000 مهندس إلى DevOps بمساعدة فريق خدمات Visual Studio، تركز هذه الصورة على العادات الخمس الرئيسية التي تعلموها أثناء تحولهم إلى DevOps. يعدّ التركيز على العملاء، والاستقلال الذاتي للفِرق، وتنسيق الشركة، والتركيز على عادات Shift Left، هي عوامل التطوير لمنهجية التصميم المرن (Agile)، كما أن عقلية الإنتاج أولًا والبنية التحتية مثل الموارد المرنة جميعهم خواص تتفرد بها عقلية DevOps.

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

تُعد عادات Shift left طريقةً لاختبار البرمجيات والنظام، ويتم إجراء الاختبار في وقت مُبكر من دورة الحياة (أي تم نقله إلى اليسار في الجدول الزمني للمشروع). ويشجع shift left على المراجعات، والتحقق من الصحة، والموافقات على كل من الاختبار والأمان في أقرب وقت ممكن في دورة توصيل الميزات وذلك لزيادة الجودة وتمكين أسلوب الفشل السريع (أحد أهداف هذه الفلسفة هي تقليل الخسائر، وذلك عندما يكشف الاختبار وجود شيء ما لا يعمل فالأفضل دومًا تجربة شيء آخر بسرعة. أي تجاوز الفشل بسرعة). عندما يتجاوز الأعطال الفنية الحد المحدد مسبقًا (مثلا خمسة أخطاء لكل مهندس)، يجب تشجيع الفِرق التي تعمل على المميزات على تعليق العمل حتى يتم جميع الأخطاء الموجودة.

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

إن عقلية الإنتاج أولًا لا تُميّز كيفية التعامل مع المميزات والأخطاء خلال التطوير والاختبار والدعم الفني. وإنما كل شيء يجب أن يكون مُؤتمت، ومُحرر، ومُحسن في الإنتاج. ويتم الاعتماد على النشر الدائري والحلقات (ring-based deployment and rings) والتي تنص على عرض التغييرات لمستخدمين محددين ومراقبتها والتحقق من صحتها قبل عرضها على جميع المستخدمين وذلك للحد من الأخطاء التي تنتج أثناء إحداث تغييرات في المميزات المطروحة، ومعالجة جميع المشكلات من جذورها، وتذكر أن تكون واضحًا عند حدوث مشكلة معينة وتوضيحها وما هو السبب الرئيسي لظهورها والحل الذي استخدمته لتجاوزها (لان المستخدم سيكون أكثر تفهما في حال كان لديه معرفة بسبب حدوث المشكلة والآلية المتبعة في حلها).

تصف البنية التحتية مثل الموارد المرنة كيفية تكيّف الحلول المطروحة مع الخدمات السحابية والحاويات (container) والخدمات المصغّرة (Microservices). يجب تبني تحوّل عملي يكون منطقيًا لشركتك وأهدافك ومنتجاتك وثقافتك. كما هو الحال مع العادات السابقة، من المهم أن نُفضّل البنية الاستقلالية على بنية الوصفية وألا نُغير كل شيء في وقت واحد.

الشروع في العمل

يجمع التصور الأخير بين كل ما سبق ويقترح خمس خطوات للبدء مع Devops.

أفضّل أن أبدأ بالتقييم لقدرته في تحديد المناطق الرئيسية التي يمكن تحسينها.

توفر التقييمات معيارًا لعقلية وأداء DevOps مقارنة بباقي المنهجيات المتبعة في قطاع الصناعات الأخرى. من المهم أن نفهم أي جزء من عملك يسير على ما يرام وأي جزء يحتاج لأن تستثمر فيه لنقله إلى المستوى التالي. إن كُلًا من التقييمات التابعة لشركة DORA و تقييمات شركة مايكروسوفت بالنسبة Devops هي تقييمات رائعة للبداية. بالإضافة إلى ذلك، إجمع أدوات القياس لاستخدامها كقاعدة لقياس التقدم - على سبيل المثال، معدل تكرار النشر (Deployment Frequency) والوقت اللازم لتطبيق التغييرات (lead time for changes)، ومتوسط وقت الإصلاح (mean time to repair)، ومعدل فشل التغيير (change failure rate).

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

وبدون وجود أشخاص ملتزمين وثقافة تجريبية، فإن بقية رحلة التحول إلى DevOps ستفشل.

إن العملية (Process) هي نظامك الهندسي، والذي يقوم بتمكين الفرق من إصلاح المشاكل بشكل مباشر، واستخدام الإدارة والتطوير الرشيق (lean management and development)، وتقديم خدمة قيّمة باستمرار. ويوفر نظام الهندسة المشترك الثبات، ويخول فِرق المميزات، ويتيح ويشجع الجميع على دعم بعضهم بعضًا والمساهمة فيه. يجب أن تتضمن أهم أهداف عملياتك التركيز على الجودة، واحتضان البنيات خفيفة الترابط (loosely coupled architectures) لتمكين التطوير، والإدارة الخفيفة، والأتمتة، والإصدارات المتعددة في اليوم، والاحتفال بالنجاح كفريق وكشركة.

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

اقتباس

يمكن تحقيق التحسين للجميع إذا قدمت القيادة دعمًا ثابتًا، وأن يلتزم أعضاء الفريق بالعمل. - Accelerate: The Science of Lean Software and DevOps

أيّ من صور أحببتها؟ أيّ منها أحسست بأنها لا تضيف أي قيمة؟ وما الجزء الذي تعتقد بأنه مفقود؟ دعونا نتعاون لكشف الغموض عن DevOps ومساعدتك وموظفينك على التألق. يحتاج المستخدمون إلى فهم أنهم ليسوا وحدهم وأن يعرفوا بأنه يمكنهم الاعتماد على الممارسات المُجربة والمُثبت فعاليتها وعلى النهج التعليمي الواقعي.

ترجمة -وبتصرف- للمقال Visualizing a DevOps mindset لصاحبه Willy-Peter Schaub

لقد أحدثت الحاويات (Containers) والخدمات المصغّرة (Microservices) ثورة في تطوير التطبيقات وإدارة البنية التحتية لها، وقدمت لنا تحديات أمنية جديدة دون أن تعالج التحديات السابقة. إذن ما هي أبرز التحديات الأمنية الجديدة؟ وما الذي يجب علينا فعله تجاهها؟

تقنيات جديدة وتحديات جديدة

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

لقد غيّرت الخدمات المصغّرة كلّ شيء. إذ نلاحظ أن أغلب الشركات في وقتنا الحالي تتجه لوضع خارطة عملٍ معتمدة على الخدمات المصغّرة باستخدام بنى معمارية مثل البنية التحتية الثابتة (Immutable infrastructure)، أو البنية المعمارية التي لا تدعم التشارك (shared-nothing architecture)، أو التطبيقات المتوضعة في الحاويات (containerized applications).

لقد كانت طريقة الكشف عن فعالية المشاريع في حالات معينة مثل العمل في نطاق صغير، أو في الإستقلالية، أو في تحقيق الإستدامة الذاتية تُعرف عند بناء الواجهة البرمجية API وتشغيلها على الآلة الوهمية (virtual machine) أو بداخل حاوية، أو حتى بتشغيلها على القرص الصلب (حيث يكون مُثبت عليه نظام التشغيل)، أما الآن فيمكننا الكشف عن فعالية هذه المشاريع باستخدام الخدمات المصغّرة بحيث يتم إختبار كلّ حالة على حدة ومعرفة فعالية المشاريع بدون بناء واجهة برمجية.

وعلى الرغم من المزايا المتعددة لإستخدام الحاويات إلا أنها تقدم لنا مجموعة من التحديات أيضًا من بين تلك التحديات المباشرة التي تواجه الحاويات هي الزحف على الحاويات (container crawl)، وحماية الحاويات، وتعقب الخدمات المصغّرة، ومعرفة مصدر نُسخ الحاويات.

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

ومن منظور أمني، زادت إمكانية التعرض للهجوم بشكل كبير في عالم الخدمات المصغّرة بالموازنة مع التطبيقات أحادية النواة. أن زيادة قابلية النشر للوحدات وللأجهزة البعيدة (مثل: الهواتف الذكية والأجهزة المحمولة والأجهزة اللاسلكية الأخرى) أدى إلى زيادة التعرض للخطر، وإحتمالية حدوث هجوم أمني على الأجهزة البعيدة، ومشكلات التكاملية. بالإضافة إلى ذلك، قد تحتوي نُسخ Docker الأساسية على ثغرات أمنية والتي قد تضر بالخدمات المصغّرة. لذا ينبغي إدارة مصدر نُسخ Docker لضمان صحتها وخلوها من الثغرات. ويشكّل نشر تحديثات الأمنية والترقيعات مع المحافظة على أدنى مدة زمنية لتعطل الحاويات تحديًا آخر يصعب تجاوزه. يمكن أن تضيف DevOps المزيد من التركيز على الاحتياجات الأمنية في عالم الخدمات المصغّرة. حيث تركز أدوات النشر والبناء المستمرة حاليًا على تبسيط عملية التسليم، على الرغم من عدم تركيزها كثيرًا على حماية DevOps .

أفضل الممارسات الأمنية

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

وينبغي تعزيز المراقبة من خلال آليات للكشف عن حالات الشذوذ لاكتشاف أي استخدام خاطئ للموارد أو الأحداث الغير طبيعية مع الحاويات، كما ينبغي تعزيز جميع قدرات المراقبة لتتبع العمليات المعتمدة على وكيل (agent-based) والعمليات بدون وكيل (agentless). كما يجب تحديث إدارة الترقيعات (Patch management) وتحسينها لضمان ترقيع الحاويات بأحدث التحديثات مع ضمان الحد الأدنى من وقت التوقف عن العمل.

ولقد قدم Docker آلية لتحديد مصدر النُسخ تسمى (Notary)، والتي تستند إلى TUF (اختصارًا إلى The Update (Framework الذي يُستخدم في توزيع وتحديث البرامج بشكل نموذجي). ولكن العديد من أخصائيي الحاويات في وقتنا الحالي لا يستخدمونه Notary وذلك لأنه لا يزال في مرحلة التطوير. كما أن Notary يتطلب عملية إدارة رئيسية خبيرة في الشركة. تعدّ المنطقة التي تقع بين الخدمات المصغّرة من المناطق التي تُرتكب فيها الأخطاء أمنية، ويمكن استخدام Gateway API (وهي برمجية تقع أمام الواجهة البرمجية وتعمل كنقطة دخول واحدة لمجموعة محددة من الخدمات المصغّرة) بفعالية في هذا الموقف. إن تشفير الرسائل باستخدام تشفير الرسائل التقليدي PKI (البنية التحتية للمفتاح العام Public Key Infrastructure وهو إطار التشفير والأمن السيبراني الذي يحمي الاتصالات بين الخادم والعميل) ليس خيارًا قابلًا للتوسعة في هذا الموقف. لذا بدلًا من ذلك، يمكننا استخدام JSON Web Token) JWT) وهو رمز مشفّر مع مجموعة من سياسات التأكيد assertion policies حول الطالب للخدمة (requestor).حيث يوقعّ خادم الهوية الرسائل برمز مُميز والذي يُمكن التحقق منه بواسطة نظام المستلم (recipient system). كما يمكن تشفير JWT رقميًا للحفاظ على سرية وسلامة التأكيدات (assertions) والتي تسمى حينَئِذٍ JSON Web Encryption) JWE).

غالبًا ما تكون الحماية صعبة وباهظة الثمن. لذا حاول أن تجعل من الحماية سمة أساسية للبنية التحتية للخدمات المصغّرة لتوفير أفضل مستوى من الأمان والأداء.

ترجمة -وبتصرف- للمقال Secured DevOps for microservices لصاحبه Sreekanth Nyamars

على مدار الأشهر القليلة الماضية، نشرت بعض المقالات الّتي تستكشف النقاط الأساسية الثلاث في تحولك الرقمي وهي المنتج والعملية والناس، وذلك لتمكينك من الانتقال من نموذج عمل مُحسن للموارد استنادًا إلى النفقات الرأسمالية (CAPEX) إلى نموذج مُحسن للسوق استنادًا إلى النفقات التشغيلية (OPEX). ومن الأمثلة على الانتقال من CAPEX إلى OPEX هو استخدام خدمات أمازون السحابية AWS بدلًا من إنشاء بنية تحتية من الصفر والتي ستُخدّم المشروع. ومن بين الفوائد الأخرى، يساعدك إتحاد الأشخاص والعمليات والمنتجات على رفع قيم العمل الأساسية، مثل زيادة قيمة الأعمال Business Value، مثل: زيادة قيمة الموظف، وقيمة العميل وقيمة الموارد وكثير من هذه القيم التي لا تقاس مباشرة بالقيم النقدية، بالإضافة إلى تقليل أوقات دورة التسليم، وتمكين الجميع من التعلم والتكيّف وتطوير مستواهم بشكل مستمر.

يركز المهندسون (مثلي) عادة على المنتجات والأدوات والتقنيات. إذا أردنا النجاح في الانتقال إلى DevOps، فمن المهم أن ندرك أنه لا يمكنك شراء أو تركيب DevOps! المنتجات هي أدوات داعمة، وليست الحل السحري للأمر، فهي تتيح لك التركيز على النتائج، مثل الأتمتة، والتطابق، والموثوقية، والقدرة على الصيانة، وتمكين الميزات أو تعطيلها بشكل تدريجي، و تصور الخطوات اللازمة للانتقال من إنشاء المنتج إلى تسليمه إلى العميل النهائي أو ما يسمى flow of value.

عندما نتحدث عن العملية، فإننا غالبًا ما نتجه نحو الأتمتة لرفع قيمة الكفاءة والاستقرار والثبات. ومن المهم أيضا تضمين أهداف الاحتفال بالنجاح سواءً كفريق أو منظمة، والتركيز على الجودة انطلاقًا من تصوّرها وتخيلها وانتهاءً بتحقيقها على أرض الواقع، وإنشاء عملية إدارة التغيير بحيث تكون سريعة الاستجابة وخفيفة، واحتضان البنيات المترابطة بشكل خفيف (loosely coupled architectures) لتمكين التطوير، والسعي إلى إصدار عدة مميزات جديدة في اليوم.

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

ترجمة -وبتصرف- للمقال Breaking down walls between people, process, and products لصاحبه Willy-Peter Schaub

كيف شَكّل نموذج الشلال (Waterfall)، والنموذج المرن (Agile)، وغيرها من أُطر التطوير الشكل الحالي DevOps؟ إليك ما اكتشفناه.

إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟

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

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

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

والجدير بالذكر أن أغلب النماذج الحالية من نموذج التصميم الرشيق (Lean) ونموذج (Kanban) ونموذج التصميم المستمر (Continuous) ونموذج التصميم المرن (agile) تتتبع مبادئ وعمليات تعود إلى أوائل الأربعينات، لذا لا يمكن أن ندعي DevOps أنها فكرة جديدة كليًا.

دعنا نعود بالزمن لبضع سنوات وننظر إلى نماذج تطوير البرمجيات مثل نموذج الشلال، والنموذج الرشيق، والنموذج المرن. يوضح الشكل التالي المخطط الزمني لتطور دورة حياة تطوير البرمجيات. (تذكر أننا لا نبحث عن أفضل طريقة ولكننا نحاول فهم المنحى الذي أحدث تأثيرًا إيجابيًا على هندسة البرمجيات والتي قمنا بتجميعها منذ 67 عامًا والتطور الذي حصل على مرِّ هذه السنوات حتى وصولنا لعقلية DevOps).

اقتباس

"يبقى الأحمق أحمقًا حتى وإن كان معه أداة" - ماثيو ماثاي

نموذج الشلال التقليدي (Waterfall)

من وجهة نظرنا، تأتي أقدم الممارسات من نموذج الشلال، الذي قُدم لأول مرة من قبل الدكتور وينستون دبليو رويس في ورقة نشرت في السبعينيات.

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

نموذج التصميم الرشيق (Lean)

رغم أن التصميم الرشيق يعود إلى عام 1450 في مدينة البندقية، إلا أننا سنبدأ عندما قامت تويوتا بإنشاء نظام إنتاج تويوتا، الذي طوره المهندسون اليابانيون بين عامي 1948 و 1972. ونشرت تويوتا وصفًا رسميًا للنظام في عام 1992.

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

نموذج Kaizen

تعتمد kaizen على التحسينات الإضافية وتتكون دورة حياة kaizen المراحل التالية: التخطيط ->التنفيذ->التحقق->التصحيح. وتهدف عقلية kaizen للتوجه للتحسين المستمر. طُوّر مفهوم kaizen في الأصل لتحسين تدفق وعمليات خط التجميع، وهو يضيف أيضًا قيمة عبر سلسلة التوريد. وكان نظام إنتاج تويوتا واحدًا من أوائل المنفذين لنموذج kaizen والتحسين المستمر. يعمل كل من kaizen و DevOps معا بشكل جيد في البيئات التي ينتقل فيها سير العمل من التصميم إلى الإنتاج. يركز kaizen على مجالين:

• التدفق (هو التوجه نحو تدفق المواد والمعلومات)
• العملية (وهي تعني تحسين وضعية عمل الشخص)

التسليم المستمر (Continuous Delivery)

وقد ألهمت kaizen تطوير العمليات والأدوات لأتمتة الإنتاج. وقد تمكنت الشركات من تسريع الإنتاج وتحسين الجودة والتصميم والبناء والاختبار والتسليم عن طريق تقليل مصادر الهدر (بما في ذلك الثقافة والعقلية) والتوجه نحو الأتمتة قدر الإمكان وذلك باستخدام الآلات والبرمجيات والروبوتات. كما أن معظم فلسفة kaizen تنطبق أيضا على الممارسات التجارية والبرمجيات غير المحدودة ونشر التسليم المستمر لمبادئ وأهداف DevOps.

نموذج التصميم المرن (Agile)

ظهر بيان تطوير البرمجيات المرنة في عام 2001، والذي كتبه مجموعة من الشبان الطموحين النهج المتبع في التطوير.

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

النموذج المرن المنضبط (Disciplined Agile Delivery)

ومنذ أن ظل البيان المرن ثابتًا لمدة 20 عامًا، بحث العديد من الممارسين للنموذج عن طرق لإضافة خيارات إضافية ومخصصة إلى النهج. بالإضافة إلى ذلك، يركز البيان المرن بشكل كبير على التطوير، لذا تكونت الحاجة الماسّة إلى الحلول بدلًا من الشيفرات البرمجية أو البرمجيات وخصيصًا في بيئة التطوير السريعة اليوم. شارك سكوت أمبلر وماركس بريز في تأليف عملية تسليم المرنة المنضبطة وإطار عمل مرن ومنضبط، استنادًا إلى خبرتهما في شركة Rational و IBM والمنظمات التي تحتاج فيها الفرق إلى مزيد من الخيارات المتاحة أو الشركات التي لم تكن ذات خبرة بما يكفي لتنفيذ المنهجية الرشيقة (lean)، أو حيث لا يتناسب دورة حياة البرمجية مع سياق النهج.

تأتي أهمية النموذج المرن النضبط أو ما يعرف DAD (اختصارًا للعبارة Disciplined agile delivery) و DA (اختصارًا للعبارة Disciplined agile) من أنه يسمح لنا باتخاذ قرارت حول العمليات بشكل مبسط من أجل تقديم حلول تدريجية ومتكررة. ويعتمد DAD على العديد من ممارسات تطوير البرمجيات المرنة (Agile)، بما في ذلك ممارسات Scrum، وممارسات نموذج الرشيق (Lean)، وغيرها. إن الاستخدام المكثف للنمذجة الرشيقة وإعادة تحليل، بما في ذلك تشجيع الأتمتة من خلال نموذج التطوير القائم على الاختبار TDD (اختصارًا للعبارة Test-driven Development)، والتصميم الرشيق مثل Kanban و XP و Scrum و Rup من خلال اختيار واحدة من خمس دورات حياة رشيقة، وإدخال مفاهيم هيكلية المالك (Architecture Owner)، يكتسب الممارسين لنموذج المرن مجموعة من الأفكار وطرق التفكير وعمليات وأدوات لتحقيق DevOps بنجاح.

نموذج DevOps

وعلى المدى الذي يمكننا أن نجمع فيه، ظهرت DevOps خلال سلسلة من DevOpsDays في بلجيكا في عام 2009، لتصبح الأساس للعديد من التحولات الرقمية. يعرّف مدير DevOps الأساسي في شركة مايكروسوفت Donovan Brown نموذج DevOps بأنه

اقتباس

إتحاد الأشخاص والعمليات والمنتجات لتمكين التسليم المستمر لتقديم القيمة Value (إن القيمة هي المنتج أو الخدمة، والتي يكون الزبون مستعدًا للدفع مقابلها) للعملاء.

والآن لنعود إلى سؤالنا الأصلي: إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟

إننا ننظر إلى التاريخ الذي يعود إلى 80 و48 و26 و17 عامًا، ولكن في وقتنا الحالي إن البيئة اليومية سريعة الإيقاع وغالبًا ما تكون مضطربة. بطبيعتنا نحن البشر نختبر ونجرب باستمرار ونتعلم ونتكيّف ونورّث نقاط القوة ونحل نقاط الضعف تيمّنًا بجيناتنا الوراثية.

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

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

نموذج eDevOps

في عام 2016، صاغ Brent Reed مصطلح eDevOps (لا توجد له مراجع في Google أو ويكيبيديا حتى هذه اللحظة)، وهو يُعرف بأنه "طريقة للعمل (Way of Work) التي تجلب التحسين المستمر في الشركة بسلاسة، من خلال الأشخاص والعمليات والأدوات.

وجد برانت أن النموذج المرن فشل في شركات تقنية المعلومات فالشركات التي اعتمدت تفكيرًا رشيقًا كانت لا تحقق قيمة (Value) للعملاء ولم تحقق أيضًا التركيز والسرعة التي توقعوها خبراء النموذج المرن الموثوق بهم في مجال تكنولوجيا المعلومات. وعندما شعر بالإحباط لرؤية "برج عاجي" تم فيه فصل فريق خدمات تقنية المعلومات المستقل عن فرق الدعم في مجال الهندسة والتطوير والعمليات ومكتب المساعدة، عندها طبق معرفته السابقة بنموذج التسليم الرشيق المنضبط (DAD)، وأضاف بعض الأهداف والتطبيقات العملية لمجموعة أدوات DAD، من ضمنها:

التركيز على الثقافة ودفعها من خلال عقلية التحسين المستمر (Kaizen)، والجمع بين الناس حتى عندما يكونون في غرفة واحدة. السرعة من خلال الأتمتة (TDD + إعادة تحليل كل شئ ممكن)، إزالة الهدر واعتماد نهج TOGAF، أو JBGE (وهو جيد إلى حدٍ ما) من أجل التوثيق تقديم القيمة (Value) من خلال النمذجة (نمذجة التصميم) و (shift left) لتمكين الكشف عن الأنماط المتضاربة أثناء المشاركة من خلال أنماط التعاون في مستودع رقمي أكثر تنوعا واستراتيجيا حديث

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

• تحويل نظام الأعمال إلى Bizdevops) DevOps).
• تحويل نظام الأمن إلى SecDevOps) DevOps).
• تحويل نظام المعلومات إلى DataDevOps) DevOps).
• تقديم خدمات تقنية مترابطة بشكل خفيف والتي تجمع بين جميع أصحاب المصلحة.
• بناء حلول قابلة للاستخدام كل أسبوعين أو أسرع.
• جمع وقياس وتحليل وعرض وأتمتة الرؤية القابلة للتنفيذ من خلال عمليات DevOps من المفهوم من خلال الاستخدام المباشر للإنتاج.
• تحسين مستمر امتثالًا بنموذج Kaizen ونموذج الرشيق منضبط.

المرحلة التالية في تطوير DevOps

في النهاية هل تعدّ DevOps مجموعة من العبارات الطنانة والأفكار التقنية التي تُلقى على الشركات؟ سوف ندرك بكل تأكيد مع مرور الوقت كيف DevOps سيتقدم ويتطور. ومع ذلك، فإن حمض DevOps النووي يجب أن يستمر في النضج وأن يُنقح، ويجب أن يفهم المطورون أنه ليس الحل السحري ولا علاج لكل الأمراض والحلّ لكل المشاكل.

إذن ما هي العلاقة بين DevOps وبقية النماذج السابقة
DevOps != Agile != Lean Thinking != Waterfall
DevOps != Tools !=Technology
إن DevOps تحتوي على ممارسات من النموذج المرن (Agile) ونموذج التصميم الرشيق (Lean) ونموذج الشلال (Waterfall).

ترجمة -وبتصرف- للمقال Analyzing the DNA of DevOps لصاحبيه Willy-Peter Schaub و Brent Aaron Reed

اقتباس

ينبغي أن يتطور الأمان ليواكب الطريقة التي تُكتب بها وتُنشر التطبيقات اليوم.

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

ومع ذلك، كما كتب جون ويليس في وقت سابق من هذا العام عند وقوفه على المصطلحات الخاصة بـالDevSecOps: "نأمل أنه في يوم من الأيام سنكون في عالم ليس علينا أن نستخدم فيه كلمة DevSecOps، وسيكون الأمن جزءًا لا يتجزأ من جميع مناقشات تقديم الخدمة. حتى ذلك اليوم، وفي هذه المرحلة، استنتاجي العام هو أنها مجرد ثلاث حروف جديدة (Sec). والأهم من ذلك أن الاسم يميز حقًا مشكلتنا في عالم لا نقوم فيه بعمل رائع في مجال أمن المعلومات."

فلماذا لا نقوم بعمل رائع في مجال أمن المعلومات؟ وماذا يعني القيام بعمل رائع في سياق DevSecOps؟

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

لا تصف هذه الظروف بدقةٍ حقيقة معظم المنظمات منذ عدة سنوات حتى الآن. لكن الحقبة الحالية، التي لم تجلب مفهوم DevSecOps فحسب، بل حتى الأنماط الهيكلية للتطبيقات الجديدة، وممارسات التطوير، وعدد متزايد من التهديدات، تحدد وضعًا طبيعيًا جديدًا وقاسيًا يتطلب وتيرة تغيير أسرع. ليس تغيير منظومة الأمان مرتبطا بالDevSecOps منعزلة، ولكن الأمر يتطلب أمنًا معلوماتيًا بمقاربات جديدة.

أمعن النظر في هذه المجالات الخمسة.

1. الأتمتة (Automation)

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

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

2. التحرّك نحو اليسار (Shift left)

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

وبالتالي، لم لا نحرك الأمن مبكرًا نحو اليسار (في الرسم النموذجي من اليسار إلى اليمين لمسلسل التطوير)؟ قد يصرّ الأمنيون على الرفض، ولكن عواقب إعادة الصياغة في مرحلة مبكرة من التطوير هي بالتأكيد أقل بكثير مما يكون عليه الحال عندما يكون التطبيق كاملًا وجاهزًا للتسليم.

لا أحب مصطلح "التحرّك نحو اليسار" فذلك يعني أن الأمان لا يزال مجرّد حدثٍ لمرة واحدة نُقل لمرحلة مبكّرة. يجب أن يكون الأمان عملية مؤتمتة إلى حد كبير في كل مكان في دورة حياة التطبيق، من سلسلة التوريد إلى عملية التطوير والاختبار على طول الطريق حتى النشر.

3. إدارة التبعيات (Manage dependencies)

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

نتيجة لذلك، تحتاج منظومة DevSecOps إلى تركيز جادٍّ على سلسلة التوريد الخاصة بالبرنامج. هل تحصل على برنامجك من مصادر موثوقة؟ هل هو مُحدّث؟ هل هو مدمج في عمليات الأمان التي تستخدمها لكودك الخاص؟ ما هي السياسات التي تطبقها في أيّ أكوادٍ وأيّ واجهات لبرمجة التطبيقات قد تستخدمها؟ هل يتوفر الدعم التجاري للمكونات التي تستخدمها لشيفرة المنتج الخاص بك؟

لن تكون هناك مجموعة من الإجابات تناسب جميع الحالات. قد تكون مختلفة في حالة "إثبات الجدوى" عنها في حالة الإنتاج على نطاق واسع. ولكن، كما كان الحال في التصنيع لفترة طويلة (هناك العديد من أوجه الشبه بين DevSecOps وكيفية تطور التصنيع)، تبقى سلامة سلسلة التوريد أمرًا بالغ الأهمية.

4. الرؤية (Vision)

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

تتطلب منظومة DevSecOps الفعالة بالضرورة أدوات فعالة حتى يتضح ما يجب على الأتمتة أن تقوم به. وتندرج هذه الأدوات في عدد من الفئات. هناك مقاييس طويلة الأمد وعالية المستوى تساعدنا في معرفة ما إذا كانت عملية DevSecOps الشاملة تعمل بشكل جيد. وهناك أدوات إنذار حساسة تتطلب تدخلًا بشريًا فوريًا (إذا كان نظام المسح الأمني معطّلًا!). وهناك إنذارات، مثل الفحص الفاشل، تتطلب علاجًا أو إصلاحًا. وهناك سجلات للعديد من البارامترات التي نلتقطها من أجل التحليل لاحقًا (ما الذي يتغير بمرور الوقت؟ وما الذي يتسبب في هذا الفشل؟).

5. الخدمات مقابل الوحدات المتراصة

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

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

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

ترجمة وبتصرف للمقال ‎5 ways DevSecOps changes security لغوردون هاف

اقتباس

لا ترتكب هذه الأخطاء الأمنية الشائعة التي تجعلك عرضة للهجوم.

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

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

1. لا تشفر كلمات المرور، بل جزّئها

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

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

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

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

لماذا؟ لأنني أستطيع ذلك.

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

2. لا تضع أبوابا خلفية سرية في البرنامج

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

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

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

قال لي: "أوه نعم! لقد وضعنا ذلك في مكان يسهل الوصول إليه، ولم يعثر عليه أحد حتى الآن قبلك. سنقوم بإزالته على الفور". قبل أن ننهي المكالمة، سألني سؤالًا أخيرًا:" لماذا بدأت تبحث في HTML؟".

كانت إجابتي بسيطة: "لأنني أستطيع".

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

3. فعِّل تصديق هوية المستخدمين في كل صفحة، وليس فقط على صفحة تسجيل الدخول

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

إذا وضعت إشارة مرجعية على أحد عناوين URL التي ألج إليها كثيرا في النظام، فيمكنني فقط نسخها ولصقها في متصفح آخر، وقضي الأمر! سأكون هناك دون الحاجة إلى تسجيل الدخول. سألت المطور: "لماذا لا تُسجّل الدخول في كل صفحة؟ إذا أدخلت عنوان URL لصفحة ما في النظام، فيمكنني الوصول إليها دون تسجيل الدخول". فسألني: "لماذا تفعل ذلك؟".

أجبته: "لأنني أستطيع".

لا تترك أي شيء للصدفة

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

لماذا؟ لأنهم يستطيعون!

ترجمة وبتصرف للمقال ‎3 security tips for software developers لبيت سافايج