Ali Issa

تعتقد أنّك تعرف كل شيء عن sudo؟ فكّر بذلك مجدّدًا. يعرف الجميع sudo أليس كذلك؟ تُثبَّت هذه الأداة بشكل افتراضي على معظم أنظمة Linux وهي متوفّرة لمعظم توزيعات BSD (اختصارًا إلى Berkeley Software Distributions) ومختلف توزيعات يونكس التجاريّة. ومع ذلك كانت الإجابة الأكثر شيوعًا التي تلقيتها بعد التحدث إلى مئات مستخدمي sudo هي أنّ sudo أداة لتعقيد الحياة. يوجد لديك مستخدم جذر root ولديك أمر su، فلماذا يكون لديك أداة أخرى؟ كان sudo بالنسبة للكثيرين مجرّد بادئة للأوامر الإداريّة. ذكرت قلّة قليلة فقط أنّه يمكنك استخدام سجلات sudo لمعرفة من قام بعملٍ ما عندما يكون لديك العديد من المسؤولين في نفس النظام. ما هو sudo؟ وفقًا لموقع sudo الإلكتروني: يأتي sudo افتراضيًّا بضبط بسيط، حيث أن قاعدة واحدة تسمح للمستخدم أو لمجموعة من المستخدمين بالقيام بأي شيء عمليًا (المزيد حول ملف الضبط لاحقًا ضمن هذه المقالة): %wheel ALL=(ALL) ALL تعني «المعاملات» (parameters) في هذا المثال ما يلي: يحدّد المعامل الأول أعضاء المجموعة. يحدّد المعامل الثاني المُضيف (المضيفين) الذي يمكن لأعضاء المجموعة تشغيل الأوامر عليه. يحدّد المعامل الثالث أسماء المستخدمين التي يمكن بموجبها تنفيذ الأمر. يحدّد المعامل الأخير التطبيقات التي يمكن تشغيلها. لذلك يمكن لأعضاء مجموعة Wheel في هذا المثال تشغيل جميع التطبيقات مثل كافة المستخدمين على جميع المضيفين. حتى هذه القاعدة المتسامحة حقًا مفيدة لأنها تؤدي إلى تسجيل من قام بعملٍ ما على جهازك. الأسماء المستعارة (Aliases) بالطبع بمجرّد كونك لا تقوم أنت وصديقك المفضّل فقط بإدارة صندوق مشترك ما، فسوف تبدأ التفكير في ضبط الأذونات. يمكنك استبدال العناصر الموجودة في الضبط أعلاه بقوائم: قائمة المستخدمين، قائمة الأوامر، وما إلى ذلك. ستَنسخ على الأرجح وتلصق بعض هذه القوائم في الضبط الخاص بك. في مثل هذه الحالة حيث يكون استخدام الأسماء المستعارة في متناول اليد. يكون الحفاظ على نفس القائمة في أماكن متعدّدة عُرضة للخطأ. بالإمكان تعريف اسم مستعار مرّة واحدة وبعد ذلك يمكنك استخدامه مرّات عديدة. لذلك عندما تفقد الثقة في أحد أو بعض المسؤولين لديك، يمكنك إزالتَهم من خلال الاسم المستعار وينتهي الأمر. ولكن مع وجود قوائم متعددة بدلاً من الأسماء المستعارة فإنّه من السهل أن تنسى إزالة مستخدم ما من إحدى القوائم ذات الامتيازات العالية. تمكين الميزات لمجموعة معيّنة من المستخدمين يأتي الأمر sudo مزودًا بمجموعة كبيرة من الإعدادات الافتراضيّة. لا يزال هناك حالات تريد فيها تغيير بعضٍ من هذه الإعدادات. وذلك عند استخدام التعليمة Defaults في الضبط. عادةً ما يتم فرض هذه الإعدادات الافتراضيّة على كل مستخدم، ولكن يمكنك تضييق مجال هذه الإعدادات لتُطبّق فقط على مجموعة فرعيّة من المستخدمين بناءً على المضيف واسم المستخدم وما إلى ذلك. هنا مثال على أن مسؤول النظام الخاص بي (sysadmins) يُحبّ استخدام "التوبيخ" insults. وهي مجرّد بضع رسائل هزليّة تظهر كَتوبيخ عندما يُخطئ المستخدم في كلمة السرّ عند تنفيذ أوامر في sudo: czanik@linux-mewy:~> sudo ls [sudo] password for root: Hold it up to the light --- not a brain in sight! [sudo] password for root: My pet ferret can type better than you! [sudo] password for root: sudo: 3 incorrect password attempts czanik@linux-mewy:~> وبما أنه ليس الجميع معجب بفكاهة مدير النظام، تُعطّل هذه التوبيخات افتراضيًا. يوضّح المثال التالي كيفية تمكين هذا الإعداد فقط لمسؤولي النظام المتمرسين وهم أعضاء في المجموعة wheel: Defaults !insults Defaults:%wheel insults ليس لدي ما يكفي من الأصابع لتعداد الأشخاص الذين شكروني على إعداد هذه الرسائل. مُصادقة القيم المختصرة المشفرة (Digest verification) بالطبع هناك ميزات أكثر أهميّةً في sudo كذلك. إحدى الميزات هي «مُصادقة القيم المختصرة المشفرة» (digest verification). يمكنك تضمين مصادقة القيم المختصرة المشفرة للتطبيقات في الضبط الخاص بك: peter ALL = sha244:11925141bb22866afdf257ce7790bd6275feda80b3b241c108b79c88 /usr/bin/passwd يقوم sudo في هذه الحالة بفحص وموازنة القيمة المتخصرة المشفرة لتطبيق مع القيمة المشفرة المختصرة لتطبيق المخزّن في الضبط قبل تشغيله. فإذا لم يكونا متطابقين عندها يرفض sudo تشغيل التطبيق. على الرغم من صعوبة الحفاظ على هذه المعلومات في الضبط الخاص بك – حيث لا توجد أدوات تلقائية لهذا الغرض - إلا أنّ هذه الملخّصات يمكن أن توفر لك طبقة إضافيّة من الحماية. تسجيل الجلسة تسجيل الجلسة هو أيضًا ميزة أقل شهرةً لـ sudo. بعد عرضي التوضيحي يغادر كثير من الأشخاص محادثتي مع خطط عازمين على تنفيذها على بنيتهم التحتيّة. لماذا؟ لأن تسجيل الجلسة لا يتيح لك رؤية اسم الأمر فقط، بل كل ما يحدث في الجهاز الطرفي أيضًا. فبإمكانك معرفة ما يفعله المسؤولون لديك حتى لو كان لديهم وصول إلى الصدفة (shell) والسجلات تُظهر فقط أن bash بدأ العمل. توجد محدوديّة واحدة حاليًّا وهي أن السجلات تخزّن محليًّا، لذلك يمكن للمستخدمين حذف سجلات التتبع الخاصّة بهم إذا توفرت لهم أذونات كافية. ترقبوا الميزات القادمة. الإضافات تم تغيير sudo إلى بنية معياريّة قائمة على «الإضافات» (plugins) بدءًا من الإصدار 1.8. حيث أصبح بالإمكان استبدال أو توسيع وظائف sudo بسهولة عن طريق كتابة وظائفك الخاصّة، وذلك اعتمادًا على معظم الميزات التي نُفّذت كإضافات. يتوفر حاليًا كلًّا من الإضافات مفتوحة المصدر والإضافات التجاريّة لـ sudo. عَرضتُ في حديثي الإضافة sudo_pair والتي تتوفر على GitHub. طوّرت هذه الإضافة في Rust مما يعني أنه ليس من السهل «ترجمتها» (compile) والأكثر صعوبةً من ذلك هو نشر النتائج. تُوفّر الإضافات من ناحيةٍ أخرى وظائف مثيرة للاهتمام، مُتطلبةً من مسؤولٍ ثانٍ الموافقة (أو الرفض) لتشغيل الأوامر من خلال sudo. ليس ذلك فحسب، بل يمكن أيضًا تتبع الجلسات على الشاشة وإنهاؤها في حال وجود نشاط مشبوه. في عرضٍ توضيحيّ قدمته خلال حديثي مؤخرًا في مؤتمر "All Things Open" شعرت كمن يجلب لنفسه السمعة السيئة. czanik@linux-mewy:~> sudo rm -fr / كان الجميع يحبس أنفاسهم لمعرفة ما إذا كان جهاز الحاسوب المحمول قد دُمّر عند رؤية الأمر المعروض على الشاشة، لكنه نجا. السجلات يُعدّ التسجيل والتنبيه جزءًا مهمًا من sudo كما ذكرت سابقًا في البداية. إذا لم تقم بفحص سجلات sudo الخاصّة بك بانتظام فليس هناك قيمة كبيرة لاستخدام sudo. تُنبّه هذه الأداة عن طريق البريد الإلكتروني عن الأحداث المحدّدة في الضبط وتُسجل جميع الأحداث في syslog. يمكن تشغيل سجلات التنقيح (Debug) واستخدامها لتصحيح القواعد أو الإبلاغ عن «الأخطاء» (bugs). التنبيهات Alerts تعد تنبيهات البريد الإلكتروني من النمط القديم الآن، ولكن إذا كنت تستخدم syslog-ng لتَجميع رسائل السجل الخاصّة بك، فستُنقّح رسائل سجل sudo تلقائيًا. يمكنك بسهولة إنشاء تنبيهات مخصّصة وإرسالها إلى مجموعة واسعة من الوجهات، بما في ذلك Slack أو Telegram أو Splunk أو Elasticsearch. الضبط تحدثنا كثيرًا عن ميزات sudo وحتى شاهدنا بضعة أسطر من «الضبط» (Configuration). دعنا الآن نلقي نظرة أقرب على كيفيّة ضبط sudo. الضبط نفسه متاح في ‎/etc/sudoers وهو ملف نصيّ بسيط. ومع ذلك ما يزال لا يُنصح بتحرير هذا الملف مباشرة، استخدم بدلاً من ذلك visudo حيث تتحقق هذه الأداة من بناء الجملة النحويّ أيضًا. بإمكانك إذا كنت لا تحب vi تغيير المحرّر المُستخدَم عن طريق ضبط متغير البيئةEDITOR إلى الخيار المفضل لديك. تأكّد قبل البدء في تحرير ضبط sudo من معرفة كلمة مرور المستخدم root. (نعم، حتى على Ubuntu حيث الـ root ليس لديه كلمة مرور افتراضيًّا.) بما أنّ visudo يتحقّق من البناء النحويّ للجملة فمن السهل إنشاء ضبط صحيح نحويًّا يمنعك من الولوج إلى نظامك. يمكنك عندما تتوفر لديك كلمة مرور جذر في حالة الطوارئ البدء في تحرير الضبط الخاص بك. هناك شيء واحد مهم يجب تذكره عندما يتعلق الأمر بملف sudoers وهو أنّه: يُقرأ هذا الملف من الأعلى إلى الأسفل وبالتالي يُنفّذ الإعداد الأخير. ما تعنيه هذه الحقيقة بالنسبة لك هو أنّه يجب أن تبدأ بالإعدادات العامّة وتضع الاستثناءات في النهاية، وإلا فإنّ الإعدادات العامة ستُلغي الاستثناءات. يمكنك العثور على ملف sudoers بسيط أدناه اعتمادًا على ذلك الموجود في CentOS وإضافة بضعة أسطر كنا قد ناقشناها سابقًا: Defaults !visiblepw Defaults always_set_home Defaults match_group_by_gid Defaults always_query_group_plugin Defaults env_reset Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS" Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin root ALL=(ALL) ALL %wheel ALL=(ALL) ALL Defaults:%wheel insults Defaults !insults Defaults log_output يبدأ هذا الملف عن طريق تغيير عدد من الإعدادات الافتراضيّة. ثم تأتي القواعد الافتراضيّة المعتادة: المستخدم root وأعضاء مجموعة wheel لديهم أذونات كاملة على الجهاز. نُمكّن بعد ذلك insults لمجموعة wheel ونعطّلها للجميع. يفعّل السطر الأخير تسجيل الجلسة. الضبط أعلاه صحيح نحويًّا، لكن هل يمكنك اكتشاف الخطأ المنطقي؟ نعم، هناك خطأ: تُعطّل insults للجميع عند آخر إعداد عام حيث يُلغي الإعداد السابق الإعداد الأكثر تحديدًا. وبمجرّد تبديل السطرين يعمل الإعداد كما هو متوقع: يتلقى أعضاء مجموعة wheel رسائل هزليّة في حين أنً باقي المستخدمين لن يتلقونها. إدارة الضبط بمجرد أن تضطر إلى الاحتفاظ بملف sudoers على أجهزة متعدّدة فمن المرجح أنك تريد إدارة الضبط الخاص بك مركزيًا. لدينا هنا احتمالان رئيسيان مَفتوحا المصدر. لكلٍ منهما مزايا وعيوب. يمكنك استخدام أحد تطبيقات إدارة الضبط التي تستخدمها أيضًا لضبط بقية البنية التحتيّة الخاصّة بك. تحتوي Red Hat Ansible و Puppet و Chef على وحدات لضبط sudo. المشكلة في هذا النهج هي أنّ تحديث الضبط بعيد عن الوقت الحقيقي. كما أنه لا يزال بإمكان المستخدمين تحرير ملف sudoers محليًا وتغيير الإعدادات. يمكن للأداة sudo أيضًا تخزين ضبطها في خادم LDAP. تكون تغييرات الضبط في هذه الحالة في الوقت الحقيقي ولا يمكن للمستخدمين العبث بملف sudoers. ولكن من ناحية أخرى لهذه الطريقة محدوديّة أيضًا. حيث لا يمكنك على سبيل المثال استخدام الأسماء المستعارة aliases أو استخدام sudo عندما يكون خادم LDAP غير متوفر. ميزات جديدة هناك نسخة جديدة من sudo قاب قوسين أو أدنى. سيتضمن الإصدار 1.9 العديد من الميزات الجديدة المثيرة للاهتمام. فيما يلي أهم الميزات المُخطط لها: خدمة تسجيل لجمع تسجيلات الجلسة مركزيًا والتي توفر العديد من المزايا مقارنة بالتخزين المحلي: أكثر ملاءمة للبحث حيث يتم ذلك في مكان واحد. تتوفر التسجيلات حتى ولو كان جهاز المرسل متوقفا. لا يمكن حذف التسجيلات بواسطة شخص يريد حذف سجلات التتبع الخاصّة به. لا تضيف الإضافة "Audit" ميزات جديدة إلى sudoers، ولكنها توفّر واجهة برمجة تطبيقات API للإضافات للوصول بسهولة إلى أي نوع من سجلات sudo. تمكّن هذه الإضافة إنشاء سجلات مخصّصة من أحداث sudo باستخدام الإضافات. تُمكّن إضافة approval موافقات الجلسة دون استخدام إضافات خارجية (third-party plugins). والميزة المفضّلة لدي شخصيًا: دعم Python للمكونات الإضافيّة والتي تمكّنك من توسيع sudo بسهولة باستخدام شيفرة Python بدلاً من كتابة شيفرة أصليّة في C. الخلاصة آمل أن يكون هذا المقال قد أثبت لك أن sudo أكثر بكثير من مجرّد بادئة بسيطة. هناك الكثير من الاحتمالات لضبط الأذونات على نظامك. فأنت هنا لا تتمكن من ضبط الأذونات فحسب بل تتمكن أيضًا من تحسين الأمان عن طريق التحقق من عمليات مصادقة digests. تُمكّنك تسجيلات الجلسة من التحقّق مما يحدث على أنظمَتك. بإمكانك أيضًا توسيع وظيفة sudo باستخدام الإضافات، إما باستخدام شيء متاح مُسبقًا أو كتابة ما تريد بشكل خاص. أخيرًا وبالنظر إلى قائمة الميزات القادمة يمكنك أن ترى أنه حتى لو كان عمر sudo عقودًا إلاّ أنّه مشروع حيّ يتطور باستمرار. إذا كنت ترغب بمعرفة المزيد عن sudo فإليك بعض الموارد: موقع sudo الإلكتروني مدونة sudo ترجمة وبتصرف للمقال What you probably didn’t know about sudo لصاحبه Peter Czanik

سيُزار موقعك الإلكتروني هذه الأيام من مجموعةٍ واسعةٍ من الأجهزة: أجهزة الحواسيب المكتبيّة ذات الشاشات الكبيرة وأجهزة الحواسيب المحمولة متوسطة الحجم والأجهزة اللوحيّة والهواتف الذكيّة وغيرها. يتوجب على موقعك من أجل تحقيق تجربة المستخدم المثلى كمطوّر واجهة أماميّة (front-end engineer) ضبط تخطيط الصفحة (layout) استجابةً لهذه الأجهزة المختلفة (على سبيل المثال، دقّة الشاشة وأبعادها المتنوعة). يُشار إلى عملية الاستجابة لشكل جهاز المستخدم باسم (ربما توقعت ذلك) تصميم الويب المتجاوب (RWD). لماذا يجدر بك صرف وقتك لدراسة أمثلة تصميم الويب المتجاوب وتحويل تركيزك إليه؟ يعمل بعض مصممي الويب على سبيل المثال على التأكّد من الحصول على تجربة مستخدم مستقرة عبر جميع المتصفحات، حيث يمضون غالبًا أيامًا في معالجة قضايا صغيرة باستخدام المتصفح Internet Explorer. هذا نهج فاشل. يُمضي بعض مصممي الويب أيامًا في معالجة المشكلات الصغيرة لمستخدمي متصفح Internet Explorer ويتركون مستخدمي الأجهزة المحمولة لديهم كزوار درجة ثانية. وهذا نهج فاشل. أطلق Mashable على عام 2013 عام تصميم الويب المتجاوب. لماذا ا؟ لأن أكثر من 30 ٪ من «حركة مرور البيانات» (traffic) الخاصّة بهم تأتي من الأجهزة المحمولة. إنّهم يتوقعون أن يصل هذا العدد إلى 50٪ بحلول نهاية العام. في الويب بشكل عام، جاءت 17.4٪ من حركة مرور بيانات الويب من الهواتف الذكيّة في عام 2013. يمثل استخدام Internet Explorer في الوقت نفسه على سبيل المثال 12٪ فقط من إجمالي حركة مرور بيانات المستعرض، بانخفاض وقدره 4٪ تقريبًا عن مثل هذا الوقت من العام الماضي (وفقًا لـ W3Schools). إذا كنت تعمل على التحسين لمتصفح معين، بدلًا من مستخدمي الهواتف الذكيّة العالميين، فأنت تضيع في التفاصيل. يمكن أن يُشكّل هذا في بعض الحالات الفرق بين النجاح والفشل - التصميم المتجاوب له آثار على معدلات التحويل (conversion rates) وتحسين ظهور الموقع في محركات البحث (SEO) ومعدلات الارتداد (bounce rates) وغيرها. نهج تصميم الويب المتجاوب إنّ الأمر الأكثر أهميّة في RWD عادةً لا يتعلق فقط بضبط مظهر صفحات الويب الخاصّة بك، بل إنّ التركيز يجب أن يكون على تكييف موقعك منطقيًا للاستخدام عبر أجهزة مختلفة. على سبيل المثال: لا يوفّر استخدام الماوس تجربة المستخدم نفسها التي توفّرها شاشة اللمس. ألا توافقني الرأي؟ يجب أن يعكس تخطيط هاتفك المحمول مقابل تخطيطات الأجهزة المكتبيّة هذه الاختلافات. أنت لا تريد في الوقت نفسه إعادة كتابة موقعك بالكامل من أجل كل حجم من عشرات الأحجام المختلفة للشاشة التي قد يُعرض عليها - فهذه الطريقة ببساطة غير مُمكنة. إنّ الحل البديل هو استعمال عناصر تصميم متجاوبة مرنة تستخدم نفس شيفرة الـ HTML للتكيّف مع حجم شاشة المستخدم. يكمن الحل من وجهة نظر تقنيّة في هذا الدليل للتصميم المتجاوب: في استخدام استعلامات وسائط CSS والعناصر الزائفة وضبط تخطيطات الشبكة المرنة، وأدوات أخرى للتكيُّف ديناميكيًا مع دقّة معيّنة. استعلامات الوسائط في التصميم المتجاوب ظهرت أنواع الوسائط للمرة الأولى في HTML4 و CSS2.1، مما أتاح وضع ملف CSS منفصل للشاشة و آخر للطباعة. وبهذه الطريقة، أصبح بالإمكان تعيين أنماط منفصلة لعرض الصفحة على الحاسوب بشكل مقابل للنسخة المطبوعة. <link rel="stylesheet" type="text/css" href="screen.css" media="screen"> <link rel="stylesheet" type="text/css" href="print.css" media="print"> أو @media screen { * { background: silver } } يمكنك في CSS3 تحديد تنسيق الصفحة وتخطيطها اعتمادًا على عرض الصفحة. ولأن عرض الصفحة يرتبط بحجم جهاز المستخدم، فإنّ هذه الإمكانية تتيح لك بالتالي تحديد تخطيطات مختلفة للأجهزة المختلفة. ملاحظة: تُدعم استعلامات الوسائط من قبل جميع المتصفحات الرئيسية إنّ هذا التعريف ممكن من خلال إعداد الخصائص الأساسية: max-widt وdevice-width وorientation وcolor وهناك تعريفات أخرى ممكنة كذلك، ولكن في هذه الحالة فإنّ أهم الأشياء التي يجب وضعها في الحسبان هو الحد الأدنى من الدقّة («العرض» (width)) وإعدادات الاتجاه (أفقي أو عمودي). يوضّح مثال CSS المتجاوب أدناه الإجراء لبدء ملف CSS معين اعتمادًا على عرض الصفحة. ستُطبّق على سبيل المثال الأنماط المحدّدة في الملف main_1.css إذا كان الحد الأقصى لدقّة شاشة الجهاز الحالي هو 480 بكسل. <link rel="stylesheet" media="screen and (max-device-width: 480px)" href="main_1.css" /> يمكننا أيضًا تحديد أنماط مختلفة داخل ورقة أنماط CSS نفسها بحيث تُستخدم فقط في حالة استيفاء قيود محدّدة. لن يُستخدم على سبيل المثال هذا الجزء من ملف CSS المتجاوب إلا إذا كان عرض الجهاز الحالي أكثر من 480 بكسل: @media screen and (min-width: 480px) { div { float: left; background: red; } ....... } التكبير الذكيّ (smart zoom) تَستخدم متصفحات الهاتف المحمول ما يسمى «التكبير الذكي» (smart zoom) لتزويد المستخدمين بتجربة قراءة "ممتازة". يُستخدم التكبير الذكيّ في الأساس لتقليل حجم الصفحة بشكل متناسب. وهذا يمكن أن يظهر بطريقتين: (1) التكبير الذي يبدؤه المستخدم (على سبيل المثال، النقر مرتين على شاشة iPhone للتكبير على موقع الويب الحالي)، و(2) عرض نسخة مكبّرة منذ البداية من صفحة الويب عند التحميل. نظرًا لأنه يمكننا فقط استخدام استعلامات الوسائط المتجاوبة لحل أي من المشكلات التي قد يستهدفها التكبير / التصغير الذكيّ، فمن المستحسن في كثير من الأحيان (أو حتى الضروري) تعطيل التكبير والتأكّد من أنّ محتوى صفحتك يملأ المتصفح دائمًا: <meta name="viewport" content="width=device-width, initial-scale=1" /> إننا نتحكم في مستوى تكبير الصفحة الأولي (أي مقدار التكبير عند تحميل الصفحة) عن طريق ضبط قيمة initial-scale إلى القيمة 1. إذا صُممت صفحة الويب الخاصة بك لتكون متجاوبة، فإنّه عليك أن يملأ التصميم الديناميكي المتكيّف شاشة الهاتف الذكي بطريقة ذكيّة دون الحاجة إلى أي تكبير أولي. يمكننا إضافة إلى ذلك تعطيل التكبير / التصغير بالكامل باستخدام user-scalable=false. عرض الصفحة (page widths) افترض أنك ترغب بتوفير ثلاثة تخطيطات مختلفة للصفحة المتجاوبة: واحدة من أجل أجهزة الحواسب المكتبيّة، وأخرى للأجهزة اللوحيّة (أو أجهزة الحواسيب المحمولة)، وثالثة للهواتف الذكيّة. ما هي أبعاد الصفحة التي يجب أن تستهدفها كقوالب (على سبيل المثال، 480 بكسل)؟ لا يوجد لسوء الحظ معيار محدّد يمكن اعتماده لعرض الصفحة (page width)، ولكن غالبًا ما يتم استخدام قيم التجاوب التالية: 320 بكسل 480 بكسل 600 بكسل 768 بكسل 900 بكسل 1024 بكسل 1200 بكسل يوجد مع ذلك عددًا من تعريفات العرض المختلفة. يحتوي على سبيل المثال عرض 320 وما فوق على خمس زيادات افتراضية لاستعلام الوسائط في CSS3 وهي:480، 600، 768، 992، 1382 بكسل. يمكنني أن أعدّد عشرة أساليب أخرى على الأقل إضافة إلى المثال الوارد في هذا الدليل لتطوير الويب المتجاوب. يمكنك تغطية معظم أجهزة العرض مع أي من هذه المجموعات المنطقية من الزيادات. عمليًا لا توجد حاجة عادةً للتعامل بشكل منفصل مع جميع الأمثلة المذكورة أعلاه لعرض الصفحة- سبعة خيارات دقّة مختلفة تُعدّ مبالغةً نوعًا ما. إنّ 320px و 768px و 1200px هي القيم الأكثر استخدامًا اعتمادًا على تجربتي. يجب أن تكون هذه القيم الثلاثة كافيةً للتعامل مع الهواتف الذكيّة والأجهزة اللوحيّة / أجهزة الحواسيب المحمولة وأجهزة الحواسيب المكتبيّة بالترتيب. العناصر الزائفة (Psuedo-Elements) قد ترغب أيضًا بناءً على أفضل استعلامات الوسائط المتجاوبة لديك في المثال السابق بإظهار أو إخفاء معلومات معيّنة برمجيًّا وفقًا لحجم شاشة جهاز المستخدم. يمكن لحسن الحظ تحقيق ذلك أيضًا باستخدام CSS صرف كما هو موضّح في الدليل أدناه. بالنسبة للمبتدئين، يمكن أن يكون إخفاء بعض العناصر (display: none;‎) حلاً رائعًا عندما يتعلق الأمر بتقليل عدد العناصر التي تظهر على شاشة التخطيط الخاص بالهاتف الذكيّ حيث لا تتوفر دائمًا مساحة كافية. يمكنك من جهة أخرى أيضًا أن تكون مبدعًا باستخدام عناصر CSS الزائفة (محددات (selectors))، مثل ‎:before و‎:aft. ملاحظة: مرّةّ أخرى، تُدعم العناصر الزائفة من قبل جميع المتصفحات الرئيسية. تُستخدم العناصر الزائفة لتطبيق أنماط محدّدة على أجزاء محدّدة لعنصر HTML، أو لتحديد مجموعة فرعيّة معيّنة من العناصر. يتيح لك على سبيل المثال العنصر الزائف :first-line تحديد الأنماط المطبّقة فقط على السطر الأول لمحدّد معين (على سبيل المثال، p:first-line سيُطبّق على السطر الأول من كل عناصر الفقرة p). وبالمثل، فسيُتيح لك العنصر الزائف a:visited تحديد الأنماط المطبّقة على كافة عناصر a مع الروابط التي زارها المستخدم سابقًا. كان هذا مفيدًا صراحةً. فيما يلي مثال بسيط لتصميم متجاوب، حيث نُنشئ ثلاثة تخطيطات مختلفة لزر تسجيل الدخول لكل من أجهزة الحواسيب المكتبيّة والأجهزة اللوحيّة والهواتف الذكيّة. سيكون لدينا على الهاتف الذكيّ فقط أيقونة، بينما سيكون على الحاسوب اللوحيّ الأيقونة نفسها مرفقةً بعبارة "User name"، سنُضيف أخيرًا للأجهزة المكتبيّة أيضًا رسالة توضيحيّة قصيرة ("Insert your user name"). .username:after { content:"Insert your user name"; } @media screen and (max-width: 1024px) { .username:before { content:"User name"; } } @media screen and (max-width: 480px) { .username:before { content:""; } } يمكننا إنجاز ما يلي اعتمادًا فقط على العناصر الزائفة التالية:before و:after:: لمعرفة المزيد عن سحر العناصر الزائفة، يوجد لدى Chris Coyier " وصف تفصيلي جيد عن حيل CSS)(CSS-Tricks. إذًا، من أين أبدأ؟ أنشأنا في هذا الدليل بعضًا من العناصر الأساسيّة لتَصميم ويب متجاوب (أي استعلامات الوسائط والعناصر الزائفة) وقدّمنا بعض الأمثلة لكل منها. ولكن إلى أين سنذهب الآن؟ الخطوة الأولى التي يجب اتخاذها هي تنظيم جميع عناصر صفحة الويب الخاصة بك من أجل أحجام مختلفة للشاشة. ألقِ نظرة على إصدار الأجهزة المكتبيّة للتخطيط المقدّم أعلاه. يمكن في هذه الحالة أن يكون المحتوى على اليسار (المستطيل الأخضر) كنوع من أنواع القائمة الرئيسية. ولكن عند استخدام الأجهزة ذات الدقة المنخفضة (على سبيل المثال، جهاز لوحي أو هاتف ذكي)، فقد يكون من المنطقي إظهار هذه القائمة الرئيسية بالعرض الكامل. يمكنك تطبيق هذا النهج باستخدام استعلامات الوسائط كما يلي: @media screen and (max-width: 1200px) { .menu { width: 100%; } } @media screen and (min-width: 1200px) { .menu { width: 30%; } } لسوء الحظ، غالبًا ما يكون هذا النهج الأساسي غير كافٍ مع زيادة تعقيد الواجهة الأماميّة. ونظرًا لأن تنظيم محتوى الموقع غالبًا ما يختلف اختلافًا كبيرًا بين إصدارات الأجهزة المحمولة والأجهزة المكتبيّة، فإنّ تجربة المستخدم تعتمد في نهاية المطاف ليس فقط على استخدام CSS المتجاوب، ولكن أيضًا على استخدام HTML وJavaScript. هناك عدة عناصر رئيسيّة مهمّة عند تحديدك لتخطيطات متجاوبة للأجهزة المختلفة. يُعد التطوير بالنسبة للهواتف الذكيّة أكثر تطلبًا بخلاف الإصدارات الخاصّة بالحواسيب المكتبيّة حيث تتوفر مساحات كافية لعرض المحتوى. فمن الضروري أكثر من أي وقت مضى تجميع محتويات محدّدة وتحديد أهميّة الأجزاء الفرديّة هرميًّا. إنّه من المهم أكثر من أي وقت مضى بالنسبة للهاتف الذكي تجميع محتويات محدّدة وتحديد أهمية الأجزاء الفرديّة هرميًّا. إنّ الاستخدامات المختلفة لمحتواك مهمة أيضًا. فمثلًا عندما يكون لدى المستخدم إمكانية استخدام الفأرة يمكنه عندها ضبط المؤشر فوق عناصر معيّنة للحصول على معلومات إضافيّة، بحيث يمكنك (كمطوّر ويب) ترك بعض المعلومات لتُجمّع بهذه الطريقة - لكن الحال لن يكون ذاته عند استخدام الهاتف الذكيّ. بالإضافة إلى ذلك، إذا وضعت أزرارًا على موقعك والتي ستظهر على الهواتف الذكيّة بحجم أصغر من الحجم النموذجي للإصبع، فسَتخلق حالةً من عدم اليقين وعدم الارتياح في استخدام موقعك وفي مظهره. لاحظ إنّ عرض الويب القياسي في الصورة أعلاه (على اليسار) يجعل بعض العناصر غير قابلة للاستخدام تمامًا عند عرضها على جهاز أصغر. سيزيد هذا السلوك أيضًا من فرص قيام المستخدم بخطأ ما، مما يؤدي إلى إبطاء تجربته. يمكن أن يتجلى ذلك في الممارسة العمليّة في انخفاض عدد مرات عرض الصفحة، وانخفاض المبيعات، ومشاركة أقل بشكل عام. عناصر تصميم متجاوبة أخرى يتوجب تذكّر سلوك جميع عناصر الصفحة عند استخدام استعلامات الوسائط وليس فقط العناصر المستهدفة -لا سيما عند استخدام «الشبكات المرنة» (fluid grids)- وفي هذه الحالة (وعلى عكس الأبعاد الثابتة) ستُملئ الصفحة بالكامل في أي وقت، وسيكبر ويصغر حجم المحتوى بما يتناسب معها. نظرًا لتعيين قيم العرض بالنسب المئوية، يمكن أن يحدث تشوه للعناصر الرسوميّة (أي الصور) أو تلفها عند استخدام الشبكات المرنة. إنّ أحد الحلول للصور هو كما يلي: img { max-width: 100% } يجب التعامل مع العناصر الأخرى بطرق مماثلة. فمثلًا يُعدّ استخدام IconFontsحلًّا رائعًا للأيقونات في تصميم الويب المتجاوب. نبذة عن أنظمة الشبكات المرنة عندما نناقش عملية التكيّف الكامل للتصميم فإننا غالبًا ما نتطلع إلى تجربة المشاهدة المثلى (من وجهة نظر المستخدم). يجب أن تتضمن مناقشة كهذه الحد الأعلى لسهولة الاستخدام ولأهميّة العناصر (استنادًا إلى مناطق الصفحة المرئية) ولسهولة القراءة وللتنقل السهل. يُعدّ ضبط عرض المحتوى (content width) من أهم المكونات من بين التصنيفات السابقة. حدَّدت على سبيل المثال ما يسمى بأنظمة الشبكات المرنة عناصر تعتمد على العرض النسبي كنسب مئوية من الصفحة الإجمالية. وبهذه الطريقة تُضبط تلقائيًا جميع العناصر في نظام تصميم الويب المتجاوب بما يتناسب مع حجم الصفحة. على الرغم من أن أنظمة fluid grids هذه ترتبط ارتباطًا وثيقًا بما ناقشناه هنا، إلا أنّها في الحقيقة كيان منفصل بالكامل يتطلب تعليمًا إضافيًا للمناقشة التفصيليّة. لذلك سأذكر هنا فقط بعضًا من الأُطر الرئيسيّة التي تدعم مثل هذا النهج: Bootstrap و Unsemantic و Brackets. الخلاصة كان تحسين موقع الويب حتى وقت قريب مصطلحًا مخصّصًا حصريًا لتخصيص الوظائف استنادًا إلى متصفحات الويب المختلفة. يفترض هذا المصطلح الآن إلى جانب الصراع المحتوم مع معايير المتصفح المختلفة التي نواجهها اليوم التكيف مع الأجهزة والأحجام المختلفة الشاشة ومع تصميم الويب المتجاوب أيضًا. ولكي يتناسب مع شبكة الإنترنت الحديثة. يجب أن يعرف موقعك ليس فقط من يتصفحه ولكن كيف يتصفحه. ترجمة وبتصرف للمقال Introduction to Responsive Web Design: Pseudo-Elements, Media Queries, and More لصاحبه Tomislav Krnic.

