Hogyan lehet gyorsan beállítani egy statikus webhely összeépítési folyamatát

Van egy statikus webhelye, amelyet minden megvalósított és készen áll arra, hogy a világ lássa, de hol kellene otthonnod? Hogyan válassza ki a megfelelő platformot és tervezzen egy statikus fájlkészletet? Hogyan biztosíthatja, hogy a webhely automatikusan megújuljon, amikor megváltoztatja a tartalmát?

Ebben a cikkben bemutatom, hogyan lehet létrehozni egy statikus webhelyet, beállítani a tartalom változásai által kiváltott automatikus összeállítási folyamatot, és telepíteni a webhelyet egy nyilvános kiszolgálóra.

Bevezetés

Korábbi cikkekben elmagyaráztam, hogyan lehet dinamikus JavaScript webhelyet készíteni fej nélküli CMS Kentico Cloud tartalmával. Aztán megmutattam, hogyan lehet statikus hellyé konvertálni a teljesítmény, a biztonság és a SEO javítása érdekében. Tehát itt az ideje, hogy létrehozza ezt a webhelyet, és online módon terjessze az egész világ számára.

Statikus hely létrehozása

Minden statikus webhelygenerátor lehetővé teszi a webhely helyi felépítését anélkül, hogy minden egyes fájlcsere után létrehozná az összes fájlt. Ha követte a cikkeimet, van egy olyan webhelye a Vue.js-n, amelyet átalakítanak a Nuxt.js használatára keretrendszerként, de a webhelykérések kezeléséhez továbbra is fejlesztői kiszolgálóra van szükség. A statikus fájlok előállításához futtassa a következő parancsot:

npx nuxt generate

Nyissa meg a distprojekt gyökérkönyvtárában található mappát a létrehozott fájlok megkereséséhez, és ellenőrizze, index.htmlhogy a webhelye megfelelően generálódik-e. Szokásom, hogy a gyermekoldalakat is ellenőrizzem, ahol tudom, hogy van egy tartalom egy fej nélküli CMS-ből, például egy Blog oldalról. Ha HTML formában látja a tartalmat, akkor Ön nyertes!

Hol kell otthont adnom egy statikus webhelynek?

Valószínűleg ez a következő kérdés, amelyet az összes fájl létrehozása után feltesz. Ha újjáépít egy webhelyet, és a régi webhelye még mindig online, akkor valószínűleg azon gondolkodik, hogy ugyanazt a szolgáltatót használja a statikus webhelyhez. Ez teljesen rendben van. Ha azonban a régi webhelyet egy hagyományos CMS vagy más programozási nyelv tetejére építették, akkor lehet, hogy kétszer is át kell gondolnia.

A jelenlegi tárhelyet úgy méreteztük, hogy megfeleljen egy másik rendszer követelményeinek, vagy úgy tervezték, hogy egy adott beállítást támogasson, például PHP és MySQL vagy .NET és PostgreSQL. Tehát ha ez a helyzet, akkor valószínűleg a forgalom mennyiségét, a munkameneteket és az egyéb értékeket használta annak kiszámításához, hogy mekkora számítási teljesítményre lesz szüksége (vagy mint korábban, csak reméltem, hogy ez rendben lesz).

A statikus helyek megkönnyebbüléssel járnak: nincsenek bonyolultabb képletek, közelítések és szakmai találgatások. Egy csomó statikus fájlt minden webszerver könnyedén megtehet. A legfontosabb szempont az, hogy a szervernek már nem kell végigmennie az igények kezelésének kifinomult folyamatán. Csak statikus fájlokat szolgál ki helyette. És ez könnyű és gyors.

A statikus webhelyek tárolása ezért sokkal olcsóbb. Több tucat olyan szolgáltatás létezik, amelyek lehetővé teszik a webhelyek ingyen tárolását vagy legalább ingyenes kezdő terveket. Tartalmazzák:

  • GitHub oldalak
  • Netlify
  • Heroku
  • valamint más globális és helyi szolgáltatók. Természetesen használhat olyan globális webhely-hosting szolgáltatásokat is, mint például az Azure vagy az AWS.

Úgy döntöttem, hogy a GitHub oldalakat választom, mivel az összes tárhelyemet már a GitHub tárolja. Ez is teljesen ingyenes, és támogatja az egyedi 2. szintű domaineket.

Hogyan készíthetek és telepíthetek statikus webhelyet?

De nem csak a tárhelyről van szó. Az oldalak online elérhetősége elengedhetetlen, de ugyanolyan fontos átgondolni a telepítés teljes folyamatát. Vagyis - hogyan lehet a statikus oldalakat létrehozni és továbbítani a szerverre. Az első építéskor oldalakat generálhat a helyi környezetben, npx nuxt generateés a statikus fájlokat FTP-n keresztül másolhatja be a tárhelyre. De meg fogja ismételni ezt a folyamatot minden alkalommal, amikor tartalmi változás történik?

A statikus webhely telepítésének folyamata három részből áll:

  1. Trigger
  2. Épít
  3. Telepítés

Trigger

Új összeállításnak akkor kell megtörténnie, ha tartalmi vagy megvalósítási változás történik. Ez azt jelenti, hogy amikor egy tartalomszerkesztő új tartalmat tesz közzé egy fej nélküli CMS-ben, vagy ha megváltoztatja a forráskódot, akkor a webhelyet újjá kell építeni. De hogyan érhetjük el ezt?

Tartalomváltás kiváltója

Minden érett fej nélküli CMS tartalmaz webhorgot. Bizonyos típusú tevékenységről a szolgáltatás-szolgáltatás értesítést jelentenek. Tehát amikor egy szerkesztő közzétesz egy tartalmi elemet, a fej nélküli CMS kezdeményez egy webhook értesítést, amelyet egy meghatározott URL-re küld. Ebben az esetben egy build-kiszolgálóra, amely az értesítés alapján cselekszik, és újjáépíti a webhelyet.

De honnan tudja a build szerver, mit kell tennie? Nos, fogalma sincs arról, hogy milyen tartalmat tárol, és valószínűleg nem értené az általános webhook értesítést. Ezért középen egy egyszerű Azure-függvényt adtam hozzá, amely két dolgot végez - először azt ellenőrzi, hogy az értesítés eredete 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);}

(lásd a teljes fájlt a GitHubon)

majd elindítja a buildet a build kiszolgáló API-jával:

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

(lásd a teljes fájlt a GitHubon)

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. How to power up your website with Vue.js and minimal effort
  4. How to Mix Headless CMS with a Vue.js Website and Pay Zero
  5. How to Make Form Submissions Secure on an API Website
  6. Building a super-fast and secure website with a CMS is no big deal. Or is it?
  7. How to generate a static website with Vue.js in no time
  8. How to quickly set up a build process for a static site