O scară nelimitată și găzduire web gratuită cu Pagini GitHub și Cloudflare

Am un secret care economisește clienții mei o mulțime de bani, păstrează site-ul lor în siguranță și are copii de siguranță încorporate.

Secretul: le fac site-ul static. Apoi, îl stochez și îl găzduiesc cu GitHub și folosesc Cloudflare pentru a-l servi prin HTTPS și pentru a-l face rapid. Clienții mei plătesc întotdeauna doar pentru numele lor de domeniu, dar primesc mult mai mult decât s-au târzit vreodată.

De ce conținut static?

Site-urile statice sunt extraordinar de rapide, deoarece nu este implicat timp de procesare a serverului. De asemenea, prin comiterea unei baze de cod de active statice într-un depozit git, anularea modificărilor devine pur și simplu o chestiune de revenire la o comitere anterioară. Backup-urile sunt git push de îndepărtat și, în esență, vă serviți întregul site din cache, ceea ce înseamnă că serverul dvs. nu va mai fi nevoit să proceseze o solicitare din nou.

Construirea unei interfețe de utilizare complexă?

Odată cu apariția framework-urilor front-end, cum ar fi React și rudele sale, puteți crea experiențe magice cu nimic mai mult decât HTML/CSS și JavaScript. Totuși, va trebui să vă separați logica back-end de front-end, dar chiar și Ruby on Rails este livrat cu un mod API acum.

Ori de câte ori sunt contractat pentru construirea unui site web, mă gândesc dacă un site static este sau nu suficient pentru a satisface nevoile clientului meu și, în multe cazuri, este.

Vă întrebați ce fel de cazuri de utilizare am în minte? Grozav! Să discutăm câteva situații în care ați putea dori să luați în considerare conținutul static și să explicăm cum această abordare vă poate economisi timp atât dvs., cât și clientului dvs.

Site-uri web pentru broșuri

Site-urile web brochureware sunt menite să ofere informații despre o afacere și nu se schimbă semnificativ de-a lungul vieții. O aplicație dinamică este în mod clar exagerată pentru astfel de site-uri și, din moment ce aceste site-uri rămân neîntreținute ani de zile, primind puține actualizări, dacă nu există, de obicei, ele sunt ținte ușoare pentru hackeri, ei bine, să pirateze.

Șabloanele HTML statice sunt semnificativ mai ieftine decât omologii lor CMS și sunt mai ușor de modificat în viitor. Dezvoltatorii cărora li se solicită să actualizeze astfel de site-uri nu necesită cunoștințe de specialitate despre un anumit CMS. De regulă, fac întotdeauna site-uri web statice pentru site-uri cu broșuri.

Bonus: întreprinderilor mici le place să nu plătească taxe lunare de găzduire recurente. Desigur, găzduirea nu este un cost uriaș, dar clienții pur și simplu nu trebuie să se chinuie să plătească altceva decât domeniul, ceea ce este grozav.

Aplicații cu o singură pagină

Prezinți o nouă aplicație minunată și cool, care se bazează pe framework-uri front-end moderne?

Aplicația dvs. este deja în mare parte statică. Faceți câțiva pași suplimentari pentru a izola orice logică din partea serverului într-o aplicație separată și obțineți beneficiul complet de a vă servi aplicația în întregime din memoria cache Cloudflare.

Aplicația dvs. va fi disponibilă în orice moment.

Bloguri

Aceasta este o vânzare grea. Este greu să-i convingi pe oameni că site-urile statice pot fi folosite pentru bloguri, dar citește-mă – nu am trecut la capăt.

Blogurile nu sunt altceva decât conținut redat cu șabloane. Pur și simplu nu aveți nevoie de o aplicație completă care analizează fiecare cerere și redă o pagină nouă. Un site static este perfect pentru acest caz de utilizare.

Luați în considerare Jekyll. Îi oferiți șabloane Liquid și conținut Markdown și le combină într-un site web static. Nu este necesară procesarea din mers, iar blogul tău se simte brusc mult mai rapid.

