Πώς να ρυθμίσετε γρήγορα μια διαδικασία κατασκευής για έναν στατικό ιστότοπο

Έχετε έναν στατικό ιστότοπο που έχει εφαρμοστεί και είναι έτοιμος να δει ο κόσμος, αλλά πού πρέπει να τον φιλοξενήσετε; Πώς επιλέγετε τη σωστή πλατφόρμα και σχεδιάζετε ένα σύνολο στατικών αρχείων; Πώς μπορείτε να διασφαλίσετε ότι ο ιστότοπος θα αναδημιουργείται αυτόματα κάθε φορά που αλλάζετε το περιεχόμενό του;

Σε αυτό το άρθρο, θα σας δείξω πώς να δημιουργήσετε έναν στατικό ιστότοπο, να δημιουργήσετε μια αυτόματη διαδικασία δημιουργίας που ενεργοποιείται από αλλαγές περιεχομένου και να αναπτύξετε τον ιστότοπο σε έναν διακομιστή που αντιμετωπίζει το κοινό.

Εισαγωγή

Σε προηγούμενα άρθρα, εξήγησα πώς να δημιουργήσω έναν δυναμικό ιστότοπο JavaScript με περιεχόμενο από ένα χωρίς κεφαλή CMS Kentico Cloud Στη συνέχεια, σας έδειξα πώς να το μετατρέψετε σε στατικό ιστότοπο για να βοηθήσετε την απόδοση, την ασφάλεια και το SEO. Τώρα λοιπόν ήρθε η ώρα να δημιουργήσετε αυτόν τον ιστότοπο και να τον προωθήσετε online για να δείτε ολόκληρο τον κόσμο.

Δημιουργία στατικού ιστότοπου

Κάθε στατική γεννήτρια ιστότοπου σάς επιτρέπει να δημιουργείτε τον ιστότοπο τοπικά χωρίς να δημιουργείτε όλα τα αρχεία μετά από κάθε αλλαγή αρχείου. Εάν ακολουθήσατε τα άρθρα μου, έχετε έναν ιστότοπο στο Vue.js που έχει μετατραπεί για να χρησιμοποιήσει το Nuxt.js ως πλαίσιο, αλλά εξακολουθεί να απαιτεί έναν διακομιστή ανάπτυξης για τον χειρισμό αιτημάτων ιστότοπου. Για να δημιουργήσετε στατικά αρχεία, εκτελέστε την ακόλουθη εντολή:

npx nuxt generate

Ανοίξτε το distφάκελο στη ρίζα του έργου σας για να βρείτε τα δημιουργημένα αρχεία και ελέγξτε για index.htmlνα βεβαιωθείτε ότι ο ιστότοπός σας δημιουργεί σωστά. Έχω τη συνήθεια να ελέγχω επίσης τις θυγατρικές σελίδες όπου γνωρίζω ότι υπάρχει κάποιο περιεχόμενο από ένα CMS χωρίς κεφάλι, όπως μια σελίδα Blog. Εάν δείτε το περιεχόμενο σε μορφή HTML, κερδίζετε!

Πού πρέπει να φιλοξενήσω έναν στατικό ιστότοπο;

Αυτή είναι πιθανώς η επόμενη ερώτηση που θα θέσετε μετά τη δημιουργία όλων των αρχείων. Εάν δημιουργείτε ξανά έναν ιστότοπο και ο παλιός σας ιστότοπος εξακολουθεί να είναι διαδικτυακός, πιθανώς σκέφτεστε να χρησιμοποιήσετε τον ίδιο πάροχο για τον στατικό ιστότοπο. Αυτό είναι εντάξει. Ωστόσο, εάν ο παλιός σας ιστότοπος δημιουργήθηκε πάνω από μια παραδοσιακή CMS ή άλλη γλώσσα προγραμματισμού, ίσως χρειαστεί να σκεφτείτε δύο φορές.

Ο τρέχων χώρος φιλοξενίας σας κλιμακώνεται για να ταιριάζει στις απαιτήσεις ενός άλλου συστήματος ή έχει σχεδιαστεί για να υποστηρίζει μια συγκεκριμένη εγκατάσταση, όπως PHP και MySQL ή .NET και PostgreSQL. Έτσι, αν συμβαίνει αυτό, πιθανότατα χρησιμοποιήσατε το ποσό της κίνησης, των περιόδων σύνδεσης και άλλων τιμών για να υπολογίσετε ποια ποσότητα υπολογιστικής ισχύος θα χρειαστείτε (ή όπως εγώ στο παρελθόν, απλώς ήλπιζα ότι θα ήταν εντάξει).

Με τις στατικές τοποθεσίες ανακουφίζεται: όχι πιο περίπλοκοι τύποι, προσεγγίσεις και επαγγελματική εικασία. Η φιλοξενία πολλών στατικών αρχείων είναι κάτι που κάθε διακομιστής ιστού μπορεί να κάνει εύκολα. Η πιο σημαντική πτυχή είναι ότι ο διακομιστής δεν χρειάζεται πλέον να περάσει από τον εξελιγμένο αγωγό διαχείρισης αιτημάτων για κάθε επίσκεψη. Απλώς εξυπηρετεί στατικά αρχεία. Και αυτό είναι εύκολο και γρήγορο.

