Scalabilità illimitata e hosting Web gratuito con GitHub Pages e Cloudflare

Pubblicato: 2022-03-11

Ho un segreto che fa risparmiare un sacco di soldi ai miei clienti, mantiene il loro sito Web sicuro e dispone di backup integrati.

Il segreto: rendo statico il loro sito web. Quindi, lo memorizzo e lo ospito con GitHub e uso Cloudflare per servirlo su HTTPS e renderlo veloce. I miei clienti pagano sempre e solo per il loro nome di dominio, ma ottengono molto di più di quanto non si aspettassero.

Perché contenuto statico?

I siti statici sono straordinariamente veloci poiché non sono necessari tempi di elaborazione del server. Inoltre, eseguendo il commit di una base di codice di risorse statiche in un repository git, il rollback delle modifiche diventa semplicemente una questione di ripristino di un commit precedente. I backup sono un git push e essenzialmente servi l'intero sito Web dalla cache, il che significa che il tuo server non dovrà quasi mai elaborare di nuovo una richiesta.

Costruire un'interfaccia utente complessa?

Con l'avvento dei framework front-end, come React e i suoi simili, puoi creare esperienze magiche con nient'altro che HTML/CSS e JavaScript. Tuttavia, dovrai separare la tua logica di back-end dal front-end, ma ora anche Ruby on Rails viene fornito con una modalità API.

Ogni volta che vengo incaricato di creare un sito Web, valuto se un sito statico sia sufficiente o meno per soddisfare le esigenze del mio cliente e, in molti casi, lo è.

Ti stai chiedendo che tipo di casi d'uso ho in mente? Grande! Discutiamo alcune situazioni in cui potresti voler considerare il contenuto statico e spieghiamo come questo approccio può far risparmiare tempo a te e al tuo cliente.

Siti web di brochure

I siti Web Brochureware hanno lo scopo di fornire informazioni su un'azienda e non cambiano in modo significativo nel corso della loro vita. Un'applicazione dinamica è chiaramente eccessiva per tali siti e, dal momento che questi siti non vengono mantenuti per anni, ricevendo pochi aggiornamenti o addirittura nessun aggiornamento, di solito sono facili bersagli per gli hacker che, beh, hackerano.

I modelli HTML statici sono significativamente più economici delle loro controparti CMS e sono più facili da modificare in futuro. Gli sviluppatori a cui è stato chiesto di aggiornare tali siti non richiedono conoscenze specialistiche su un particolare CMS. Di norma, realizzo sempre siti Web statici per siti di brochure.

Bonus: le piccole imprese amano non pagare canoni di hosting mensili ricorrenti. Certo, l'hosting non è un costo enorme, ma i clienti non devono preoccuparsi di pagare nient'altro che il dominio, il che è fantastico.

Applicazioni a pagina singola

Stai sfoggiando una nuova fantastica app che si basa su moderni framework front-end?

La tua applicazione è già per lo più statica. Esegui alcuni passaggi aggiuntivi per isolare qualsiasi logica lato server in un'applicazione separata e ottieni tutti i vantaggi di avere la tua app interamente servita dalla cache di Cloudflare.

La tua candidatura sarà sempre disponibile.

Blog

Questa è una vendita difficile. È difficile convincere le persone che i siti statici possono essere utilizzati per i blog, ma leggimi ad alta voce: non sono andato oltre.

I blog non sono altro che contenuti resi con modelli. Semplicemente non hai bisogno di un'applicazione in piena regola che analizzi ogni richiesta e visualizzi una nuova pagina. Un sito statico è perfetto per questo caso d'uso.

Considera Jekyll. Gli dai modelli Liquid e il contenuto Markdown e li combina insieme in un sito Web statico. Non è richiesta alcuna elaborazione al volo e il tuo blog sembra improvvisamente molto più veloce.

Questo flusso di lavoro è particolarmente utile perché le pagine GitHub supportano le build di Jekyll. Improvvisamente, i post del blog possono essere forniti con richieste pull e tutti i tuoi contenuti vengono archiviati nel controllo della versione. I non sviluppatori possono comunque contribuire con i propri post in Markdown pubblicando i propri post tramite Stackedit.

In effetti, sto usando Stackedit per comporre questo post proprio ora!

Inoltre, se desideri commenti sui post del tuo blog, Disqus ti offre un potente sistema di commenti inserendo uno snippet di JavaScript.

Questa pagina che stai leggendo utilizza anche Disqus.

Pagine GitHub

GitHub Pages è la risposta di GitHub alle pagine di progetto e ti consente di servire qualsiasi sito Web statico direttamente dal tuo repository. Poiché le pagine GitHub supportano domini personalizzati, puoi ospitare gratuitamente un sito Web statico su pagine GitHub, con distribuzioni direttamente da Git.

