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

اقتباس

ما الفرق بين الشركات التي تُوفّر خدمات الاستضافة لمواقع الويب؟ وما الفرق بين الشركات التي تَتّسِم بالتقليدية في بعض الأحيان مثل GoDaddy وHostgator، وبين الشركات الأخرى مثل Heroku وDigital Ocean وAWS وFirebase؟ وكيف أختار الاستضافة المناسبة لموقعي؟

وكانت إجاباته على النحو التالي.

اختيار الباقة المناسبة

لقد ذكرت غودادي GoDaddy أولاً، ولذلك سنبدأ بالحديث عنه؛

سنحاول تقديم معلوماتٍ مفيدةٍ بعد قليلٍ، وسنبدأ بالسؤال الآتي، لماذا نلاحظ أنّ استضافة ووردبريس WordPress أغلى من الاستضافة العادية والتي قد تَبلُغ دولارًا واحدًا في بعض الأحيان؟ وهل تستطيع تثبيت ووردبريس WordPress لو اشتريتَ استضافة ويبٍ بقيمة 5.99 دولارٍ أمريكيٍ؟ أم أن الأنسب اختيار استضافة ووردبريس WordPress مُهيّأةٍ ومُعدّةٍ مُسبقًا؟ وإذا كان ووكوميرس WooCommerce إضافةً plugin تعمل على ووردبريس WordPress، فهل ستستطيع تثبيتها في حال لم تكن الحزمة التي اخترتها خاصةً باستضافة التجارة الالكترونيّة؟ ولماذا لا تستطيع استخدام ووكوميرس WooCommerce في ووردبريس WordPress إلا للحزمة الأغلى ثمنًا؟ ولماذا تُعَد باقة استضافة الخادم الافتراضي الخاص VPS هي الأرخص ثمنًا رغم أنها إحدى خدمات الاستضافة التي تُقدّمها غودادي Godaddy؟ لا داعي للقلق، فهذا محير فعلًا.

عمومًا، تربح شركة غودادي GoDaddy مليارات الدولارات سنويًا، ولذا فمن المؤكّد أنهم يفهمون كلّ هذا، ولكنّني شخصيًّا -الكاتب المقال بنسخته الأصلية- أعتمد على التخمين في اختيار باقة الاستضافة المناسبة، ولذلك من الممكن أن تكون هذه الحيرة مقصودةٌ كونها أحد أساليب البيع.

التقنية

ما ندركه هو أن الباقات التي تحتوي على جميع أنظمة إدارة المحتوى الكبيرة مثل باقة لامب LAMP مخصّصةٌ للمواقع التي تعمل بلغة PHP ومواقع MySQL مثل ووردبريس WordPress وكرافت Craft وبيرش Perch وغوست Ghost ودروبال Drupal وجوملا Joomla، وما إلى ذلك، وكذلك هو الحال فيما يتعلّق بالاستضافات مثل ميديا تيمبل Media Temple وهوسغيتور Hostgator وبلوهوست Bluehost وغيرها، ولذلك يُعتَقد أن توصيف شركات الاستضافة هذه بالتقليديّة، صفةٌ مناسبة.

هل تريد تشغيل نظام إدارة البيانات PostgreSQL أو MariaDB بدلاً من MySQL؟ أو تريد العمل مع ASP بدلاً من لغة البرمجة PHP؟ يُزعم أنّ (أغلب) شركات الاستضافة ستجيبك بشيء من هذا القبيل عن كلّ هذه المتطلبّات، إذ ستَقترح عليك استخدام الخادم الافتراضي الخاص VPS والذي يتمتع بوصولٍ مباشرٍ إلى الجذر root، بحيث يمكنك تثبيته بنفسك بدلًا من استخدام الاستضافة المشتركة، وفي الحقيقة، لا يُعتَقَد أن هذا جيدًا بما يكفي، ومن المهم أن تنتبه إلى أنها ليست أفضل الخيارات لأنه من الصعب الحصول على دعمٍ فنيٍ جيدٍ في حال واجهتك مشكلةٌ ما.

وهو ما يقودني إلى وجهة النظر القائلة بوجوب تَتبُّع عروض الطريق السعيد التي تُقدّمها شركات الاستضافة.

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

لا يمكننا ترجيح هيروكو Heroku لأنني لم أستخدمها من قبل، ولكننا نسمع الكثير من الآراء الإيجابية مِمّن يستخدمونها منذ 15 عامًا.

تُذكّرنا هيروكو بوجود فجوةٍ أخرى مهمّةٍ بين شركات الاستضافة، وهي أنّ شركات استضافة الويب التقليديّة لا تساعدك في نَشْر موقعك، وإنما تعطيك بيانات اعتماد بروتوكول نَقْل الملفات FTP فحسب، ثُم تقول لك حظًّا سعيدً؛ أما بالنسبة لشركات الاستضافةٍ مثل هيروكو Heroku، فهي تقدّم لك واجهة سطر الأوامر مع أوامرٍ مساعدةٍ مثل heroku container:push، والتي تمكّنك من نشر الكود المحلي الخاص بك في الموقع مباشرةً، بل وتقدّم لك ما هو أفضل من ذلك، إذ تساعدك هيروكو Heroku على نشر الموقع مباشرةً من مستودع غيت هاب GitHub، فلماذا لا تَفعَل شركات الاستضافة كلّها هذا؟ يا له من لغزٍ بالنسبة لي، وذلك لأنّ المُضيف الذي يساعدك في النّشْر هو مضيفٌ لا يُقدّر بثمنٍ.

حتى كُنا نتحدث عن الطرق السعيدة، وتُطلِق هيروكو على نفسها اسم منصة التطبيقات السحابية، أي أنّ الطريق السعيد في هيروكو هي لغات المُخدّم مثل نود Node وروبي Ruby وبايثون Python وجو Go، ولكن ماذا لو لم تكن بحاجةٍ لأي من ذلك؟ فلنفترض أنك ستُنشِئ موقعًا ثابتًا باستخدام أداةٍ خاصّةٍ بإنشاء المواقع الثابتة مثل إيليفينتي Eleventy، أي مواقع جامستاك Jamstack، فهل يُفضّل اختيار هيروكو Heroku عندها؟ طبعًا لا، فهيروكو هنا ليست الحل الأمثل، فعلى الرغم من عمل الموقع عليها بصورةٍ جيدةٍ، إلا أن استضافة المواقع الثابتة ليست جَوهَر هيروكو، وبالتالي فهي ليست طريقًا سعيدًا.

إذًا أين يُفضّل أن تستضيف موقعًا ثابتًا؟ الإجابة هنا هي أن نيتليفاي Netlify أفضل بكلّ تأكيد، فهذا هو اختصاصها، وهي الطريق الأسعد للمواقع الثابتة.

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

أما جامستاك Jamstack، فهي للاستضافة الثابتة بالإضافة إلى الخدمات الأخرى، وتُتاح في الكثير من الأماكن الآن. تحتوي كلاودفلير Cloudflare على كلاودفلير بيجز Cloudflare Pages، وهي خدمةٌ يمكنك الاستفادة منها عن طريق استخدام العروض غير المحدودة مثل استضافة عددٍ غير محدودٍ من المواقع غير المحدودة، والطلبات غير المحدودة، والسّعات غير المحدودة، وخدمة عددٍ غير محدودٍ من أفراد الفِرق البرمجيّة.

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

كما تمتلك فيرسيل Vercel استضافة جامستاك Jamstack كذلك، وستقدّم لك مُخدّماتٍ إذا كنت تحتاجها، حيث إن إطار عملها نيكست جافاسكربت Next.js وصفحاتها مُجّهزةٌ مُسبقًا، كما أنها تُقدّم صفحاتٍ من جانب المُخدمّ بلغة البرمجة نود Node، فتعطيك فيرسيل Vercel لغة الواجهة الخلفيّة back end كذلك.

أي أن إطار العمل نيكست جافا سكربت Next.js هو الطريق السعيد بالنسبة لاستضافة فيرسيل Vercel، فهو يدعم النّشْر على النظام الأساسي المُصمّم للإطار Next.js، ومن الصعب التَغلّب على ذلك.

تمتلك استضافة AWS Amplify كذلك استضافة جامستاك Jamstack، والطريق السعيد هنا هو استخدام أمبليفاي Amplify لتجميع خدماتٍ مثل AWS خدمات ويب أمازون، فهذا هو الهدف من AWS Amplify.