مع انتقال أدوات المطوّرين إلى «السحابة» (cloud)، يتزايد إنشاء واعتماد منصّات بيئة التطوير المتكاملة (IDE) السحابية. تتيح منصّات Cloud IDE التعاون في الوقت الحقيقي بين فرق المطوّرين من أجل العمل في بيئة تطوير موحّدة ما من شأنه التقليل من حالات عدم التوافق وتحسين الإنتاجية. حيث يمكن الوصول إليها من خلال متصفحات الويب، وتتوفر Cloud IDEs من كل أنواع الأجهزة الحديثة. إن code-server هو نسخة Microsoft Visual Studio Code تعمل على خادم بعيد ويمكن الوصول إليها مباشرة من متصفحك. المحرر Visual Studio Code هو محرّر تعليمات برمجيّة حديث مع دعم متكامل لـ Git ومنقّح شيفرة وإكمال تلقائي ذكي وميزات أخرى قابلة للتخصيص والتوسيع. يعني هذا أنه سيتوفر لديك دائمًا بيئة تطوير متناسقة حتى مع استخدامك لأجهزة متنوعة تعمل بأنظمة تشغيل مختلفة. ستقوم في هذه الدليل بإعداد منصّة code-server cloud IDE على جهاز يعمل بنظام تشغيل أبونتو 18.04 وإتاحتها على «اسم النطاق» (domain) خاصتك، وسيكون محميّ بشهادات TLS Let's Encrypt المجانيّة. وسيكون لديك في النهاية نسخة Microsoft Visual Studio Code تعمل على خادم Ubuntu 18.04 الخاص بك ومتاحةً على اسم نطاقك ومحميّة بكلمة مرور. المتطلبات المُسبقة خادم يعمل بنظام تشغيل Ubuntu 18.04 على الأقل مع ذاكرة وصول عشوائي (RAM) سعة 2 جيجا بايت، وامتيازات «وصول المستخدم الجذر» (root access)، وحساب sudo «عادي» (non-root). يمكنك إعداد ذلك باتباع هذا الدليل للإعداد الأولي للخادم. نسخة Nginx مُثبتة على خادمك. للحصول على دليل حول كيفيّة القيام بذلك، أكمل الخطوات من 1 إلى 4 حول كيفيّة تثبيت Nginx على Ubuntu 18.04. كلًّا من سجلي DNS التاليين المُعدّين لخادمك. يمكنك متابعة هذه المقدمة إلى DigitalOcean DNS للحصول على تفاصيل حول كيفية إضافتها. سجل لـyour-domain يشير إلى عنوان IP العام للخادم الخاص بك. سجل لـwww.your-domain يشير إلى عنوان IP العام لخادمك. اسم نطاق domain مسجّل بالكامل لاستضافة code-server يُشير إلى خادمك الخاص. سيَستخدم هذا الدليل code-server.your-domain في كامل المقال. يمكنك شراء اسم نطاق من Namecheap أو الحصول على واحد مجانًا عبر Freenom أو استخدام أي موقع تسجيل نطاقات تختاره. الخطوة 1: تثبيت code-server ستقوم في هذا القسم بإعداد code-server على خادمك الخاص. سيستلزم ذلك تنزيل أحدث إصدار وإنشاء خدمة systemd والتي من شأنها أن تُبقي code-server يعمل دائمًا في الخلفية. ستحدد أيضًا سياسة إعادة التشغيل للخدمة، بحيث يبقى code-server متاحًا بعد الأعطال أو إعادات التشغيل المحتملة. سنُخزن جميع البيانات المتعلقة بـ code-server في مجلد باسم ‎~/code-server أنشئه عن طريق تنفيذ الأمر التالي: mkdir ~/code-server انتقل إليه: cd ~/code-server ستحتاج إلى الانتقال إلى صفحة إصدارات Github لـ code-server واختيار أحدث إصدار من Linux (سيحتوي اسم الملف على الكلمة "linux"). كان الإصدار الأخير عند كتابة هذا التقرير هو 2.1692. نزّله باستخدامwgetعن طريق تشغيل الأمر التالي: wget https://github.com/cdr/code-server/releases/download/2.1692-vsc1.39.2/code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz فكّ بعد ذلك ضغط الأرشيف من خلال تشغيل الأمر التالي: tar -xzvf code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz ستحصل على مجلد باسم الملف الأصلي الذي قمت بتنزيله والذي يحتوي على ملف الـ code-server القابل للتنفيذ. انتقل إليه: cd code-server2.1692-vsc1.39.2-linux-x86_64 انسخ ملف code-server التنفيذي إلى المسار /usr/local/bin حتى تتمكن من الوصول إليه عبر كامل نطاق النظام عن طريق تشغيل الأمر التالي: sudo cp code-server /usr/local/bin أنشئ بعد ذلك مجلد لـ code-server حيث ستُخزين بيانات المستخدم: sudo mkdir /var/lib/code-server الآن وبعد تنزيلك لـ code-server وجعله متاحًا على مستوى النظام، ستُنشئ خدمة systemd لإبقاء code-server يعمل في الخلفيّة بشكل دائم. ستخزّن ضبط الخدمة في ملف باسم code-server.service، في المسار‎/lib/systemd/system حيث يخزن systemd خدماته. أنشئه باستخدام محرّر نصوصك الخاص: sudo nano /lib/systemd/system/code-server.service أضف الأسطر التالية في الملف ‎/lib/systemd/system/code-server.service: [Unit] Description=code-server After=nginx.service [Service] Type=simple Environment=PASSWORD=your_password ExecStart=/usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password Restart=always [Install] WantedBy=multi-user.target يتوجب عليك هنا أولًا تحديد وصفٍ للخدمة. تذكر بعد ذلك أنّ خدمة nginx يجب أن تُشغّل قبل هذه الخدمة. يمكنك بعد القسم [Unit] تحديد نوع الخدمة (تعني simple أنه يجب تشغيل العملية ببساطة) وتجهيز الأمر الذي سيُنفّذ. يمكنك أيضًا تحديد أنّه يجب تشغيل code-server العموميّ القابل للتنفيذ مع إضافة بعض «الوسائط» (arguments) لـ code-server. الوسيط ‎--host 127.0.0.1 يربطه مع localhost، وبذلك يمكن الوصول إليه مباشرة فقط من داخل خادمك الخاص. يعين الوسيط ‎--user-data-dir /var/lib/code-server مسار بيانات المستخدم الخاص به، - يُحدّد ‎--auth password أنّه يجب مصادقة الزائرين باستخدام كلمة مرور، كما هو محدّد في متغير البيئة PASSWORD المصرّح عنه في السطر الذي يسبقه. لا تنسَ استبدال your_password بكلمة مرورك الخاصّة ثم احفظ وأغلق الملف. يطلب السطر التالي من systemd إعادة تشغيل code-server عند حصول أي خلل (على سبيل المثال عند تعطله أو إنهاء العملية قسريًّا). يطلب القسم [Install] من systemd بدء هذه الخدمة عندما يصبح بالإمكان تسجيل الدخول إلى الخادم الخاص بك. ابدأ خدمة code-server عن طريق تشغيل الأمر التالي: sudo systemctl start code-server تحقّق من أنها بدأت بشكل صحيح من خلال مراقبة حالاتها: sudo systemctl status code-server سترى خرجًا مشابهًا لما يلي: code-server.service - code-server Loaded: loaded (/lib/systemd/system/code-server.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2019-12-09 20:07:28 UTC; 4s ago Main PID: 5216 (code-server) Tasks: 23 (limit: 2362) CGroup: /system.slice/code-server.service ├─5216 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password └─5240 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password Dec 09 20:07:28 code-server-ubuntu-1804 systemd[1]: Started code-server. Dec 09 20:07:29 code-server-ubuntu-1804 code-server[5216]: info Server listening on http://127.0.0.1:8080 Dec 09 20:07:29 code-server-ubuntu-1804 code-server[5216]: info - Using custom password for authentication Dec 09 20:07:29 code-server-ubuntu-1804 code-server[5216]: info - Not serving HTTPS مكّن خدمة code-server لجعله يعمل تلقائيًا بعد إعادة تشغيل الخادم من خلال تشغيل الأمر التالي: sudo systemctl enable code-server قمتَ في هذه الخطوة بتنزيل code-server وجعله متاحًا على نحوٍ عمومي. وقمت بعدها بإنشاء خدمة systemd له وتمكينها، لذلك سيبدأ code-server بالعمل عند كل إقلاع للخادم. بعد ذلك، ستعرضه في نطاقك الخاص من خلال ضبط Nginx ليكون بمثابة وكيل عكسيّ بين الزائر و code-server. الخطوة 2: عرض code-server على نطاقك الخاص ستقوم في هذا القسم بضبط Nginx كوكيل عكسي لـ code-server. كما تعلمت في خطوة المتطلبات المُسبقة لـ Nginx، تُخزّن ملفات ضبط الموقع الخاصة به ضمن ‎/etc/nginx/sites-available، ويجب ربطها لاحقًا بـ ‎/etc/nginx/sites-enabled لتصبح نشطة. سنُخزين الضبط لعرض خادم الشفرة في نطاقك في ملف باسم code-server.conf تحت المسار ‎/etc/nginx/sites-available. ابدأ بإنشائه باستخدام المحرّر الخاص بك: sudo nano /etc/nginx/sites-available/code-server.conf أضف الأسطر التالية في الملف ‎/etc/nginx/sites-available/code-server.conf: server { listen 80; listen [::]:80; server_name code-server.your-domain; location / { proxy_pass http://localhost:8080/; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } } استبدل code-server.your-domain باسم لنطاق المطلوب ثم احفظ وأغلق الملف. تحدّد في هذا الملف أنه على Nginx أن يتنصت إلى منفذ HTTP رقم 80. ثم يمكنك تحديد server_name والذي يُخبر Nginx عن النطاق الذي يقبل الطلبات ويطبّق هذا الضبط المحدّد. في الكتلة التالية بالنسبة، لموقع الجذر (/) يمكنك تحديد أنّ الطلبات يجب تمريرها ذهابًا وإيابًا إلى code-server يعمل على localhost:8080. تطلب الأسطر الثلاثة التالية (بدءًا من proxy_set_header) من Nginx نقل بعض ترويسات طلبات HTTP اللازمة من أجل التشغيل الصحيح لـ WebSockets، والذي يستخدمه code-server على نطاق واسع. ستحتاج إلى إنشاء رابط له في المجلد ‎/etc/nginx/sites-enableمن أجل تنشيط ضبط هذا الموقع وذلك من خلال تشغيل الأمر الآتي: sudo ln -s /etc/nginx/sites-available/code-server.conf /etc/nginx/sites-enabled/code-server.conf شغّل الأمر التالي لاختبار صحّة الضبط: sudo nginx -t سترى الخرج التالي: Output nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful ستحتاج إلى إعادة تشغيل Nginx لكي يُطّبق الضبط: sudo systemctl restart nginx لديك الآن تثبيت code-server قابل للوصول على نطاقك. ستقوم في الخطوة التالية بتأمينه من خلال تطبيق شهادة Let's Encrypt TLS المجانيّة. الخطوة 3: تأمين النطاق ستقوم في هذا القسم بتأمين نطاقك الخاص باستخدام شهادة Let’s Encrypt TLS، والتي ستوفرها باستخدام Certbot. ستحتاج من أجل تثبيت أحدث إصدار من Certbot إلى إضافة مستودع الحزمة الخاص به إلى خادمك عن طريق تشغيل الأمر التالي: sudo add-apt-repository ppa:certbot/certbot ستحتاج إلى الضغط علىENTER للموافقة. ثبّت بعد ذلك Certbot وإضافة Nginx الخاص به: sudo apt install python-certbot-nginx كنت قد مكّنت ufw (جدار حماية غير معقّد) كجزء من المتطلبات المُسبقة وقمت بضبطه للسماح بحركة مرور HTTP غير المشفّرة. وستحتاج إلى ضبطه لقبول حركة المرور المشفّرة حتى تتمكن من الوصول إلى الموقع الآمن عن طريق تشغيل الأمر التالي: sudo ufw allow https سيكون الخرج: Output Rule added Rule added (v6) ستحتاج كما في Nginx إلى إعادة تحميله حتى يصبح الضبط ساري المفعول: sudo ufw reload سيُظهر الخرج ما يلي: Firewall reloaded انتقل بعد ذلك في متصفحك إلى النطاق الذي استخدمته لـ code-server. حيث سيظهر محّث تسجيل الدخول لـ code-server. سيطلب code-server كلمة المرور الخاصّة بك. أدخل الكلمة التي اخترتها في الخطوة السابقة واضغط على** Enter IDE**. ستدخل الآن إلى code-server وسترى محرّر واجهة المستخدم الرسومية GUI مباشرةً. الآن وبعد تأكّدك من أن خادم الشيفرة قد عُرض بشكل صحيح في نطاقك، سنُثبّت شهادات Let’s Encrypt TLS لتأمينه، باستخدام Certbot. شغّل الأمر التالي لطلب شهادات لنطاقك: sudo certbot --nginx -d code-server.your-domain تقوم في هذا الأمر بتشغيل certbot لطلب شهادات لنطاقك — يمكنك تمرير اسم النطاق باستخدام الراية ‎-d تخبر الراية ‎--nginx بتغيير ضبط موقع Nginx تلقائيًا لدعم HTTPS. تذكر استبدال code-server.your-domain باسم نطاقك الخاص. إذا كانت هذه هي المرة الأولى التي تُشغّل فيها Certbot فسيُطلب منك تقديم عنوان بريد إلكتروني للإشعارات العاجلة وقبول شروط خدمة EFF. سيطلب Certbot بعد ذلك شهادات لنطاقك من Let’s Encrypt. كما سيسألك بعدها فيما إذا كنت ترغب في إعادة توجيه جميع زيارات HTTP إلى HTTPS: Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): يُوصى بتحديد الخيار الثاني من أجل زيادة الأمان. اضغطENTERبعد إدخال اختيارك. سيكون الخرج مشابهًا لهذا: IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/code-server.your-domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/code-server.your-domain/privkey.pem Your cert will expire on ... To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le هذا يعني أن Certbot أنشئ شهادات TLS بنجاح وطبّقها على ضبط Nginx لنطاقك. يمكنك الآن القيام بإعادة تحميل اسم نطاق code-server الخاص بك في متصفحك ورؤية رمز القفل على يسار عنوان الموقع مما يعني أن اتصالك أصبح آمنًا. الآن وبعد أن أصبح لديك code-server يمكن الوصول إليه في نطاقك من خلال وكيل Nginx عكسي آمن، أصبحت على استعداد لاستعراض واجهة المستخدم لـ code-server. الخطوة 4: استخدام واجهة code-server ستستخدم في هذا القسم بعضًا من ميزات واجهة code-server. ولأنّ code-server هو عبارة عن Visual Studio Code يعمل على السحابة، فإنّه يحتوي على نفس واجهة إصدار سطح المكتب المستقلة. يوجد على الجانب الأيسر من الـ IDE صف عمودي مكوّن من ستة أزرار يُتيح استعمال أكثر الميزات استخدامًا في لوحة جانبية تُعرف باسم Activity Bar. هذا الشريط قابل للتخصيص بحيث يمكنك نقل هذه الأزرار إلى ترتيب مختلف أو إزالتها من الشريط. افتراضيًا يفتح الزر الأول القائمة العامة في قائمة منسدلة، بينما يفتح الزر الثاني لوحة Explorer التي توفر التنقل الهرمي الشبيه ببنية المشروع. يمكنك إدارة المجلدات والملفات هنا – من إنشاء وحذف ونقل وإعادة تسمية حسب الضرورة. يُوفّر الزر التالي التالية إمكانية الوصول إلى وظيفة البحث والاستبدال. بعد ذلك، وبالترتيب الافتراضي (أي الزر الرابع) يُتيح معاينة لأنظمة التحكم في المصدر مثل Git. يدعم Visual Studio code أيضًا موفري التحكم بالمصدر الآخرين ويمكنك العثور على مزيد من الإرشادات لتدفقات عمل التحكم بالمصدر مع المحرّر في هذه الوثائق. يوفر خيار المنقّح debugger في Activity Bar جميع الأدوات الشائعة للتنقيح في اللوحة. يأتي Visual Studio Code مع دعم مضمّن لمنقّح وقت التشغيل Node.js وأي لغة تنتمي إلى Javascript. وبالنسبة للغات أخرى يمكنك تثبيت إضافاتextensions للمنقح المطلوب. كما يمكنك حفظ ضبط التنقيح في ملفlaunch.json. يوفر الزر الأخير في Activity Bar قائمة للوصول إلى الملحقات المُتاحة في Marketplace. إنّ الجزء الرئيسي من واجهة المستخدم الرسوميّة هو محرّرك، والذي يمكنك فصله بواسطة علامات تبويب لتحرير شيفرتك. ويمكنك تغيير طريقة العرض الخاصة بك إلى نظام شبكة أو إلى طريقة عرض الملفات جنبًا إلى جنب. بعد إنشاء ملف جديد من خلال قائمة File، سيُفتح ملف فارغ في علامة تبويب جديدة، وبعد حفظه، سيكون اسم الملف معروضًا في اللوحة الجانبيّة لـ Explorer. يمكن إنشاء المجلدات عن طريق النقر بزر الفأرة الأيمن على الشريط الجانبي لـ Explorer والنقر فوق New Folder. يمكنك توسيع أحد المجلدات بالنقر فوق اسمه وكذلك سحب الملفات والمجلدات وإسقاطها في الأجزاء العليا من التسلسل الهرمي لنقلها إلى موقع جديد. بالإمكان الوصول إلى محطة طرفية عن طريق إدخال CTRL ‎+ SHIFT +‎، أو عن طريق النقر على Terminal في القائمة المنسدلة العليا واختيار New Terminal. سيُفتح الجهاز في لوحة أصغر وسيُوضع مجلد العمل الخاص به في مساحة عمل المشروع، والذي يحتوي على الملفات والمجلدات المعروضة في لوحة Explorer الجانبيّة. لقد أخذت نظرةً عامة عالية المستوى على واجهة code-server وراجعت بعضًا من الميزات الأكثر استخدامًا. الخلاصة لديك الآن بيئة التطوير المتكاملة code-server السحابية متعددة الاستخدامات مُثبّتة على خادم Ubuntu 18.04 ومعروضة في نطاقك المؤّمن باستخدام شهادات Let’s Encrypt. يمكنك الآن العمل على المشاريع بشكل فردي، وكذلك في إطار التعاون الجماعي. يحرّر تشغيل Cloud IDE الموارد على جهازك المحلي ويسمح لك بتوسيع نطاق الموارد عند الحاجة. راجع لمزيد من المعلومات توثيق Visual Studio Code للحصول على ميزات إضافيّة وإرشادات مفصّلة حول المكونات الأخرى لـ code-server. ترجمة وبتصرف للمقال How To Set Up the code-server Cloud IDE Platform on Ubuntu 18.04 لصاحبه Savic