Distribuzione su GitHub Pages.

Basta parlare, vediamolo in azione!

Sono andato avanti e ho creato un'app React a pagina singola che recupera e mostra il tasso di cambio corrente per la rupia pakistana da un'API pubblica. Distribuiamolo su GitHub Pages.

Innanzitutto, creiamo un nuovo repository GitHub.

Uno screenshot della nuova schermata di creazione del repository di GitHub, con i campi "Proprietario" e "Nome del repository". Quest'ultimo ha il nome "price-check" compilato.

Le pagine GitHub sono servite da un ramo chiamato gh-pages quindi creiamone uno per il mio progetto.

 $ git checkout -b gh-pages Switched to a new branch 'gh-pages'

E spingiamo il sito verso l'alto:

 $ git remote add origin [email protected]:amingilani/price-check.git $ git push -u origin gh-pages Counting objects: 27, done. Delta compression using up to 8 threads. Compressing objects: 100% (25/25), done. Writing objects: 100% (27/27), 28.67 KiB | 0 bytes/s, done. Total 27 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), done. To github.com:amingilani/price-check.git * [new branch] gh-pages -> gh-pages

E abbiamo finito! A questo punto il sito sarà disponibile all'indirizzo https://amingilani.github.io/price-check con SSL gratuito:

La pagina "Welcome to Price Check" del sito ospitato sulle pagine GitHub, con un'etichetta Secure accanto al campo URL del browser.

Cose importanti da notare:

  • Le pagine GitHub servono il file index.html nel ramo gh-pages del tuo progetto
  • Il sito Web è servito all'indirizzo USERNAME.github.io/REPOSITORY-NAME

Personalizzazione del nome di dominio.

Servire il sito al di fuori di GitHub va bene, ma qualsiasi sito Web decente ha bisogno di un nome di dominio personalizzato. Fortunatamente, GitHub ti consente di portare il tuo dominio alla festa!

Per prima cosa, creiamo un file CNAME speciale e inseriamo lì il nostro nome di dominio. Ciò consentirà a GitHub di sapere quale nome di dominio instradare al repository.

 $ echo 'pricecheck.gilani.me' > CNAME $ git add . $ git commit -m 'Add a custom domain' ... $ git push ...

In secondo luogo, puntiamo un CNAME per il nostro sottodominio al DNS di GitHub su USERNAME.github.io :

Uno screenshot che mostra un menu a discesa con CNAME selezionato, il nome "pricecheck" digitato nel campo centrale e il dominio "amingilani.github.io" digitato nel campo di destra.

Attenzione: NON utilizzarlo per un dominio apex! L'aggiunta di un record CNAME alla radice del tuo dominio disabiliterà i tuoi record MX e TXT . Usalo solo per il tuo sottodominio. I domini Apex sono discussi più avanti.

A questo punto, il nostro sito Web dovrebbe essere eseguito sul nostro dominio personalizzato su HTTP:

La stessa pagina di controllo dei prezzi nel browser, ma ora accessibile tramite pricecheck.gilani.me. Questa volta l'etichetta Secure è assente.

Cose importanti da notare:

  • Il dominio *.github.io predefinito viene servito tramite HTTPS.
  • Il nostro nome di dominio personalizzato viene servito tramite HTTP non sicuro.
  • NON utilizzare un record CNAME sul tuo dominio apex a meno che tu non voglia uccidere le tue e-mail.

Limitazioni delle pagine GitHub:

  • I repository devono avere una dimensione del file inferiore a 1 GB.
  • I siti Web devono avere una dimensione del file inferiore a 1 GB.
  • Il limite di larghezza di banda mensile è di 100 GB. Lo ignoreremo in seguito.

Utilizzo di un dominio apex come dominio personalizzato

Il modo più semplice per aggirare questa limitazione è utilizzare www come sottodominio e reindirizzare tutto il traffico HTTP dall'apice a www . Nel mio esempio, reindirizzerei gilani.me a www.gilani.me , che punta al mio sito statico, ma non mi piace fare le cose nel modo più semplice.

Se vuoi davvero utilizzare un dominio apex, controlla se il tuo provider DNS ti consente di impostare record ANAME . Questi sono (semplificati) a metà strada tra i record CNAME poiché ti consentono di puntare a domini e record A poiché non annullano altri record sulla stessa zona.

Nessun ANAME ? L'ultima opzione è passare a un provider DNS che lo supporta: inserisci Cloudflare. Cloudflare fornisce l'appiattimento CNAME sui domini Apex, che è l'equivalente di un record ANAME . È meglio effettuare il passaggio in questo momento poiché tratteremo Cloudflare nella prossima sezione.

TLDR : passa al DNS gratuito di Cloudflare e imposta un CNAME sul tuo dominio apex. Fanno qualcosa di speciale con il loro CNAME che lo fa funzionare.