• هل تحتاج إلى مصادقةٍ؟ أمازون كوغنيتو Amazon Cognito هي من تنجز العمل من وراء الكواليس، بينما يساعد Amplify على ربط المصادقة بعملك الحاليّ.
• هل تحتاج إلى تخزينٍ؟ تُعدّ S3 معيارًا صناعيًّا وسيساعدك Amplify على دمجِه.
• هل تحتاج إلى قاعدة بياناتٍ؟ سيساعدك Amplify على تصميم قاعدة البيانات وبناء واجهات برمجة التطبيقات API.

وتمتلك منصة فايربيس Firebase استضافة على غرار Jamstack، والطريق السعيد هنا هو في الغالب إطار العمل Firebase.

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

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

يجب أن يعتني مضيفك باحتياجاتك الأساسية

هل تتذكر عندما قلنا من قبل أن المُضيف الذي يساعدك في النشر مُضيفٌ قيّمٌ جدًا؟ إليك الأخبار الجيّدة، سيساعدك بالنشر كلٌ من نيتليفاي Netlify وفيرسيل Verce و AWS Amplify وغوغل فايربيس Google Firebase وكلاودفير بيجز Cloudflare Pages وآزور Azure للصفحات الثابتة، فلقد أصبحت هذه أقلّ ما يمكن أن يقدّمه المُضيفون، كما توجد هناك المزيد من الخدمات الأخرى.

وفيما يلي الخدمات الأساسيّة لكل المُضيفات الحديثة بالإضافة إلى استضافة المواقع بالطبع.

1. HTTPS: إذ يجب على المُضيف منح موقعي شهادة SSL تلقائيًا أو حتى مجانًا، وذلك نظرًا لأن خدمة Let’s Encrypt مجانيّة، فهي تُوفّر شهادات أمانٍ مجّانًا.
2. CDN: وهي شبكة توصيل المحتوى، حيث يجب أن يساعد المُضيف في تخديم موقعي بالإضافة إلى خدمات توصيل المحتوى، حتى لو كانت ميزةً مدفوعةً أو تتطلب التهيئة المُسبقة.
3. Deployment: وهو النشر، حيث يجب على المُضيف الاتصال بمستودعات غيت Git، ونقل الملفات من المستودع الرئيسي إلى الموقع المباشر.
4. Staging: فعلى المُضيف توفير بيئاتٍ لتهيئة الملفات للنقل من مرحلة التطوير إلى مرحلة الإنتاج.

وبالعودة إلى ووردبريس WordPress وغيره من أنظمة إدارة المحتوى العاملة بلغات PHP وMySQL، فغالبًا ما تُوفّر المُضيفات التقليديّة استضافة هذه المواقع، حيث يُمثّل ووردبريس 35.2٪ من مواقع الويب، وهذا رقمٌ كبيرٌ جدًا، مما يعني أنه هناك الكثير من الأموال الناتجة عن استضافة ووردبريس WordPress، لكن من واقع الخبرة لكريس كوير Chris Coyier يمكن القول بأن المُضيفين التقليديين لا يُقدّمون أيًّا من الخدمات التي ذُكِرت أعلاه رغم أنّها الخدمات الأساسيّة لكل المُضيفات الحديثة، ففي كثيرٍ من الأحيان قد تضطر إلى استخدام HTTPS ودمج شبكة توصيل المحتوى ونشر الموقع بنفسك، كما سيتوجّب عليك شراء مخدّمٍ آخرٍ لإجراء عملية staging، ومع وجود فجوةٍ واسعةٍ في مُضيفي الويب الحديثة التي تُقدّم ما لا تقدّمه المُضيفات التقليديّة، أصبح مجال الاستضافة غريبٌ جدًا.

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

ديجيتال أوشن Digital Ocean

يقول Chris Coyier:

اقتباس

أشعر أنني غير مؤهلٍ للحديث عن ديجيتال أوشن Digital Ocean، ولكنني أظن أنه يحتوي على الكثير من الطرق السعيدة.

لدى هذه المنصّة مفهوم دروبلت Droplet والترجمة الحرفيّة لهذه الكلمة هي قطرات المياه، ولكنّها في هذا السياق تعني مُخدّم، وهي مكوّنةٌ من حاوياتٍ، أو لنَقُل بأنّها مُخدّماتٌ مُعدةٌ مسبقًا وقادرةٌ على تشغيل جميع أنواع التقنيّات، فإن كنت تريد تشغيل لامب LAMP في Droplet، فسيكون طريقًا سعيدًا، ولكن هناك الكثير من التقنيات الأخرى كذلك. ولنأخذ المثال التالي، فإذا كنت تريد استخدام سترابي Strapi وهو نظام إدارة محتوىً يتكون من نود Node وNginx وPostgreSQL، فتستطيع منصة ديجيتال أوشن Digital Ocean تقديم droplet جاهزةٍ لذلك.

تبدأ أسعار droplets من 5 دولاراتٍ شهريًا، لذا فهي اقتصاديةٌ مثل الاستضافات الأخرى تمامًا إذا لم تكن أكثر منهم، وقد تجد منتجات استضافةٍ متنوعةً في ظاهرها، بينما هي ديجيتال أوشن في حقيقتها. فعلى سبيل المثال، تتيح أداة استضافة SpinupWP إنشاء بيئات استضافة ووردبريس مهيأةً بسرعةٍ ولكنها لا تتكفّل بالاستضافة نفسها لأنّك قد تجلب مضيفك الخاص، والذي قد يكون ديجيتال أوشن أو خدمات ويب أمازون Amazon Web Services واختصارًا AWS.

تعقيد الخدمات المقدمة

وإذا بدا ديجيتال أوشن Digital Ocean معقدًا، فسترى أنّ خدمات ويب أمازون AWS أكثر تعقيدًا، فلقد تحدثنا عن AWS Amplify مسبقًا، فهو يشْبِه AWS المُصمّم للمطورين الأفراد لاستضافة التطبيقات بسرعةٍ، وهو رائعٌ جدًا لكنه جزءٌ صغيرٌ مما يُمثّل AWS.

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

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

مطابقة احتياجاتك مع ما هو متاح

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

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

أسعار الاستضافات

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

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

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

ترجمة -وبتصرف- للمقال The Differences in Web Hosting (Go with the Happy Path) من موقع CSS Tricks.

اقرأ أيضًا

• مساعدة المبتدئين في فهم كيفية رفع الموقع على الإنترنت
• دليل إعداد خادم ويب محلي خطوة بخطوة
• كيفية تثبيت برمجية Jenkins على خادوم أوبنتو 16.04
• كل ما تود معرفته عن السحابة الهجينة Hybrid Cloud

يُستعمل Varnish Cache بكثرة لتخبئة محتوى مواقع الويب لتسريع أداء المواقع وتخفيض الحمولة على الخادوم الأصل (origin-server). لطالما شجعنا على استعمال التّخبئة لتسريع أداء تطبيقات الويب وتسهيل قابلية التوسع (Scalability) وضمان الاستقراريّة إضافة إلى الفوائد الأخرى التي تأتي مع هذه الإجراءات من تحسين لتجربة المُستخدم إلى التوفير في الموارد. لكن رغم ذلك فلا نزال بحاجة إلى التأكيد على أهميّة التّخبئة. وفي بعض الأحيان، قد يعني الأمر شرح كيفيّة استعمال Varnish Cache وما يُميّزه عن بقيّة التقنيات الأخرى.

الأمور الغريبة التي تُميّز Varnish Cache

Varnish Cache عبارة عن خادوم HTTP بنظام HTTP خلفي له قدرة على تقديم الملفّات. يعتمد على هندسة سلسليّة (threaded architecture)، دون حلقة أحداث (event loop). ولأن شيفرة الكتابة قادرة على استعمال استدعاءات النظام الحاصرة (blocking system calls)، فذلك يجعله أسهل استعمالا من Apache أو NGINX، التي يتطلّب استعمالها التعامل مع حلقة أحداث.

يقوم Varnish Cache بالتسجيل (logging) على الذاكرة عوضا عن القرص الصلب، تم تصميمه بهذه الطّريقة لأن تسجيل 10000 من عمليات HTTP كل ثانية على القرص الصلب أمر يتطلب الكثير من الموارد.

يقوم Varnish بتسجيل جميع التّفاصيل (حوالي 200 سطر لكل طلب) على الذاكرة مُباشرة. إن لم يتم طلب التفاصيل المُسجّلة فستتم الكتابة فوقها (overwrite). يعتبر Varnish التطبيق الوحيد الذي يتخذ هذا المسلك.

المرونة: استعمال VCL