غالبًا ما تشكّل الخطوط مشكلةً للعديد من مستخدمي الحاسوب، فهل سبق لك مثلًا وأن صَممت منشورًا رائعًا، وعند أخذك للملف للطباعة في مكان ما وجدت أنّ جميع عناوين تصميمك تحولت إلى خط 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 على صفحة الويب خاصتك: حمّل ملف GoudyStM-webfont.woff إلى خادم الويب الخاص بك: scp GoudyStM-webfont.woff seth@example.com:~/www/fonts/ قد يوفّر مضيفك أيضًا أداة تحميلٍ رسوميّة من خلال cPanel أو لوحة تحكم ويب مشابهة. أضف قاعدة ‎@font-face مشابهة لما يلي في ملف CSS الخاص بموقعك: @font-face { font-family: "titlefont"; src: url("../fonts/GoudyStM-webfont.woff"); } قيمة الواصفfont-familyهي تسمية تختارها للخط. إنها اسم أو وصف مألوف للإنسان بغض نظر عمّا تمثله قاعدة ‎@font-face للخط. استَخدمتُ القيمة "titlefont" في هذا المثال لأنني أتصوّر أنّ هذا الخط سيُستخدم للعناوين الرئيسية في موقع وهميّ. يمكنك ببساطة استخدام أيّة قيم أخرى مثل "officialfont" أو "myfont". قيمة الواصفsrc تُحدَد المسار إلى ملف الخط. يجب أن يكون هذا المسار موافقا لبنية ملف الخادم الخاص بك، لدي في هذا المثال المجلد fonts بجانب المجلد css. قد لا يكون موقعك منظمًا بهذه الطريقة، لذا اضبط المسارات بما يناسبك مع الآخذ بالحسبان أن نقطة واحدة (.) تعني هذا المجلد ونقطتان (..) تعنيان مجلدًا آخرًا للخلف (المجلد الحاوي [الأب] للمجلد الحالي). الآن وبعد تحديد اسم الخط وموقعه، يمكنك استدعائه في أي صنف class من أصناف CSS أو معرّف ID تريده. على سبيل المثال، إذا كنت ترغب في عرض <h1> بخط Sorts Mill Goudy، فعليك جعل قاعدة CSS الخاصّة به تستخدم اسم خطك المخصّص: h1 { font-family: "titlefont", serif; } أنت الآن تستخدم وتَستضيف خطوطك الخاصّة. ترجمة وبتصرف للمقال How to host your own webfonts لصاحبه Seth Kenlon

إزالة بعض الالتباس حول مفهوم DevOps. يتعرف الكثير من الناس على DevOps للمرّة الأولى عند رؤيتهم لإحدى انتاجاتها وتساؤلهم عن كيفية حدوث ذلك. إذ أنه ليس من الضروري فهم فيما إذا كان شيء ما يشكل جزءًا من DevOps للبدء بتنفيذه، لكن معرفة ذلك – ومعرفة ما الذي يجعل من DevOps استراتيجية مهمة- يمكن أن تشّكل الفارق بين كونك قائدًا أو تابعًا في مجالٍ ما. ربما سمعت عن بعض النتائج المدهشة التي تُنسب إلى DevOps، مثل بيئات الإنتاج عالية المرونة والتي يمكنها التعامل مع الآلاف من الإصدارات يوميًا بينما تدور أداة "Chaos Monkey" (وهي أداة برمجية طُوّرت بواسطة مهندسي Netflix لاختبار مرونة واسترداد خدمات Amazon Web Services [اختصارًا AWS] الخاصة بهم) حول هذه الاصدارات لفصل الأشياء بشكل عشوائي. هذا أمر مثير للإعجاب، ولكنه في حد ذاته يُمثل حالة عمل ضعيفة، مثقلة بشكل أساسي بإثبات سلبي (proving a negative): أن بيئة DevOps مرنة لأنه لم يُلاحظ فشل خطير ... حتى الآن. يوجد الكثير من الالتباس حول مفهوم DevOps ولا يزال الكثير من الناس يحاولون فهم ذلك. إليك مثال عن شخص ما عبر حسابي على موقع التواصل الاجتماعي LinkedIn: يتابع هذا المنشور المتخصصون في المجال التقني على موقع LinkedIn عبر شريحة واسعة من الإجابات. فكيف ترد؟ جذور DevOps في التصميم الرشيق (lean) والتصميم المرن (agile) تُعد DevOps أسهل للفهم إذا بدأنا باستراتيجيات هنري فورد وتحسينات نظام إنتاج تويوتا لنموذج فورد. وضمن هذا التاريخ ظهور منهجية التصميم الرشيق (lean)، والتي دُرست جيدًا. قام جيمس ب. ووماك ودانييل جونز في كتاب Lean Thinking بتلخيصها إلى خمسة مبادئ: تحديد القيمة المرغوبة من قبل العميل. تحديد سلسلة القيم لكل منتج يوفر هذه القيمة ويلغي جميع الخطوات المهدورة اللازمة حاليًا لتوفيره. جعل تدفق المنتج متواصلًا من خلال خطوات القيمة المضافة المتبقية. ادخال السحب بين جميع الخطوات التي يكون فيها التدفق المستمر ممكنًا. إدارة نحو الاكتمال بحيث ينخفض باستمرار عدد الخطوات ومقدار الوقت والمعلومات اللازمة لخدمة العملاء. تسعى منهجية التصميم الرشيق إلى إزالة الهدر باستمرار وزيادة تدفق القيمة إلى العميل. يمكن التعرف عليها بسهولة وفهمها من خلال مبدأ أساسي للتصميم الرشيق وهو مبدأ: تدفق القطعة الواحدة. يمكننا القيام بعدد من الأنشطة لمعرفة السبب في أن تحريك قطعة منفردة في كل مرة أسرع من تحريك قطع متعددة دفعة واحدة؛ إن لعبة Penny Game و لعبة الطائرة Airplane Game أمثلة على ذلك. ففي لعبة Penny، إذا استغرقت دفعة الـ 20 بنس دقيقتين للوصول إلى العميل، فسيحصل على كامل الدُفعة بعد دقيقتين من الانتظار. بينما إذا نقلت بنس واحد في كل مرة، فسيحصل العميل على أول بنس في غضون خمس ثوانٍ ويستمر في الحصول عليهم بنس تلو الآخر حتى يصل البنس العشرين بعد 25 ثانية تقريبًا. وهذا يعتبر فرقًا كبيرًا، ولكن ليس كل شيء في الحياة بسيط ويمكن التنبؤ به كما هو الحال هنا في مثال البنس في لعبة بيني. ومن هنا أتت «المنهجية المرنة» (agile). بالتأكيد نرى مبادئ Lean تنسحب على فرق Agile عالية الأداء، ولكن هذه الفِرق تحتاج إلى ما هو أكثر من مبادئ Lean للقيام بعملها. تركز عملية التصميم المرن Agile من أجل التمكن من التعامل مع عدم القدرة على التنبؤ وتباين مهام تطوير البرامج النموذجية، على المعرفة الصحيحة والتشاور والقرار والعمل على ضبط المسار في مواجهة الوقائع المتغيرة باستمرار. على سبيل المثال، تزيد الأطر الرشيقة (مثل «فريق سكروم» [scrum]) من الوعي بالمهام مثل الجاهزية اليومية والمراجعة الزمنية. فإذا أصبح فريق سكروم مدركًا لحقيقة جديدة، فإن الإطار يسمح له ويشجعه على ضبط المسار إن لزم الأمر. تحتاج الفِرق لاتخاذ هذه الأنواع من القرارات، إلى أن تكون منظمة ذاتيًا في بيئة عالية الثقة. تحقق فرق التصميم المرن عالية الأداء التي تعمل بهذه الطريقة تدفقًا سريعًا للقيمة مع ضبط للمسار بشكل مستمر، مزيلةً بذلك مضيعة الوقت في السير بالاتجاه الخاطئ. حجم الدفعة الأمثل يساعد فهم اقتصاديات حجم الدُفعات على فهم قوة DevOps في تطوير البرمجيات. تأمل الرسم التوضيحي الأمثل لمنحنى U التالي من كتاب دونالد راينترسن مبادئ تدفق تطوير المنتجات Principles of Product Development Flow: يمكن تفسير ذلك بتشبيه حول التسوق في البقالية. افترض أنك بحاجة إلى شراء بعض البيض وتعيش في مكان يبعد 30 دقيقة من المتجر. إن شراء بيضة واحدة (أقصى اليسار على الرسم التوضيحي) في المرة الواحدة يعني رحلة لمدة 30 دقيقة في كل مرة تريد فيها شراءها. هذه هي تكلفة المعاملة (transaction cost). قد تمثل تكلفة الحجز (holding cost) البيض التالف وشغل المساحة في الثلاجة لفترة من الزمن. التكلفة الإجمالية (total cost) هي تكلفة المعاملة مضافًا إليها تكلفة الحجز في الثلاجة. يفسر منحنى U هذا السبب، بالنسبة لمعظم الناس، بإن شراء أكثر من 12 بيضة (دزينة) في وقت واحد هو الحجم الأمثل للدفعة. إذا كنت تعيش بجوار المتجر، فستكلفك القليل من المشي إلى هناك، وربما تشتري كرتونًا أصغر حجمًا في كل مرة لتوفير مساحة في الثلاجة والاستمتاع بالبيض الطازج. يمكن لهذا الرسم التوضيحي لتحسن منحنى U توضيح سبب زيادة الإنتاجية بشكل كبير في تحويلات المنهجية المرنة الناجحة. تأمل في تأثير تحويل agile على صنع القرار في المنظمة. تكون سلطة اتخاذ القرار مركزية في المنظمات الهرمية التقليدية. هذا يؤدي إلى اتخاذ عدد أكبر من القرارات وبتواتر أقل ومن قبل عدد أقل من الأشخاص. حيث ستعمل المنهجية المرنة (agile) على تقليل تكلفة معاملات المؤسسة بشكل فعال لاتخاذ القرارات من خلال تطبيق اللامركزية على القرارات إلى المكان الذي تكون فيه المعرفة والمعلومات متوفرة بشكلها الأمثل: أي إلى فرق agile ذات الوثوقية العالية والتنظيم الذاتي. توضح الرسوم المتحركة التالية كيف يؤدي خفض تكلفة المعاملة إلى تغيير الحجم الأمثل للدُفعة إلى اليسار. لا يمكنك التقليل من قيمة المؤسسة في اتخاذ قرارات أسرع بشكل متكرر. أين تكون DevOps أكثر ملائمة؟ إن الأتمتة هي إحدى الأشياء التي تشتهر بها DevOps. يوضح الرسم التوضيحي السابق قيمة الأتمتة بتفصيل كبير. نقلل من خلال الأتمتة تكاليف معاملاتنا إلى ما يقارب الصفر، ونحصل بشكل أساسي على الاختبارات والنشر مجانًا. يتيح لنا ذلك الاستفادة من أحجام دُفعات العمل الأصغر والأصغر. إن دُفعات العمل الأصغر يسهل فهمها والالتزام بها واختبارها ومراجعتها ومعرفة وقت إنجازها. كما تنطوي أحجام الدُفعات الأصغر هذه أيضًا على تباين وخطر أقل، مما يجعلها أسهل للنشر واستكشاف الأخطاء وإصلاحها واستردادها عند حدوث خطأ ما. يمكننا من خلال الأتمتة المدمجة مع أنشطة agile القوية أن نجعل تدفق تطوير ميزاتنا قريبًا جدًا من تدفق قطعة واحدة، مما يوفر قيمة سريعة للعملاء بشكل متواصل. تُفهم DevOps بشكل أكثر تقليدية كطريقة لهدم جدران الالتباس بين فرق التطوير dev والعمليات ops. تُطوّر فرق التطوير في هذا النموذج ميزات جديدة، بينما تحافظ فرق العمليات على استقرار النظام وتشغيله بسلاسة. يحدث الالتباس لأن الميزات الجديدة من التطوير تُحدث تغييرًا في النظام، مما يزيد من خطر توقف الخدمة والذي لا يشعر فريق العمليات بالمسؤولية عنه -لكن عليه التعامل معه على أي حال. لا تكتفي DevOps فقط بمحاولة جعل الناس يعملون معًا فحسب، بل أيضًا بمحاولة إجراء تغييرات أكثر تكرارًا في بيئة معقدة وبشكل آمن. يمكننا إلقاء نظرة على أبحاث Ron Westrum للبحث في موضوع تحقيق السلامة في المنظمات المعقدة. فقد وجد عند البحث عن سبب كون بعض المنظمات أكثر أمانًا من غيرها أن ثقافة المنظمة هي التي تنبئ بسلامتها. وحدّد ثلاثة أنواع من الثقافة: «المرضيّة أو غير المُتوقعة» (Pathological)، و«البيروقراطية» (Bureaucratic)، و«الابداعية» (Generative). فوجد أن الثقافة المرضيّة كانت تنبئ بسلامة أقل وأن الثقافة الإبداعية كانت تنبئ بمزيد من السلامة (على سبيل المثال، عدد أقل بكثير من حوادث الطيران أو وفيات المستشفى عن طريق الخطأ في مجالات بحثه الرئيسية). تُحقق فرق DevOps الفعالة ثقافة ابداعية باستخدام أنشطة lean و agile، مما يدل على أن السرعة والأمان متكاملان، أو وجهان لعملة واحدة. تحقق DevOps من خلال تقليل الأحجام المثالية لدُفعات القرارات والميزات لتصبح صغيرة جدًا تدفقًا أسرع للمعلومات وللقيمة في الوقت الذي تزيل فيه الهدر وتقلل المخاطر. وفقا لبحث Westrum، يمكن أن يحدث التغيير بسهولة عند تحسين السلامة والموثوقية في نفس الوقت. عندما يتم الوثوق بفريق agile و DevOps لاتخاذ قراراته الخاصة، سنمتلك حينها الأدوات والتقنيات التي تشتهر بها DevOps اليوم: التشغيل الآلي والتسليم المتواصل. تٌقلل من خلال هذه الأتمتة تكاليف المعاملات أكثر من السابق، ويتحقق تدفق هائل على مبدأ القطعة الواحدة مما يخلق إمكانات لآلاف القرارات والإصدارات في اليوم، كما يجري في مؤسسات DevOps عالية الأداء. التدفق وردود الأفعال (التغذية الراجعة) والتعلم لا تتوقف DevOps عند هذا الحد. لقد كنا نتحدث بشكل رئيسي عن تحقيق DevOps لتدفق ثوري، ولكن يتم زيادة تضخيم أنشطة lean و agile من خلال جهود مماثلة تحقق حلقات تغذية راجعة أسرع كما تحقق تعلمًا أسرع. يشرح المؤلفون في كتاب DevOps Handbook بالتفصيل كيف يُنجز DevOps وفوق تدفقه السريع القياس عن بُعد عبر كامل تدفق القيمة لديه للتغذية الراجعة السريعة والمتواصلة. ستستفيد علاوة على ذلك فرق DevOps عالية الأداء باستمرار من التعلم والتحسين المستمر في أسس مؤسساتها، وذلك من خلال الاستفادة من رشقات «كايزن» (kaizen) الرشيقة و«الأثر الرجعي» (retrospectives) لـسكروم، مما سيؤدي إلى تحقيق ثورة في التصنيع في مجال تطوير منتجات البرمجيات. ابدأ بتقييم DevOps تتمثل الخطوة الأولى في الاستفادة من DevOps، إما بعد دراسة طويلة أو بمساعدة مستشار ومدرب من DevOps، في إجراء تقييم عبر مجموعة من الأبعاد الموجودة دائما في فرق DevOps عالية الأداء. يجب أن يحدّد التقييم قواعد الفريق الضعيفة أو غير الموجودة التي تحتاج إلى تحسين. قيّم نتائج التقييم لإيجاد مكاسب سريعة – التركيز على مجالات ذات فرص عالية للنجاح والتي ستؤدي إلى تحسينات شديدة التأثير. المكاسب السريعة مهمة لاكتساب الزخم اللازم لمعالجة المجالات الأكثر تحديًّا. يجب أن تولد الفرق أفكارًا يمكن تجربتها بسرعة والبدء في تحريك البوصلة باتجاه DevOps. يجب على الفريق مع مرور بعض الوقت إعادة تقييم الأبعاد نفسها لقياس التحسينات وتحديد مجالات تركيز جديدة عالية التأثير مجدّدا بأفكار جديدة من الفريق. سنلقي النظر في الجزء الثاني من هذه المقالة على نتائج استبيان DevOps في مجتمع «دروبال» (Drupal) ونرى أين يمكننا إيجاد المكاسب السريعة. ترجمة وبتصرف للمقال: Why DevOps is the most important tech strategy today لصاحبه: Kelly Albrecht. اقرأ أيضًا المقال السابق: رحلة المطور عبر DevOps كامل مقالات السلسلة.