SSL e Cloudflare

Benvenuti nell'era post-Snowden. Tutti i nostri peggiori timori di ficcanaso e hacking sanzionati dal governo sono stati confermati e il mondo si sta affrettando per proteggere i dati in transito e inattivi.

In qualità di amministratore web moderno, devi fornire almeno SSL sul tuo sito web, senza contenuti misti .

Si è arrivati ​​al punto in cui Google Chrome contrassegna i siti Web HTTPS come non sicuri e la Ricerca Google sta iniziando a favorire i siti Web HTTPS in modo più favorevole nelle loro classifiche. Discuteremo ancora più strategie per rendere sicuro il tuo front-end in seguito, ma per ora tratteremo solo SSL.

Fortunatamente, ora abbiamo Let's Encrypt.

È un'autorità di certificazione (CA) senza scopo di lucro e completamente automatizzata che ti consente di emettere in modo programmatico certificati SSL a breve termine di 90 giorni per tutti i domini che controlli. È un gioco da ragazzi da usare; è open source; e il progetto è sostenuto da una pletora di aziende, tra cui Mozilla e Electronic Frontier Foundation.

Fare buon uso di Cloudflare

Cloudflare è un servizio di protezione DNS, CDN e DDoS.

Memorizza nella cache il tuo sito Web e lo offre agli utenti da server geograficamente vicini, rendendo il tuo sito Web più veloce. Ha l'ulteriore vantaggio di tenerti al di sotto del limite di larghezza di banda di 100 GB di GitHub perché anche se il tuo sito Web diventa follemente popolare, la maggior parte delle richieste raggiungerà la cache e non raggiungerà mai il server.

Inoltre, Cloudflare offre un servizio chiamato Universal SSL in cui ti rilasciano un certificato SSL gratuito dai loro partner CA, quindi ottieni HTTPS gratuitamente... per sempre.

Perché Cloudflare?

So cosa stai pensando: Gilani, mi hai appena detto quanto sia fantastico Let's Encrypt. Perché parli di Cloudflare? Bene, tutto si riduce alla semplicità.

Come esercizio mentale, immagina di configurare più cache Nginx e proxy inversi in tutto il mondo, fornendo loro tutti i certificati SSL validi e servendo le pagine Web degli utenti dalle posizioni più vicine.

Ciò comporta che il tuo sito Web venga servito tramite SSL anche se il server di origine non dispone di un certificato SSL, sebbene Cloudflare ti dia speciali certificati autofirmati che puoi inserire sul tuo server di origine per proteggere la connessione ai server di Cloudflare. Questo è ciò che Cloudflare ti offre con un piano gratuito e non devi nemmeno rinnovare il tuo certificato ogni 90 giorni.

Come libero professionista, ricevo clienti che desiderano un sito attivo e funzionante per la loro attività il più velocemente possibile. Non capiscono né si preoccupano dei problemi di sicurezza, dell'afflizione del Web moderno o della crittografia durante il transito. Alcuni clienti faticano a capire l'idea dei nomi di dominio e trovano fastidioso quando devono pagare una quota annuale di $ 15 "solo per mantenere in funzione il mio sito web". Quindi prova a spiegare loro perché devono pagare per un cluster di proxy inversi che proteggono il loro sito Web che funziona su hosting gratuito stesso.

Configurazione di Cloudflare SSL

Sporciamoci di nuovo le mani. La prima cosa da fare è passare all'instradamento di tutto il traffico tramite Cloudflare:

Uno screenshot della configurazione di Cloudflare, che mostra quattro copie di una coppia di righe CNAME in modo da poter vedere i suggerimenti sull'icona di configurazione di ciascuna riga, insieme alla configurazione finale desiderata. La coppia ha "amin" sopra "pricecheck" ed entrambe le righe dicono "è un alias di amingilan..." e "Automatico" nel mezzo. All'inizio, la riga superiore ha l'icona "DNS e HTTP proxy", ma la riga inferiore ha l'icona "Solo DNS". Facendo clic sull'icona, la riga inferiore viene commutata per essere la stessa della riga superiore, facendo diventare verde la riga inferiore e una piccola icona "i" accanto a "CNAME" scompare.

Quindi, in Cripto, imposta il livello SSL su "Completo".

Uno screenshot della sezione SSL, con un menu a discesa impostato su Off. Altre opzioni sono Flessibile, Completo e "Completo (rigoroso)". Quando si seleziona Completo, sotto l'elenco a discesa viene visualizzata un'etichetta verde "CERTIFICATO ATTIVO".

Forza "Riscrittura HTTPS automatica" per eliminare gli avvisi di contenuto misto.

Uno screenshot della sezione Riscritture HTTPS automatiche, che mostra l'interruttore che si sposta da Off a On.