الميّزة الكبرى لـ Varnish Cashe هي لغة الضّبط الخاصّة به. تمّ إنشاء لغةVCL (Varnish Configuration Language) منذ أكثر من 11 عاما لتدعم النسخة الأولى من Varnish Cache. على عكس Apache أو بقيّة البرمجيّات، فـVarnish Cache لا يعتمد على إعداد تقليدي.بل يعتمد عوضا عن ذلك على مجموعة من السّياسات التي تُكتب بهذه اللغة. تتم ترجمة هذه السيّاسات إلى شيفرة ثنائية، تُحمّل هذه الشيفرة ويتمّ تشغيلها بعد ذلك.

يقول مهندس Varnish Cache Poul-Henning Kamp بأنVCL أُنشأت لتكون مجموعة أدوات يمكن استعمالها حسب الحاجة، وليس قطعة موحدة يُمكن إضافتها إلى بيئة العمل. في يومنا الحالي، هناك أكثر من 100 وحدة (modules) لـ VCL يمكن استعمالها ببساطة. في الحقيقة، ففي ملتقيات Varnish Summits هناك دائما ورشة عمل لتعليم الأشخاص كيفيّة كتابة وحدات خاصّة.

تعتبر لغة VCL من أكبر الأسباب التي تجعل النّاس تستعمل وتتعلّق بـVarnish Cache. إذ تفتح المرونة التي توفرها اللغة الأبواب للقيام بأي شيء قد يرغب أحدهم بفعله، ما يمحو القيود التي عادة ما تأتي مع البرمجيّات التقليديّة.

إذا، ما هي أهم الأدوات التي توفّرها VCL وكيف يُمكننا الاستفادة منها؟

التنطيف Purging

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

sub vcl_recv {
 if (req.method == "PURGE") {
  return (purge);  } }
إن لم ترغب بتمكين الأشخاص على الأنترنت من تنظيف المحتوى على نظام تخبئتك، فسيتوجب عليك ضبط حدّ الوصول ACL كما يلي:

acl purge {
  "localhost";
  "192.168.55.0"/24;
}
 sub vcl_recv {
 if (req.method == "PURGE") {
  if (!client.ip ~ purge) {
   return(synth(405,"Not allowed."));
   }
  return (purge);  } }

إضافة ميزة لـVarnish Cache: خنق الرّبط السّاخن (Hot linking)

يسمح إطار العمل الخاص بـVarnish للمستخدمين بإضافة أية ميزة يحتاجون إليها. أول ميّزة أضيفت هي استعمال VCL للحد من الرّبط السّاخن. الرّبط السّاخن هو عمليّة سرقة موارد أحدهم على الويب وكتابة مقال يستخدم صورا مرفوعة على خادوم الضّحية ليدفع تكاليف استخدام الموارد. يسمح Varnish للخوادم بإيقاف هذه العملية عند استعمال الرّبط السّاخن للموارد الخاصة بالخادم دون إذن. على سبيل المثال، يمكن لـVarnish وضع سقف لعدد مرّات حدوث هذا الأمر كل ثانيّة عبر استخدام وحدة من وحدات Varnish (VMOD) باسم vsthrottle لإضافة الخنق (throttling). يمكن القيام بالأمر عبر استيراد وتحميل الوحدة. شيفرة VCL أسفله تُوضّح كيفيّة الحدّ من الرّبط السّاخن. في هذا المثال، نقوم بتطبيق ثلاثة قواعد. القاعدة الأولى تتحقّق من أن عنوان URL المطلوب يبدأ بـ/assets/. القاعدتان الثانيّة والثّالثة تحميان مجلّد الملفات السّاكنة من الرّبط السّاخن. يتمّ هذا عبر التحقق ممّا إذا كان المُحيل referrer طرفا غير مُتوقّع، وما إن طلبت أسماء نطاق أخرى ملفّاتك لأكثر من 10 مرّات خلال 60 ثانيّة. ما سبق عبارة عن دالّة الخنق، يُستعمل رابط URL كمفتاح للخنق.الحدّ المسموح به هو 10 مرّات كلّ 60 ثانيّة. يُمكن تقديم الملفات السّاكنة غير المُشار إليها، وعندما يحصل ذلك، فسيتم إرسال خطأ 403 مع منع الربط السّاخن. يُمكن كذلك توسيع الخنق لاستعمال memcache، وذلك ليحصل المستخدم على المُحاسبة الرّئيسيّة (central accounting) في العنقود (cluster).

