Échelle illimitée et hébergement Web gratuit avec GitHub Pages et Cloudflare

J'ai un secret qui permet à mes clients d'économiser une tonne d'argent, de sécuriser leur site Web et de disposer de sauvegardes intégrées.

Le secret : je rends leur site web statique. Ensuite, je le stocke et l'héberge avec GitHub, et j'utilise Cloudflare pour le servir via HTTPS, et le rendre rapide. Mes clients ne paient que pour leur nom de domaine, mais ils obtiennent bien plus que ce qu'ils avaient prévu.

Pourquoi du contenu statique ?

Les sites statiques sont merveilleusement rapides car il n'y a pas de temps de traitement du serveur impliqué. De plus, en validant une base de code d'actifs statiques dans un référentiel git, l'annulation des modifications revient simplement à revenir à un commit précédent. Les sauvegardes sont à portée de git push , et vous servez essentiellement l'intégralité de votre site Web à partir du cache, ce qui signifie que votre serveur n'aura presque plus jamais à traiter une demande.

Construire une interface utilisateur complexe ?

Avec l'avènement des frameworks frontaux, comme React et ses proches, vous pouvez créer des expériences magiques avec rien de plus que HTML/CSS et JavaScript. Vous devrez cependant séparer votre logique back-end de votre front-end, mais même Ruby on Rails est désormais livré avec un mode API.

Chaque fois que je reçois un contrat pour créer un site Web, je me demande si un site statique est suffisant ou non pour répondre aux besoins de mon client, et dans de nombreux cas, c'est le cas.

Vous vous demandez quel genre de cas d'utilisation j'ai en tête ? Génial! Discutons de certaines situations dans lesquelles vous voudrez peut-être envisager un contenu statique et expliquons comment cette approche peut vous faire gagner du temps, à vous et à votre client.

Sites Web de brochures

Les sites Web Brochureware sont destinés à fournir des informations sur une entreprise et ne changent pas de manière significative tout au long de leur vie. Une application dynamique est clairement exagérée pour de tels sites, et comme ces sites ne sont pas entretenus pendant des années, recevant peu ou pas de mises à jour, ils sont généralement des cibles faciles pour les pirates.

Les modèles HTML statiques sont nettement moins chers que leurs homologues CMS, et ils sont plus faciles à modifier à l'avenir. Les développeurs invités à mettre à jour ces sites n'ont pas besoin de connaissances spécialisées sur un CMS particulier. En règle générale, je crée toujours des sites Web statiques pour les sites de brochures.

Bonus : les petites entreprises adorent ne pas payer de frais d'hébergement mensuels récurrents. Certes, l'hébergement n'est pas un coût énorme, mais les clients n'ont tout simplement pas à se soucier de payer autre chose que le domaine, ce qui est formidable.

Demandes d'une seule page

Présentez-vous une nouvelle application merveilleuse et cool qui s'appuie sur des frameworks frontaux modernes ?

Votre application est déjà majoritairement statique. Prenez quelques mesures supplémentaires pour isoler toute logique côté serveur dans une application distincte et profitez pleinement du fait que votre application est entièrement servie à partir du cache de Cloudflare.

Votre application sera disponible à tout moment.

Blogues

C'est une vente difficile. Il est difficile de convaincre les gens que les sites statiques peuvent être utilisés pour les blogs, mais lisez-moi – je ne suis pas allé au fond des choses.

Les blogs ne sont rien de plus que du contenu rendu avec des modèles. Vous n'avez tout simplement pas besoin d'une application complète analysant chaque demande et affichant une nouvelle page. Un site statique est parfait pour ce cas d'utilisation.

Considérez Jekyll. Vous lui donnez des modèles Liquid et du contenu Markdown, et il les combine dans un site Web statique. Aucun traitement à la volée requis, et votre blog semble soudainement beaucoup plus rapide.