Η φιλοξενία στατικών ιστότοπων είναι επομένως πολύ φθηνότερη. Υπάρχουν δεκάδες υπηρεσίες που σας επιτρέπουν να φιλοξενείτε τους ιστότοπούς σας δωρεάν ή τουλάχιστον να έχετε δωρεάν προγράμματα εκκίνησης. Περιλαμβάνουν:

  • Σελίδες GitHub
  • Netlify
  • Ηρόκου
  • και άλλους παγκόσμιους και τοπικούς παρόχους. Φυσικά, μπορείτε να χρησιμοποιήσετε παγκόσμιες υπηρεσίες φιλοξενίας ιστότοπων όπως το Azure ή το AWS.

Αποφάσισα να επιλέξω σελίδες GitHub καθώς όλα τα αποθετήρια μου φιλοξενούνται ήδη στο GitHub. Είναι επίσης εντελώς δωρεάν και υποστηρίζει προσαρμοσμένους τομείς 2ου επιπέδου.

Πώς μπορώ να δημιουργήσω και να αναπτύξω έναν στατικό ιστότοπο;

Αλλά δεν αφορά μόνο τη φιλοξενία. Το να έχετε τις σελίδες στο διαδίκτυο είναι απαραίτητο, αλλά είναι εξίσου σημαντικό να σκεφτείτε ολόκληρη τη διαδικασία ανάπτυξης. Δηλαδή - πώς θα δημιουργηθούν και θα μεταφερθούν οι στατικές σελίδες στο διακομιστή. Για την πρώτη έκδοση, μπορείτε να δημιουργήσετε σελίδες στο τοπικό σας περιβάλλον χρησιμοποιώντας npx nuxt generateκαι αντιγράψτε-επικολλήστε τα στατικά αρχεία στο χώρο φιλοξενίας σας μέσω FTP. Αλλά θα επαναλάβετε αυτήν τη διαδικασία κάθε φορά που υπάρχει αλλαγή περιεχομένου;

Η διαδικασία ανάπτυξης ενός στατικού ιστότοπου έχει τρία μέρη:

  1. Δώσει το έναυσμα για
  2. Χτίζω
  3. Ανάπτυξη

Δώσει το έναυσμα για

Μια νέα έκδοση πρέπει να συμβεί όταν πραγματοποιηθεί αλλαγή περιεχομένου ή εφαρμογής. Αυτό σημαίνει ότι κάθε φορά που ένας επεξεργαστής περιεχομένου δημοσιεύει νέο περιεχόμενο σε ένα χωρίς κεφαλή CMS ή αλλάζετε τον πηγαίο κώδικα, ο ιστότοπος πρέπει να ξαναχτίσει. Αλλά πώς το επιτυγχάνουμε αυτό;

Ενεργοποίηση αλλαγής περιεχομένου

Κάθε ώριμο CMS χωρίς κεφάλι διαθέτει webhooks. Αντιπροσωπεύουν ειδοποίηση από υπηρεσία σε υπηρεσία σχετικά με ένα συγκεκριμένο είδος δράσης. Έτσι, όταν ένας επεξεργαστής δημοσιεύει ένα στοιχείο περιεχομένου, το CMS χωρίς κεφάλι ξεκινά μια ειδοποίηση webhook που αποστέλλεται σε μια καθορισμένη διεύθυνση URL. Σε αυτήν την περίπτωση σε έναν διακομιστή build που θα ενεργήσει κατά την ειδοποίηση και θα αναδημιουργήσει τον ιστότοπο.

Αλλά πώς ξέρει ο διακομιστής build τι να κάνει; Λοιπόν, δεν έχει ιδέα τι είδους χώρο αποθήκευσης περιεχομένου χρησιμοποιείτε και πιθανώς δεν θα καταλάβετε τη γενική ειδοποίηση webhook. Για αυτόν τον λόγο, πρόσθεσα μια απλή συνάρτηση 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);}

(δείτε το πλήρες αρχείο στο GitHub)

και στη συνέχεια ενεργοποιεί το build χρησιμοποιώντας το API του διακομιστή build:

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']}` },
...

(δείτε το πλήρες αρχείο στο GitHub)

I know I know, Azure asks you for your credit card before you can create functions. But you can use Webtask.io, which is completely free. I explained how to create a simple function there in one of my previous articles.

Code change trigger

With code, the process gets even easier. The build servers often offer direct integration with GitHub, so it is just a matter of authorizing the build server with GitHub. When you push your code change into a remote repository, the build server receives the information automatically, and based on its configuration triggers a new build.

Build

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. Πώς να αναμίξετε το Headless CMS με έναν ιστότοπο Vue.js και να πληρώσετε μηδέν
  5. Πώς να κάνετε τις υποβολές φόρμας ασφαλείς σε έναν ιστότοπο API
  6. Η δημιουργία ενός εξαιρετικά γρήγορου και ασφαλούς ιστότοπου με CMS δεν είναι μεγάλη υπόθεση. Ή μήπως είναι?
  7. Πώς να δημιουργήσετε έναν στατικό ιστότοπο με το Vue.js σε χρόνο μηδέν
  8. Πώς να ρυθμίσετε γρήγορα μια διαδικασία κατασκευής για έναν στατικό ιστότοπο