Acest flux de lucru este util în special deoarece paginile GitHub acceptă versiuni Jekyll. Dintr-o dată, postările de blog pot fi contribuite cu solicitări de extragere, iar tot conținutul tău este stocat în controlul versiunilor. Non-dezvoltatorii pot contribui în continuare cu postări în Markdown publicându-și postările prin Stackedit.

De fapt, folosesc Stackedit pentru a compune această postare chiar acum!

De asemenea, dacă doriți comentarii la postările de pe blog, Disqus vă oferă un sistem puternic de comentarii prin inserarea unui fragment de JavaScript.

Această pagină pe care o citiți folosește și Disqus.

Pagini GitHub

GitHub Pages este răspunsul GitHub la paginile de proiect și vă permite să serviți orice site web static direct din depozitul dvs. Deoarece paginile GitHub acceptă domenii personalizate, puteți găzdui un site web static pe paginile GitHub gratuit, cu implementări direct din Git.

Implementarea în paginile GitHub.

Destul de vorbă, să vedem în acțiune!

Am continuat și am creat o singură pagină React care preia și afișează cursul de schimb curent pentru rupia pakistaneză dintr-un API public. Să implementăm acest lucru în paginile GitHub.

Mai întâi, să creăm un nou depozit GitHub.

Paginile GitHub sunt servite dintr-o ramură numită gh-pages așa că haideți să creăm una pentru proiectul meu.

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

Și să ridicăm site-ul:

 $ 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

Și am terminat! În acest moment, site-ul web va fi disponibil la https://amingilani.github.io/price-check cu SSL gratuit:

Lucruri importante de reținut:

• Paginile GitHub servesc fișierul index.html în ramura gh-pages a proiectului dumneavoastră
• Site-ul web este difuzat la USERNAME.github.io/REPOSITORY-NAME

Personalizarea numelui de domeniu.

Servirea site-ului în afara GitHub este bine, dar orice site decent are nevoie de un nume de domeniu personalizat. Din fericire, GitHub vă permite să vă aduceți propriul domeniu la petrecere!

Mai întâi, să creăm un fișier CNAME special și să plasăm acolo numele nostru de domeniu. Acest lucru va permite GitHub să știe ce nume de domeniu să direcționeze către depozit.

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

În al doilea rând, să îndreptăm un CNAME pentru subdomeniul nostru către DNS-ul GitHub la USERNAME.github.io :

Atenție: NU utilizați acest lucru pentru un domeniu apex! Adăugarea unei înregistrări CNAME la rădăcina domeniului dvs. va dezactiva înregistrările dvs. MX și TXT . Utilizați acest lucru numai pentru subdomeniul dvs. Domeniile Apex sunt discutate mai târziu.

În acest moment, site-ul nostru ar trebui să ruleze pe domeniul nostru personalizat pe HTTP:

Lucruri importante de reținut:

• Domeniul implicit *.github.io este deservit prin HTTPS.
• Numele nostru de domeniu personalizat este oferit prin HTTP nesecurizat.
• NU utilizați o înregistrare CNAME pe domeniul dvs. apex decât dacă doriți să vă distrugeți e-mailurile.

Limitări ale paginilor GitHub:

• Repos trebuie să aibă dimensiunea fișierului mai mică de 1 GB.
• Site-urile web trebuie să aibă dimensiunea fișierului mai mică de 1 GB.
• Limita lunară de lățime de bandă este de 100 GB. Vom ocoli asta mai târziu.

Folosind un domeniu apex ca domeniu personalizat

Cel mai simplu mod de a ocoli această limitare este să utilizați www ca subdomeniu și să redirecționați tot traficul HTTP de la vârf la www . În exemplul meu, aș redirecționa gilani.me către www.gilani.me , care indică site-ul meu static, dar nu-mi place să fac lucrurile pe calea ușoară.

Dacă doriți cu adevărat să utilizați un domeniu apex, verificați dacă furnizorul DNS vă permite să setați înregistrări ANAME . Acestea sunt (simplificate) la jumătatea distanței dintre înregistrările CNAME , deoarece vă permit să indicați domenii și înregistrările A , deoarece nu anulează alte înregistrări din aceeași zonă.