A questo punto, il nostro sito web funzionerà sia su HTTP che HTTPS. Forziamo HTTPS per tutto sul nostro dominio.

Uno screenshot di una finestra di dialogo "Crea una regola di pagina per gilani.me". Il campo "Se l'URL corrisponde" ha "http://*gilani.me/*" compilato. La sezione "Allora le impostazioni sono" ha il suo campo a discesa impostato su "Usa sempre HTTPS".

Tutto fatto. Il nostro sito Web dovrebbe sempre essere caricato su HTTPS con una valutazione "Sicuro" verde in Chrome.

La stessa pagina di controllo dei prezzi in-browser di prima, sempre accessibile tramite pricecheck.gilani.me, ma questa volta l'etichetta Secure è ancora una volta presente.

Parole finali e considerazioni sulla sicurezza

Ci sono alcune cose che non ho discusso sopra e vorrei prendermi un momento per chiarire alcuni punti.

Gli astuti tra voi faranno notare che ci sono alcuni evidenti problemi di sicurezza con questa configurazione, vale a dire che non ci sono intestazioni HTTP sicure come:

  • Content-Security-Policy : carica script e risorse da una whitelist di host e può non consentire js inline.
  • X-Frame-Options : disabilita il caricamento del tuo sito Web in un iframe.

E hai ragione. Le pagine GitHub e persino Cloudflare non ti consentono di personalizzare le tue intestazioni HTTP . Tuttavia, puoi impostare un CSP utilizzando il meta tag HTML.

Basta inserirlo nella tua pagina web:

 <meta http-equiv="Content-Security-Policy" content="default-src https:">

Tuttavia, al momento, non esiste un modo pratico per impostare l'intestazione X-Frame-Options sulle pagine di GitHub, il che significa che un utente malintenzionato può caricare la tua pagina Web in un iframe appositamente predisposto ed eseguire un attacco XSS. Se sei dedicato, tuttavia, puoi aggirare questo problema chiedendo agli utenti di confermare la propria password o token 2FA su ogni azione sensibile o passando un token CSRF a ogni richiesta autenticata.

Una delle principali preoccupazioni per alcuni è che, utilizzando i repository pubblici gratuiti su GitHub, il tuo sito Web e il codice sorgente sono disponibili per chiunque desideri eseguirne il fork o scaricarlo. Quindi penso che la preoccupazione qui sia fuori luogo.

Il contenuto statico non è codice sorgente, nel senso che non viene compilato o elaborato come script prima di essere servito all'utente. Il tuo utente riceverà la stessa identica copia statica del sito web se dovesse eseguire un web crawler puntato al tuo sito web. Sebbene l'hosting del codice in un repository GitHub faciliti sicuramente il download di una copia del tuo sito Web, non espone nulla che non fosse già pubblico.

Ridimensionamento, Ridimensionamento illimitato

Le idee presentate in questo articolo non si limitano all'hosting web gratuito di piccole applicazioni.

Puoi creare un livello front-end basato su un moderno framework JavaScript, collegarlo a un Backend-as-a-Service (BaaS) basato su cloud su larga scala, come Firebase, e creare applicazioni complesse senza preoccuparti di server, uptime, o qualsiasi altro problema relativo all'infrastruttura.

Fare un nuovo entusiasmante gioco basato sul web?! Dai un'occhiata a GameSparks e sei a posto.

L'utilizzo di Github Pages come servizio di hosting "standard", che dovrebbe gestire siti Web con larghezza di banda elevata, è sconsigliato e non dovrebbe essere fatto. L'aggiunta di Cloudflare CDN sopra le pagine GitHub fa funzionare questa soluzione. Cloudflare è molto più di un servizio SSL gratuito. È un'azienda con una CDN globale che protegge il tuo sito Web dai picchi e riduce al minimo il carico sulle pagine di GitHub.

Riepilogo, confessione e collegamenti

In questo articolo, ho fatto sembrare che avessi pubblicato manualmente la mia app React su gh-pages . Non ho fatto una cosa del genere. Ho lavorato su master e quando è arrivato il momento di distribuire, ho eseguito npm run deploy che ha avviato uno script di build e ha inviato la build a gh-pages . Si prega di consultare il ramo master del mio repository per vedere come funziona.

Asporto

Professionisti:

  • Distribuzione istantanea
  • Facile collaborazione
  • Ambiente di hosting sicuro

Avvertenze:

  • Nessun accesso alle intestazioni HTTP
  • Facile da scaricare una copia del sito web
  • È richiesta la conoscenza di GitHub
  • Dipende dai fornitori di tecnologia

Collegamenti:

  • Troverai il codice sorgente della mia app su amingilani/price-check
  • Questa app è disponibile su pricecheck.gilani.me e dovrebbe essere disponibile a tempo indeterminato.