كيفية إعداد عملية إنشاء لموقع ثابت بسرعة

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

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

المقدمة

في المقالات السابقة ، أوضحت كيفية إنشاء موقع ويب JavaScript ديناميكي بمحتوى من Kentico Cloud بدون رأس. ثم أوضحت لك كيفية تحويله إلى موقع ثابت للمساعدة في الأداء والأمان وتحسين محركات البحث. حان الوقت الآن لإنشاء هذا الموقع ودفعه عبر الإنترنت ليشاهده العالم بأسره.

توليد موقع ثابت

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

npx nuxt generate

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

أين يجب علي استضافة موقع ثابت؟

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

يتم توسيع مساحة الاستضافة الحالية لتلائم متطلبات نظام آخر أو مصممة لدعم إعداد معين ، مثل PHP و MySQL أو .NET و PostgreSQL. لذلك إذا كان الأمر كذلك ، فمن المحتمل أنك استخدمت مقدار حركة المرور والجلسات والقيم الأخرى لحساب مقدار قوة الحوسبة التي ستحتاجها (أو مثلي في الماضي ، كنت آمل فقط أن تكون على ما يرام).

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

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

  • صفحات جيثب
  • نيتليفاي
  • هيروكو
  • ومقدمي الخدمات العالميين والمحليين الآخرين. يمكنك بالطبع استخدام خدمات استضافة مواقع الويب العالمية مثل Azure أو AWS أيضًا.

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

كيف أقوم بإنشاء موقع ثابت ونشره؟

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

تتكون عملية نشر موقع ثابت من ثلاثة أجزاء:

  1. اثار
  2. بناء
  3. تعيين

اثار

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

مشغل تغيير المحتوى

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

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

...
if (!isValidSignature(req, process.env['KC_WEBHOOK_SECRET'])) { context.log('Signature was invalid'); return;}
...
const isValidSignature = (req, secret) => { const givenSignature = req.headers['x-kc-signature']; const computedSignature = crypto.createHmac('sha256', secret) .update(req.rawBody) .digest();
 return crypto.timingSafeEqual(Buffer.from(givenSignature, 'base64'), computedSignature);}

(انظر الملف الكامل على جيثب)

ثم يتم تشغيل الإنشاء باستخدام واجهة برمجة التطبيقات لخادم الإنشاء:

request.post({ url: "//api.travis-ci.org/repo/Kentico%2Fkentico.github.io/requests", headers: { "Content-Type": "application/json", "Accept": "application/json", "Travis-API-Version": "3", "Authorization": `token ${process.env['TRAVIS_TOKEN']}` },
...

(انظر الملف الكامل على جيثب)

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

مشغل تغيير الكود

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

بناء

I know, the words “build server” sounds so complicated and expensive. But when you think about it, the only thing a build server needs to do for you is to generate pages and deploy them. Exactly what you did manually with one npx command and copy-paste operation. And that was not that hard, was it?

So how can you decide which build server to use? First, you need to choose whether you want to run the build locally on your server or remotely on a third-party service. I don’t have a local server I could use for this purpose, so I decided to use third-party services. These services include:

  • AppVeyor
  • Travis CI

Both of these services are free for open-source projects.

“What? Is my website open-source? This guy is crazy!”

Am I? :-) I already mentioned the benefits of open-sourcing your website implementation in my previous article about security. In most cases, websites are very similar in functionality, so there is probably no special know-how in your implementation. It’s the content that holds the value.

But let’s get back to the build server. I chose Travis CI as it was recommended to me by a colleague. We use it for many GitHub projects in our company. So how long does it take to set it up?

Initially, I was expecting a complicated UI to configure all aspects of a build within Travis (remember VSTS online?), so finding out it all sits in a single file was a relief. So the first thing you need to do is create a file #.travis.yml# in the root of your project. This file defines what is happening during a build.

dist: trusty language: node_js node_js: — "stable" before_script: — npm install script: — npm run build deploy: ...
packages.json:"scripts": { ... "build": "npx nuxt generate && cpx CNAME dist", ...}

You see it is straightforward to understand. First I instruct NPM to install all required packages as a prerequisite to running a build. Then all static files are generated into a dist folder — this is the default when using Nuxt. I also included a preview of a packages.json file, which defines build script. Note that I am also copying CNAME file to dist directory — this tells GitHub Pages I am using custom domain rather than github.io.

Deployment

Finally the last part of the whole process. We have files generated, and now we need to transfer them to our hosting space, just like we did before using FTP. This is yet another thing a build server can do for you.

As I mentioned before I have chosen GitHub Pages as my host and Travis CI as a build server. Travis provides many options for automated deployments including GitHub Pages, so the configuration was a piece of cake. Take a look at the deployment configuration:

deploy: local-dir: dist target-branch: master provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN keep-history: true verbose: true on: branch: source

Local-dir defines where my generated static pages are, target-branch marks a branch in the GitHub repository to deploy to, and pages is the name of the Travis provider for GitHub Pages. To deploy successfully you also need to generate and provide a github-token. You see there is just a variable in the build configuration as the file sits in public repository. The token’s value is stored in repository settings in Travis UI.

The finale of the series

And that’s it. That’s all you need to trigger, build, and deploy a static site automatically. Without any previous experience with build and deployment processes, this should not take you longer than a few hours. You see, static sites can be very dynamic in terms of content, the actual static file generating is handled automatically without a single human effort.

During this series of articles, I explained how to build a website using Content-as-a-Service (CaaS) to store your content, how to ensure your website is secure by not using any database, and how to ensure such a website still contains dynamic functionality like form submissions.

Good luck with your new static websites and have a #staticNewYear!

Other articles in the series:

  1. How to start creating an impressive website for the first time
  2. How to decide on the best technology for your website?
  3. كيفية تعزيز موقع الويب الخاص بك باستخدام Vue.js بأقل جهد
  4. كيفية مزج CMS مقطوعة الرأس مع موقع Vue.js ودفع الصفر
  5. كيفية جعل عمليات إرسال النماذج آمنة على موقع ويب API
  6. بناء موقع ويب فائق السرعة وآمن باستخدام CMS ليس بالأمر الهين. أو هو؟
  7. كيفية إنشاء موقع ويب ثابت باستخدام Vue.js في لمح البصر
  8. كيفية إعداد عملية إنشاء لموقع ثابت بسرعة