Ce flux de travail est particulièrement utile car les pages GitHub prennent en charge les builds Jekyll. Soudainement, les articles de blog peuvent être contribués avec des demandes d'extraction, et tout votre contenu est stocké dans le contrôle de version. Les non-développeurs peuvent toujours contribuer aux publications dans Markdown en publiant leurs publications via Stackedit.

En fait, j'utilise Stackedit pour rédiger ce post en ce moment !

De plus, si vous souhaitez des commentaires sur les articles de votre blog, Disqus vous offre un puissant système de commentaires en insérant un extrait de code JavaScript.

Cette page que vous lisez utilise également Disqus.

Pages GitHub

GitHub Pages est la réponse de GitHub aux pages de projet et vous permet de servir n'importe quel site Web statique directement à partir de votre référentiel. Étant donné que les pages GitHub prennent en charge les domaines personnalisés, vous pouvez héberger gratuitement un site Web statique sur les pages GitHub, avec des déploiements directement depuis Git.

Déploiement sur les pages GitHub.

Assez parlé, voyons-le en action !

Je suis allé de l'avant et j'ai créé une application React d'une seule page qui récupère et affiche le taux de change actuel de la roupie pakistanaise à partir d'une API publique. Déployons ceci sur les pages GitHub.

Commençons par créer un nouveau référentiel GitHub.

Les pages GitHub sont servies à partir d'une branche appelée gh-pages , alors créons-en une pour mon projet.

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

Et poussons le site vers le haut :

 $ 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

Et nous avons terminé ! À ce stade, le site Web sera disponible sur https://amingilani.github.io/price-check avec SSL gratuit :

Choses importantes à noter :

• Les pages GitHub servent le fichier index.html dans la branche gh-pages de votre projet
• Le site Web est servi à USERNAME.github.io/REPOSITORY-NAME

Personnalisation du nom de domaine.

Servir le site depuis GitHub est bien, mais tout site Web décent a besoin d'un nom de domaine personnalisé. Heureusement, GitHub vous permet d' apporter votre propre domaine à la fête !

Tout d'abord, créons un fichier CNAME spécial et plaçons-y notre nom de domaine. Cela permettra à GitHub de savoir quel nom de domaine acheminer vers le référentiel.

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

Deuxièmement, pointons un CNAME pour notre sous- domaine vers le DNS de GitHub à USERNAME.github.io :

Attention : ne l'utilisez PAS pour un domaine apex ! L'ajout d'un CNAME à la racine de votre domaine désactivera vos enregistrements MX et TXT . Utilisez-le uniquement pour votre sous-domaine. Les domaines Apex sont discutés plus tard.

À ce stade, notre site Web devrait fonctionner sur notre domaine personnalisé sur HTTP :

Choses importantes à noter :

• Le domaine *.github.io par défaut est servi via HTTPS.
• Notre nom de domaine personnalisé est servi via HTTP non sécurisé.
• N'utilisez PAS d' CNAME sur votre domaine apex, sauf si vous souhaitez supprimer vos e-mails.

Limites des pages GitHub :

• Les dépôts doivent avoir une taille de fichier inférieure à 1 Go.
• Les sites Web doivent avoir une taille de fichier inférieure à 1 Go.
• La limite mensuelle de bande passante est de 100 Go. Nous contournerons cela plus tard.

Utiliser un domaine apex comme domaine personnalisé

Le moyen le plus simple de contourner cette limitation consiste à utiliser www comme sous-domaine et à rediriger tout le trafic HTTP de l'apex vers www . Dans mon exemple, je redirigerais gilani.me vers www.gilani.me , qui pointe vers mon site statique, mais je n'aime pas faire les choses de manière simple.

Si vous voulez vraiment utiliser un domaine apex, vérifiez si votre fournisseur DNS vous permet de définir des enregistrements ANAME . Ceux-ci sont (simplifiés) à mi-chemin entre les CNAME puisqu'ils vous permettent de pointer vers des domaines et des enregistrements A puisqu'ils n'annulent pas les autres enregistrements sur la même zone.