import vsthrottle;
 (..)
 if (req.url ~
 "^/assets/" &&
 (req.http.referer !~
 "^http://www.example.com/") &&
 vsthrottle.is_denied(req.url, 10, 60s) {
   return(error(403,"Hotlinking prohibited");
}

التّعامل مع ملفات تعريف الارتباط (cookies)

لن يقوم Varnish بتخبئة المحتوى الذي يُطلَبُ باستعمال ملفّات تعريف الارتباط. ولن يستجيب إلى طلب محتوى مخبّأ إن كان الطّلب متعلّقا بملف تعريف ارتباط. عوضا عن هذا، يُمكن استعمال وحدة VMOD لحذف ملفّ تعريف الارتباط. المحترفون يستعملون تعبيرا نمطيّا (regular expression) لترشيح ملفات تعريف الارتباط. ولأنّنا لسنا محترفين، فـVarnish يوفّر وحدة باسم cookie تبدو كما يلي:

import cookie;
sub vcl_recv {
       cookie.parse ("cookie1: value1; cookie2: value2");
       cookie.filter_except("cookie1");
        // get_string() will now yield
       // "cookie1: cookie2: value2;"; }

لا يقوم Varnish بإنشاء ترويسة (header) ملف تعريف ارتباط. وإن رأى بأن النظام الخلفي قد أرسل شيفرة إنشاء ملفّ تعريف ارتباط، فلن يقوم بتخبئته. الحل أن تحذف ترويسة Set-Cookie أو إصلاح الخادوم الخلفي.

• ترويسات Set-Cookie تقوم بتعطيل ملفّات تعريف الارتباط.
• الحلّ: احذف ترويسة Set-Cookie أو أصلح النّظام الخلفيّ.

نمط الإمهال Grace Mode

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

في الوقت الذي تم فيه تقديم Varnish 1.0 كحل لنظام تخبئة لموقع الجريدة النرويجيّة Verdens Gang، كانت هناك مشاكل كبرى بسبب التكتّلات السلسليّة (threading pileups). كانت الصفحة الرّئيسيّة للموقع تُقدّم 3000 مرّة كلّ ثانيّة، لكن نظام إدارة المُحتوى (CMS) كان بطيئا، إذ كان يأخذ 3 ثوان لإعادة توليد الصّفحة الرّئيسيّة. في بعض المواقع، إن اتّبعت طلبات التّعليقات (RFC)، فسيقوم وسيط (proxy) التّخبئة بإلغاء الصّفحة الرّئيسيّة أو سيحدث انقضاء وقت (time out). عندها سيأتي مُستخدم آخر وسيتوجب جلب نسخة جديدة من الصّفحة الرّئيسيّة. يقوم Varnish بهذا عبر عمليّة التئام التّخبئة (coalescing). إذ يتم وضع المستخدمين الجدد عند وصولهم على قائمة انتظار. (أنظمة التّخبئة الأخرى تُرسل المُستخدمين إلى النظام الخلفيّ ما يقتل الخادم). إن تّمت إضافة 3000 مُستخدم إلى قائمة الانتظار كلّ ثانيّة، فبعد ثلاثة ثوان، سيكون الطابور عبارة عن 9000 مستخدم ينتظرون النظام الخلفي لجلب المحتوى. في البداية، كان Varnish يأخذ المحتوى المطلوب، ويقوم بالتواصل مع السّلاسل (Thread) الـ9000 التي تمّ إنشاؤها، ويُحاول دفع كل شيء دفعة واحدة. سمّي هذا الحدث بالقطيع الصّاخب (thundering herd). وكانت النّتيجة موت الخادوم فورا.

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

تغيّرت التّفاصيل المتعلّقة بـGrace خلال السنوات الماضيّة. في Varnish 4.0 (إن تمّ تفعيله) فستبدو كما يلي:

sub vcl_backend_response { set beresp.grace = 2m; }

يتم ربط Grace مع كائن الإجابة الخلفيّة (backend response object). إن تم تحديد القيمة في دقيقتين (2m) فسيُبقي Grace على الكائن لدقيقتين بعد انقضاء الـTPL. إن تم طلب الكائن خلال هذا الوقت، فسيتم تفضيل تقديم ما هو مُخبّأ عوضا عن إرسال طلب جديد إلى النظام الخلفيّ. سيتم استعمال الكائن وإعادة تحميله بعدها بشكل غير متزامن.

تفاصيل Grace

لا يتطلب فهم Varnish Cache النظر إلى الشّيفرة المصدريّة، عوضا عن ذلك، يتم توفير VCL افتراضيّ يُمكن الاعتماد عليه لإضافة أية تفاصيل أخرى حسب الحاجة. فبِميّزة مثل Grace يُمكن للمُستخدمين قراءة شيفرة VCL والنظر إلى التفاصيل:

Insert code

sub vcl_hit {
  if (obj.ttl >= 0s) {
      // A pure unadulterated hit, deliver it
     return (deliver);
   }
   if (obj.ttl + obj.grace > 0s) {
       // Object is in grace, deliver it
      // Automatically triggers a background fetch
       return (deliver);
  }
  // fetch & deliver once we get the result
return (fetch);
   }

إن كان الكائن VCL يحمل قيمة أكبر من 0 ثوان، هذا يعني بأنّ الـTTL موجب، سيتمّ الرجوع والتّقديم. إن كانتا كل من قيمتي TTL وGrace أكبر من 0 ثوان، فهذا يعني بأنّها ضمن Grace وسيقوم Varnish بتقديمها. إن كانتا كل من قيمتي TTL وGrace أصغر من 0 ثوان، فسيتّم طلب الصّفحة من النّظام الخلفيّ.

تعديل كيفيّة عمل Grace

يُمكن للمؤسّسات التي تكون بحاجة إلى تقديم معلومات ماليّة وتأبى عرض معلومات قديمة للمُستخدم أن تُغيّر من كيفيّة عمل Grace. في المثال التّالي، لم يتغيّر الجزء الأول، في الجزء الثّاني نقوم بالتقديم في حالة لم يكن الخادوم الخلفيّ على ما يرام وكانت كلا من قيمتي TTL و Grace أكبر من 0 ثانيّة.

sub vcl_hit {   if (obj.ttl >= 0s) {
      // A pure unadulterated hit, deliver it
      return (deliver);
   }
   if (!std.healthy(req.backend_hint) &&
       (obj.ttl + obj.grace > 0s)) {
         return (deliver);
   }
   // fetch & deliver once we get the result
   return (fetch);
 }

*بضعة معلومات إضافيّة:

• beresp: كائن الطّلب الخلفّي backend request object.
• req: كائن الطّلب request object. يُستعمل في vcl_recv.
• bereq: كائن الطّلب الخلفي backend request object. يُستعمل في vcl_backed_fetch.
• beresp: كائن الإجابة الخلفيّة. يُستعمل في vcl_backend_response.
• resp: كائن الإجابة response object. يُستعمل في vcl_deliver.
• obj: الكائن الأصلي في الذّاكرة. يُستعمل في vcl_hit.
• للمزيد من التّفاصيل استعمل man(7) vcl.

آلة الحالة (state machine)

يمرّ كل طلب عبر عدّة حالات. يُمكن تشغيل شيفرة مخصّصة في كل حالة لتعديل كائنات الطّلب. بعد تنفيذ الشّيفرة المخصّصة، يقوم Varnish باتّخاذ قرار ما إذا كان نجاحا (Hit) أو إخفاقا (Miss) بعدها يتم تشغيل إمّا VCL hit أو VCL Miss. في حالة النّجاح سيقوم Varnish بتقديم المحتوى. والإخفاقات تُعيد الطّلب من النظام الخلفي. 90% من التّغييرات التي يُحدثها المُستخدمون تحدث هنا.

كيفيّة التّضبيط (Tuning) على Linux

يتم تحديد الانضباطيات (Tunables) على Linux بشكل محافظ، ونجد SOMAXCONN و TCP_MAX_SYN_Backlog أكثرها مشقّة.

عند الانصات (listen) إلى المقابس (socket)، يأخذ Varnish بضعة ثوان للانصات للنّداء. إن كانت السّلاسل مشغولة، فستبدأ النّواة (kernel) بالتّكتّل (queue). لا يُسمَحُ لهذا التّكتّل بأن ينمو إلى ما وراء قيمة SOMAXCONN. سيطلب Varnish 1024 اتّصالا على تكتّل عمق الانصات (listen depth queue)، لكنّ النواة تقوم بإبطال ذلك لتحصل على 928 فقط. ولأنّ Varnish يعمل بصلاحيات الجذر (root)، فمن الممكن تقرير عمق انصات خاصّ، لكنّ Linux أدرى بما هو أفضل. قد يرغب المُستخدمون بالرّفع من هذا الحدّ إن أرادوا تخفيض خطر رفض الاتّصالات عند انقضاء عمق الانصات. سيتوجّب على المستخدم اتخاذ قرار ما إذا كان عدم التّقديم وتقديم صفحة خطأ أفضل أو لا. يقوم TCP_MAX_SYN_Backlog بتعريف عدد الاتّصالات البارزة التي يُمكن لها أن تكون بداخل إقامة الاتّصال (handshake) الثّلاثي الأطراف قبل أن تقرّر النواة بأنّها تحت الهجوم. القيمة الافتراضيّة هي 128. لكن في حالة دخل جمع كبير من النّاس إلى موقعك دفعة واحدة فقد تحصل على أكثر من 128 اتّصال TCP كلّ ثانيّة.

لا تقم بتعديل tcp_tw_recycle. تأكّد بأنّك تعرف ما تفعله قبل لمس الإعدادات وابحث على الويب قبل ذلك. إذ أنّ الكثير من العفاريت (demons) تعتمد على هذه القيّم.

مساحات العمل (Work spaces) في Linux

في Varnish، الذاكرة المحليّة متواجدة في كلّ سلسلة. ولأنّ التّراجع (rollback) يستنزف الموارد، فإنّنا لا نتراجع كلّما احتجنا إلى قليل من المساحة في الذّاكرة. عوضا عن ذلك، نقوم بتعيين مُسبق للذّاكرة على كلّ سلسلة إن كان للمستخدم العديد من سياسات VCL التي قد تستنزف مساحة العمل بأكملها.

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

خلاصة:

• احذر عند التّعامل مع مساحات العمل.
• لا تقم بتتبّع الاتّصالات (connection tracking).
• ارفع معدّل السّلاسل إلى طلب واحد في الثانيّة لكل سلسلة.

الموازنة بين ما هو غريب وما هو رائع في Varnish Cache

المرونة القويّة والمميّزات التّي يتمتّع بهاVarnish Cache لا تأتي في حزمة جاهزة (ما قد يجده البعض غريبا)، لذا فقد لا يكون الحلّ الأنسب للجميع. لكنّ المرونة التي يتمتّع بها قد تُغيّر من مجريات الأمور عند الرغبة في تخصيص والتّحكم بأداء المواقع وقابليّة توسيعها.

ترجمة -بتصرّف- للمقال Getting started with web app accelerator Varnish Cache لصاحبه Per Buer.

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

Apache HTTP

تم إطلاق خادوم Apache HTTP -  والذي غالبا ما يشار إليه باسم httpd  أو Apache- في عام 1995، واحتُفل بعيد ميلاده العشرين في فبراير 2015. يشغل Apache 52٪ من جميع المواقع على مستوى العالم، وهو خادوم الويب الأكثر شعبية في العالم. يغلب أن يكون Apache مشغلا على لينكس ، ولكن يمكنك أيضا تشغيله على OS X و ويندوز. ليس غريبا أن   Apacheمرخص بموجب رخصة Apache الإصدار 2. وهو يستخدم معمارية الوحدات، والتي  يمكن بها إضافة وحدات جديدة لتمديد عمل الخادوم وزيادة ميزات أخرى . على سبيل المثال سيؤدي تحميل الوحدة mod_proxy إلى السماح للبروكسي على الخادوم الخاص بك، وسيعمل mod_proxy_balancer على تمكين موازنة التحميل لجميع البروتوكولات المدعومة.  اعتبارا من الإصدار 2.4 صار Apache  يدعم HTTP/2 من خلال  الوحدة الجديدةmod_http2. وبما أن خادوم  Apache HTTP  هو خادوم الويب الأكثر شعبية منذ عام 1996، فإنه "يستفيد من الوثائق الكبيرة والدعم المتكامل من مشاريع البرامج الأخرى ." يمكنك العثور على مزيد من المعلومات حول Apache  في صفحة مشروع.

NGINX

بدأ Igor Sysoev  تطوير NGINX مرة أخرى في عام 2002. وقد طوّر NGINX  جوابًا على ما يسمى مشكلة C10K ، وهو اختصار لــ "كيف يمكنك تصميم خادوم الويب الذي يمكنه التعامل مع عشرة آلاف اتصال متزامن ؟  " . NGINX  يحل هذا المشكل وهو الثاني على قائمة خوادم الويب المفتوحة المصدر حسب الاستخدام، فهو يشغل ما يزيد عن 30٪ من المواقع. يعتمد NGINX على معمارية  الأحداث الموجهة (event-driven) غير المتزامنة ، وذلك ما يساعده في تحقيق هدفه ، ألا وهو التعامل مع أكبر عدد ممكن من الاتصالات ، وبسبب ذلك أصبح خادوم الويب الأكثر شعبية جدًا بين مديري الأنظمة بسبب استخدامه لموارد خفيفة وقدرته على التوسع بسهولة. يتم إصدار NGINX تحت رخصة BSD-like ، ولا يقتصر استخدامه على خدمة الويب فحسب، بل أيضًا كخادوم وكيل proxy  أو موازن التحميل load-balancer  ، يمكنك العثور على مزيد من المعلومات حول  NGINX في موقع المجتمع.

Apache Tomcat

Apache Tomcat هو حاوية جافا (اسمها الكامل  Java servlet) مفتوح المصدر. وهو برنامج جافا بقدرات ملقمات الويب، على الرغم من أن servlet  يمكن أن تستجيب لأي أنواع من الطلبات، فإنها استخدامها شائع فقط في تنفيذ التطبيقات المستضافة على خوادم الويب. servlet  هي نظير تقنيات الويب الديناميكية الأخرى مثل PHP  و ASP.NET، تم التبرع بالشيفرة المصدرية لــ Apache Tomcat من قبل شركة  Sun Microsystems  إلى مؤسسة Apache للبرمجيات في عام 1999، وأصبحت مشروع Apache الأعلى قيمة في عام 2005.  وهي حاليًا تحتل 1٪ فقط من جميع المواقع.

يستخدم Apache Tomcat  -والذي يصدر تحت رخصة Apache الإصدار 2-  عادة لتشغيل تطبيقات الجافا . ومع ذلك، فإنه يمكن تمديده بـ Coyote لأداء دور خادوم الويب العادي لكي يخدم الملفات المحلية كوثائق HTTP   ، يمكنك الإطلاع على مزيد من المعلومات على موقع المشروع. غالبًا ما يتم ذكر  Apache Tomcat  مع خوادم تطبيقات الجافا المفتوحة المصدر الأخرى.  مثل    JBoss و  Wildfly و Glassfish

Node.js

Node.js  هي بيئة جافا سكريبت من جانب الخادوم ، وهي تعمل لتشغيل تطبيقات الشبكة، لا تحتل Node.js   إلا مكانة منخفضة في السوق ، فنسبة تشغيلها لا تتجاوز 0.2٪ من المواقع . طور هذه البيئة في الأصل  Ryan Dahl في عام 2009 ، وتسيرها الآن مؤسسة  Node.js  وبمساعدة مؤسسة لينكس. الفرق بين Node.js وغيرها من خوادم الويب الشعبية الأخرى هو أنها بيئة تشغيل عابرة للمنصات لتشغيل تطبيقات الشبكة،  تطبّق Node.js معمارية الأحداث الموجهة event-driven القادرة على الإدخال والإخراج غير المتزامن.  هذه الخيارات في التصميم هي الأمثل إنتاجية وقابلية للتوسع في تطبيقات الويب مما يسمح بتشغيل الاتصالات وألعاب المتصفح في الوقت الحقيقي، يظهر الفرق أيضًا في أن  Node.js  هو في الحقيقة جزء من مراحل تطوير الويب (HTML, CSS, and JavaScript)، على عكس Apache أو NGINX التي هي جزء من العديد من البرامج المختلفة.

يتم إصدار Node.js تحت مزيج من التراخيص . يمكن الحصول على مزيد من المعلومات على الموقع الإلكتروني للمشروع .

Lighttpd

أطلق Lighttpd في أول إصدار له في مارس 2003. وهو حاليًا يشغل 0.1٪ من المواقع ويتم توزيعه تحت رخصة BSD. يميز Lighttpd أنه يعمل  بموارد  أقل مقارنة بالخوادم الأخرى (من حيث الذاكرة ، والمعالج) وهذا يجعله أسرع أداء واستجابة ، وهو يستخدم معمارية الأحداث الموجهة  event-driven architecture  ، ويعتبر الخيار الأمثل في حال كثرة الاتصالات المتزامنة وموارد أقل من العتاد، يدعم Lighttpd الكثير من التقنيات مثل : FastCGI, SCGI, Auth, Output-compression, URL-rewriting. كثيرًا ما يستعمل Lighttpd   مع إطار العمل Ruby on Rails  وإطار العمل Catalyst. لمزيد من المعلومات حوله قم بزيارة الصفحة الرئيسية للمشروع .

نصائح

إذا كنت ترغب أن تجرب واحدا من خوادم الويب الأكثر شعبية فأنا أوصي بشدة بتحميل التجميعية LAMP (Linux, Apache, MySQL, PHP) أو التجميعية LEMP (Linux, NGINX, MySQL, PHP) ، هناك الكثير من هذه التجميعيات المتاحة التي توفير نكهات مختلفة ، وعادة ما يتم توفيرها كمثبتات بنقرة واحدة، أو متوفرة كحزمة  في مدير برامجك على لينوكس.

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

ترجمة -وبتصرّف- للمقال Top 5 open source web servers  لصاحبه Robin Muilwijk

حقوق الصورة البارزة محفوظة لـ Freepik

نحن نبني أغلب أعمالنا على خوادم مبنية على Apache أو NGNIX، وربما حان الوقت لتجربة خادم ويب جديد بدأ يحصد شعبية بسبب بساطته، وهو خادم Caddy.
وقد أُطلق هذا الخادم لأول مرة في 2015 مكتوبًابالكامل بلغة Go، وتعتمد تهيئته على caddyfile، وهي ملفات يسهل كتابتها وإدارتها كما سنرى في هذا المثال، وما حمّسنا له حقيقة هو أنه يتكامل مع Let’s Encrypt بشكل افتراضي ودون أي تهيئة يدوية.

مزايا Caddy

• Automatic HTTPS مفعّلة افتراضيًا من خلال Let’s Encrypt.
• HTTP/2 افتراضيًا.
• Static Files في مجلد العمل الحالي.
• كل أنواع الخوادم، والموجّهات-directives، ومزودو DNS، ومزايا أخرى، كل ذلك موجود في صورة إضافات.
• يمكن استخدامه كمكتبة في برامج أخرى بلغة Go.
• يمكن تهيئته ليشغّل أوامر خاصة بالنظام عند بدء التشغيل أو إيقافه.
• ملف تنفيذي واحد لا يحتاج إلى اعتماديات إلا فيما يتعلق بالنواة-kernel.

كل هؤلاء إضافة إلى مزايا أخرى عديدة، أما الآن فسنلقي نظرة على كيفية تثبيته واستخدامه على خادم أوبنتو 16.04.

تثبيت خادم ويب Caddy

يوفّر Caddy شفرة نصية-script للتثبيت، تحمّل وتثبت الملف التنفيذي له -فهو لا يحتاج إلى اعتماديات كما ذكرنا-، نفذ الأمر التالي لتنفيذ الشفرة:

$ curl https://getcaddy.com | bash
وستسألك الشفرة أثناء التثبيت عن كلمة المرور من أجل الحصول على صلاحيات إدارية، فيكون الخرج هكذا:
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
100 5593 100 5593 0 0 3696 0 0:00:01 0:00:01 --:--:-- 3696
Downloading Caddy for linux/amd64...
https://caddyserver.com/download/linux/amd64?plugins=
Download verification OK
Extracting...
Putting caddy in /usr/local/bin (may require password)
[sudo] password for gmolica: 
Caddy 0.10.6
Successfully installed

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

تهيئة Caddy

سيعتبر Caddy أن المجلد الجذر للموقع هو المجلد الذي نفّذته منه، فإن نفّذت Caddy من مجلد $HOME فسيستخدمه كمجلد جذر له، وهذا يعني بعبارة أخرى أن من السهل استخدام Caddy في العمل على المواقع محلّيًا.
- لبدء Caddy:

$ caddy

• ستظهر الطرفية الرسالة التالية:

Activating privacy features... done.
http://:2015
WARNING: File descriptor limit 1024 is too low for production servers. 
At least 8192 is recommended. Fix with "ulimit -n 8192".

لاحظ أن Caddy يعمل على مضيف محلي-localhost، في منفذ 2015.
قد يؤدي فتح صفحة http://your_server_IP:2015 -استبدل عنوان خادمك بـyour server IP-إلى صفحة خطأ 404، هذا بسبب أن المجلد الذي يستخدمه Caddy لا يحتوي على موقع، فيجب أن ننشئ تلك المجلدات المطلوبة أولًا:

إنشاء المجلدات المطلوبة

• أولًا، ننشئ مجلدًا يحتوي ملف caddyfile الأساسي:

# mkdir /etc/caddy

• نغير ملكيته إلى المستخدم الجذر ومجموعته إلى www-data:

# chown -R root:www-data /etc/caddy

• أنشئ مجلدًا ثانيًا ليخزن فيه Caddy شهادات SSL والمفاتيح الخاصة:

# mkdir /etc/ssl/caddy

• غير مالكه إلى www-data:

# chown -R www-data /etc/ssl/caddy

• غيّر صلاحياته كما يلي:

# chmod 0770 /etc/ssl/caddy

• والآن أنشئ المجلد الذي سيحتوي الموقع:

# mkdir /var/www

• وغيّر مالكه إلى www-data:

# chown www-data:www-data /var/www

تحميل ملف Caddy Unit

• لن يثبّت Caddy نفسه افتراضيًا كخدمة systemd، لكنه يوفّر رسميًا ملف unit، حمّله بالأمر التالي:

# curl -s https://raw.githubusercontent.com/mholt/caddy/master/dist/init/linux-systemd/caddy.service -o /etc/systemd/system/caddy.service

• بفتح الملف، سنلاحظ هذه السطور:

; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/etc/ssl/caddy

; Always set "-root" to something safe in case it gets forgotten in the Caddyfile.
ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp

• لاحظ مسارات المجلدات في تلك السطور، لهذا قد أنشأنا المجلدات قبل قليل. والآن أنشئ ملفًا فارغًا باسم caddyfile:

# sudo touch /etc/caddy/Caddyfile

• نفّذ الأمر التالي كي يعمل Caddy عند الإقلاع:

# systemctl daemon-reload
# systemctl enable caddy

• تفقد حالته بهذا الأمر:

# systemctl status caddy
يجب أن يكون الخرج هكذا:
----------------------------------
â caddy.service - Caddy HTTP/2 web server
 Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: en
 Active: inactive (dead)
 Docs: https://caddyserver.com/docs

السماح باتصالات HTTP وHTTPS

• سنسمح لاتصالات HTTP وHTTPS عبر UFW (Uncomplicated Firewall)، كي يتمكن Caddy من خدمة المستخدمين بشكل سليم، نفّذ هذه الأوامر في الطرفية للسماح بهذه الاتصالات:

# ufw allow http
# ufw allow https

اختبار Caddy

آخر خطوة هي اختبار Caddy للتأكد أن كل شيء تم بشكل سليم:

تعديل Caddyfile

لقد أنشأنا ملف caddyfile فارغ من قبل، الآن سنبدأ الكتابة فيه:
- افتح الملف باستخدام المحرر النصي الذي تفضّله:

# $EDITOR /etc/caddy/Caddyfile

• الصق هذا المحتوى في الملف:

example.com {
 root /var/www
 gzip
 tls gmolica@example.com
}

ملاحظة: سطر tls يحتوي على عنوان بريد يستخدمه Caddy ليحصل على شهادات SSL من Let’s Encrypt.
- احفظ الملف وأغلقه.
- شغّل Caddy:

# systemctl start caddy

أنشئ صفحة ويب

• سننشئ صفحة ويب لاختبار Caddy:

$ echo '<h1>Website using Caddy</h1>' | sudo tee /var/www/index.html

استخدم نفس الجذر الذي ثبتنا فيه ملف caddyfile.

خاتمة

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

ترجمة -بتصرف- لمقال Caddy Web Server On Ubuntu 16.04 لصاحبه Giuseppe Molica

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

إنشاء صفحاتٍ جديدة في موقعك

نَحنُ الآن جاهزون للبدء بإنشاء المحتوى الفعلي لموقعنا. المحتوى في Hugo مكتوبٌ بلغات توصيف سهلة الاستخدام. يتم تحديد البيانات الوصفية metadata في قسمٍ خاص في كلّ صفحة يُدعى بالـ “front matter”.

يُمكننا توليد محتوى جديد باستخدام الأمر hugo new متبوعًا بمسار المحتوى المُراد توليده. تتم كتابة محتوى Hugo بشكلٍ افتراضي بالـ Markdown. لكي يتمكّن Hugo من توليد مستندات HTML من صفحات الـ Markdown بشكلٍ صحيح، يجب أن تكون الملفات التي نقوم بإنشائها تملك اللاحقة .md

إنشاء صفحة “حول الموقع”

سيُحدّد القالب الذي قُمت باختياره الصفحات التي سيتم الرّبط عليها من الصفحة الرئيسية والمسارات المتعلّقة بصفحاتك. قم بزيارة صفحة القالب على GitHub لمعرفة ما الذي ستحصل عليه. يحتوي قالب “nofancy” الّذي قُمنا باختياره على رابط لصفحة about (حول الموقع). نكتب الأمر التالي لإنشاء هذه الصفحة:

$ hugo new about.md

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

~/my-website/content/about.md
+++
categories = ["misc"]
date = "2015-11-05T16:58:58-05:00"
title = "about"

+++

تتم تهيئة الإعدادات والبيانات الوصفية في قسم الـ “front matter”، المُحدّد ضمنَ إشارات الجمع الثلاث “+++”. يُعرّف قسم الـ front matter المُضمّن بشكلٍ افتراضي عن طريق القالب الذي قمت باختياره.

يتضمّن قالبنا الحالي ثلاثة أسطر في قسم front matter في كلّ من الصفحات المولّدة. يمكنك ضبط هذه الأسطر أو إضافة أسطر جديدة حسب رغبتك. المُتغيّرات العامّة المُتاحة في Hugo موجودة هنا. يَستخدم القالب الّذي قُمت باختياره مُتغيّرات front matter الخاصّة به. يمكنك قراءة ملف الـ README الخاص بالقالب في مستودع قوالب Hugo للحصول على معلوماتٍ دقيقة حول القالب.

القائمة التاليّة توضّح بعض إعداداتfront matter العامّة:

• Date: التاريخ المُستخدم لترتيب المحتوى.
• Description: وصف عام عن الصفحة.
• Draft: يقوم هذا السطر بوسم الصفحة على أنّها غير جاهزة للنشر في حال إسناد قيمة true لها.
• Slug: عيّن هذا السطر في حال أردت تعيين عنوان URL بديل للصفحة.
• Publishdate: يمكن أن يكون هذا تاريخًا في المستقبل في حال أردت بناء الصفحة بعد زمنٍ معين.
• Title: عنوان الصفحة.

لنقم كبداية بتعديل عنوان صفحتنا لتدلّ على أنّها صفحة “حول الموقع”.

~/my-website/content/about.md
+++
categories = ["misc"]
date = "2015-11-05T16:58:58-05:00"
title = "About Me"

+++

يمكننا الآن إضافة نص Markdown تحت إشارات الجمع الثلاث “+++”، حيثُ تتم ترجمة هذا القسم ليصبح بمثابة جسم مستند HTML . سنقوم بإضافة بضعة فقرات نصية، عنوانٍ رأسي، وصورة.

~/my-website/content/about.md
+++
categories = ["misc"]
date = "2015-11-05T16:58:58-05:00"
title = "About Me"

+++
  
Hello and welcome to my site!

## A Bit About Me

I like alpacas and I'm a fan of static sites.

![Great alpaca picture](https://upload.wikimedia.org/wikipedia/commons/c/c4/Alpaka_33444.jpg)

عند انتهائك، قم بحفظ وإغلاق الملف.

إنشاء أوّل تدوينة

قُمنا بإنشاء صفحة الـ about.md في جذر مجلّد المحتوى لأنّ القالب الذي اخترناه يتوقّع أن تكون هذه الصفحة في الجذر. ولكن من المُستحسن أن يتم حفظ المنشورات في مجلّد posts فرعي.

لنقم بإنشاء أوّل تدوينة لنا في مجلد المنشورات “posts”. سيقوم Hugo:

$ hugo new post/My-First-Post.md

عند استخدامنا لعلامة الترقيم “-” في اسم ملف الـ Markdown، سيتم تحوليها بشكلٍ تلقائي إلى مسافات ليكون عنوان الملف هو نفسه عنوان الصفحة. 

~/my-website/content/post/My-First-Post.md
+++
categories = ["misc"]
date = "2015-11-05T17:52:41-05:00"
title = "My First Post"

+++

قم بملء أيّة بيانات وصفية ناقصة وإضافة بعض شيفراتMarkdown للصفحة. سنقوم بإضافة مثال عن شيفرة لتتمكّن من ملاحظة وظيفة أداة Pygments. للقيام بذلك، بدلاً من استخدام ثلاث إشارات ترقيم لإغلاق كتلة الشيفرة، نضع الشيفرة بين وسمي highlight كالتالي: 

{{< highlight language >}}

code_goes_here

{{< /highlight >}}

سيقوم هذا بتوفير تلوين النّصوص البرمجية الذي يُوفّره Pygment. ضع في اعتبارك أن بعض القوالب تحتوي ملفّات CSS تقوم بتخطّي خيارات العرض الخاصّة بـ Pygments.

في داخل صفحتنا، يجب على المحتوى أن يبدو كالتالي: 

~/my-website/content/post/My-First-Post.md
+++
categories = ["misc"]
date = "2015-11-05T17:52:41-05:00"
title = "My First Post"

+++

This is my first post on the site.  I hope that you like it!

## Welcome Function

Here is a little Python function to welcome you:

{{< highlight python >}}
def hello_world():
    print "Hello there!"
{{< /highlight >}}

أغلق واحفظ الملف في حال انتهائك من تعديله. إذا أردت أن تُعدّل تلك الصفحات لاحقًا، ستتمكّن من إيجادها في مجلّد المحتوى content الخاص بموقع الـ Hugo.

لنقم الآن بإيداع صفحاتنا الجديدة لمستودع الـ git:

$ git add .
$ git commit -m 'First pages of our site'

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

يستطيع Hugo أخذ ملفّات الـ Markdown وتطبيق الإعدادات المُعرّفة في ملف التهيئة والقالب وأخيرًا مُعالجة صفحات الـ HTML الفعلية التي ستظهر للزائرين.

لبناء موقعك، قم بكتابة التالي:

$ hugo

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

ملاحظة: لا يقوم Hugo بتنظيف مجلّد ملفّات الخرج بعد كل بناءٍ للموقع، مما يُزيد من إمكانية وجود محتوىً قديم في المجلّد العام public يَعود لإصدار أقدم من الموقع؛ لذلك يَنصح مبرمجو Hugo بحذف المجلّد العام public بعد كل عملية بناء للموقع (خاصةً قبل الانتقال إلى بيئة الانتاج)، بُغية إعادة إنشاء جميع المحتوى من جديد.

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

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

سنقوم باستخدام الخيار –bind لتحديد أنّنا نريد جعل الموقع متاحاً على جميع الواجهات، إلّا أنّه في حال كان Hugo منصّبًا محلّيًا، يمكنك إزالة هذا الخيار. ينبغي علينا أيضًا تضمين خيار الـ --bindUrl، حيث قٌمنا بضبط هذا الخيار في ملفِّ التهيئة، إلّا أنّه ليس مُحمّلًا على الخادوم في الإصدار الحالي من Hugo. أسنِد اسم نطاق موقعك أو عنوان الـ IP الخاصّ بك لهذا الخيار: 

$ rm -r public
$ hugo server --bind=0.0.0.0 --baseUrl=http://your_domain_or_IP/

إذا عيّنت draft = true لأيّة صفحة، أو عيّنت الـ date لتاريخٍ في المستقبل لمحتواك، يُمكنك بناء وعرض هذه الصفحات بإضافة خيارات الـ -D والـ -F إلى الأمر على التّوالي: 

$ rm -r public
$ hugo server --bind=0.0.0.0 --baseUrl=http://your_domain_or_IP/ -D -F

عند زيارتك الآن لاسم نطاق خادومك أو عنوان الـ IP في مستعرضك، وإضافتك للمنفذ :1313 إلى نهاية العنوان، سترى موقعك الّذي تمّت مُعالجته: 

http://your_domain_or_IP:1313

يُمكننا النقر على أوّل منشور للتحقّق من مُعالجة نصِّ الـ Markdown بالشكلِ الصحيح. في حين تمّ تطبيق أسلوب العرض الخاص بـ Pygments على كتلة الشيفرة التي قٌمنا بوضعها أعلاه:

في حال نقرِك على “About”، سيتم أخذك إلى صفحة “حول الموقع”:

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

إذا أردت تجربة قوالبٍ أخرى، يمكنك إضافة الخيار --theme=إلى نهاية سطر الخادوم، كالتالي: 

$ rm -r public
$ hugo server --bind=0.0.0.0 --baseUrl=http://your_domain_or_IP/ --theme=redlounge

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

إذا أردت أن تَستخدم Hugo ليعمل على تخديم المحتوى على منفذ 80 كما هوَ مُعتاد لخادوم ويب، قم بإضافة الخيار –port لسطر الأوامر، حيثُ يجب أيضًا كتابة الأمر مسبوقًا بـ sudo، نظرًا لكونِ المنافذ الأصغر من 1024 محجوبةً للمستخدمين العاديين: 

$ rm -r public
$ sudo hugo server --bind=0.0.0.0 --baseUrl=http://your_domain_or_IP/ --theme=redlounge --port=80

ستتمكّن الآن من زيارة موقعك في متصفحٍ من دون الحاجة إلى إضافة رقم المنفذ إلى عنوان الموقع.

بعد تشغيل خادوم Hugo باستخدام sudo، ستحتاج أيضًا إلى إدخال الأمر rm مسبوقًا بـ sudo:

 $ sudo rm -r public

الخُلاصة

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

ترجمة -وبتصرّف- للمقال How to Install and Use Hugo, a Static Site Generator, on Ubuntu 14.04 لصاحبه Justin Ellingwood

المقدّمة

يُعتبر Hugo موّلدًا للمواقع الإستاتيكية، يتميّز بسرعتِه وسهولةِ استخدامه، تمّت كتابته باستخدام لغة Go وهو متاح للعديد من الأنظمة. تُعد موّلدات المواقع الإستاتيكية خيارًا مثاليًا للمدوّنات والمحتويات الأخرى التي لا تتطلّب محتوًى ديناميكيًا يتم تحميله من قاعدة بيانات. تسمح لك أدات مثل Hugo بتبسيط مهامك، وبكتابة مستندات Markdown سهلة الاستخدام.

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

المتطلّبات المُسبقة

لإكمال خطوات هذا المقال، يجب أن يتوفّر لديك الوصول إلى خادوم Ubuntu 14.04. على هذا الخادوم، ستحتاج إلى مستخدم غير مستخدم Root مع صلاحيات sudo تمّت تهيئتها للقيام بمهامٍ إداريّة.

تنصيب آخر إصدار من Hugo

Hugo ليس متاحًا في مستودعات تخزين Ubuntu الافتراضية (Default Repositories)، إلّا إن هذه الحزم متاحة على GitHub للعديد من المعماريات والتوزيعات.

تحقّق من معمارية النظام

قبل أن نبدأ، يجب أن نتحقّق من معمارية خادوم Ubuntu لنتمكّن من تحميل الحزمة المناسبة. نفّذ الأمر التالي على خادومك:

$ uname –i

إذا ظهر التالي، هذا يعني أنّك تقوم بتشغيل إصدار64 بت من Ubuntu:

Output
X86_64

أمّا إذا ظهرَ التالي، هذا يعني أنّ إصدار الـ Ubuntu الخاص بك هو إصدار32 بت:

Output
i686

سنقوم باستخدام هذه المعلومات لاحقًا.

تحميل وتنصيب حزمة Hugo

قم بزيارة صفحة إصدارات Hugo لإيجاد آخر إصدار من Hugo (أعلى الصفحة). اذهب إلى قسم “Downloads”.

ثمّ بعد ذلك، يجب أن ننسخ رابط تنصيب الحزمة المناسبة. تعتمد الحزمة المناسبة على بُنية النظام التي تحقّقتَ منها أعلاه.

• في حال استخدامك لإصدار 64 بت من Ubuntu، اضغط بالزر الأيمن على الرابط المنتهي بـ amd64.deb وانسخ موقع الرابط.
• أمّا في حال استخدامك لإصدار 32 بت من Ubuntu، اضغط بالزر الأيمن على الرابط المنتهي بـ i386.deb وانسخ موقع الرابط.

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

$ cd ~
$ wget https://github.com/spf13/hugo/releases/download/v0.14/hugo_0.14_amd64.deb

يمكنك الآن تنصيب الحزمة باستخدام dpkg عن طريق كتابة التالي:

$ sudo dpkg -i hugo*.deb

تحقّق من نجاح التنصيب عن طريق تنفيذ أمر Hugo الذي سيقوم بطباعة إصدار البرنامج.

$ hugo version

يقوم هذا الأمر بطباعة إصدار Hugo الحالي.

Output
Hugo Static Site Generator v0.14 BuildDate: 2015-05-25T21:29:16-04:00

تنصيب برنامج دعم Hugo

أنهينا تنصيب Hugo، إلّا أنّ هنالك بضعة برامجيات صغيرة يجب علينا أن نُنصّبها لنتمكّن من تشغيل البرنامج بشكلٍ صحيح.

تنصيب القوالب Hugo Themes

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

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

$ sudo apt-get update
$ sudo apt-get install git

ثمّ بعد ذلك، يمكننا نسخ مستودعات قوالب Hugo. تم تضمين كل قالب فردي كوحدة برمجيّة فرعيّة (submodule).

يفضل نسخ القوالب إلى المجلد الرئيسي home. يُمكننا بعد ذلك إنشاء رابط رمزي (Symbolic Link) لتلك القوالب ضمن مجلّد الموقع. ستسمح لنا هذه العمليّة بمشاركة القوالب بسهولة تامّة في حال امتلاكنا لعدّة مواقع.

انسخ مستودع القوالب إلى المجلّد الرئيسي عن طريق كتابة التالي:

$ git clone --recursive https://github.com/spf13/hugoThemes ~/themes

تنصيب برنامج تلوين النّصوص البرمجية Pygments Syntax Highlighter

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

يمكننا الحصول على pip من مستودعات التخزين الافتراضية بكتابة:

$ sudo apt-get install python-pip

حالما ينتهي الأمر apt، يمكننا استخدام pip لتنصيب Pygments عن طريق كتابة التالي:

$ sudo pip install Pygments

تفعيل خاصيّة الإكمال التلقائي الخاصة بـ Hugo على Bash

آخر إجراء يجب علينا القيام به قبل البدء بالعمل على موقعنا الأول، هو تفعيل خاصيّة الإكمال التلقائي الخاصة بـ Hugo على Bash. يتم ذلك بتنفيذ الأمر التالي:

$ sudo hugo genautocomplete

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

$ . /etc/bash_completion

إذا قمت الآن بكتابة hugo متبوعةً ببضعة ضغطات على مفتاح الجدولة TAB، ستتمكن من رؤية الأوامر المدعومة من قبل Hugo:

$ hugo [TAB][TAB][TAB]

Output
benchmark        config           genautocomplete  help             new              undraft
check            convert          gendoc           list             server           version

إنشاء موقعك الأوّل

بعدَ انتهائنا من تهيئة البرنامج، يمكننا المُضي قدمًا وإنشاء أول موقع لدينا. يحتوي Hugo على موّلدٍ قادرٍ على إنشاء هيكل من الملفّات والمجلّدات اللازمة لإنشاء الموقع.

يمكننا إنشاء موقعٍ جديد في المجلد الرئيسي عن طريق كتابة التالي: 

$ hugo new site ~/my-website

انتقل إلى المجلد الذي يحتوي موقعك الجديد لرؤية المزيد:

$ cd ~/my-website
$ ls -F

سترى بنية المجلد وملف الإعدادات الرئيسي المُستخدم لبناء موقع الـ Hugo.

الخرج:

archetypes/  config.toml  content/  data/  layouts/  public/  static/

لنقم بالربط على مجلد القوالب ~/themes من داخل موقعنا. ولتسهيل مهمة نقل الموقع لاحقًا، سنقوم بإعداد رابط رمزي نسبي.
$ln -s ../themes .$

 ls -l

total 28
drwxrwxr-x  2 demouser demouser 4096 Nov  5 11:25 archetypes
-rw-rw-r--  1 demouser demouser  210 Nov  5 11:55 config.toml
drwxrwxr-x  3 demouser demouser 4096 Nov  5 11:38 content
drwxrwxr-x  2 demouser demouser 4096 Nov  5 11:25 data
drwxrwxr-x  2 demouser demouser 4096 Nov  5 11:25 layouts
drwxrwxr-x 13 demouser demouser 4096 Nov  5 11:25 public
drwxrwxr-x  2 demouser demouser 4096 Nov  5 11:25 static
lrwxrwxrwx  1 demouser demouser    9 Nov  5 14:21 themes -> ../themes

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

التّحكم في الموقع باستخدام نظام إدارة الإصدارات Source Control

قبل الشّروع في إعداد الموقع وإنشاء المحتوى، يجب أن ندير موقعنا باستخدام git.

تأكّد من وجودِك في مجلّد الموقع وأنشئ مستودع git بكتابة التالي:

$ cd ~/my-website
$ git init

الخرج:

Initialized empty Git repository in /home/demouser/my-website/.git/

قُم بإعداد git (إن لم يسبق لك القيام بذلك) . الطريقة الأسهل للقيام بذلك هي عن طريق الأمر git config –global يجب عليك أن تُحدّد اسمك وعنوان البريد الإلكتروني الخاص بك، حتى تتمكّن git من تخزين معلوماتنا في الإيداعات commit بشكل صحيح.

$ git config --global user.name "yourName"
$ git config --global user.email "user@email.com"

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

يمكننا إضافة ملف .gitkeep مخفي لكلِّ من مجلّدات المستوى الأعلى (غير مجلّد .git المخفي أصلًا) بكتابة التالي:

$ for DIR in `ls -p | grep /`; do touch ${DIR}.gitkeep; done

نلاحظ إضافة الملف المخفي .gitkeep لكلٍّ من مجلّدات المستوى الأعلى عن طريق كتابة ما يلي:

$ find . -name .gitkeep

الخرج:

./data/.gitkeep
./layouts/.gitkeep
./archetypes/.gitkeep
./static/.gitkeep
./content/.gitkeep

احرص أيضًا أن لا يتم إيداع الملفات التي تم توليدها (ملفات HTML، JavaScript و CSS) إلى المُستودع. يجب أن يتم توليد هذه الملفات بعد كل عملية نشر للموقع. يمكننا أن نطلب من git تجاهل المجلّد العام public حيث يتم تخزين المحتوى المُوّلد عن طريق إضافته إلى ملفّ .gitignore كالتالي:

$ echo "public" >> .gitignore

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

$ git add .
$ git commit -m 'Initial commit, pre-configuration.'

ضبط الإعدادات الأوليّة للموقع

لنقم الآن بضبط ملف إعدادات Hugo الرئيسي لتحديد كيفية بناء Hugo لموقعنا.
قم بفتح الملف config.toml في محرّرك:

$ nano config.toml

سترى في داخله بضعة أسطر بحاجة إلى الضبط:

~/my-website/config.toml
baseurl = "http://replace-this-with-your-hugo-site.com/"
languageCode = "en-us"
title = "My New Hugo Site"

السطر الأول الواجب تغييره هو سطر الـ baseurl. يُستخدم هذا السطر لبناء عناوين URL عند بناء الموقع. قم بتغيير ذلك السطر إلى اسم نطاق خاص بك أو عنوان الـ IP العام الخاص بخادومك. ينبغي عليك أيضًا أن تُعدّل القيمة المُسندة لسطر العنوان title. يُستخدم هذا السطر لتحديد عناوين صفحات موقعك.

~/my-website/config.toml
baseurl = "http://your_domain_or_IP/"
languageCode = "en-us"
title = "Your Site Name"

هنالك بضعة إعداداتٍ إضافيّة يجب علينا تعديلها في هذا الملف. أولاً، يمكننا ضبط محرّر النصوص المفضّل لدينا؛ يتم بهذه الطريقة عند توليد صفحاتٍ جديدة فتح نموذج الصفحة في محرّرنا.

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

~/my-website/config.toml
baseurl = "http://your_domain_or_IP/"
languageCode = "en-us"
title = "Your Site Name"
newContentEditor = "nano"
theme = "nofancy"
pygmentsStyle = "native"

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

لنقم بإيداع تعديلات التهيئة قبل أن نستمر بإنشاء الموقع:

$ git add .
$ git commit -m 'Initial configuration complete'

خاتمة:

تعرفنا في هذا المقال على كيفية تنصيب وإعداد Hugo. في المقال القادم سنستعرض كيفية إضافة صفحات ومُحتويات إلى الموقع.

ترجمة -وبتصرّف- للمقال How to Install and Use Hugo, a Static Site Generator, on Ubuntu 14.04 لصاحبه Justin Ellingwood