انتهت أيام فرق التطوير وفرق العمليات المنعزلة. ما علاقة المطوًر «بور سوتر» (Burr Sutter وكتابه، The Phoenix Project؟ كما أوضح سوتر في حديثه المقتضب الذي استمر لمدة خمس دقائق في مؤتمر All Things Open 2016، فإنهم يشتركون في شغفهم بالتقنيين العمليين – وهم المطورون الذين يصممون شيفرات رائعة والمشغلون الذين يقومون بتطوير البنية التحتية لتشغيلها. وتابع سوتير قائلًا أن أيام فِرق التطوير وفرق العمليات المنعزلة انتهت، وأن مستقبل البرامج أن يعمل الجميع معا لإنشاء أعمال ذات قيمة أفضل وبشكل أسرع. استشهادًا برواية جين كيم The Phoenix Project حول إطلاق مبادرة تكنولوجيا المعلومات على نطاق واسع باستخدام مبادئ الـ DevOps، فقد شارك سوتر "مشروع Phoenix" الخاص به. حيث أراد أحد العملاء نظامًا جديدًا غير مرئي ينقله من واجهة المستخدم ذات النمط القديم إلى الويب، مما يتيح الخدمة الذاتية للعملاء عبر الويب. أخبر سوتر المدير التنفيذي أنّه وبالنظر إلى نطاق المشروع والقيود الزمنية المفروضة فإن الفريق "لن يكون لديه وقت حتى للنوم." فكان رد رئيسه تقريبًا: «يمكنك النوم عندما تكون ميتًا». بدأ سوتر وفريقه العمل بتطوير مخطط تفصيلي يركز على النواتج الأسبوعية، مع البقاء على اتصال دائم مع العميل، وتقديم نسخ تجريبية أسبوعية، ثم الانتقال مباشرة إلى الإنتاج. لكن "أبواب الجحيم فتحت" بعد خطأ أتلف نقاط بيع العميل وتكاملات الطرف الثالث. قال سوتر: "لقد فهمنا سريعًا أن السبيل الوحيد للخروج من هذا المأزق هو في المتابعة والمضي قدمًا – كلنا معًا– المطورين، وموظفي العمليات، ومديري قواعد البيانات، وموظفينا- الفريق بأكمله". أوجد الفريق التصحيحات سريعًا خلال ليلةٍ واحدة، وتأكّد من أن كل مطوّر عرف كيف كانت تُستخدَم شيفرته، وقام بفحص منتظم مع فريق العمليات، وخصّص أيام السبت بأكملها لإصلاح الأخطاء. استغرق الأمر مع فريق التطوير يومي سبت فقط للبدء في كتابة شيفرة أفضل بكثير وأكثر استقرارًا، وكان مستعدًا للذهاب في صباح اليوم التالي عندما بدأ العمل على الإنترنت. أوصى سوتر في الختام بكتابين من أشهر كتب جين كيم هما: The Phoenix Project و The DevOps Handbook. ترجمة وبتصرف للمقال: A developer's journey through DevOps. اقرأ أيضًا المقال التالي: لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم المقال السابق: أفضل 5 لغات برمجة لـ DevOps كامل مقالات السلسلة.

نجمع هنا خمسًا من أفضل لغات البرمجة لـ DevOps وبعضًا من الموارد التعليمية المفيدة لكلٍ منها. ركزتُ على البنية التحتية لغالب حياتي المهنية، وقد تبدلت المهارات التقنية المحدّدة المطلوبة بمرور الزمن. سأضع في هذه المقالة، خمسًا من أفضل لغات البرمجة في مجال DevOps، والموارد التي كانت مفيدة للغاية بالنسبة لي، حيث كنت أُضيف هذه المهارات التطويرية إلى مجموعة أدوات البنية التحتية خاصتي. لا تُعد معرفة كيفية تجميع الخوادم وتكدسها مهارة في الطلب في هذه المرحلة. فمعظم مشاريع الأعمال لا تبني مراكز بيانات مادية لها. وبدلاً من ذلك، تُصمم وتبني مقدِرات الخدمة التي تُستضاف في البيئات السحابية العامة. تُهيئ البنية التحتية وتُنشر وتُدار من خلال التعليمات البرمجية. وهذا هو جوهر تصميم الـ DevOps - فعندما تتمكن المؤسسة من تحديد بنيتها التحتية في سطور من التعليمات البرمجية، يصبح عندها أتمتة معظم المهام (إن لم تكن جميعها) في مركز البيانات أمرًا ممكنًا. تتيح المستويات المتقدمة للأتمتة تمكين أنشطة «التركيب المتواصل / التسليم المتواصل» (Continuous Integration /Continuous Delivery CI/CD) التي لم تكن متاحة من قبل. تجعل مهام سير عمل CI / CD هذه من التسليم عملية سلسة خالية من الاحتكاك – حيث يستطيع المطور دفع شفرته إلى مستودع مصدري، وتتولى البنية التحتية تلقائيًا نشرها لدعم عمليات الاختبار التي يمكن أن تدفع تطبيق ما حتى مرحلة الإنتاج تلقائيا دون تدخل بشري. فعمل تقني يزحف تحت قبة أرضية مرتفعة لتوصيل كابلات الشبكة الجديدة لم يعد ضمن المسار الحرج لنشر تطبيق الإنتاج. تقوم فرق البنية التحتية الآن بتحويل قدراتها بعيدًا عن خوادم الأرفف والتكديس إلى دعم قنوات CI / CD، مما يعني شيفرة التعلم. تُنشر ملفات القوالب المضمنة في YAML والبرامج النصية لنشر البنية التحتية في بايثون والتطبيقات في جافا سكريبت من خلال القنوات المحددة في Groovy. تقترب شيفرة التطبيق نفسه من البنية التحتية. يمكن الآن لمطوري التطبيقات إنشاء «إجرائيات» (routines) في تطبيقاتهم لتوسيع نطاق ومعالجة حالات الفشل من خلال واجهات برمجة التطبيقات الخاصة بالبنية التحتية. وهذا هو السبب في أنني بدأت في استثمار فترة جيدة من وقتي في تعلم الشيفرة. قررت التركيز على تعلم لغات التطوير المشاركة في DevOps، واخترت خمسًا من أكثر اللغات أهمية وهي: Python و Ruby و Java Script و Go و C. أنا لست في هذه المرحلة مطورًا يعمل بدوام كامل بأي حال من الأحوال، كما أني لست متأكدًا حتى من أنه بإمكاني تسمية نفسي هاويا. لكني وصلت إلى ما هو أكثر من المعرفة الأساسية بفضل الموارد التي أقدمها في هذا المقال. بايثون Python أصبحت بايثون لغة متعددة الأغراض في البنية التحتية. وقد استُخدمت لبناء مشاريع البنية التحتية السحابية مثل OpenStack، وحتى لدعم تطبيقات الويب من خلال أطر عمل مثل Django. إن بايثون هي لغة سلسة لتلبية مجموعة واسعة من الاستخدامات. Codecademy: بدأت تعلم بايثون في موقع Codecademy. الذي يُقدِّم تمهيدًا رائعًا لبايثون. تدريب Safari Books عبر الإنترنت: انتقلتُ منه إلى المقدمة الممتازة لجيسيكا ماكلار في دورة Introduction to Python في مكتبة Safari Books Online. إن خدمة Safari مكلفة، ولكن غالبًا ما تكون هناك حسومات على مبيعات الأعضاء يمكن أن تمنحك خصمًا قد يصل إلى 50٪. تحتوي SafariBooks أيضًا على مقاطع فيديو لمؤتمرات O'Reilly، بما في ذلك المحادثات والمختبرات. حيث توفر المحادثات فرصة لإيجاد مواضيع هامّة في كل لغة. مقاطع الفيديو الخاصة بالمؤتمرات عبر الإنترنت: ابحث عبر الإنترنت وستجد محادثات مثيرة للاهتمام في مؤتمرات مطوّري برامج مختلفة حول كيفية استخدام اللغات بطرق ربما لم تفكر فيها من قبل. تتوفر على سبيل المثال على YouTube مقاطع فيديو مؤتمر PyCon. روبي Ruby تُستخدم روبي في عدد من مشاريع البنية التحتية. على سبيل المثال إن تطبيق ManageIQ، هو تطبيق Ruby on Rails. كثيرا ما كنت أمازح العملاء خلال وظيفتي في Red Hat، بأنه مع ManageIQ (و CloudForms)، يكون المستخدمون على بعد 10 سطور فقط من شيفرة Ruby للقيام بأي شيء. Codecademy: حصلت على معرفتي في روبي بشكل رئيسي من هذا الموقع، كما هو الحال مع بايثون. التوثيق الرسمي: إن المصدر الآخر الذي ساعدني على فهم روبي بشكل عملي أكثر (أي بالنسبة لوظيفتي) هو كتاب بيتر ماكووان Mastering CloudForms Automation (متوفر بتنسيق PDF مجاني). وساعد العمل مع state machines لـ CloudForms وأتمتة سير العمل المتقدمة في تشكيل فهمي للبنى داخل روبي. الحلقات الصوتية: استمعت أيضًا إلى Ruby on Rails Podcast، و Ruby Rogues. جافا سكريبت JavaScript تستمر منصة ومشاريع النظام البيئي لأطر جافا سكربت والمشاريع في النمو بوتيرة مذهلة. حيث تحتل حيزا ضخما من مساحة الاعمال على الإنترنت، سواء تلك المستخدمة من جانب العميل أو من أطر العمل المستخدمة من جانب الخادم. FreeCodeCamp: ما زلت أتعلم لغة جافا سكريبت، خاصة من خلال FreeCodeCamp. الذي يحتوي على برنامج مجاني ممتاز يوفر أمثلة في العالم الحقيقي ويدفع الطلاب إلى ما هو أبعد من تجربة كتابة الكلمات التقليدية. ستتلقى مع تقدمك في البرنامج، إرشادات أقل إلزاميةً وبدلاً من ذلك ستُكلف بمهام لإكمالها. كانت الدروس التي تعلمتها بشكل أكثر اكتمالا في رحلتي كانت من مبدأ "ابدأ من الجزء الأصعب". والذي لا أستطيع أن أوصي به بدرجة كافية. التوثيق الرسمي: إن التوثيق الرسمي هو مرجعي الأول لأي شيء غامض يواجهني أثناء رحلتي في تعلم جافاسكربت. الحلقات الصوتية: أستمع أيضًا إلى الملفات الصوتية التي تركز على جافا سكريبت، مثل JavaScript Jabber و FiveJS. Go طُرحت لغة Go في عام 2009، وحققت نجاحًا كبيرًا في السوق منذ طرحها. كان مصممو اللغة يركزون على عمل لغة مكتوبة ثابتة مقروءة، كما تقدم أيضًا أداءً جيدًا على نطاق واسع. golang.org: لقد بدأت مع Go، بدءًا من الجولة التعليمية الموجودة في golang.org. قناة Google Developers على YouTube: بدأت أيضًا بمشاهدة مقاطع الفيديو على قناة Google Developers channel، بما في ذلك Go for Pythonistas و Get Started with Go و Go Programming. تدريب Safari Books Online: ركزتُ بشكل أكبر على Go في عام 2017 لأنها تدعم عددًا من تقنيات الويب المهمة مثل Docker و Kubernetes وغيرها. يعد مسار التعلم في Safari Books Online مصدرًا رائعًا آخر، بما في ذلك Master Google's Go. السي C حاولت تعلم لغة C مرات عديدة. في كل مرة كنت أقترب فيها من C لم يكن لدي هدف معين في الحسبان. أردت فقط تعلم اللغة لأن الكثير من الشيفرات في العالم مكتوبة بلغة C، والعديد من« البنى» (constructs) في هذه اللغة يُعاد استخدامها في لغات أخرى. تعلمت سريعًا عند انضمامي إلى Red Hat، أن هناك مقولة موجودة في مجتمع «البرمجيات الحرة والمفتوحة المصدر» (FOSS) لفترة طويلة جدًا وهي: أفضل التوثيق هو الشيفرة نفسها. وأدركت أنني بحاجة إلى تعلم لغة C عند محاولتي فهم مشاريع مثل KVM و libvirt و QEMU، وذلك لفهم ما يحدث في المستوى التأسيسي. تعلم C بالطريقة الصعبة: لتعلم C تعلمت طريقة Learn C the Hard Way والتي أثبتت أنها طريقة مميَّزة للغة. أحب أسلوب كتابة المؤلف والنهج المعبر لتمارين كتابة الشيفرة. يمكنك قراءة الكتاب مجانًا عبر الإنترنت، أو شراء الكتاب للحصول على أمثلة التعليمات البرمجية وملفات الفيديوأيضًا. يُركز عملي الحالي على التحدث مع العملاء حول الحلول السحابية، لكنني استثمرت في مجتمع تكنولوجيا المعلومات لفترة طويلة وأشعر بأنني مضطر لتقديم رد. أحد الأشياء التي ركزت عليها في عام 2017 هو المساعدة في تثقيف موظفي تقنية المعلومات الحاليين حول الاتجاهات السائدة في سوق العمل، وكيفية المشاركة في عالم تكنولوجيا المعلومات الجديد الذي بدأ التركيز عليه. آمل أن تكون قادرًا على أخذ بعض الموارد المتوفرة في هذه المقالة وتحويل البند في سيرتك الذاتية الذي يقول "بناء الخوادم" إلى "بناء الشيفرة". ما هي لغات البرمجة التي تركز على تعلمها الآن؟ أخبرنا عن الموارد التي كانت أكثر فائدة لك في رحلتك البرمجية الخاصة. ترجمة وبتصرف للمقال: Top 5 programming languages for DevOps لصاحبه:Chris Saunders. اقرأ أيضًا المقال التالي: رحلة المطور عبر DevOps المقال السابق: ثلاث خطوات لتأمين DevOps مفتوح المصدر كامل مقالات السلسلة.

إنّ المفتاح الرئيسي لتأمين تطوير تطبيق ما هو "الإزاحة نحو اليسار" - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير. حقيقةً، لم يعد أحد الآن يكتب شيفرته الخاصّة، أليس كذلك؟ نذهب إلى GitHub (أحد مواقع خدمات استضافة مستودعات المشاريع مفتوحة المصدر يوفر طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها)، وننزل بعضًا من المكتبات، ونتجنب إعادة اختراع العجلات غير الضرورية، نجمع هذه العجلات بالشكل الذي يناسبنا لإنشاء برامج جديدة. ثم نُنزّل بعضًا من الأطر الأمامية لجعلها تبدو جميلةً وسريعة الاستجابة ونحن خارج السياق. وجدت خلال مراجعتي للتطبيقات، سواء تلك الموجودة في شركتي أو في شركات أخرى، أن أكثر من 90٪ من الشيفرة التي تشكل تطبيقًا هذه الأيام هي عبارة عن أشياء استعرناها، ولم نكتبها بأنفسنا. يفحص معظمنا شيفرته بحثًا عن العيوب مستخدمًا «أدوات التحليل الثابتة» (static analysis tools)، لكن ماذا عن كل المواضيع التي لم نكتبها بأنفسنا؟ كيف يمكننا معرفة ما في داخلها بالفعل؟ وبمجرد معرفتنا لذلك، ما هي الإجراءات التي نتخذها إما لتنظيفها أو لإبقائها محدّثة؟ كيف يمكننا تجنب التعرض للاختراق لأننا ندع شيئا مفتوحًا يعمل في الخلفية باستخدامنا لتلك المكتبة القوية المزدحمة التي تفعل ذاك الشيء الجميل الذي لا يمكننا الاستغناء عنه؟ الطريقة القديمة أُبرمج منذ 20 عامًا تقريبًا، وهي فترة طويلة وكافية لرؤية التطور بدءًا من النماذج التقليدية لتخطيط البرامج كالنماذج الشلالية أو الحلزونية إلى نماذج «البرمجة الفائقة» (Xtreme Programing)، والنماذج المرنة Agile و تطوير العمليات DevOps الآن. في الماضي كانت دورات التطوير الطويلة والافتقار إلى أي تدريب حقيقي وعدم جدوى الأدوات في تحديد العيوب الأمنية حيث تجري تقييمات الأمان بشكل أساسي في المراحل اللاحقة من دورة حياة تطوير البرمجيات وأكثرها يتم على شكل أنشطة يدوية. وعادةً ما يكون الدافع وراء بدء المراجعة يتعلق بتدقيق أو بعميل يطلب تأكيد بياناته في أنظمتك (والتي قليلًا ما تحدث). بالنظر إلى هذا النهج قليل التكرار والمتعلق بالتقييم الأمني، فإنّه غالبًا ما تُخفّض أولوية العيوب القائمة على الأمان والاختبارات للعثور عليها. ركّزت مجموعات أمن المعلومات على "النتائج"، وعلى تشغيل أدوات لإنتاج التقارير عند الطلب لطمئنة المدققين بأن الأمور تجري على ما يرام. أعطيت الميزات والفاعلية الوظيفية الأولوية على حل الخلل الذي لن يراه المستخدمون العاديون أبدًا، ولن يُطلعهم أحد عليه، أليس كذلك؟ أضف إلى هذا السيناريو حقيقة أنه حتى مع إضافة عمال تقنيين جُدد إلى السوق يوميًا، فإن القليل منهم مُدّرب على أنشطة كتابة الشيفرة الدفاعية، ويمكنك أن ترى كيف يمكن أن ينتهي بنا الأمر إلى حدوث مشكلة. إن الخبر الجيد هنا هو أنه الآن يوجد استراتيجيات حقيقية لإيضاح المشكلة وطرق حلها. الطريقة الجديدة عالم اليوم هو عالم الأتمتة و«التكرار المتواصل» (continuous iteration). نسمي هذه العملية بـ "DevOps" لأنها تمزج تطوير البرمجيات وتعريف وأتمتة البنية التحتية لإنشاء نماذج للنشر والعمليات التي تُمكّن ذاتيًا. عندما نضيف أمانًا إلى ذلك، فإننا نطبق نفس التوقعات بأن نؤتمت كل شيء تلقائيًا ونعرّف «الأنماط» (patterns) والعمليات بحيث يمكن تكرارها باستمرار. وبهذا يكون انتهى بنا الأمر إلى ما أحب أن أسميه "DevSecOps". (DevSecOps هي اختصار لمصطلح التطوير والأمن والعمليات. هدفها هو جعل كل شخص مسؤولاً عن الأمان بهدف تنفيذ القرارات والإجراءات الأمنية بنفس المستوى والسرعة كما في قرارات وإجراءات التطوير والعمليات.) إن المفتاح الرئيسي في هذا النهج الجديد هو "الإزاحة نحو اليسار"، ونقل اختبار الأمان وجهود تركيب المصدر المفتوح بعيدًا عن مرحلة الإنتاج المتأخرة والعودة نحو التصميم والتطوير. كما هو الحال في DevOps، التي تُمكّن المطورين من تعريف« بُنى» (architecture) معتمدة على البرمجيات وإصدارها ونشرها باستخدام الأتمتة، تمنح DevSecOps المطورين نفس الأدوات والتقنيات والعمليات للقيام بالشيء نفسه من أجل أمان البرنامج. الخطوة 1: البدء في التصميم إنّ الطريقة الأكبر التي تخرج بها التطبيقات مفتوحة المصدر عن مسارها بسرعة، تتمثل في عدم التفكير في بنيّة التطبيق قبل البدء بكتابة الشيفرة. هل ما زلت تستخدم نسخة "Struts" عمرها سنتين لتطبيقك الجديد فقط لمجرد أنّها مثبّتة على جهازك المحلي مسبقًا، متبقيةً من مشاريعك العشرة السابقة التي أنجزتها؟ تأكّد في كل مرّة تبدأ فيها مشروعًا جديدًا بأنّك تستخدم الإصدار الأحدث والأكثر موثوقية من إطار العمل الذي تعتمده. استخدم أدوات مجانيّة أو أدوات غير مكلفة مثل SourceClear لتحديد «فاتورة المواد» (Bill Of Materials- BOM) في تطبيقك وكن متأكدًا من أنها تفي بالمطلوب قبل بدء العمل. سيوفر عليك لك المتاعب لاحقًا. الخطوة 2: أتمتة كل شيء بالنسبة لي كمطور، إنه من أكثر الأمور إزعاجًا قدوم شخص ما إلى عندما أكون مشغولًا بشيء آخر يتوجب على إنجازه في يومي المثقل بالأعمال. فإذا كنت تتوقع من المطورين استخدام أداة أو البحث في موقع ويب أو طلب إذن من شخص ما في كل مرّة يقومون فيها بالنشر، فسيجدون حتمًا طريقةً لتجنب ذلك. من ناحية أخرى، إذا كنت تستطيع أتمتة عملية تشغيل شيء ما، أو التحقق من قائمة معينة، أو إخطار مجموعة ما، عندها سيواصل المطورين التركيز على ما يجلب للشركة أموالًا أو ما يضيف قيمةً للعميل. يود InfoSec أن يقول: "الأمان هو مهمة الجميع" ولكن غالبًا ما ينسى أن القيمة المضافة تأتي في المرتبة الأولى. إذا لم نتمكن من إضافة قيمة لعملائنا أو المساهمين معنا، فلن يكون هناك أي شيء لحمايته وتأمينه. (InfoSec هي مجموعة من العمليات التي تحافظ على سرية وسلامة وتوافر بيانات الأعمال بأشكالها المختلفة.) تتمثل الفكرة الرئيسية هنا بالقيام بذلك خارج النطاق وجعله شفافًا. يجب أن يكون غير متزامن وغير مرئي أو سيصبح نقطة عناء وإجهاد لشخص ما. الخطوة 3: تطوير "مواطنين جيدين" وليس "بنى جيدة" أخيرًا، لكي يتحقق DevSecOps بالفعل، علينا العمل على تغيير طريقة التفكير حول سياسة أمن المعلومات InfoSec وعمليات النشر المتعلقة بذلك. كانت تبدو معظم نماذج النشر التي تتضمن الأمان في الماضي كالتالي: تصميم -> كتابة شيفرة -> اختبار التكامل -> ضمان الجودة QA -> مراجعة InfoSec -> الإنتاج. ( QA: هي اختصار للكلمتين Quality Assurance) ولكن عندما تكون دورات DevOps مُحتملة خلال ساعات أو حتى دقائق، فكيف يمكنك مراجعة InfoSec قبل مرحلة الإنتاج؟ الجواب: ليس أنت من يفعل ذلك. واسمحوا لي أن أصيغ السؤال على هذا النحو: إذا كان المطورون يحصلون على معلومات جيدة في وقت مبكر لأنك عملت على أتمتة تحليل الشفرة الثابتة، ووفرتَ طريقة تلقائية لإنشاء فاتورة المواد BOM لأطر عمل المصادر المفتوحة لديك، وقدّمت ذلك مبكرًا في دورة حياة تطوير البرمجيات منذ مرحلة التطوير أو حتى التصميم، فما الذي تختبره بالضبط في هذه البنية؟ أنت ببساطة تسأل عما إذا كانوا قد اتخذوا الإجراءات التي يعرفونها أصلًا. اسأل نفسك الآن السؤال التالي، "هل تثق بهم؟" لاحظ، إذا كنت تقدم المعلومات في وقت مبكر بما فيه الكفاية، فبإمكانك إزالة "مراجعة InfoSec" بالفعل عندما يحين وقت النشر. ماذا؟ وهذا صحيح. يمكن ببساطة في هذه المرحلة أن تسأل عملية التحكم في التغيير الخاصة بك الأسئلة التالية: "هل أُكمِلت مراجعات الأمان التلقائية لهذا التطبيق في كل مرحلة من المراحل؟" "هل حلّ المطورون العيوب الحرجة كما هو متوقع على أسس ثابتة؟" "هل كان آخر تقييم مكتمل يصل إلى مستوى توقعاتنا (سياستنا)؟" إذا كان بإمكانك الإجابة بنعم على هذه الأسئلة، فإن ما عليك فعله هو الوثوق في أن فريق التطوير يعمل بشكل نموذجي (مواطنين جيدين)، والحرص على إنتاج نوعية جيدة، والتصرف بطريقة مسؤولة. سيبدو نموذجنا الجديد مشابها لهذا: تصميم مستنير -> مراجعة الشيفرة الآلية -> ضمان الجودة -> IT -> مواطن جيد؟ -> النشر. ترجمة وبتصرف للمقال: 3 steps to secure, open source DevOps لصاحبه: Jet Anderson. اقرأ أيضًا المقال التالي: أفضل 5 لغات برمجة لـ DevOps المقال السابق: ما هي الغاية من DevOps؟ كامل مقالات السلسلة.

يساعدك التغيير الحقيقي في الثقافة التنظيمية على ردم الفجوات التي اعتقدت أنه ليس بالإمكان تجاوزها. فكّر في آخر مرّة حاولت فيها تغيير عادةٍ شخصية. من المحتمل أن تصل إلى نقطة تحتاج فيها إلى تغيير طريقة تفكيرك وجعل هذه العادة أقل جزء من هويتك. هذا صعب — مع أنك تحاول فقط تغيير طرق تفكيرك الخاصة. لذلك، ربما حاولت وضع نفسك في مواقف جديدة. حيث يمكن أن تساعدنا المواقف الجديدة فعليًا في خلق عادات جديدة، والتي بدورها تؤدي إلى طرق جديدة للتفكير. هذا ما يتعلق بالتغيير الناجح: إنه يتعلق بالتوقعات بقدر ما يتعلق بالنتائج. عليك أن تعرف سبب تغييرك وأين تتجه (وليس فقط كيف ستفعل ذلك)، لأن التغيير فقط من أجل التغيير غالبًا ما يكون محدود الأجل وقصير النظر. فكّر الآن في التغييرات التي تحتاجها مؤسسة تعمل في مجال تكنولوجيا المعلومات. ربما فكّرتَ في اعتماد شيء مثل DevOps. يحتوي هذا الشيء الذي نسميه "DevOps" على ثلاثة مكونات: الأشخاص والعملية والأدوات. يمثل الناس والعملية الأساس لأي منظمة. لذلك، يتطلب اعتماد DevOps إجراء تغييرات أساسية في جوهر معظم المنظمات، وليس فقط تعلم أدوات جديدة. ويمكن أن يكون التغيير قصير النظر، كما هو الحال في أي تغيير، إذا كنت تركز على التغيير كحل لنقطة محددة على سبيل المثال - "الحصول على أداة أفضل لعمل تنبيه"، - فمن المحتمل أن تتوصل إلى رؤية محدودة للمشكلة. قد توفر طريقة التفكير هذه أداة تحتوي على مزيد من الأجراس والصفارات وطريقة أفضل للتعامل مع الإدارة عند الطلب. لكن لا يمكنها معالجة حقيقة أن التنبيهات لا تصل إلى الفريق المطلوب، أو أن تلك الإخفاقات لا تزال موجودةً لأن أحدًا لا يعرف كيفية إصلاح الخدمة. تخلق الأداة الجديدة (أو على الأقل فكرة الأداة الجديدة) فرصة لإجراء مناقشة حول المشاكل الأساسية التي شوهت نظرة فريقك في المراقبة. حيث تتيح لك الأداة الجديدة إجراء تغييرات أكبر - تغييرات على معتقداتك وممارساتك - والتي تُعدُّ أكثر أهمية كأساس لمؤسستك. يتطلب إحداث تغيير أعمق أساليب جديدة لمفهوم التغيير المُشترَك. ونحتاج أولًا إلى فهم محرك التغيير بشكل أفضل لاكتشاف هذه الأساليب. إزالة الحواجز لفهم الحاجة إلى DevOps، التي تحاول إعادة تجميع كيانات "الانقسام" التقليدية "للتطوير" و "العمليات"، يجب علينا أولاً أن نفهم كيف حدث الانقسام. بمجرد "معرفة استخدامه"، يمكننا أن نرى الانقسام على حقيقته- ونزيله إذا لزم الأمر. يوجد اليوم أكثر من نظرية للإدارة، ولكن يمكننا تتبع أصول معظم نظريات الإدارة الحديثة لفريدريك وينسلو تايلور. كان تايلور مهندسًا ميكانيكيًا أنشأ نظامًا لقياس كفاءة العمال في مصنع للفولاذ. اعتقد تايلور أنه بالإمكان تطبيق التحليل العلمي على العمال في المصنع، ليس فقط لتحسين المهام الفردية، ولكن أيضًا لإثبات أن هناك طريقة أفضل يمكن اكتشافها لأداء أي مهمة. يمكننا بسهولة رسم شجرة تاريخية اعتمادًا على وضع تايلور في الجذر. ظهرت من جهود تايلور المبكرة في أواخر الثمانينات من القرن الماضي برامج دراسة الحركة الزمنية وغيرها من برامج تحسين الجودة التي امتدت في عشرينيات القرن العشرين حتى يومنا هذا، حيث نرى منهجيات معايير سيجما الستة (Six Sigma) والتصنيع الرشيق (Lean) وما شابه. وتُهيمن على ثقافة الأعمال السائدة اليوم منهجيات: من من الأعلى إلى الأسفل (Top-down)، والإدارة موجَّهة النمط (directive-style management)، والمقترنة بالنهج النظامية لدراسة العملية. إنها تركز في المقام الأول على الفاعلية كمقياس رئيسي لنجاح العمال. إذا كان تايلور هو الأصل لشجرتنا التاريخية، فإن فرعنا الرئيسي التالي في الصندوق سيكون الفريد سلون (Alfred P. Sloan) من جنرال موتورز في العشرينات من القرن الفائت. إن هيكلية Sloan التي أُنشئت في جنرال موتورز، لن تظل قويةً فقط حتى عام الـ 2000، بل أنها أيضًا ستكون النموذج الرئيسي للشركة على مدار الخمسين عامًا القادمة. كانت جنرال موتورز في عام 1920 تعاني من أزمة في الإدارة -أو بالأحرى أزمة بسبب نقص الإدارة. كتب سلون كتابه «"الدراسة التأسيسية"» (Organizational Study) لمجلس الإدارة، مقترحًا هيكلًا جديدًا لعدد وافر من أقسام جينرال موتورز. يركّز هذا الهيكل الجديد على مفهوم "العمليات اللامركزية مع التحكم المركزي". ستعمل الآن الأقسام الفردية، المرتبطة بعلامات تجارية مثل شيفروليه وكاديلاك وبويك بشكل مستقل في حين توفر الإدارة المركزية الوسائل اللازمة لتوجيه الاستراتيجية والتحكم المالي. صعدت جنرال موتورز نتيجة توصيات سلون (وتوجيهات لاحقة كمدير تنفيذي) إلى مركز رائد في صناعة السيارات الأمريكية. حيث خلقت خطة سلون شركة ناجحة للغاية من واحدة على شفا كارثة. من وجهة النظر المركزية، فالوحدات المستقلة عبارة عن صناديق سوداء. يتم تعيين الحوافز والأهداف في المستويات العليا، والفرق في المستوى الأسفل من أجل التنفيذ. لا تزال فكرة تايلور حول "أفضل الممارسات" - السلوكيات القياسية التبادلية والتكرارية - تحتل مكانًا في مُثُل الإدارة الحالية، حيث تقترن بالنموذج الهرمي للهيكل المؤسسي لسلون، الذي يدعو إلى انقسامات صلبة للإدارة وصوامع من أجل السيطرة القصوى. يمكننا الإشارة إلى العديد من الدراسات الإدارية التي تثبت ذلك. لكن ثقافة الأعمال لا تُنشَأ وتُنشَر فقط من خلال قراءة الكتب. الثقافة التنظيمية هي نتاج أناس حقيقيين في مواقف فعلية يقومون بسلوكيات ملموسة تدفع المعايير الثقافية عبر الزمن. هذه هي الطريقة التي تتعزز بها أشياء مثل نظريات Taylorism و Sloanianism وتصبح ثابتة. إن تمويل قطاع التكنولوجيا هو مثال على ذلك. إليك طريقة عمل الحلقة: يستثمر المستثمرون فقط في الشركات التي يعتقدون أنها يمكن أن تحقق رؤيتهم الخاصة للنجاح. لا ينشأ هذا النموذج للنجاح بالضرورة من الشركة نفسها (وأهدافها الخاصة)، إنه يأتي من أفكار مجلس الإدارة حول الصيغة التي يجب أن تبدو عليها الشركة الناجحة. يأتي العديد من المستثمرين من الشركات التي نجت من اختبارات ومتاعب إدارة الأعمال، ونتيجة لذلك لديهم مخططات مختلفة لما يمكنه جعل الشركة ناجحة. إنهم يمولون الشركات التي يمكن تعليمها لتقليد نماذجهم للنجاح. لذا فإن الشركات التي ترغب في الحصول على تمويل تتعلم محاكاتهم. وبهذه الطريقة، فإن حاضنة بدء التشغيل هي وسيلة مباشرة لاستنساخ بنية وثقافة يفترض أنهما مثاليتان. انقسام "Dev" و "Ops" ليس نتيجة الشخصية أو المهارات المتباينة أو القبعة السحرية الموضوعة على رؤوس الموظفين الجدد، إنها نتيجة ثانوية للنظريات للتيلورية والسلانية. وإن الحدود الواضحة والفاصلة بين المسؤوليات والأشخاص هي وظيفة إدارية مقرونة بالتركيز على كفاءة العمال. كان بالإمكان تقسيم الإدارة بسهولة إلى حدود المنتج أو المشروع بدلاً من المهارات، ولكن يخبرنا تاريخ نظرية إدارة الأعمال حتى اليوم أن التجميع القائم على المهارات هو الطريقة "الأفضل" لتحقيق الكفاءة. لسوء الحظ، تخلق تلك الحدود توترات، وهذه التوترات هي نتيجة مباشرة للأهداف المتعارضة التي حددتها حلقات إدارة مختلفة ذات أهداف مختلفة. فمثلًا: الرشاقة ⟷ الاستقرار استقطاب مستخدمين جدد ⟷ خبرة المستخدمين الحاليين الحصول على ميزات التطبيق ⟷ تطبيق متاح للاستخدام النجاح في المنافسة ⟷ حماية الإيرادات إصلاح المشكلات التي تظهر ⟷ منع المشكلات قبل حدوثها يمكننا أن نرى اليوم اعترافًا متزايدًا بين كبار قادة المنظمات بأن ثقافة الأعمال الحالية (وبالتالي مجموعة التوترات التي تنتجها) تمثل مشكلة خطيرة. في تقرير Gartner لعام 2016، قال 57 بالمائة من المشاركين أن التغيير الثقافي كان أحد التحديات الرئيسية التي ستواجه الشركة حتى عام 2020. إن ظهور أساليب جديدة مثل المنهجية المرنة و DevOps كوسيلة للتأثير على التغييرات التنظيمية يعكس هذا الاعتراف. الارتفاع في «"تكنولوجيا معلومات الظل"» (shadow IT) هو الوجه الآخر للعملة. حيث تربط التقديرات الحديثة ما يقرب من 30 في المئة من إنفاق تكنولوجيا المعلومات خارج سيطرة منظمة تكنولوجيا المعلومات. هذه ليست سوى بعضًا من "الاهتمامات الثقافية" التي تواجهها الشركات. فالحاجة إلى التغيير واضحة، لكن الطريق إلى الأمام لا يزال محكومًا بقرارات الماضي. المقاومة ليست عديمة الجدوى عادةً ما يكون التغيير استجابة تنظيمية لخطأ ما. وبهذا المعنى، إذا كان التوتر (حتى الشدائد) هو المحفز الطبيعي للتغيير، فإن مقاومة التغيير هي مؤشر للنجاح. لكن التركيز المفرط على المسارات الناجحة يمكن أن يجعل المنظمات غير مرنة، وبليدة، وجامدة. إن تقييم سياسة التوجيه من خلال النتائج الفعّالة هو أحد أعراض هذه الصلابة المتزايدة. أدى النجاح في أقسام تقنية المعلومات التقليدية إلى زيادة سماكة جدران تقنية المعلومات. الأقسام الأخرى هي الآن "عملاء"، وليست زملاء عمل. تنشئ محاولات إزاحة تكنولوجيا المعلومات بعيدًا عن كونها مركزًا للتكلفة نموذجَ تشغيلٍ جديد يفصل تكنولوجيا المعلومات عن باقي أهداف العمل. وهذا بدوره يخلق المقاومة التي تحدّ من خفة الحركة أو الرشاقة، ويزيد من الاحتكاك، ويقلل من الاستجابة. التعاون يحصل على الرف لصالح "توجيه الخبراء". والنتيجة هي أن النظرة الانعزالية لتكنولوجيا المعلومات لا يمكن إلا أن تضر أكثر مما تنفع. وبما أن "البرمجيات تجتاح العالم"، يصبح تكنولوجيا المعلومات أكثر وأكثر أهمية للنجاح العام للمنظمة. تدرك مؤسسات تكنولوجيا المعلومات ذات التفكير المتقدم هذا وتقوم بالفعل بإجراء تغييرات متعمدة على قواعد العمل، بدلاً من التعامل مع التغيير على أنه شيء تخافه. على سبيل المثال، تشاور موقع Facebook مع عالم الأنثروبولوجيا «روبن دنبار» (Robin Dunbar) حول أسلوب تعامله المجموعات الاجتماعية، ولكنه أدرك مع نمو الشركة تأثير ذلك على المجموعات الداخلية (وليس فقط المستخدمين الخارجيين للموقع). نالت ثقافة زابوس الكثير من الثناء لدرجة أن المنظمة أنشأت قسمًا يركّز على تدريب الآخرين على وجهات نظرهم حول القيم الأساسية وثقافة الشركات. وبالطبع يعد هذا الكتاب مرافقًا لـكتاب The Open Organization، وهو كتاب يوضح كيف يمكن للمبادئ المفتوحة المطبقة على الإدارة - كالشفافية والمشاركة والمجتمع - إعادة إنشاء المنظمة بما يناسب عصرنا المترابط سريع الخطى. حل للتغيير أخبرني أحد الزملاء ذات مرّة أنّه بإمكانه شرح DevOps لمدير المشروع باستخدام مفردات إطار عمل مكتبة البنية التحتية لتكنولوجيا المعلومات فقط. في حين أن هذه الأطر تبدو متعارضة، فإنها في الواقع تركز على إدارة التغيير والمخاطر. أنها ببساطة تقدّم عمليات وأدوات مختلفة لمثل هذا النوع من الإدارة. من المهم ملاحظة هذه النقطة عند التحدث عن DevOps خارج إطار تقنية المعلومات. فبدلاً من التركيز على أعطال العملية وإخفاقاتها، أظهر كيف أن التغييرات الأصغر تقدّم مخاطر أقل وما شابه ذلك. وهذه طريقة قوية لتسليط الضوء على الفوائد التي تغير ثقافة الفريق: إن التركيز على القدرات الجديدة بدلاً من المشاكل القديمة هو عامل فعال للتغيير، خاصة عند تتبنى إطار مرجعي لشخص آخر. لا يتعلق التغيير فقط بإعادة بناء المنظمة؛ إنه يتعلق أيضًا بطرق جديدة لردم الفجوات التي لا يمكن تجاوزها تاريخيًا - حل لتلك التوترات التي حدّدتها سابقًا برفض وضع أشياء مثل "الرشاقة" و "الاستقرار" كقوى متبادلة. إن إنشاء فرق متداخلة تركز على النتائج أكثر من الوظائف يمثل أحد الاستراتيجيات في العمل. ويعد الجمع بين فرق مختلفة يعتمد كل منها على الآخر حول مشروع أو هدف واحد من أكثر الطرق شيوعًا. تسفر إزالة الاحتكاك بين هذه الفرق وتحسين الاتصالات عن تحسينات هائلة - حتى أثناء التمسك بهياكل الإدارة في صومعة الحديد (لا يلزم هدم الصوامع إذا أمكن إتقانها). حيث لا تعد مقاومة التغيير في هذه الحالات مؤشرًا على النجاح. احتضان التغيير هو المؤشر. إن هذه ليست "أفضل الممارسات". هي ببساطة طريقة لفحص الحدود الخاصة بك. كل منظمة لديها حدود فريدة من نوعها أنشأها الأشخاص داخلها. وبمجرد "معرفة استخدامها"، يمكنك أن تقرّر ما إذا كانت تحتاج إلى إزالة أو إلى تخصيص. ترجمة وبتصرف للمقال: What's the point of DevOps لصاحبه: Matt Micene. اقرأ أيضًا المقال التالي: ثلاث خطوات لتأمين DevOps مفتوح المصدر المقال السابق: ما المقصود بـ DevOps؟ كامل مقالات السلسلة.

تُستخدَم كلمة DevOps (اختصارٌ للكلمتين Development و Operations) لوصف مجموعةٍ من أنشطة التكنولوجيا الحديثة التي تسعى إلى تقريب مطوري البرمجيات وموظفي العمليات من بعضهم بعضًا بشكلٍ أوثق بغية العمل بصورة أكثر تعاونية على نفس المشروع. الهدف من ذلك هو خلال كسر الحواجز التقليدية الموجودة بين هذين الفريقين التقنيين، مما يمكِّن المؤسسات من تقليل الوقت وزيادة الانخراط في تقديم ونشر إصدارات جديدة من البرمجيات. سيؤدي هذا الجهد بديهيًا إلى دورات تطوير أقصر مما قد يوفر الوقت والمال بشكل مثالي، ويمنح المؤسسة ميزة تنافسية تُنافِس بها المؤسسات الأخرى التي تعتمد دورات التطوير الطويلة والأكثر تقليديةً. لماذا ينبغي اتباع استراتيجية DevOps؟ لم تعد عملية الابتكار السريع موضوعًا اختياريًا. فبغض النظر عن مجال عمل مؤسستك، أصبح من شبه المؤكّد أنّه مجال يشهد تقلبات في الأنشطة التجارية التقليدية نتيجة الانتقال إلى الاقتصاد القائم على البرمجيات. فبدءًا من النقل إلى التصنيع، ومن التعدين إلى الزراعة، ومن التمويل إلى الرعاية الصحية، تجعل البيانات الضخمة، والحوسبة السحابية، والتطبيقات المحمولة، وعدد كبير من التقنيات الأخرى من البرمجيات هي ما يشكل الفارق الرئيسي بين الأعمال والمؤسسات التي تتقدم إلى الأمام وتلك التي تتراجع وتتخلف عن الركب. حتى وإن لم تكن مؤسستك تنافس في سوق البرمجيات قبل عقد من الزمن، فهي اليوم كذلك، والطريقة للمضي قدمًا هي في استخدام حلول أفضل للتقدم بشكل أسرع. كيف أبدأ؟ تتمثل الخطوات الأولى في مجال DevOps في فحص ثقافتك وممارساتك، وتحديد العوائق التي تحول دون التواصل والتنسيق بين الفريق، واتخاذ الخطوات اللازمة لتوطيد التواصل بين فِرق التطوير والعمليات لديك. إن تحقيق ذلك يمثل تحدّيًا لا يمكنك بلوغه بين عشية وضحاها. ابدأ بإلقاء نظرة على منهجياتك الحالية ثم قم بتنقيحها وتقويمها. على الرغم من أنّ DevOps يتمحور بشكل رئيسي حول الثقافة التنظيمية، فإنّ تحديد أدوات البرامج الصحيحة والمناسبة يعدّ خطوةً مهمةً أيضًا. فهل تستخدم مؤسستك أدوات للتحكم بالإصدار والمراجعة مثل Git لمساعدتك في إدارة الشيفرة البرمجية؟ هل تعتمد أدوات البناء و «التركيب المتواصل» (continuous integration) لجعل التحرك من المصدر وحتى الاختبار سلسًا قدر الإمكان؟ وماذا عن الأدوات المستخدمة لأتمتة الاختبار وتحزيم البرامج تلقائيًا، أو لاختبارات النشر والحماية؟ هل تبحث عن طرق لإدارة البنية الأساسيّة الخاصّة بك مثل الشيفرة البرمجية باستخدام «أدوات إدارة التكوين» (configuration management tools)، لتوسيع نطاق البيئات وتكرارها بسهولة؟ وماذا عن أدوات المراقبة لمتابعة كامل العملية بدءًا من التطوير وحتى الإنتاج؟ تستفيد DevOps من إيجاد الأدوات المناسبة للحفاظ على عمل فِرق التطوير والعمليات الخاصة بك معًا وتحركها بشكل أسرع إذا كنت بحاجةٍ إلى دليل لحماية تقنية «حاويات لينكس» (Linux container)، ألق نظرة على قائمة التحقق المرجعيّة هذه: 4 خطوات لبدء رحلتك مع الحاويات. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن أين يمكنني تعلم المزيد؟ سننشر عددًا من المقالات تشرح ماهية DevOps وتُعرِّفك عليها؛ راجع الوسم «تعرف على DevOps» أو بعضًا من المقالات الأكثر شيوعًا أدناه. ما الهدف من DevOps؟: توضح نظرة موجزة لتاريخ DevOps الحاجة إلى التفكير بطريقة مختلفة حول العمل التعاوني في مجال تكنولوجيا المعلومات. 3 خطوات لحماية DevOps مفتوحة المصدر: المفتاح الرئيسي لتأمين تطوير التطبيق هو «الإزاحة نحو اليسار» (shift left) - انقل اختبار الأمان بعيدًا عن مرحلة الإنتاج المتأخرة وعُد إلى التصميم والتطوير. أفضل 5 لغات برمجة لـ DevOps: نجمع هنا خمسًا من أفضل لغات البرمجة لـ DevOps وبعضًا من الموارد التعليمية المفيدة لكل منها. رحلة المطور عبر DevOps: انتهت أيام التطوير المنعزلة لفرق التشغيل والعمليات. لماذا تعد DevOps الاستراتيجية التقنية الأكثر أهمية اليوم: إزالة بعض الالتباس حول مفهوم DevOps. تقنيات DevOps المحميّة «للخدمات المصغرة» (microservices): أحدثت الحاويات والخدمات المصغّرة ثورةً في تطوير التطبيقات وإدارة البنية التحتية. ربما يمكنك أيضًا إيجاد الفائدة في هذه الموارد الخارجية التي توفّر المزيد من المعلومات. التحديث بسرعة تطبيقات المصدر المفتوح باستخدام DevOps 9 عبارات مفتاحية لـ DevOps تحديث أسرع اعتمادا على DevOps كتاب إلكتروني مجاني: كتاب إلكتروني مجاني: DevOps with OpenShi. ترجمة وبتصرف للمقال: What is DevOps اقرأ أيضًا المقال التالي: ما الهدف من DevOps؟

مقدّمة يُعتبر Apache و Nginx اثنين من أشهر خوادم الويب مفتوحة المصدر ويُستخدمان غالباً مع PHP. قد يكون من المفيد تشغيل كل منهما على نفس الجهاز الإفتراضي virtual machine عند استضافة مواقع ويب متعددة ذات متطلباتٍ متنوعة. إنّ الحل العام لتشغيل خوادم الويب على نظام واحد هو استخدام عناوين IP متعددة أو أرقام منافذ مختلفة. بالإمكان ضبط الخوادم التي تملك كلّا من عناوين IPv4 و IPv6 لخدمة مواقع Apache على أحد البروتوكولين ومواقع Nginx على البروتوكول الآخر، ولكن عمليًا هذا غير مُطبّق حاليًا، نظرًا لأن تبنّي مزودي خدمات الإنترنت لـ IPv6 لا يزال غير شائع. حيث يعدّ وجود رقم منفذ مختلف مثل 81 أو 8080 لخادم الويب الثاني حلاً آخر، ولكن مشاركة عناوين URL بأرقام المنافذ (مثل http://example.com:81) ليس منطقيًّا أو مثاليًّا دائمًا. سنتعلّم في هذه الدورة كيفيّة ضبط Nginx كخادم ويب وكذلك كوسيط عكسي Reverse Proxy لـ Apache - كل ذلك على خادم واحد. قد تكون هنالك حاجة اعتمادًا على تطبيق الويب إلى تغييرات في الشفرة ليبقى Apache مُدركًا بالوسيط العكسي، وخاصّة عند ضبط مواقع SSL. سنتجنّب ذلك بتثبيت module وحدة Apache تسمى mod_rpaf والتي تُعيد كتابة متغيرات بيئة معيّنة بحيث يبدو أن Apache يتعامل مباشرة مع الطلبات من عملاء الويب. ستُضاف أربعة أسماء نِطاقات domain names على خادم واحد. وسيُخدَّم اثنين منهما بواسطة Nginx هما:example.com (المُضيف الظاهري الافتراضي) و sample.org. والاثنين المتبقيين، foobar.net و test.io، سيُخدّمان من قبل Apache. سنُعدّ أيضًا Apache لخدمة تطبيقات PHP باستخدام PHP-FPM، والذي يقدّم أداء أفضل عبر mod_php. المتطلبات المُسبقة ستحتاج لإكمال هذه الدورة التعليميّة إلى ما يلي: خادم Ubuntu 18.04 جديد تم إعداده من خلال اتباع خطوات الإعداد الأولي للخادم في Ubuntu 18.4، مع مستخدم sudo عادي (non-root) و جدار ناري. ضبط أربعة أسماء نطاق مؤهلة بالكامل للإشارة لعنوان IP الخاص بخادمك. انظر الخطوة 3 من كيفية إعداد اسم مضيف فيDigitalOcean كمِثال لكيفية القيام بذلك. إذا كنت تستضيف DNS للنطاقات الخاصّة بك في مكان آخر، فعليك إنشاء سجلات A مناسبة هناك بدلاً من ذلك. الخطوة 1 - تثبيت Apache و PHP-FPM لنبدأ بتثبيت Apache و PHP-FPM. سنثبّت أيضًا بالإضافة إلى تثبيت Apache و PHP-FPM، وحدة PHP FastCGI Apache وهيlibapache2-mod-fastcgi، لدعم تطبيقات ويب FastCGI. أولاً، يجب تحديث قائمة الحزم package الخاصّة بك للتأكد من حصولك على أحدث الحزم. $ sudo apt update يجب بعد ذلك تثبيت حزم Apache و PHP-FPM: $ sudo apt install apache2 php-fpm يجب تنزيل وحدة FastCGI Apache من kernel.org وتثبيتها باستخدام الأمر dpkg لأنّها غير متوفرة في مستودع Ubuntu: $ Wget https://mirrors.edge.kernel.org/ubuntu/pool/multiverse/liba/ libapache-mod-fastcgi/libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb $ sudo dpkg -i libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb علينا بعد ذلك تغيير الضبط الافتراضي لخادم Apache من أجل استخدام PHP-FPM. الخطوة 2 - ضبط Apache و PHP-FPM سنغيّر في هذه الخطوة رقم منفذ Apache إلى 8080 وضبطه للعمل مع PHP-FPM باستخدام الوحدة mod_fastcgi. أعد تسمية ملف ضبط ports.conf لمخدم Apache: $ sudo mv /etc/apache2/ports.conf /etc/apache2/ports.conf.default أنشئ ملف ports.conf جديد مع تعيين المنفذ إلى 8080: $ echo "Listen 8080" | sudo tee /etc/apache2/ports.conf ملاحظة: تُضبط خوادم الويب بشكل عام للتنصت على المنفذ 127.0.0.1:8080 عند ضبط الوكيل العكسي، ولكن القيام بذلك سيؤدي إلى ضبط قيمة متغير بيئة (PHP (SERVER_ADDR إلى عنوان IP الاسترجاع بدلاً من عنوان الـ IP العام للخادم. هدفنا هو إعداد Apache بطريقة لا ترى مواقعه على الويب الوكيل العكسي أمامها. لذلك، سنضبطه للتنصت على المنفذ 8080 لجميع عناوين IP. سننشئ بعد ذلك ملف مضيف افتراضي لـ Apache. سيعدّ التوجيه في هذا الملف ليخدّم المواقع فقط على المنفذ 8080. عطّل المضيف الظاهري الافتراضي: $ sudo a2dissite 000-default ثم أنشئ ملف مضيف افتراضي جديد، باستخدام الموقع الافتراضي الموجود: $ sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/001-default.conf افتح الآن ملف الضبط الجديد: $ sudo nano /etc/apache2/sites-available/001-default.conf غيّرمنفذ التنصت إلى 8080: /etc/apache2/sites-available/000-default.conf ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined احفظ الملف وقم بتنشيط ملف الضبط الجديد: $ sudo a2ensite 001-default ثم أعد تحميل Apache: $ sudo systemctl reload apache2 تحقّق من أن Apache يتنصت الآن على 8080: $ sudo netstat -tlpn يجب أن يبدو الخرج output كالمثال التالي، حيث يتنصّت apache2 على المنفذ 8080: output Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1086/sshd tcp6 0 0 :::8080 :::* LISTEN 4678/apache2 tcp6 0 0 :::22 :::* LISTEN 1086/sshd يمكنك إعداد دعم PHP و FastCGI بمجرّد التحقق من أن Apache يتنصت على المنفذ الصحيح. الخطوة 3 - ضبط Apache لاستخدام mod_fastcgi يخدّم Apache صفحات PHP باستخدام mod_php افتراضيًا، ولكنه يتطلب إعدادًا إضافيًّا للعمل مع PHP-FPM. ملاحظة: إذا كنت تجرّب هذا الدرس على نسخة موجودة مسبقًا من LAMP مع mod_php، عطّله أولاً باستخدام sudo a2dismod php7.2. سنضيف كتلة ضبط لوحدة mod_fastcgi التي تعتمد على mod_action. يُعطّل mod_action بشكل افتراضي، لذلك نحتاج أولاً إلى تفعيله: $ sudo a2enmod action أعد تسمية ملف ضبط FastCGI الموجود: $ sudo mv /etc/apache2/mods-enabled/fastcgi.conf/etc/apache2/mods -enabled/fastcgi.conf.default أنشئ ملف ضبط جديد: $ sudo nano /etc/apache2/mods-enabled/fastcgi.conf أضف التوجيهات التالية إلى الملف لتمرير طلبات ملفات php. إلى مقبس PHP-FPM UNIX: /etc/apache2/mods-enabled/fastcgi.conf AddHandler fastcgi-script .fcgi FastCgiIpcDir /var/lib/apache2/fastcgi AddType application/x-httpd-fastphp .php Action application/x-httpd-fastphp /php-fcgi Alias /php-fcgi /usr/lib/cgi-bin/php-fcgi FastCgiExternalServer /usr/lib/cgi-bin/php-fcgi -socket /run/php/php7.2-fpm.sock -pass-header Authorization Require all granted احفظ التغييرات واختبر الضبط: $ sudo apachectl -t إذا ظهرت عبارة Syntax OK، أعد تحميل Apache: $ sudo systemctl reload apache2 إذا رأيت رسالة التحذير التالية، يمكنك تجاهلها الآن بشكل آمن. سنَضبط أسماء الخادم في وقت لاحق: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message. دعنا نتأكد الآن من أنّه بإمكاننا تخديم PHP من Apache. الخطوة 4 - التحقق من عمل PHP سَنتأكّد من أن PHP يعمل، وذلك من خلال إنشاء ملف ()phpinfo والوصول إليه من متصفح الويب. أنشئ الملف var/www/html/info.php/ والذي يحتوي على استدعاء للدّالة phpinfo: $ echo "" | sudo tee /var/www/html/info.php انتقل في المتصفح إلى http: // your_server_ip: 8080 / info.php لاستعراض هذا الملف. ستظهر لك قائمة إعدادات الضبط التي يستخدمها PHP. كما في الشكل التالي: تحقّق من أن الخيار Server API يأخذ القيمة FPM/FastCGI وذلك في أعلى الصفحة كما في الصورة السابقة. سترى كذلك في أسفل الصفحة تقريبًا في القسم PHP Variables بأنّ قيمة SERVER_SOFTWARE هي Apache على Ubuntu. وهذا يؤكّد أنّ الوحدة mod_fastcgi مُفعّلة وأنّ Apache يستخدم PHP-FPM لمعالجة ملفات PHP. الخطوة 5 - إنشاء مضيفات افتراضيّة لـ Apache دعونا ننشئ ملفات المضيف الافتراضي لـ Apache للنطاقين foobar.net و test.io. سنقوم لعمل ذلك أولاً بإنشاء الأدلّة الجذر للمستند في كِلا الموقعين ووضع بعض الملفات الافتراضيّة في هذه الأدلة حتى نتمكن من اختبار الضبط لدينا بسهولة. أولاً، أنشئ الأدلّة الجذر للمستند: $ sudo mkdir -v /var/www/foobar.net /var/www/test.io أنشئ بعد ذلك ملف index لكل موقع: $ echo "<h1 style='color: green;'>Foo Bar</h1>" | sudo tee /var/www/foobar.net/index.html $ echo "<h1 style='color: red;'>Test IO</h1>" | sudo tee /var/www/test.io/index.html " | sudo tee /var/www/test.io/index.html ثم أنشئ ملف ()phpinfo لكل موقع حتى نتمكن من اختبار فيما إذا ضُبط PHP بشكل صحيح. $ echo "" | sudo tee /var/www/foobar.net/info.php $ echo "" | sudo tee /var/www/test.io/info.php الآن أنشئ ملف المضيف الافتراضي للنطاق foobar.net: $ sudo nano /etc/apache2/sites-available/foobar.net.conf أضف الشفرة التالية إلى الملف لتعريف المضيف: /etc/apache2/sites-available/foobar.net.conf ServerName foobar.net ServerAlias www.foobar.net DocumentRoot /var/www/foobar.net AllowOverride All يتيح السطر AllowOverride All تفعيل دعم htaccess. احفظ وأغلق الملف. ثم أنشئ ملف ضبط مماثل لـ test.io. أولاً أنشئ الملف: $ sudo nano /etc/apache2/sites-available/test.io.conf ثم أضف الضبط إلى الملف: /etc/apache2/sites-available/test.io.conf ServerName test.io ServerAlias www.test.io DocumentRoot /var/www/test.io AllowOverride All احفظ الملف وإغلاق المحرّر. والآن بعد إعداد كل من مضيفي Apache الافتراضيين، فعّل المواقع باستخدام الأمر a2ensite. والذي يُنشئ رابط رمزي لمَلف المضيف الافتراضي في الدليل sites-enabled: $ sudo a2ensite foobar.net $ sudo a2ensite test.io تحقّق من Apache للتأكّد من وجود أخطاء في الضبط مرّة أخرى: $ sudo apachectl –t سترى عبارة Syntax OK إذا لم يكن هناك أخطاء. إذا رأيت أي شيء آخر، فتحقّق من الضبط وحاول مرّة أخرى. قم بإعادة تحميل Apache لتطبيق التغييرات بمجرّد أن يكون الضبط الخاص بك خاليًا من الأخطاء: $ sudo systemctl reload apache2 افتح http://foobar.net:8080 و http://test.io:8080 في متصفحك للتأكّد من عمل المواقع والتحقّق من أنّ كل موقع يعرض ملف index.html الخاص به. سترى النتائج التالية: تأكّد أيضًا من أن PHP تعمل وذلك عن طريق الوصول إلى ملفات info.php لكل موقع. افتح http://foobar.net:8080/info.php و http://test.io:8080/info.php في متصفحك. سترى قائمة مواصفات ضبط PHP نفسها على كل موقع كما رأيت في الخطوة 4. لدينا الآن موقعين مُستضافين على Apache على المنفذ 8080. فلنَضبط بعد ذلك Nginx. الخطوة 6 - تثبيت وضبط Nginx سنقوم في هذه الخطوة بتثبيت Nginx وإعداد ضبط النطاقات example.com و sample.org كمضيفين افتراضيين لـ Nginx. ثبّت Nginx باستخدام مدير الحزم: $ sudo apt install nginx أزل الرابط الرمزي الافتراضي للمضيف الافتراضي حيث أننا لن نستخدمه بعد الآن: $ sudo rm /etc/nginx/sites-enabled/default سنُنشئ الموقع الافتراضي الخاص بنا فيما بعد (example.com). سنُنشئ الآن مضيفين افتراضيين لـ Nginx باستخدام نفس الإجرائيّة التي استخدمناها من أجل Apache. أنشئ أولاً الأدلّة للمستند الجذر لكل من موقعي الويب: $ sudo mkdir -v /usr/share/nginx/example.com /usr/share/nginx/sample.org سنحتفظ بمواقع الويب الخاصّة بـ Nginx في /usr/share/nginx، وهو المسار الافتراضي الذي سيختاره Nginx. يمكنك وضع هذه المواقع في /var/www/html مع مواقع Apache، لكن هذا الفصل بينها قد يساعدك على ربط المواقع بـ Nginx. كما فعلت مع مضيفي Apache الافتراضيين، أنشئ ملفات index و ()phpinfo من أجل الاختبار بعد اكتمال الإعداد: $ echo "<h1 style='color: green;'>Example.com</h1>" | sudo tee /usr/share/nginx/example.com/index.html $ echo "<h1 style='color: red;'>Sample.org</h1>" | sudo tee /usr/share/nginx/sample.org/index.html $ echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/example.com/info.php $ echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/sample.org/info.php الآن أنشئ ملف مضيف افتراضي للنطاق example.com: $ sudo nano /etc/nginx/sites-available/example.com يستدعي Nginx كتل server {. . .} من ملف الضبط server blocks. أنشئ كتلة خادم من أجل المضيف الافتراضي الأساسي example.com. تجعل ضبط التوجيه default_server هذا المضيف كمضيف افتراضي افتراضي لمعالجة طلبات HTTP التي لا تتطابق مع أي مضيف افتراضي آخر. /etc/nginx/sites-available/example.com server { listen 80 default_server; root /usr/share/nginx/example.com; index index.php index.html index.htm; server_name example.com www.example.com; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.2-fpm.sock; include snippets/fastcgi-php.conf; } } احفظ وأغلق الملف. أنشئ الآن ملف مضيف Nginx افتراضي للنطاق الثاني، sample.org: $ sudo nano etc/nginx/sites-available/sample.org أضف ما يلي إلى الملف: /etc/nginx/sites-available/sample.org server { root /usr/share/nginx/sample.org; index index.php index.html index.htm; server_name sample.org www.sample.org; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.2-fpm.sock; include snippets/fastcgi-php.conf; } } احفظ وأغلق الملف. ثم فعّل كِلا الموقعين من خلال إنشاء روابط رمزيّة للدّليل sites-enabled: $ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com $ sudo ln -s /etc/nginx/sites-available/sample.org /etc/nginx/sites-enabled/sample.org اختبر بعد ذلك ضبط Nginx لضمان عدم وجود أخطاء في الضبط: $ sudo nginx -t ثم أعد تحميل Nginx إذا لم يكن هناك أخطاء: $ sudo systemctl reload nginx الآن قم بالوصول إلى ملف ()phpinfo الخاص بمُضيفي Nginx الافتراضيين من متصفح الويب من خلال زيارة http://sample.org/info.php و http://example.com/info.php. انظر مجدّدًا إلى الصورة في الأسفل إلى قسم المتغيرات PHP Variables. يجب أن يحوي["SERVER_SOFTWARE"] على القيمة Nginx، مشيرًا إلى أنّ الملفات خُدّمت بشكل مباشر بواسطة Nginx. يجب أن يشير["DOCUMENT_ROOT"] إلى الدليل الذي أنشأته مُسبقًا في هذه الخطوة لكل موقع من مواقع Nginx. ثبّتنا في هذه المرحلة Nginx وأنشأنا مضيفين افتراضيين.سنقوم بعد ذلك بضبط Nginx على طلبات الوكيل المخصّصة للنطاقات المستضافة على Apache. الخطوة 7 - ضبط Nginx لمضيفي Apache الافتراضيين لنُنشئ مضيف Nginx افتراضي إضافي مع أسماء نطاقات متعددة في توجيهات server_name. سيتم توكيل طلبات هذه النطاقات إلى Apache. أنشئ ملف مضيف Nginx افتراضي جديد لإعادة توجيه الطلبات إلى Apache: $ sudo nano /etc/nginx/sites-available/apache أضف كتلة الشفرة التالية التي تحدد أسماء نطاقات كلاً من مضيفي Apache الاتراضيين وتوكل طلباتها إلى Apache. تذكّر استخدام عنوان IP العام في proxy_pass: /etc/nginx/sites-available/apache server { listen 80; server_name foobar.net www.foobar.net test.io www.test.io; location / { proxy_pass http://your_server_ip:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } قم بحفظ الملف وتفعيل هذا المضيف الافتراضي الجديد عن طريق إنشاء رابط رمزي: $ sudo ln -s /etc/nginx/sites-available/apache /etc/nginx/sites-enabled/apache اختبر الضبط للتأكد من عدم وجود أخطاء: $ sudo nginx -t إذا لم يكن هنالك أخطاء، أعد تحميل Nginx: $ sudo systemctl reload nginx افتح متصفحك وقم بالوصول إلى العنوان http://foobar.net/info.php. انتقل لأسفل إلى قسم PHP Variables وتحقق من القيم المعروضة كما في الصورة. يؤكّد المتغيران ERVER_SOFTWARE و DOCUMENT_ROOT أنّ هذا الطلب عُولج بواسطة Apache. وأضيفت المتغيرات HTTP_X_REAL_IP و HTTP_X_FORWARDED_FOR بواسطة Nginx ويجب أن تُظهر عنوان IP العام للحاسب الذي تستخدمه للوصول إلى عنوان URL. لقد أعددنا Nginx بنجاح ليوكل بطلبات نطاقات محدّدة إلى Apache. بعد ذلك، لنقم بضبط Apache لضبط المتغير REMOTE_ADDR كما لو أنه يتعامل مع هذه الطلبات مباشرة. الخطوة 8 - تثبيت وضبط mod_rpaf سنُثبّت في هذه الخطوة وحدة Apache تسمى mod\_rpaf والتي تعيد كتابة قيم REMOTE_ADDR، HTTPS و HTTP_PORT استنادًا إلى القيم المقدّمة من قبل وسيط عكسي. وبدون هذه الوحدة، تتطلب بعض تطبيقات PHP تغييرات في الشفرة للعمل بسلاسة من خلفْ الخادم الوكيل. هذه الوحدة موجودة في مستودع Ubuntu باسم libapache2-mod-rpaf ولكنها قديمة ولا تدعم توجيهات ضبط معينة. سنقوم بدلاً من ذلك بتثبيتها من المصدر. تثبيت الحزم اللازمة لبناء الوحدة: $ sudo apt install unzip build-essential apache2-dev نزّل أحدث إصدار مستقر من GitHub: $ wget https://github.com/gnif/mod_rpaf/archive/stable.zip استخراج الملف الذي نزل: $ unzip stable.zip انتقل إلى المجلد الجديد الذي يحتوي على الملفات: $ cd mod_rpaf-stable ترجم Compile الوحدة ثم ثبّتها: $ make $ sudo make install أنشئ بعد ذلك ملف في المجلد mods-available والذي سيُحمّل وحدة rpaf: $ sudo nano /etc/apache2/mods-available/rpaf.load أضف الشفرة التالية إلى الملف لتحميل الوحدة: /etc/apache2/mods-available/rpaf.load LoadModule rpaf_module /usr/lib/apache2/modules/mod_rpaf.so احفظ الملف وأغلق المحرر. أنشئ ملف آخر في نفس الدليل وسمّه rpaf.conf والذي سوف يحتوي على توجيهات الضبط للوحدة mod_rpaf: $ sudo nano /etc/apache2/mods-available/rpaf.conf أضف كتلة الشفرة التالية لضبط mod_rpaf، مع التأكّد من تحديد عنوان IP الخاص بخادمك: /etc/apache2/mods-available/rpaf.conf RPAF_Enable On RPAF_Header X-Real-Ip RPAF_ProxyIPs your_server_ip RPAF_SetHostName On RPAF_SetHTTPS On RPAF_SetPort On فيما يلي وصف موجز لكل توجيه. لمزيد من المعلومات، راجع ملف mod_rpaf README. RPAF_Header - الترويسة المراد استخدامها لعنوان IP الحقيقي للعميل. RPAF_ProxyIPs - عنوان IP للوكيل لضبط طلبات HTTP من أجله. RPAF_SetHostName - يقوم بتحديث اسم المضيف الافتراضي بحيث يعمل كل من ServerName و ServerAlias. RPAF_SetHTTPS - يضبط متغير بيئة HTTPS استنادًا إلى القيمة الموجودة في X-Forwarded-Proto. RPAF_SetPort - يضبط متغير بيئة SERVER_PORT. يكون مفيد عندما يكون Apache يعمل خلف وكيل SSL. احفظ الملف rpaf.conf وقم بتفعيل الوحدة: $ sudo a2enmod rpaf يؤدي هذا إلى إنشاء روابط رمزيّة من الملفات rpaf.load و rpaf.conf في الدليل mods-enabled. الآن قم بإجراء اختبار الضبط: $ sudo apachectl -t أعد تحميل Apache إذا لم يكن هنالك أخطاء: $ sudo systemctl reload apache2 قم بالوصول إلى الملف ()phpinfo في الصفحات http://foobar.net/info.php و http://test.io/info.php من متصفحك وتحقق من قسم PHP Variables. الآن سيكون المتغير REMOTE_ADDR هو أيضًا عنوان IP العام للحاسب المحلي لديك. الآن دعنا نعد تشفير TLS / SSL لكل موقع. الخطوة 9 - إعداد مواقع HTTPS باستخدام Let's Encrypt (اختياري) سنضبط في هذه الخطوة شهادات TLS / SSL لكل من النطاقات المُستضافة على Apache. سوف نحصل على الشهادات بواسطة [Let's Encrypt](https://letsencrypt.org]. يدعم Nginx إنهاء SSL، لذا من الممكن إعداد SSL بدون تعديل ملفات ضبط Apache. تَضمنْ الوحدة mod_rpaf أن يتم تعيين متغيرات البيئة المطلوبة على Apache لجعل التطبيقات تعمل بسلاسة خلفْ وكيل عكسي لـ SSL. أولاً سنفصل كتل الخادم {...}server من كِلا النطاقين بحيث يمكن أن يكون لكلٍ منهما شهادات SSL خاصّة به. افتح الملف etc/nginx/sites-available/apache/ في المحرّر الخاص بك: $ sudo nano /etc/nginx/sites-available/apache عدّل الملف بحيث يبدو مثل هذا، مع foobar.net و test.io في كتل الخادم الخاصّة بهم: /etc/nginx/sites-available/apache server { listen 80; server_name foobar.net www.foobar.net; location / { proxy_pass http://your_server_ip:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } server { listen 80; server_name test.io www.test.io; location / { proxy_pass http://your_server_ip:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } سنستخدم Certbot لإنشاء شهادات TLS/SSL الخاصّة بنا. ستتولى إضافة Nginx plugin" Nginx" مُهمة إعادة ضبط Nginx وإعادة تحميل الضبط عند الضرورة. أولاً، أضف مستودع Certbot المرخّص: $ sudo add-apt-repository ppa:certbot/certbot اضغط على ENTER عند مطالبتك بتأكيد رغبتك في إضافة المستودع الجديد. ثم قم بتحديث قائمة الحزم للحصول على معلومات حزمة المستودع الجديدة: $ sudo apt update ثم ثبّت حزمة Nginx الخاصّة بـ Certbot باستخدام apt: $ sudo apt install python-certbot-nginx وبمجرّد تثبيته، استخدم أمر certbot لإنشاء الشهادات لـ foobar.net و www.foobar.net: $ sudo certbot --nginx -d foobar.net -d www.foobar.net يخبر هذا الأمر Certbot ليستخدم ملحق nginx، وباستخدم –d لتحديد الأسماء التي نودّ أن تكون الشهادة صالحة لها. إذا كانت هذه هي المرة الأولى التي تُشغّل فيها certbot، فسَتتم مطالبتك بإدخال عنوان بريد إلكتروني والموافقة على شروط الخدمة. سيتصل بعد القيام بذلك certbot بخادم Let's Encrypt، ثم يشغّل ردّا للتحقق من أنّك تتحكم في النطاق الذي تطلب الحصول على شهادة له. سَيسألك Certbot بعد ذلك عن الطريقة التي ترغب في ضبط إعدادات HTTPS الخاصّة بك: Output Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): حدّد خيارك، ثم اضغط على ENTER. سيتم تحديث الضبط، وإعادة تحميل Nginx لتفعيل الإعدادات الجديدة. الآن، نفّذ الأمر للنطاق الثاني: $ sudo certbot --nginx -d test.io -d www.test.io انظر في قسم PHP Variables. تم تعيين المتغير SERVER_PORT على القيمة 443 وضبط HTTPS على القيمة on، كما لو أنّه تم الوصول إلى Apache مباشرةً عبر HTTPS. مع ضبط هذه المتغيرات، لن تحتاج تطبيقات PHP إلى إعداد خاص للعمل خلف وسيط عكسي. سنقوم الآن بتعطيل الوصول المباشر إلى Apache. الخطوة 10 - حظر الوصول المباشر إلى Apache (اختياري) بما أن Apache يستمع على المنفذ 8080 على عنوان IP العام، فإنّه بإمكان الجميع الوصول إليه. ويمكن حظره من خلال عمل الأمر IPtables التالي في مجموعة قواعد الجدار الناري. $ sudo iptables -I INPUT -p tcp --dport 8080 ! -s your_server_ip -j REJECT --reject-with tcp-reset تأكّد من استخدام عنوان IP لخَادمك مكان اللون الأحمر في المثال السابق. بمجرد حظر المنفذ 8080 في الجدار الناري، اختبر عدم إمكانية الوصول إلى Apache. افتح متصفح الويب الخاص بك وحاول الوصول إلى أحد أسماء نطاقات Apache على المنفذ 8080. على سبيل المثال: http://example.com:8080 يجب أن يعرض المتصفح رسالة خطأ "غير قادر على الاتصال" أو "صفحة الويب غير متوفرة". وبضبط خيار IPtables tcp-reset، لن يرى أحد أي اختلاف بين المنفذ 8080 والمنفذ الذي لا يحتوي أيّ خدمةٍ عليه. ملاحظة: عند إعادة تشغيل النظام وبشكل افتراضي لن تبقى قواعد IPtables كما حدّدناها. هناك طرق متعددة للحفاظ على قواعد IPtables، ولكن أسهلها هو استخدام iptables-persistent في مستودع Ubuntu. استكشف هذه المقالة لمعرفة المزيد حول كيفيّة ضبط IPTables. لنضبط الآن Nginx لخدمة ملفات ثابتة لمواقع Apache. الخطوة 11 - تخديم الملفات الثابتة باستخدام Nginx (اختياري) عندما يقدم وسيط Nginx طلبات لنطاقات Apache، فإنّه يرسل كل ملف طلب لهذا النطاق إلى Apache. Nginx أسرع من Apache في خدمة الملفات الثابتة مثل الصور، وجافا سكريبت وأوراق الأنماط. لذلك دعونا نضبط ملف مضيف apache افتراضي خاص بـ Nginx لتخديم الملفات الثابتة مباشرة ولكن مع إرسال طلبات PHP إلى Apache. افتح الملف etc/nginx/sites-available/apache/ في محرّرك الخاص: $ sudo nano /etc/nginx/sites-available/apache ستحتاج إلى إضافة موضعين location إضافيين لكل كتلة خادم، بالإضافة إلى تعديل أقسام location الموجودة. بالإضافة إلى ذلك، ستحتاج إلى إخبار Nginx بمكان تواجد الملفات الثابتة لكل موقع. إذا قرّرت عدم استخدام شهادات SSL و TLS، فعدّل ملفك بحيث يبدو كالتالي: /etc/nginx/sites-available/apache server { listen 80; server_name test.io www.test.io; root /var/www/test.io; index index.php index.htm index.html; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { proxy_pass http://your_server_ip:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ /\.ht { deny all; } } server { listen 80; server_name foobar.net www.foobar.net; root /var/www/foobar.net; index index.php index.htm index.html; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { proxy_pass http://your_ip_address:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ /\.ht { deny all; { { إذا كنت تريد بأن يكون HTTPS متوفرًا أيضًا، فاستخدم الضبط التالي بدلاً من ذلك: server { listen 80; server_name test.io www.test.io; root /var/www/test.io; index index.php index.htm index.html; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { proxy_pass http://your_server_ip:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ /\.ht { deny all; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/test.io/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/test.io/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; } server { listen 80; server_name foobar.net www.foobar.net; root /var/www/foobar.net; index index.php index.htm index.html; location / { try_files $uri $uri/ /index.php; } location ~ \.php$ { proxy_pass http://your_ip_address:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ~ /\.ht { deny all; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/foobar.net/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/foobar.net/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; { إنّ التوجيه try_files يجعل Nginx يبحث عن الملفات في المستند الجذر ويقدّمها مباشرةً. إذا كان الملف له امتداد php.، سيتم تمرير الطلب إلى Apache. حتى إذا لم يُعثر على الملف في المستند الجذر، يُمرّر الطلب إلى Apache لتعمل ميزات التطبيق مثل permalinks بدون أخطاء. تحذير: إنّ التوجيه location ~ /\.ht مهم جداً؛ حيث يمنع Nginx من عرض محتويات ملفات الضبط Apache مثل htaccess. و htpasswd. التي تحتوي على معلومات حساسة. احفظ الملف وقم بإجراء اختبار الضبط: $ sudo nginx -t أعد تحميل Nginx إذا نجح الاختبار: $ sudo service nginx reload يمكنك للتحقّق من أن العمل تم بشكل صحيح فحص ملفات سجل Apache في var/log/apache2/ ومشاهدة طلبات GET لملفات info.php من test.io و foobar.net. استخدم الأمر tail لمشاهدة الأسطر القليلة الأخيرة من الملف، واستخدم رمز التبديل f- لمشاهدة الملف من أجل التغييرات: $ sudo tail -f /var/log/apache2/other_vhosts_access.log قم الآن بزيارة http://test.io/info.php في مستعرض الويب الخاص بك ثم انظر إلى خرج السجل. سترى أن Apache يجيب بالفعل: Output test.io:80 your_server_ip - - [01/Jul/2016:18:18:34 -0400] "GET /info.php HTTP/1.0" 200 20414 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" ثم قم بزيارة صفحة index.html لكل موقع ولن ترى أي إدخالات للسجّل من قبل Apache. لأن Nginx هو من يخدّمهم. عند الانتهاء من معاينة ملف السجل، اضغط على CTRL + C لإيقاف تعقبّه. باستخدام هذا الإعداد، لن يكون Apache قادرًا على تقييد الوصول إلى الملفّات الثابتة. وللتَحكم في الوصول إلى الملفّات الثابتة تحتاج إلى ضبط في ملف المضيف apache الافتراضي الخاص بـ Nginx، ولكن هذا خارج نطاق هذه الدورة التعليميّة. الخلاصة لديك الآن خادم Ubuntu مع Nginx يُخدّم example.com و sample.org، جنبًا إلى جنب مع Apache والذي يُخدّم foobar.net و test.io. على الرغم من أن Nginx يعمل كوكيل عكسي لـ Apache، إلا أن خدمة الوكيل في Nginx تتسم بالشفافية وتُظهر اتصالها بنطاقات Apache كما لو أنها مخدّمة مباشرةً من Apache. يمكنك استخدام هذه الطريقة لتخديم مواقع آمنة وثابتة. ترجمة بتصرف للمقال How To Configure Nginx as a Web Server and Reverse Proxy for Apache on One Ubuntu 18.04 Server لصاحبه Jesin A.

مقدمة صُممت أنظمة إدارة الضبط لتجعل من التحكم في عددٍ كبيرٍ من الخوادم أمرًا سهلًا للمدراء وفِرق العمليات. فهي تسمح بالتحكم في العديد من الأنظمة المختلفة بطريقةٍ آلية ومن موقع مركزي واحد. وعلى الرغم من وجود العديد من أنظمة إدارة الضبط الشائعة المتوفرة لأنظمة Linux، مثل Chef وPuppet، إلاّ أنّ هذه الأنظمة غالباً ما تكون أكثر تعقيدًا مما يريده أو يحتاجه الكثير من الأشخاص. يُعدّ Ansible بديلاً هامًا لهذه الخيارات نظرًا لأنّه يتطلب عبئا أقل بكثير للبدء. سنناقش في هذا الدليل كيفيّة تثبيت Ansible على خادم Ubuntu 18.04 وسنتحدّث عن بعض الأساسيّات حول كيفيّة استخدام البرنامج. كيف يعمل Ansible؟ يعمل Ansible عن طريق ضبط أجهزة العميل من خلال حاسب يحوي مكوّنات Ansible مُثبّتة ومُهيأة. يتصل عبر قنوات SSH الاعتيادية لاسترداد المعلومات من الأجهزة البعيدة، وإصدار الأوامر، ونسخ الملفات. ولذلك لا يتطلب نظام Ansible تثبيت أيّة برمجيّات إضافيّة على أجهزة حواسب العملاء. هذه هي إحدى الطرق التي يّبسط فيها Ansible إدارة الخوادم. يمكن ضم أي خادم لديه منفذ SSH مكشوف تحت مظلة ضبط Ansible بغض النظر عن الطور الذي يتواجد فيه ضمن دورة حياته. وهذا يعني أن أي حاسب يمكنك إدارته من خلال SSH، يمكنك إدارته أيضًا من خلال Ansible. يتخذ Ansible نهجًا معياريًا، جاعلًا من السهل التوسع لاستخدام وظائف النظام الرئيسي للتعامل مع سيناريوهات محدّدة. يمكن كتابة الوحدات باستخدام أيّة لغة وتتواصل في JSON القياسيّة. إن ملفات الضبط مكتوبة بشكل أساسي بصيغة تسلسل بيانات YAML بسبب طبيعتها الدلاليّة وتشابهها مع لغات الترميز الشائعة. ويمكن أن يتفاعل Ansible مع المضيفات hosts إما عبر أدوات سطر الأوامر أو من خلال سكربتات الضبط ، والتي تُعرف باسم Playbooks. المتطلبات المسبقة ستحتاج لمتابعة هذه الدورة التعليميّة إلى: اثنين أو أكثر من خوادم Ubuntu 18.04. سيُستخدم واحد منها كخادم Ansible الخاص بك، بينما سيُستخدم الباقي كمضيفين Ansible الخاصين بك. يجب أن يكون لكل منهم مستخدم غير جذري non-root بامتيازات sudo وجدار ناري firewall أساسي مُهيئ. يمكنك إعداد ذلك باتباع دليل إعداد الخادم المبدئي لـ Ubuntu 18.04. ويرجى ملاحظة أنّ الأمثلة في هذا الدليل تحدّد ثلاثة مضيفين Ansible، ولكن يمكن ضبط الأوامر لأيّ عدد تريده من العملاء. أُنشئت مفاتيح SSH للمستخدم الغير جذري non-root user على خادم Ansible الخاص بك. وللقيام بذلك، تابع الخطوة 1 من دليلنا حول كيفية إعداد مفاتيح SSH على Ubuntu 18.04. يمكنك من أجل هذه الدورة التعليميّة حفظ زوج المفاتيح إلى الموقع الافتراضي (ssh/id_rsa./~) ولا تحتاج إلى حماية بكلمة المرور. الخطوة 1 - تثبيت Ansible يجب تثبيت برنامج Ansible على جهاز واحد على الأقل لبدء استخدامه كوسيلة لإدارة الخوادم المختلفة. يمكنك إضافة أرشيف الحزمة الشخصيّة للمشروع (PPA (personal package archive إلى النظام الخاص بك للحصول على أحدث إصدار من Ansible على نظام Ubuntu. عليك قبل القيام بذلك أولاً تحديث فهرس الحزمة وتثبيت حزمة software-properties-common. حيث تسهّل هذه البرمجية إدارة هذا المستودع ومستودعات البرمجيات المستقلة الأخرى: $ sudo apt update $ sudo apt install software-properties-common ثم أضف PPA Ansible عن طريق كتابة الأمر التالي: $ sudo apt-add-repository ppa: ansible / ansible اضغط ENTER لقبول إضافة PPA. بعدها، حدّث فهرس حزمة النظام مرّةً أخرى حتى يصبح على معرفةٍ بالحزم المتاحة في PPA: $ sudo apt update يمكنك تثبيت برمجيّة Ansible بعد هذا التحديث: $ sudo apt install ansible يحتوي الآن خادم Ansible على جميع البرمجيّات المطلوبة لإدارة المضيفات hosts. الخطوة 2 - تهيئة الـ SSH للوصول إلى مضيفات Ansible يتصل Ansible كما ذُكر سابقًا بشكل أساسي مع أجهزة الحواسب العميلة من خلال SSH. وعلى الرغم من أن لديها بالتأكيد القدرة على التعامل مع استيثاق SSH المعتمد على كلمة المرور، إلاّ أن استخدام مفاتيح SSH يمكن أن يساعد في إبقاء الأمور بسيطة. استخدم أمر cat على خادم Ansible خاصتك لطباعة محتويات ملف مفتاح SSH العام للمستخدم الغير جذري non-root الخاص بك إلى خرْج الطرفيّة terminal: $ cat ~ / .ssh / id_rsa.pub انسخ الخرج الناتج إلى حافظتك، ثم افتح طرفيّة جديدة terminal واتصل بأحد مضيفي Ansible مُستخدمًا SSH: $ ssh sammy @ ansible_host_ip بدّل إلى المستخدم الجذري root لجهاز العميل: $ su – افتح الدليل authorized_keys ضمن المسار ~/.ssh كمستخدم جذر root : # nano ~/.ssh/authorized_keys الصق مفتاح SSH لمستخدم Ansible server في الملف، ثم احفظ الملف وأغلق المحرر (, اضغط CTRL + X, Y، ثم ENTER). ثم شغِّل الأمر exit للرجوع إلى المستخدم العادي للمضيف: # exit أخيرًا، ونظرًا لأن Ansible يستخدم مُفسّر بايثون python interpreter الموجود في المسار / usr / bin / python لتشغيل وحداته، فستحتاج إلى تثبيت Python 2 على المضيف حتى يتمكن Ansible من الاتصال به. شغّل الأوامر التالية لتحديث فهرس حزمة المضيف وتثبيت حزمة python: $ sudo apt update $sudo apt install python يمكنك بعد ذلك تشغيل أمر exit مرّةً أخرى لإغلاق الاتصال بالعميل: $ exit كرّر هذه العملية من أجل كل خادم تنوي التحكم فيه باستخدام خادم Ansible الخاص بك. بعد ذلك، سنُهيئ خادم Ansible للاتصال بالمضيفات باستخدام ملف (hosts)الخاص بـ Ansible. الخطوة 3 - إعداد مضيفات Ansible يتتبع Ansible كافة الخوادم الذي يتعرف عليها من خلال ملف المضيفات hosts. نحتاج أولًا إلى إعداد هذا الملف قبل أن نتمكن من بدء الاتصال بحواسبنا الأخرى: $ sudo nano /etc/ansible/hosts سترى ملفًا يحوي عددًا من أمثلة "نماذج" الضبط المُعقّب عليها (بإشارة # تسبق كل سطر). لن تعمل هذه الأمثلة فعليًا في حالتنا نظرًا لأن المضيفات المُدرجات في كل منها وهميّة. بكافة الأحوال سنحتفظ بهذه الأمثلة في الملف لمساعدتنا في الضبط في حال أردنا تنفيذ حالات أكثر تعقيدًا في المستقبل. إن ملف hosts مرن إلى حدّ ما ويمكن ضبطته بعدّة بطرق مختلفة. وبناءً عليه، ستبدو الصياغة التي سنستخدمها كما يلي: [group_name] alias ansible_ssh_host=your_server_ip في هذا المثال، إن group_name وسم تنظيمي يتيح لك الإشارة إلى أي خادم مدرج تحته بكلمة واحدة، بينما alias هو مجرد اسم للإشارة إلى خادم معيّن. نعتبر في حالتنا أن لدينا ثلاثة خوادم سنتحكم بهم باستخدام Ansible. يمكن عند هذه النقطة الوصول إلى هذه الخوادم من خادم Ansible بكتابة: $ ssh root@ansible_host_ip إذا أعددت هذا بشكل صحيح فلا يجب أن تُطالب بكلمة مرور. سنفترض هنا لأغراض العرض التوضيحي أن عناوين IP لمضيفاتنا هي 203.0.113.1 و 203.0.113.2 و 203.0.113.3. وسنضبط ذلك بحيث يمكننا الإشارة إليها بشكل فردي كـ host1، و host2، و host3، أو كمجموعة باسم servers. و لإتمام ذلك يتوجب إضافة هذه الكتلة إلى ملف hosts الخاص بنا: [servers] host1 ansible_ssh_host=203.0.113.1 host2 ansible_ssh_host=203.0.113.2 host3 ansible_ssh_host=203.0.113.3 يمكن أن تكون المضيفات في مجموعاتٍ متعددة، ويمكن للمجموعات ضبط المعاملات parameters من أجل جميع أعضائها. فلنجرّب هذا الآن. إن حاولنا باستخدام إعداداتنا الحاليّة الاتصال بأي من هذه الأجهزة المضيفة hosts من خلال Ansible، فسيفشل الأمر (على افتراض أنك لا تعمل كمستخدم جذر root). يحدث هذا لأنّه تم تضمين مفاتيح SSH من أجل المستخدم الجذر على الأنظمة البعيدة وسيحاول Ansible الاتصال بشكل افتراضي بواسطة المستخدم الحالي، ستعطينا محاولة الاتصال هذا الخطأ: [servers] Output host1 | UNREACHABLE! => { "changed": false, "msg": "Failed to connect to the host via ssh.", "unreachable": true } نستخدم على خادم Ansible مستخدمًا اسمه sammy. سيحاول Ansible الاتصال بكل مضيف باستخدام ssh sammy @ server. ولن يعمل هذا إذا لم يكن المستخدم sammy موجودًا على النظام البعيد أيضًا. يمكننا إنشاء ملف يخبر جميع الخوادم في مجموعة "servers " للاتصال كمستخدم جذر root. سننشئ لعمل ذلك دليلًا في بنية ضبط Ansible يدعى group_vars. ويمكننا ضمن هذا المجلد إنشاء ملفات بتنسيق YAML لكل مجموعة نريد ضبطها: $ sudo mkdir /etc/ansible/group_vars $sudo nano /etc/ansible/group_vars/servers يمكننا وضع ضبطنا هنا. تبدأ ملفات YAML بـ "---"، لذا تأكد من عدم نسيان هذا الجزء. /etc/ansible/group_vars/servers --- ansible_ssh_user: root احفظ وأغلق هذا الملف عند الانتهاء. إذا كنت تريد تحديد تفاصيل الضبط لكل خادم، بغض النظر عن المجموعة المرتبط بها، فيمكنك وضع هذه التفاصيل في ملف في المسار etc/ansible/group_vars/all/. يمكن ضبط المضيفات بشكل فردي عن طريق إنشاء ملفات مُسماة بالاسم البديل alias تحت الدليل في /etc/ansible/host_vars. الخطوة 4 - استخدام أوامر Ansible بسيطة يمكننا الآن -وبعد أن أعددنا مضيفاتنا و ضبطنا تفاصيل تهيئة كافية للسماح لنا بالاتصال بنجاح مع مضيفاتنا- تجربة الأمر الأول. عمل اختبار ping لجميع خوادمنا المُهيئة وذلك بكتابة: $ anmible -m ping all ستكون المخرجات كالتالي: host1 | SUCCESS => { "changed": false, "ping": "pong" } host3 | SUCCESS => { "changed": false, "ping": "pong" } host2 | SUCCESS => { "changed": false, "ping": "pong" } وهو اختبار بسيط للتأكّد من أنّ Ansible يتصل بجميع مضيفاته. تعني all جميع المضيفات. ويمكننا بسهولة تحديد مجموعة معيّنة كما يلي: $ ansible -m ping servers يمكننا أيضًا تحديد مضيف بشكل فردي: $ anmible -m ping host1 يمكننا تحديد عدّة مضيفات من خلال فصلها باستخدام النقطتين: $ anmible -m ping host1: host2 إنّ المقطع -m ping من الأمر عبارة عن تعليمة لـ Ansible لاستخدام الوحدة "ping". وهي في الأساس أوامر يمكنك تشغيلها على المضيفات عن بعد. تعمل وحدة ping بعدّة طرق مثل أداة ping العادية في Linux، ولكنها بدلاً من ذلك تتحقق من اتصال Ansible. لا تأخذ وحدة ping في الواقع أيّة وسائط arguments، لكن يمكننا تجربة أمر آخر لمعرفة كيفيّة عمل ذلك. نمرّر المعاملات في تدوين نصي "سكريبت" عن طريق كتابة -a. تتيح لنا الوحدة "shell" إرسال أمر طرفيّة terminal command إلى المضيف البعيد واسترداد النتائج. على سبيل المثال، يمكننا استخدام الأمر التالي لمعرفة استخدام الذاكرة على جهاز host1: $ ansible -m shell -a 'free -m' host1 ستكون مخرجات Shell كالتالي: host1 | SUCCESS | rc=0 >> total used free shared buffers cached Mem: 3954 227 3726 0 14 93 -/+ buffers/cache: 119 3834 Swap: 0 0 0 وبذلك أصبح خادم Ansible الخاص بك مُهيئًا ويمكنك الاتصال والتحكم في المضيفات بنجاح. الخلاصة ضبطنا في هذه الدورة التعليميّة Ansible وتأكّدنا من إمكانية اتصاله مع كل مضيف. واستخدمنا أيضًا الأمر ansible لتنفيذ مهام بسيطة عن بُعد. وعلى الرغم من أن هذا مفيد، إلا أنّنا لم نُغطّي أهم ميزة لـ Ansible في هذا المقال وهي الـ Playbooks. تعتبر Ansible Playbooks طريقةً قويّة وبَسيطة لإدارة عمليات تهيئة الخادم وعمليات النشر المتعدّدة الأجهزة. للحصول على تمهيد حول كتب Playbook، راجع هذا الدليل. بالإضافة إلى ذلك، فإننا نشجعك على مراجعة توثيق Ansible الرسميّة لمعرفة المزيد عن الأداة ترجمة وبتصرّف للمقال How to Install and Configure Ansible on Ubuntu 18.04 لصاحبيه Stephen Rees-Carter و Mark Drake

مقدمة تأتي قواعد بيانات SQL مُثبّتة مع جميع الأوامر التي تحتاجها للإضافة، والتعديل، والحذف والاستعلام عن بياناتك. يوفّر هذا الدليل لنمط الورقة المرجعية cheat sheet مرجعًا سريعًا لبعضٍ من أوامر SQL الأكثر شيوعًا. كيفية استخدام هذا الدليل: هذا الدليل على شكل ورقة مرجعيّة فيها أمثلة منفصلة قابلة للاستخدام فرادى. انتقل إلى أي مقطع ذي صلة بالمهمة التي تحاول إكمالها. عندما ترى نصًّا مميّزًا في أوامر هذا الدليل، فضع بالحسبان أن هذا النص يشير إلى الأعمدة، والجداول، والبيانات في قاعدة البيانات الخاصة بك. ضُمّنت قيم البيانات في هذا الدليل في الأمثلة المُعطاة بعلامة ('). من الضروري في SQL تضمين أي قيم بيانات تحتوي على سلاسل نصية في علامات اقتباس أحادية. هذا التضمين غير مطلوب من أجل البيانات الرقمية، ولكنه لن يتسبب بأيّة مشاكل أيضًا. يرجى ملاحظة أنّه على الرغم من كون SQL معياريّة، إلاّ أنّ معظم برامج قواعد بيانات SQL لها إضافاتها الخاصّة. يستخدم هذا الدليل MySQL كنموذج لنظام إدارة قواعد البيانات العلائقية (RDBMS)، ولكن الأوامر المقدّمة ستعمل مع برامج قواعد البيانات العلائقية الأخرى، بما في ذلك PostgreSQL و MariaDB وSQLite. سنُضمّن الأوامر البديلة عند وجود فروق مهمّة بين أنظمة إدارة قواعد البيانات العلائقية RDBMSs. بدء مِحث أوامر قاعدة البيانات (باستخدام استيثاق Socket/Trust) يمكن لمستخدم MySQL الجذر root الاستيثاق بدون كلمة مرور بشكل افتراضي في نظام التشغيل أبونتو Ubuntu 18.04 باستخدام الأمر التالي: $ sudo mysql استخدم الأمر التالي لفتح مِحث أوامر PostgreSQL. سيُسجلك هذا المثال كمستخدم postgres، والذي يتضمن صلاحيات دور المستخدم المميّز superuser role، ولكن يمكنك استبداله بأي دور مُنشئ مُسبقًا: $ sudo -u postgres psql بدء مِحث أوامر قاعدة البيانات (باستخدام استيثاق كلمة المرور) إذا ُضبط مستخدم MySQL الجذر root للاستيثاق باستخدام كلمة مرور، فبإمكانك استخدام الأمر التالي: $ mysql -u root -p إذا أعددت مُسبقًا حساب مستخدم عادي non-root لقاعدة بياناتك، فيمكنك أيضًا استخدام هذه الطريقة لتسجيل الدخول باسم هذا المستخدم: $ mysql -u user -p سيُقاطعك الأمر السابق بعد تشغيله للمطالبة بكلمة المرور الخاصّة بك. إذا كنت ترغب في جعل كلمة المرور كجزء من الأمر، فأَتبعْ الخيار p- مباشرة بكلمة مرورك، بدون ترك فراغ بينهما: $ mysql -u root -ppassword إنشاء قاعدة بيانات يُنشئ الأمر التالي قاعدة بيانات بإعداداتٍ افتراضيّة: mysql> CREATE DATABASE database_name; يمكنك إذا أردت لقاعدة بياناتك أن تستخدم مجموعة محارف وتصنيف مختلفة عن الإعدادات الافتراضيّة تحديد ذلك باستخدام الصياغة التالية: mysql> CREATE DATABASE database_name CHARACTER SET character_set COLLATE collation; إظهار قائمة قواعد البيانات شغّل الأمر التالي لرؤية قواعد البيانات الموجودة في نظام MySQL أو MariaDB: mysql> SHOW DATABASES; يمكنك في PostgreSQL مشاهدة قواعد البيانات المُنشأة باستخدام الأمر التالي: postgres=# \list حذف قاعدة البيانات شغّل الأمر التالي لحذف قاعدة بيانات بما في ذلك ضمنًا أي جداول وبيانات موجودة فيها: mysql> DROP DATABASE IF EXISTS database; إنشاء مستخدم نفّذ الأمر التالي لإنشاء معرّف مستخدِم لقاعدةِ بياناتك من دون تحديد أيّ امتيازاتٍ له: mysql> CREATE USER username IDENTIFIED BY 'password'; تَستخدم PostgreSQL بنية مشابهة، ولكنها مختلفة قليلاً، إليك الصياغة: postgres=# CREATE USER user WITH PASSWORD 'password'; يمكنك إذا أردتَ إنشاء مستخدم جديد ومنحه امتيازات باستخدام أمر واحد عن طريق إصدار عبارة GRANT. ينشئ الأمر التالي مستخدمًا جديدًا ويمنحه امتيازات كاملة لكامل قاعدة البيانات والجداول في نظام إدارة قواعد البيانات العلائقية RDBMS: mysql> GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password'; لاحظ الكلمة المفتاحيّة PRIVILEGES في تعليمة GRANT السابقة. إن هذه الكلمة اختيارية في معظم أنظمة إدارة قواعد البيانات العلائقية، ويمكن كتابة هذه التعليمة بشكل مكافئ على النحو التالي: mysql> GRANT ALL ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password'; كن منتبهًا مع ذلك، أنّ الكلمة المفتاحيّة PRIVILEGES مطلوبة لمنح امتيازات كهذه عندما يكون وضع Strict SQL مُشغّلًا. حذف مستخدم استخدم الصياغة التالية لحذف اسم مستخدم قاعدة البيانات: mysql> DROP USER IF EXISTS username; لاحظ أن هذا الأمر لا يحذف افتراضيًا أيّة جداول أُنشأت بواسطة المستخدم المحذوف، وقد تؤدي محاولات الوصول إلى جداول كهذه إلى حدوث أخطاء. اختيار قاعدة البيانات يجب أولًا إخبار RDBMS بقاعدة البيانات التي ترغب في إنشائها في MySQL و MariaDB قبل أن تتمكن من إنشاء جدول. استخدم الصياغة التالية للقيام بذلك: mysql> USE database; يجب عليك استخدام الأمر التالي في PostgreSQL لاختيار قاعدة بياناتك المرغوبة: postgres=# \connect database إنشاء جدول تنشئ بنية الأمر التالية جدولًا جديدًا باسم table يحوي عمودين لكل منهما نوع بياناته الخاص: mysql> CREATE TABLE table ( column_1 column_1_data_type, column_2 column_2_data_taype ); حذف جدول نفّذ ما يلي لحذف جدول بالكامل، بما في ذلك جميع البيانات الخاصّة به: mysql> DROP TABLE IF EXISTS table إدخال البيانات في جدول استخدم الصياغة التالية لملء جدول بصف واحد من البيانات (row): mysql> INSERT INTO table ( column_A, column_B, column_C ) VALUES ( 'data_A', 'data_B', 'data_C' ); يمكنك أيضًا ملء جدول بعدة صفوف من البيانات باستخدام أمر واحد، على النحو التالي: mysql> INSERT INTO table ( column_A, column_B, column_C ) VALUES ( 'data_1A', 'data_1B', 'data_1C' ), ( 'data_2A', 'data_2B', 'data_2C' ), ( 'data_3A', 'data_3B', 'data_3C' ); حذف بيانات من جدول استخدم بنية الأوامر التالية لحذف صف من البيانات من جدول. لاحظ أن value يجب أن تكون القيمة الموجودة في العمود المحدد column في الصف الذي تريد حذفه: mysql> DELETE FROM table WHERE column='value'; ملاحظة: إذا لم تُضمّن عبارة WHERE في تعليمة DELETE، كما هو موضّح في المثال التالي، فستُحذف جميع البيانات الموجودة في الجدول، ولكن لن تُحذف الأعمدة أو الجدول نفسه: mysql> DELETE FROM table; تغيير البيانات في جدول استخدم الصياغة التالية لتحديث البيانات الموجودة في الصف المُعطى. لاحظ أنّ عبارة WHERE في نهاية الأمر تُخبر SQL بالصف المطلوب تحديثه. إنّ value هي القيمة الموجودة في column_A المحاذية للصفِ الذي تريد تغييره. ملاحظة: إذا أهملتَ تضمين عبارة WHERE في تعليمة UPDATE، فسيَستبدِل الأمر البيانات الموجودة في كل صف من الجدول. mysql> UPDATE table SET column_1 = value_1, column_2 = value_2 WHERE column_A=value; إضافة عمود ستضيف صياغة الأمر التالية عمودًا جديدًا إلى جدول: mysql> ALTER TABLE table ADD COLUMN column data_type; حذف عمود سيؤدي هذا الأمر إلى حذف عمود من جدول: mysql> ALTER TABLE table DROP COLUMN column; تنفيذ الاستعلامات الأساسيّة استخدم الصياغة التالية لعرض جميع البيانات من عمود واحد من جدول: mysql> SELECT column FROM table; افصلْ بين أسماء الأعمدة بفاصلة للاستعلام عن أعمدة متعددة من نفس الجدول: mysql> SELECT column_1, column_2 FROM table; يمكنك أيضًا الاستعلام عن كل الأعمدة في جدول عن طريق استبدال أسماء الأعمدة بعلامة النجمة (*). تعمل علامات النجمة في SQL كبدائل لتمثيل "الكل": mysql> SELECT * FROM table; استخدام عبارات WHERE يمكنك تضييق نطاق نتائج استعلام عن طريق إلحاق تعليمة SELECT بعبارة WHERE، كما يلي: mysql> SELECT column FROM table WHERE conditions_that_apply; يمكنك على سبيل المثال الاستعلام عن جميع البيانات من صف واحد من خلال صياغة مشابهة لما يلي. لاحظ أن value يجب أن تكون قيمة محفوظة في كل من column المحدّد والصف الذي تريد الاستعلام عنه: mysql> SELECT * FROM table WHERE column = value; العمل مع مُعاملات المقارنة يحدّد مُعامل المقارنة في جملة WHERE كيفيّة مقارنة العمود المحدّد بقيمة ما. فيما يلي بعض معاملات المقارنة الشائعة لـ SQL: = : اختبار المساواة != : اختبار عدم المساواة < : اختبار أقل من > : اختبار أكبر من <= : اختبار أقل من أو يساوي >= : اختبار أكبر من أو يساوي BETWEEN : اختبار فيما إذا كانت القيمة ضمن مجال مُعطى IN : اختبار ما إذا كانت قيمة الصّف مُتضَمّنة في مجموعة من القيم المحدّدة EXISTS : اختبار ما إذا كانت صفوف موجودة، تبعاً للشروط المحدّدة LIKE : اختبار فيما إذا كانت قيمة تتطابق مع سلسلة نصيّة محدّدة IS NULL : اختبار القيم الفارغة IS NOT NULL : اختبار كافّة القيم غير الفارغة "NULL" العمل مع محارف البدل Wildcards يسمح SQL باستخدام محارف البدل wildcard. وهي مفيدة عندما تحاول العثور على مُدخل محدّد في جدول، ولكنك لا تكون متأكدًا تماماً من هذا المُدخل. تعتبر علامات النجمة (*) عناصر بديلة لتمثيل "الكل"، حيث تقوم بالاستعلام كل الأعمدة في جدول: mysql> SELECT * FROM table; تمثل علامات النسبة المئوية (٪) صفراً أو أكثر من محارف غير معروفة. mysql> SELECT * FROM table WHERE column LIKE val%; يُستخدم التسطير السفلي (_) لتمثيل محرف واحد غير معروف: mysql> SELECT * FROM table WHERE column LIKE v_lue; حساب المُدخلات في عمود تُستخدم الدّالة COUNT لإيجاد عدد الإدخالات في عمود محدّد. ستُرجع الصياغة التالية إجمالي عدد القيم الموجودة في column: mysql> SELECT COUNT(column) FROM table; يمكنك تضييق نتائج دالة COUNT من خلال إضافة عبارة WHERE، كما يلي: mysql> SELECT COUNT(column) FROM table WHERE column=value; إيجاد قيمة المعدل في عمود تُستخدم الدّالة AVG لإيجاد المعدل بين القيم الموجودة في عمود محدّد. لاحظ أن دالة AVG ستعمل فقط مع الأعمدة التي تحتوي على قيم رقميّة. وقد تُعيد خطأ أو 0 عند استخدامها على عمود يحمل قيم نصيّة: mysql> SELECT AVG(column) FROM table; إيجاد مجموع القيم في عمود تُستخدم الدّالة SUM لإجمالي مجموع القيم الرقميّة الموجودة في عمود: mysql> SELECT SUM(column) FROM table; كما هو الحال مع دالة AVG، إذا نَفّذتَ الدالة SUM على عمود يحوي قيم نصيّة، فقد تُعيد خطأ أو فقط 0، وذلك اعتمادًا على نظام إدارة قواعد البيانات العلائقية خاصتك. إيجاد القيمة الكبرى في عمود استخدم دالة MAX للعثور على أكبر قيمة رقميّة في عمود أو القيمة الأخيرة أبجديًا : mysql> SELECT MAX(column) FROM table; إيجاد القيمة الصغرى في عمود استخدم الدّالة MIN للعثور على أصغر قيمة رقميّة في عمود أو القيمة الأولى أبجديًا: mysql> SELECT MIN(column) FROM table; فرز النتائج باستخدام عبارات ORDER BY تُستخدم عبارة ORDER BY لفرز نتائج الاستعلام. تُعيد الصياغة التالية للاستعلام القيم من column_1 و column_2 وتُرتّب النتائج حسب القيم الموجودة في column_1 بترتيب تصاعدي، أو بترتيب أبجدي بالنسبة لقيم السلاسل النصيّة: mysql> SELECT column_1, column_2 FROM table ORDER BY column_1; أتبع الاستعلام بـ DESC لتنفيذ نفس الإجراء، ولكن مع ترتيب النتائج بترتيب أبجدي تنازلي: mysql> SELECT column_1, column_2 FROM table ORDER BY column_1 DESC; فرز النتائج باستخدام عبارات GROUP BY تشبه عبارة GROUP BY عبارة ORDER BY، ولكنها تُستخدم لفرز نتائج استعلام يتضمن دالة مُجمِّعة مثل COUNT أو MAX أو MIN أو SUM. ستؤدي الدوال التجميعيّة الموضّحة في القسم السابق بمفردها إلى إرجاع قيمة واحدة فقط. ويمكنك مع ذلك عرض نتائج دالة التجميع المنفّذة على كل قيمة مطابقة في العمود من خلال تضمين عبارة GROUP BY. ستَحسب الصياغة التالية عدد القيم المطابقة في column_2 وتُجمّعها بترتيب تصاعدي أو أبجدي: mysql> SELECT COUNT(column_1), column_2 FROM table GROUP BY column_2; أتبِعْ الاستعلام بـ DESC لتنفيذ نفس الإجراء، ولكن بتجميع النتائج بالترتيب الأبجدي التنازلي: mysql> SELECT COUNT(column_1), column_2 FROM table GROUP BY column_2 DESC; الاستعلام عن جداول متعددة مع عبارات JOIN تستخدم عبارات JOIN لإنشاء مجموعات نتائج تجمع بين صفوف من جدولين أو أكثر. لن تعمل عبارات JOIN إلا إذا كان لكل من الجدولين عمود له اسم ونوع بيانات متطابقان، كما في هذا المثال: mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 JOIN table_2 ON table_1.common_column=table_2.common_column; هذا مثال على عبارة INNER JOIN. ستقوم INNER JOIN بإرجاع جميع السجلات التي تحتوي على قيم متطابقة في كلا الجدولين، ولكنها لن تعرض أي سجلات لا تحتوي على قيم متطابقة. من الممكن إرجاع كافة السجلات من أحد الجدولين، بما في ذلك القيم التي لا تحتوي على مطابق في الجدول الآخر، وذلك باستخدام عبارة JOIN خارجيّة. تُكتب عبارات JOIN الخارجية إما كـ LEFT JOIN أو RIGHT JOIN. تُرجع عبارة LEFT JOIN كافة السجلات من الجدول "الأيسر" والسجلات المطابقة فقط من الجدول "اليمين". في سياق عبارة JOIN الخارجيّة، يكون الجدول الأيسر هو المشار إليه في جملة FROM، والجدول الأيمن هو أي جدول آخر مشار إليه بعد عبارة JOIN. سيَعرض الاستعلام التالي كل سجل من table_1 وفقط القيم المطابقة من table_2. ستظهر القيم غير المطابقة في table2 كـ NULL في مجموعة النتائج: mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 LEFT JOIN table_2 ON table_1.common_column=table_2.common_column; إن وظيفة عبارة RIGHT JOIN مماثلة لـ LEFT JOIN، ولكنها تُرجع جميع النتائج من الجدول الأيمن، والقيم المطابقة فقط من الجدول الأيسر: mysql> SELECT table_1.column_1, table_2.column_2 FROM table_1 RIGHT JOIN table_2 ON table_1.common_column=table_2.common_column; دمج تعليمات SELECT متعددة باستخدام عبارات UNION يفيد مُعامل UNION في دمج نتائج تعليمتي SELECT (أو أكثر) في مجموعة نتائج واحدة: mysql> SELECT column_1 FROM table UNION SELECT column_2 FROM table; يمكن بالإضافة إلى ذلك أن تجمع عبارة UNION بين تعليمتي SELECT (أو أكثر) والتي تستعلم عن جداول مختلفة في نفس مجموعة النتائج: mysql> SELECT column FROM table_1 UNION SELECT column FROM table_2; الخلاصة يغطي هذا الدليل بعضًا من الأوامر الأكثر شيوعًا في SQL المُستخدمة لإدارة قواعد البيانات، والمستخدمين، والجداول، والاستعلام عن المحتويات الموجودة في هذه الجداول. ومع ذلك، هناك العديد من تجميعات العبارات والمعاملات والتي تنتج جميعها مجموعات فريدة من النتائج. إذا كنت تبحث عن دليل أكثر شموليّة للعمل مع SQL، فإنّنا نُشجعك على مراجعة Oracle's Database SQL Reference بالإضافة إلى ذلك، إذا كانت هناك أوامر SQL شائعة ترغب في رؤيتها في هذا الدليل، فيرجى طرحها أو تقديم اقتراحات في التعليقات أدناه. ترجمة بتصرّف للمقال How To Manage an SQL Database لصاحبه Mark Drake

مقدمة تقدم المواقع والتطبيقات الحديثة في كثير من الأحيان كميّة كبيرة من المحتوى الثابت static content للمستخدمين النهائيين. يتضمن هذا المحتوى الصور، وأوراق الأنماط stylesheets، والجافا سكربت والفيديو. حيث يزداد استخدام عرض الحزمة bandwidth ويزداد زمن تحميل الصفحة مع زيادة حجم وعدد هذه الأصول الثابتة، مما يؤدي إلى تدني عملية التصفح لزبائنك وتقليص السعة المتاحة لخوادمك. يمكنك تنفيذ CDN أو شبكة تسليم المحتوى لتخزين هذه الأصول مؤقتًا عبر مجموعة من الخوادم الموزّعة جغرافيًا لتقليل زمن تحميل الصفحة بشكل كبير، وتحسين الأداء، وتقليل تكاليف عرض الحزمة bandwidth والبنية التحتيّة. سنقدّم في هذه الدورة التعليمية نظرة عامّة عالية المستوى على شبكات CDN وكيفيّة عملها، فضلاً عن الفوائد التي يمكن أن توفّرها لتطبيقات الويب الخاصّة بك. ما هي CDN ؟ شبكات تسليم المحتوى (Content Delivery Networks) هي عبارة عن مجموعة خوادم موزّعة جغرافيًا حُسّنت لتقديم المحتوى الثابت للمستخدمين النهائيين. يمكن أن يكون هذا المحتوى الثابت أي نوع من أنواع البيانات تقريبًا، ولكن تُستخدم شبكات CDN بشكل أكثر شيوعًا لتسليم صفحات الويب والملفات المرتبطة بها، وتدفقات الفيديو والصوت، وحزم البرامج الكبيرة. تتكون CDN من نقاط تواجد متعددة PoPs) points of presence) في مواقع مختلفة، يتألف كل منها من عدّة خوادم طرفيّة ‎.edge servers تخزّن هذه الخوادم الأصول مؤقتًا من ملفاتك الأصليّة، أو من خادم مضيف. وعندما يزور أحد المستخدمين موقعك ويطلب أصولًا ثابتةً كالصور أو ملفات جافا سكربت، ستُوجّه طلباته بواسطة شبكة CDN إلى أقرب خادم طرفي edge server موجود، والذي سيُعرض المحتوى منه. إذا لم يكن لدى الخادم الطرفي الأصول المخزنة وقتيّا أو كانت صلاحيتها منتهية، فسيجلب CDN النسخة الأخيرة من خادم طرفي CDN آخر قريب أو من خوادم الأصل الخاصّة بك وتخزينها مؤقتًا. وستُرجع النسخة المخزّنة إلى المستخدم النهائي إذا كانت طرفيّة CDN تحتوي على إدخالات مخبأة لهذه الأصول (والذي يحدث في معظم الأوقات عندما يستقبل موقعك كمية معتدلة من الزيارات). يسمح ذلك للمستخدمين المتوزعين جغرافيًا بتقليل عدد القفزات اللازمة لاستلام المحتوى الثابت، وجلب المحتوى مباشرة من النسخة المخزّنة للخادم الطرفي المجاور. والنتيجة هي تقليل كبير لزمن الاستجابة ولفقد الحزم، وتسريع أوقات تحميل الصفحات، وتخفيض كبير للتحميل على البنية التحتيّة الأصليّة. غالبًا ما يقدم مزوِّدو خدمات شبكات CDN ميّزات إضافية مثل تخفيف معدل هجمات DDoS، والإحصائيات الخاصّة بالمستخدمين، والتحسينات المتعلّقة بالتدفق أو بحالات الاستخدام المتنقل بتكلفة اضافية. كيف تعمل CDN؟ عندما يزور أحد المستخدمين موقعك على الويب، فإنّه يتلقى أولاً استجابةً من خادم DNS يحتوي على عنوان IP لخادم الويب المضيف. ثم يطلب متصفحهم محتوى صفحة الويب، والذي يتكون غالبًا من مجموعة متنوعة من الملفات الثابتة، مثل صفحات HTML، وأوراق الأنماط المتتالية CSS، وشفرات جافا سكربت، والصور. بمجرد طرح CDN وتفويض هذه الأصول الثابتة إلى خوادم CDN، إمّا عن طريق "دفعها" يدويًا أو جعل CDN "يسحب" الأصول تلقائيًا (كلا الآلتين مشروحتان في القسم التالي)، فأنت عندها توجّه خادم الويب الخاص بك لإعادة كتابة روابط links المحتوى الثابت بحيث تشير هذه الارتباطات إلى الملفات المستضافة بواسطة CDN. بإمكانك إذا كنت تستخدم نظام إدارة محتوى مثل WordPress، تنفيذ إعادة كتابة هذا الارتباط باستخدام إضافات الطرف الثالث third-party plugin مثل CDN Enabler. توفّر العديد من شبكات CDN الدعم للنطاقات المخصّصة custom domains، مما يسمح لك بإنشاء سجل CNAME تحت النطاق الخاص بك للإشارة إلى نقطة نهاية CDN. عندما يتلقى CDN طلب مستخدم عند نقطة النهاية هذه (الموجودة على الطرفيّة ، والأقرب إلى المستخدم من خوادمك الخلفية backend servers، فإنّه يُوجّه الطلب إلى نقطة التواجد (PoP) الأقرب إلى المستخدم. غالبًا ما يتكون PoP هذا من واحد أو أكثر من خوادم طرفيّة CDN مجمّعة في نقطة تبادل الإنترنت (IxP)، وهي في الأساس مركز البيانات الذي يستخدمه مزودي خدمة الإنترنت (ISP) لربط شبكاتهم. يقوم موازن الحمل الداخلي الخاص بـ CDN بتوجيه الطلب إلى خادم طرفي موجود في نقطة التواجد، والذي يقدّم بدوره المحتوى إلى المستخدم. تختلف آليات التخزين المؤقت Caching عبر مزودي خدمات CDN، ولكنها تعمل بشكل عام كما يلي: 1- عندما يتلقى CDN طلبًا لأصل ثابت للمرة الأولى، مثلا صورة PNG، وهو لا يحتوي على نسخة مخبأة من هذا الأصل فيتوجب عليه جلب نسخة من الأصل من خادم طرفي CDN قريب أو من الخادم الأصلي نفسه. يُعرف هذا بفقدان البيانات من ذاكرة التخزين المؤقت " Cache miss"، ويمكن عادةً اكتشافه عن طريق فحص ترويسة header استجابة HTTP، الذي يحتوي على X-Cache: MISS. سيكون هذا الطلب في المرّة الأولى أبطأ من الطلبات المستقبلية له لأن هذا الأصل سيخزّن كنسخة مخبأة على خادم طرفي بعد إكمال هذا الطلب. 2- سيتم الآن تخديم الطلبات المستقبلية لهذا الأصل (المخبأ)، الموجهة إلى موقع الطرفيّة هذا من النسخة المخبأة حتى انتهاء صلاحيتها (عادةً ما تُضبط من خلال HTTP headers ). وستكون هذه الاستجابات أسرع بشكل كبير من الطلب الأول، مما يقلّل وقت الاستجابة بشكل كبير للمستخدمين ويقلّل حركة مرور البيانات traffic إلى شبكة CDN. يمكنك التحقق من أن الاستجابة قد تم عرضها من ذاكرة التخزين المؤقت لـ CDN من خلال فحص ترويسة استجابة الـ HTTP، والذي يجب أن يحتوي الآن على X-Cache: HIT. راجع توثيق مزود CDN الخاص بك لمعرفة المزيد حول كيفية عمل وتنفيذ شبكة CDN محدّدة. سنقدم في القسم التالي نوعين شائعين من شبكات CDN: شبكات "دفع" و "سحب" CDN. مناطق الدفع مقابل مناطق السحب يوفر أغلب مزودي خدمة CDN طريقتين لتخزين بياناتك: مناطق السحب ومناطق الدفع. تنطوي مناطق السحب على إدخال عنوان خادمك الأصلي، والسماح لـ CDN تلقائيًا بجلب وعمل نسخة مخزّنة لجميع الموارد الثابتة المتوفرة على موقعك. تُستخدم مناطق السحب بشكل عام لتسليم "توفير" التحديثات المتكررة، وأصول الويب الصغيرة إلى متوسطة الحجم مثل ملفات HTML وCSS وجافا سكربت. بعد تزويد الـ CDN بعنوان الخادم الأصلي "المصدر"، فإنّ الخطوة التالية هي عادة إعادة كتابة الروابط links إلى الأصول الثابتة بحيث تشير الآن إلى عنوان URL المقدّم من شبكة CDN. ستتعامل شبكة CDN من الآن فصاعدًا مع طلبات الأصول الواردة للمستخدمين وستعرض المحتوى من ذاكرات التخزين المؤقت "النسخ المخبأة" الموزّعة جغرافيًا ومن الأصل عندما يكون ذلك مناسبًا. لاستخدام منطقة الدفع، حمّل بياناتك إلى خانة معيّنة أو موضع تخزين (bucket )، والتي تنقلها شبكات CDN للتخزين المؤقت على أسطول fleet الخوادم الطرفيّة المتوزعة. تُستخدم مناطق الدفع عادةً من أجل الملفات الأكبر حجمًا والقليلة التغيّر، مثل الأرشيفات، وحزم البرمجيات، وملفات الكتب الإلكترونية PDF، وملفات الفيديو والملفات الصوتية. فوائد استخدام CDN يمكن لأي موقع تقريبًا الاستفادة من الفوائد التي يوفرها توزع CDN، ولكن عادةً ما تكون الأسباب الأساسيّة للتنفيذ واحدة وهي لتخفيف استخدام عرض الحزمة بين خوادم الأصل الخاصّة بك وخوادم CDN، ولتقليل زمن الاستجابة للمستخدمين الموزعين جغرافيًا. سنستعرض هذا أدناه إضافة إلى العديد من الفوائد الرئيسيّة الأخرى المتاحة باستخدام CDN. تخفيف الحمل عن الأصل Origin Offload إذا كنت تقترب من استخدام كامل سعة عرض الحزمة على خوادمك، فسيُنقَل تخديم الأصول الثابتة كالصور، ومقاطع الفيديو، وملفات CSS وجافا سكريبت، مما يؤدي إلى تقليل استخدام عرض الحزمة للخوادم بشكل كبير. حيث صُمّمت شبكات تسليم المحتوى وحُسّنت لتخديم المحتوى الثابت، وستوجَّه طلبات العميل لهذا المحتوى إلى خوادم Edge CDN وتخدّم منها. ولهذا فائدة إضافية تتمثل في تقليل الحمل على خوادم الأصل الخاصّة بك، حيث ستُخدّم هذه البيانات بعدها بتكرار أقل بكثير. زمن استجابة أقل لتحسين تجربة المستخدم يمكن لـ CDN تقليل التأخير إذا كان المستخدمين لديك موزعين جغرافيًا، وكان جزء كبير من حركة مرور البيانات traffic الخاصّة بك يأتي من منطقة جغرافيّة بعيدة وذلك عن طريق التخزين المؤقت لأصول ثابتة على خوادم طرفيّة أقرب إلى هؤلاء المستخدمين. يمكنك من خلال تقليل المسافة بين المستخدمين والمحتوى الثابت، تقديم محتوى للمستخدمين بسرعة أكبر وتحسين تجربتهم بزيادة سرعات تحميل الصفحات. تتضاعف هذه الفوائد بالنسبة إلى مواقع الويب التي تُخدّم في المقام الأول محتوى الفيديو المستهلك لعرض الحزمة، حيث يؤدي التأخير المرتفع وأوقات التحميل البطيئة إلى التأثير بشكل مباشر على تجربة المستخدم وترابط المحتوى. إدارة الموجات الكبيرة لحركة مرور البيانات وتجنب التوقف تسمح لك شبكات CDN بالتعامل مع الموجات المروريّة الكبيرة والتدفقات الفائضة bursts من خلال طلبات موازنة الحمل load عبر شبكة كبيرة موزّعة من خوادم طرفيّة. يمكنك استيعاب عدد أكبر من المستخدمين المتزامنين في البنية التحتيّة المتواجدة من خلال إلغاء التحميل offloading عن الأصل والتخزين المؤقت للمحتوى الثابت في شبكة التسليم. يمكن أن تؤدي هذه الموجة الكبيرة في حركة مرور البيانات في مواقع الويب التي تستخدم خادمًا واحدًا إلى إغراق overwhelm النظام، مما يؤدي إلى حدوث انقطاع غير متوقع وتوقف عن العمل. تؤدي عملية نقل الحمل الى شبكات CDN ذات البنية العالية التوافريّة والمتاحّية والمخصّصة للتعامل مع مستويات متعددة من حمل الإنترنت، إلى زيادة توافرية أصولك ومحتوياتك. خفض التكاليف نظرًا لأن المحتوى الثابت يمثل غالبًا معظم استخدام عرض الحزمة، يمكن أن يؤدي تفويض هذه الأصول إلى شبكة تسليم المحتوى إلى تقليل الإنفاق على البنية التحتيّة بشكل كبير. بالإضافة إلى خفض تكاليف عرض الحزمة. يمكن أن تقلل شبكة CDN تكاليف الخادم من خلال تقليل الحمل على خوادم الأصل، مما يمكّن البنية التحتيّة الحالية الخاصّة بك من التوسع. أخيرًا، يقدم بعض مزودي خدمات شبكات CDN فواتير شهرية محدّدة السعر، مما يسمح لك بتحويل استخدامك الشهري المتغيّر لعرض الحزمة إلى إنفاق متكرر ولكن متوقع. زيادة الأمن هناك حالة استخدام شائعة أخرى لـ CDNs وهي التخفيف من هجمات حجب الخدمة DDoS. يُضمّن العديد من موفري خدمات CDN ميزات لمراقبة وتصفية الطلبات على خوادم الحافّة. تقوم هذه الخدمات بتحليل حركة مرور البيانات على شبكة الإنترنت بحثًا عن الأنماط المشبوهة، ومنع حركة المرور الهجوميّة الضارّة بينما تستمر في السماح بمرور الـ trafffic الخاص بالمستخدم النظامي. عادةً ما يقدّم موفرو خدمات CDN مجموعة متنوعة من خدمات التخفيف من هجمات DDoS، بدءًا من الحماية من الهجمات الشائعة على مستوى البنية التحتيّة الأساسيّة (طبقات OSI 3 و 4)، إلى خدمات التخفيف والحد من المعدل الأكثر تقدمًا. تسمح لك معظم شبكات CDN بالإضافة إلى ذلك بتكوين كامل لبروتوكول SSL Secure Sockets Layer configure full SSL، بحيث يمكنك تشفير حركة مرور البيانات بين CDN والمستخدم النهائي، بالإضافة إلى تشفير حركة المرور بين CDN وخوادم الأصل الخاصّة بك، إما باستخدام شهادات CDN أو شهادات SSL المخصّصة. اختيار الحل الأفضل إذا كانت الغاية هي حمل وحدة المعالجة المركزية CPU على الخادم المصدر، وليس عرض الحزمة، فقد لا يكون CDN هو الحل الأنسب. قد يؤدي التخزين المؤقت المحلي local caching في هذه الحالة باستخدام وسائل التخزين الشهيرة مثل NGINX أو Varnish إلى تقليل الحمل بشكل كبير من خلال تخديم الأصول من ذاكرة النظام. قبل طرح CDN، يمكن لخطوات التحسين الإضافية - مثل تقليل وضغط ملفات JavaScript وCSS، وتمكين ضغط طلب HTTP لخادم الويب - أن يكون لها تأثيرُا كبيرًا على أوقات تحميل الصفحة واستخدام عرض الحزمة. تعتبر أداة google لتحليل سرعة الصفحات أداةً مفيدةً لقياس سرعة تحميل صفحتك وتحسينها. ويعتبرPingdom من بين الأدوات المفيدة الأخرى التي توفر تخفيضًا كبيرًا لأوقات الطلب والاستجابة إلى جانب التحسينات المقترحة. الخلاصة يمكن أن تشّكل شبكات تسليم المحتوى حلاً سريعًا وفعالًا لتحسين قابلية التوسّع وإتاحيّة مواقع الويب الخاصّة بك. يمكنك من خلال التخزين المؤقت لأصول ثابتة على شبكة موزّعة جغرافيًا من الخوادم المحسّنة تقليل أوقات تحميل الصفحات ووقت الاستجابة للمستخدمين بشكل كبير. إضافة إلى ذلك، تسمح لك شبكات CDN بتقليل استخدام عرض الحزمة بشكل كبير من خلال استيعاب طلبات المستخدمين والاستجابة لهم من ذاكرة التخزين المؤقت في الخادم الطرفي، وبالتالي تقليل تكاليف عرض الحزمة والبنية التحتيّة. يمكن لشبكات CDN باستخدام الإضافات plugin ودعم الطرف الثالث Support Third-party لمنصّات إدارة المحتوى الرئيسيّة مثل WordPress و Drupal و Django و Ruby on Rails، بالإضافة إلى الميزات الإضافيّة مثل DDoS mitigation و SSL الكامل ومراقبة المستخدمين وضغط الأصول "المحتوى"، يمكنها أن تكون أداةً مؤثرةً في تحسين مواقع الويب ذات المعدّلات العالية لحركة مرور البيانات. ترجمة وبتصرّف للمقال Using a CDN to Speed Up Static Content Delivery لصاحبه Hanif Jetha.

مقدّمة إنّ TaskBoard أو "لوح المهام" هو برمجيّة مجانيّة ومفتوحة المصدر، مستوحاة من ألواح Kanban لتتبُع المهام. وألواح Kanban هي تقنية لإظهار تدفق العمل وتنظيم المشاريع. وخاصّةً في مجال تطوير البرمجيات، فهي توفّر نظامًا مرئيًّا لإدارة العمليّات للمساعدة في تحديد كيفيّة تنظيم الإنتاج. تجعل هذا البرمجيّة التتبع البصري لتطوّر مشاريعك سهلًا كما يظهر في الصورة. ميزات TaskBoard: حرّة، ومفتوحة المصدر (رخصة MIT)، وذاتيّة الاستضافة سهلة التثبيت ألواح (مشاريع) غير محدودة تخصيص الأعمدة داخل الألواح وتوسيع / تصغير مستمر من أجل كل مستخدم تسمح العناصر بالألوان المخصّصة، والتصنيفات، وتنسيق التوصيفات، والمرفقات، والتعليقات تعرض العناصر تاريخًا كاملًا "أرشيف" للأنشطة activities تعرض للمشرفين التاريخ الكامل لجميع أنشطة الألواح سهلة التخصيص تتيح إدارة أوليّة للمستخدمين (المشرف، والمستخدمين العاديين) لا وجود لتبعيّات خارجيّة إنشاء لقاعدة بيانات SQLite عند الاستخدام الأول واجهة برمجيّة RESTful API) RESTful) تبعيّات محدودة جدًا ستشرح هذه الدورة التعليميّة كيفيّة تثبيتها على CentOS 7. تثبيت خادم الويب Apache ثبّت في البداية Apache على جهاز CentOS 7 من خلال تنفيذ الأمر التالي: # yum install httpd شغّل Apache ومكّنه من التشغيل في وقت الإقلاع وذلك بمجرد انتهائك من التثبيت: # systemctl start httpd # systemctl enable httpd تثبيت PHP يجب تثبيت php باعتبار أن TaskBoard مكتوبة بهذه اللغة. ونظرًا لأنّها تتطلب الإصدار PHP الخامس أو أكثر، فسنثبّت PHP7 باستخدام مستودع Webtatic. أولاً، ثَبّت مستودع EPEL المطلوب من قبل Webtatic: # yum install epel-release حدّث: # yum install epel-release بالإمكان الآن تثبيت مستودع Webtatic عن طريق تنفيذ الأوامر التالية: # rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm # yum update ثبّت PHP 7.1 والإضافات التي تتطلبها TaskBoard وذلك بمجرّد أن يصبح المستودع جاهزًا ويصبح بالإمكان لـ yum استخدامه: # yum install php71w php71w-gd php71w-json php71-readline php71w-cli php71w-sqlite3 تثبيت SQLite يستخدم TaskBoard الـ SQLite كقاعدة بيانات، مما يعني أنه بإمكاننا استخدامه دون الحاجة إلى تثبيت MySQL أو أيّة قواعد بيانات "كبيرة" أخرى. يمكن تثبيت SQLite باستخدام أمر yum التالي: # yum install sqlite تثبيت TaskBoard إنّ تثبيت TaskBoard سهلٌ للغاية، كما هو متوقع من قائمة الميزات المطوّلة المعروضة في التمهيد. يتطلب الأمر في الواقع فقط تنزيل واستخراج أرشيف TaskBoard. انتقل إلى المسار الجذر للويب في Apache: # cd /var/www نزّل الأرشيف هنا: # wget https://github.com/kiswa/TaskBoard/archive/master.zip فُك ضغطه: # unzip master.zip سيستَخرج unzip الأرشيف إلى دليل يدعى TaskBoard-master. يمكنك إعادة تسميته (اختياري): # mv TaskBoard-master taskboard ثبّت الملحقات المطلوبة بواسطة Composer: ./taskboard/build/composer.phar install ثم غيّر مالك taskboard إلى مستخدم apache: # chown -R apache:apache /var/www/taskboard إنشاء مضيف افتراضي Virtual Host أنشئ ملف مضيف افتراضي جديد لـ TaskBoard: # $EDITOR /etc/httpd/conf.d/board.example.com.conf ثم الصق المحتوى التالي في هذا الملف: <VirtualHost *:80> ServerAdmin admin@example.com DocumentRoot "/var/www/taskboard" ServerName board.example.com ServerAlias www.board.example.com <Directory "/var/www/taskboard"> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog "/var/log/httpd/board.example.com-error_log" CustomLog "/var/log/httpd/board.example.com-access_log" combined </VirtualHost> أعد تشغيل Apache: # systemctl restart httpd إنهاء التثبيت للقيام بالخطوة الأخيرة لإنهاء التثبيت من خلال متصفح الويب، انتقل إلى عنوان الـ URL: http://board.example.com سجّل الدخول مستخدمًا كلمة admin في كل من اسم المستخدم وكلمة المرور على حد سواء. ثم غيّر كلمة مرور المسؤول administrator بعد تسجيلك للدخول مباشرةً وذلك بالانتقال إلى صفحة الإعدادات Settings. الخلاصة رأينا كيفيّة تثبيت TaskBoard على CentOS 7. سيُساعد بالتأكيد هذا التطبيق المعتمد على Kanban العديد من النّاس في تنظيم سير عمل مشاريعهم. ترجمة وبتصرّف للمقال TaskBoard: Kanban-based Software on CentOS 7 لصاحبه Giuseppe Molica.