Pas ANAME ? La dernière option consiste à passer à un fournisseur DNS qui prend en charge cela : entrez Cloudflare. Cloudflare fournit un aplatissement CNAME sur les domaines apex, ce qui équivaut à un enregistrement ANAME . Il est préférable de faire le changement dès maintenant puisque nous couvrirons Cloudflare dans la section suivante.

TLDR : Passez au DNS gratuit de Cloudflare et définissez un CNAME sur votre domaine apex. Ils font quelque chose de spécial avec leur CNAME qui le fait fonctionner.

SSL et Cloud Flare

Bienvenue dans l'ère post-Snowden. Toutes nos pires craintes d'espionnage et de piratage sanctionnées par le gouvernement ont été confirmées, et le monde se démène pour sécuriser les données en transit et au repos.

En tant qu'administrateur Web moderne, vous êtes censé fournir au moins SSL sur votre site Web, sans contenu mixte .

Nous en sommes arrivés au point où Google Chrome marque les sites Web HTTPS simples comme non sécurisés et la recherche Google commence à favoriser plus favorablement les sites Web HTTPS dans leur classement. Nous discuterons encore plus de stratégies pour sécuriser votre front-end plus tard, mais pour l'instant, nous ne couvrirons que SSL.

Heureusement, nous avons maintenant Let's Encrypt.

Il s'agit d'une autorité de certification (CA) à but non lucratif et entièrement automatisée qui vous permet d'émettre par programmation des certificats SSL à court terme de 90 jours pour tous les domaines que vous contrôlez. C'est un jeu d'enfant à utiliser ; c'est open source; et le projet est soutenu par une pléthore d'entreprises, dont Mozilla et l'Electronic Frontier Foundation.

Utiliser Cloudflare à bon escient

Cloudflare est un service de protection DNS, CDN et DDoS.

Il met votre site Web en cache et le propose aux utilisateurs à partir de serveurs géographiquement proches, ce qui rend votre site Web plus rapide. Il a l'avantage supplémentaire de vous maintenir sous la limite de bande passante de 100 Go de GitHub, car même si votre site Web devient incroyablement populaire, la plupart des requêtes atteindront le cache et n'atteindront jamais le serveur.

En plus de cela, Cloudflare propose un service appelé Universal SSL où ils vous délivrent un certificat SSL gratuit de leurs partenaires CA, vous obtenez donc HTTPS gratuitement… pour toujours.

Pourquoi Cloud Flare ?

Je sais ce que vous pensez : Gilani, vous venez de me dire à quel point Let's Encrypt est génial. Pourquoi parlez-vous de Cloudflare ? Eh bien, tout se résume à la simplicité.

En tant qu'exercice mental, imaginez la configuration de plusieurs caches Nginx et de proxys inverses dans le monde entier, en leur donnant tous les certificats SSL valides et en servant les pages Web des utilisateurs à partir de leurs emplacements les plus proches.

Il en résulte que votre site Web est servi via SSL même si le serveur d'origine n'a pas de certificat SSL, bien que Cloudflare vous fournisse des certificats auto-signés spéciaux que vous pouvez mettre sur votre serveur d'origine pour sécuriser la connexion jusqu'aux serveurs de Cloudflare. C'est ce que Cloudflare vous offre avec un plan gratuit, et vous n'avez même pas besoin de renouveler votre certificat tous les 90 jours.

En tant que pigiste, je reçois des clients qui veulent un site opérationnel pour leur entreprise le plus rapidement possible. Ils ne comprennent pas ou ne se soucient pas des problèmes de sécurité, du Web moderne ou du cryptage pendant le transit. Certains clients ont du mal à comprendre l'idée des noms de domaine et trouvent cela ennuyeux lorsqu'ils doivent payer des frais annuels de 15 $ "juste pour que mon site Web continue de fonctionner". Essayez donc de leur expliquer pourquoi ils doivent payer pour un groupe de proxys inverses protégeant leur site Web qui fonctionne lui-même sur un hébergement gratuit.

Configuration de SSL Cloudflare

Mettons-nous les mains dans le cambouis. La première chose à faire est de passer au routage de tout votre trafic via Cloudflare :