Fără ANAME ? Ultima opțiune este să treceți la un furnizor DNS care acceptă acest lucru: introduceți Cloudflare. Cloudflare oferă aplatizare CNAME pe domeniile apex, care este echivalentul unei înregistrări ANAME . Cel mai bine este să faceți schimbarea chiar acum, deoarece vom acoperi Cloudflare în secțiunea următoare.

TLDR : Comutați la DNS-ul gratuit Cloudflare și setați un CNAME pe domeniul dvs. apex. Ei fac ceva special cu CNAME care îl face să funcționeze.

SSL și Cloudflare

Bun venit în era post-Snowden. Toate cele mai mari temeri ale noastre de spionaj și piraterie sancționate de guvern au fost confirmate, iar lumea se luptă pentru a securiza datele în tranzit și în repaus.

În calitate de administrator web modern, trebuie să furnizați cel puțin SSL pe site-ul dvs., fără conținut mixt .

S-a ajuns la punctul în care Google Chrome marchează site-urile simple HTTPS ca nesigure, iar Căutarea Google începe să favorizeze site-urile HTTPS mai favorabil în clasamentele lor. Vom discuta mai târziu și mai multe strategii pentru a vă asigura front-end-ul în siguranță, dar deocamdată vom acoperi doar SSL.

Din fericire, acum avem Let's Encrypt.

Este o autoritate de certificare (CA) nonprofit și complet automatizată, care vă permite să emiteți în mod programatic certificate SSL pe termen scurt de 90 de zile pentru orice domeniu pe care îl controlați. Este ușor de folosit; este open source; iar proiectul este susținut de o multitudine de companii, inclusiv Mozilla și Electronic Frontier Foundation.

Folosind Cloudflare

Cloudflare este un serviciu de protecție DNS, CDN și DDoS.

Îți memorează site-ul în cache și îl servește utilizatorilor de pe serverele apropiate geografic, făcând site-ul tău mai rapid. Are avantajul suplimentar de a vă menține sub limita de lățime de bandă de 100 GB a GitHub, deoarece, chiar dacă site-ul dvs. devine nebun de popular, majoritatea solicitărilor vor ajunge în cache și nu vor ajunge niciodată la server.

În plus, Cloudflare oferă un serviciu numit Universal SSL în care vă eliberează un certificat SSL gratuit de la partenerii lor CA, astfel încât să obțineți HTTPS gratuit... pentru totdeauna.

De ce Cloudflare?

Știu la ce te gândești: Gilani, tocmai mi-ai spus cât de minunat este Let's Encrypt. De ce vorbești despre Cloudflare? Ei bine, totul se rezumă la simplitate.

Ca un exercițiu mental, imaginați-vă că configurați mai multe cache Nginx și proxy inverse în întreaga lume, oferindu-le tuturor certificate SSL valide și servind paginile web ale utilizatorilor din cele mai apropiate locații ale acestora.

Astfel, site-ul dvs. este servit prin SSL, chiar dacă serverul de origine nu are un certificat SSL, deși Cloudflare vă oferă certificate speciale autosemnate pe care le puteți pune pe serverul de origine pentru a securiza conexiunea la serverele Cloudflare. Acesta este ceea ce vă oferă Cloudflare cu un plan gratuit și nici măcar nu trebuie să vă reînnoiți certificatul la fiecare 90 de zile.

În calitate de freelancer, primesc clienți care doresc un site să funcționeze cât mai repede posibil pentru afacerea lor. Nu înțeleg și nu le pasă de problemele de securitate, care afectează web-ul modern sau criptarea în timpul tranzitului. Unii clienți se chinuie să înțeleagă ideea numelor de domenii și consideră că este enervant când trebuie să plătească o taxă anuală de 15 USD „doar pentru a-mi menține site-ul în funcțiune”. Așa că încercați să le explicați de ce trebuie să plătească pentru un grup de proxy inverse care își protejează site-ul web care rulează pe găzduire gratuită.

Configurarea Cloudflare SSL

Să ne murdărim din nou mâinile. Primul lucru de făcut, treceți la rutarea întregului trafic prin Cloudflare:

Apoi, sub Crypto, setați nivelul SSL la „Complet”.

Forțați „Rescrierea automată HTTPS” pentru a elimina avertismentele de conținut mixt.

În acest moment, site-ul nostru web va funcționa atât prin HTTP, cât și prin HTTPS. Să forțăm HTTPS pentru tot ce se află pe domeniul nostru.

Totul este gata. Site-ul nostru ar trebui să se încarce întotdeauna prin HTTPS cu o evaluare verde „Securizat” în Chrome.

Cuvinte finale și considerații de securitate

Sunt câteva lucruri pe care nu le-am discutat mai sus și aș dori să îmi iau un moment pentru a clarifica câteva puncte.

Cei înțelepți dintre voi vor sublinia că există câteva probleme de securitate flagrante cu această configurare, și anume că nu există anteturi HTTP sigure precum:

• Content-Security-Policy : încarcă scripturi și materiale dintr-o listă albă de gazde și poate interzice js inline.
• X-Frame-Options : dezactivează încărcarea site-ului dvs. într-un iframe.

Și ai dreptate. Paginile GitHub și chiar Cloudflare nu vă permit să vă personalizați anteturile HTTP . Cu toate acestea, puteți seta un CSP folosind meta HTML.

Pur și simplu introduceți acest lucru în pagina dvs. web:

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

Cu toate acestea, în acest moment, nu există o modalitate practică de a seta antetul X-Frame-Options pe paginile GitHub, ceea ce înseamnă că un atacator vă poate încărca pagina web într-un iframe special creat și poate realiza un atac XSS. Dacă sunteți dedicat, totuși, puteți rezolva această problemă solicitând utilizatorilor să-și confirme parola sau simbolul 2FA la fiecare acțiune sensibilă sau prin transmiterea unui simbol CSRF la fiecare solicitare autentificată.

O preocupare majoră pentru unii este că, prin utilizarea depozitelor publice gratuite de la GitHub, site-ul dvs. web și codul sursă sunt disponibile pentru oricine dorește să le descarce. Așa că cred că preocuparea de aici este greșită.

Conținutul static nu este cod sursă, în sensul că nu este compilat sau procesat ca script înainte de a fi oferit utilizatorului. Utilizatorul dvs. va primi exact aceeași copie statică a site-ului web dacă ar rula un crawler web îndreptat către site-ul dvs. Deși găzduirea codului într-un depozit GitHub face cu siguranță descărcarea mai ușoară a unei copii a site-ului dvs., nu expune nimic care nu a fost deja public.

Scalare, scalare nelimitată

Ideile prezentate în acest articol nu se limitează la găzduirea web gratuită a aplicațiilor mici.

Puteți construi un strat front-end bazat pe un cadru JavaScript modern, îl puteți conecta la un Backend-as-a-Service (BaaS) bazat pe cloud la scară largă, cum ar fi Firebase și puteți crea aplicații complexe fără a vă face griji cu privire la servere, timpul de funcționare, sau orice altă problemă legată de infrastructură.

Creați un nou joc interesant bazat pe web?! Verificați GameSparks și sunteți gata.

Rezumat, mărturisire și linkuri

În acest articol, am făcut să pară că am publicat manual aplicația mea React pe gh-pages . Nu am făcut așa ceva. Am lucrat la master și când a venit timpul să implementez, am rulat npm run deploy care a lansat un script de compilare și a împins compilarea la gh-pages . Vă rugăm să vedeți ramura master a depozitului meu pentru a vedea cum funcționează.

Concluzii

Pro:

• Implementare instantanee
• Colaborare ușoară
• Mediu de găzduire securizat

Avertismente:

• Nu există acces la antetele HTTP
• Ușor de descărcat o copie a site-ului
• Sunt necesare cunoștințe GitHub
• Depinde de furnizorii de tehnologie

Linkuri:

• Veți găsi codul sursă pentru aplicația mea la amingilani/price-check
• Această aplicație este live la pricecheck.gilani.me și ar trebui să fie disponibilă pe termen nelimitat.