Ensuite, sous Crypto, définissez le niveau SSL sur "Complet".

Forcez la "réécriture HTTPS automatique" pour supprimer les avertissements de contenu mixte.

À ce stade, notre site Web fonctionnera à la fois sur HTTP et HTTPS. Forçons HTTPS pour tout sur notre domaine.

Terminé. Notre site Web doit toujours se charger via HTTPS avec une note verte "Sécurisé" dans Chrome.

Derniers mots et considérations de sécurité

Il y a quelques points dont je n'ai pas parlé ci-dessus, et j'aimerais prendre un moment pour clarifier quelques points.

Les plus astucieux d'entre vous remarqueront qu'il y a quelques problèmes de sécurité flagrants avec cette configuration, à savoir qu'il n'y a pas d'en-têtes HTTP sécurisés comme :

• Content-Security-Policy : charge les scripts et les actifs à partir d'une liste blanche d'hôtes et peut interdire les js en ligne.
• X-Frame-Options : empêche votre site Web d'être chargé dans une iframe.

Et vous avez raison. Les pages GitHub et même Cloudflare ne vous permettent pas de personnaliser vos en-têtes HTTP . Cependant, vous pouvez définir un CSP à l'aide de la balise meta HTML.

Insérez simplement ceci dans votre page Web :

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

Cependant, pour le moment, il n'existe aucun moyen pratique de définir l'en-tête X-Frame-Options sur les pages GitHub, ce qui signifie qu'un attaquant peut charger votre page Web dans un iframe spécialement conçu et lancer une attaque XSS. Si vous êtes dédié, cependant, vous pouvez contourner ce problème en demandant aux utilisateurs de confirmer leur mot de passe ou leur jeton 2FA à chaque action sensible, ou en transmettant un jeton CSRF à chaque demande authentifiée.

Une préoccupation majeure pour certains est qu'en utilisant les référentiels publics gratuits de GitHub, votre site Web et votre code source sont disponibles pour quiconque souhaite le bifurquer ou le télécharger. Je pense donc que la préoccupation ici est déplacée.

Le contenu statique n'est pas du code source dans le sens où il n'est pas compilé ou traité comme un script avant d'être servi à l'utilisateur. Votre utilisateur obtiendra exactement la même copie statique du site Web s'il exécutait un robot d'indexation pointant vers votre site Web. Bien que l'hébergement du code dans un référentiel GitHub facilite certainement le téléchargement d'une copie de votre site Web, il n'expose rien qui n'était pas déjà public.

Mise à l'échelle, mise à l'échelle illimitée

Les idées présentées dans cet article ne se limitent pas à l'hébergement web gratuit de petites applications.

Vous pouvez créer une couche frontale basée sur un framework JavaScript moderne, la connecter à un Backend-as-a-Service (BaaS) basé sur le cloud à grande échelle, comme Firebase, et créer des applications complexes sans vous soucier des serveurs, de la disponibilité, ou tout autre problème lié à l'infrastructure.

Faire un nouveau jeu passionnant basé sur le Web ? ! Découvrez GameSparks et vous êtes prêt à partir.

Résumé, confession et liens

Dans cet article, j'ai fait apparaître comme si j'avais publié manuellement mon application React sur gh-pages . Je n'ai rien fait de tel. J'ai travaillé sur master et au moment du déploiement, j'ai exécuté npm run deploy qui a lancé un script de construction et poussé la construction vers gh-pages . Veuillez consulter la branche master de mon référentiel pour voir comment cela fonctionne.

Plats à emporter

Avantages:

• Déploiement instantané
• Collaboration facile
• Environnement d'hébergement sécurisé

Mises en garde :

• Pas d'accès aux en-têtes HTTP
• Téléchargement facile d'une copie du site Web
• Connaissance de GitHub requise
• Dépend des fournisseurs de technologie

Liens:

• Vous trouverez le code source de mon application sur amingilani/price-check
• Cette application est en direct sur pricecheck.gilani.me et devrait être disponible indéfiniment.