Escala ilimitada e hospedagem gratuita na Web com GitHub Pages e Cloudflare

Eu tenho um segredo que economiza muito dinheiro para meus clientes, mantém seu site seguro e tem backups integrados.

O segredo: eu deixo o site deles estático. Em seguida, armazeno e hospedo com o GitHub e uso o Cloudflare para servi-lo por HTTPS e torná-lo rápido. Meus clientes só pagam pelo nome de domínio, mas recebem muito mais do que esperavam.

Por que conteúdo estático?

Sites estáticos são maravilhosamente rápidos, pois não há tempo de processamento do servidor envolvido. Além disso, ao confirmar uma base de código de ativos estáticos em um repositório git, reverter as alterações simplesmente se torna uma questão de reverter para um commit anterior. Os backups são um git push away, e você essencialmente serve todo o seu site a partir do cache, o que significa que seu servidor quase nunca terá que processar uma solicitação novamente.

Construindo uma interface do usuário complexa?

Com o advento de frameworks front-end, como React e seus semelhantes, você pode criar experiências mágicas com nada mais do que HTML/CSS e JavaScript. Você terá que separar sua lógica de back-end do seu front-end, mas até o Ruby on Rails vem com um modo de API agora.

Sempre que sou contratado para construir um site, considero se um site estático é ou não suficiente para atender às necessidades do meu cliente e, em muitos casos, é.

Você está se perguntando que tipo de casos de uso eu tenho em mente? Excelente! Vamos discutir algumas situações em que você pode querer considerar o conteúdo estático e explicar como essa abordagem pode economizar tempo para você e seu cliente.

Sites de brochuras

Os sites de brochureware destinam-se a fornecer informações sobre uma empresa e não mudam significativamente ao longo de sua vida. Um aplicativo dinâmico é claramente um exagero para esses sites e, como esses sites não são mantidos por anos, recebendo poucas ou nenhuma atualização, geralmente são alvos fáceis para hackers, bem, hackear.

Os modelos HTML estáticos são significativamente mais baratos do que seus equivalentes CMS e são mais fáceis de ajustar no futuro. Os desenvolvedores solicitados a atualizar esses sites não exigem conhecimento especializado sobre um CMS específico. Como regra, sempre faço sites estáticos para sites de brochuras.

Bônus: Pequenas empresas adoram não pagar taxas mensais recorrentes de hospedagem. É verdade que a hospedagem não é um custo enorme, mas os clientes simplesmente não precisam se preocupar em pagar nada além do domínio, o que é ótimo.

Aplicativos de página única

Você está exibindo um novo aplicativo maravilhoso e legal que se baseia em estruturas front-end modernas?

Seu aplicativo já é principalmente estático. Siga algumas etapas extras para isolar qualquer lógica do lado do servidor em um aplicativo separado e obtenha todos os benefícios de ter seu aplicativo servido inteiramente do cache da Cloudflare.

Seu aplicativo estará disponível o tempo todo.

Blogues

Esta é uma venda difícil. É difícil convencer as pessoas de que sites estáticos podem ser usados ​​para blogs, mas leia-me – eu não fui ao fundo do poço.

Blogs nada mais são do que conteúdo renderizado com templates. Você simplesmente não precisa de um aplicativo completo analisando cada solicitação e renderizando uma nova página. Um site estático é perfeito para este caso de uso.

Considere Jekyll. Você fornece modelos Liquid e conteúdo Markdown e os combina em um site estático. Nenhum processamento em tempo real é necessário, e seu blog de repente parece significativamente mais rápido.

Esse fluxo de trabalho é especialmente útil porque as páginas do GitHub suportam compilações Jekyll. De repente, as postagens do blog podem ser contribuídas com solicitações pull e todo o seu conteúdo é armazenado no controle de versão. Os não desenvolvedores ainda podem contribuir com postagens no Markdown publicando suas postagens no Stackedit.

Na verdade, estou usando o Stackedit para compor este post agora mesmo!

Além disso, se você quiser comentários nas postagens do seu blog, o Disqus oferece um poderoso sistema de comentários inserindo um trecho de JavaScript.

Esta página que você está lendo também usa Disqus.

Páginas do GitHub

O GitHub Pages é a resposta do GitHub às páginas do projeto e permite servir qualquer site estático diretamente do seu repositório. Como as páginas do GitHub são compatíveis com domínios personalizados, você pode hospedar um site estático nas páginas do GitHub gratuitamente, com implantações diretamente do Git.

Implantando nas páginas do GitHub.

Chega de conversa, vamos ver em ação!

Eu fui em frente e fiz um aplicativo React de página única que busca e exibe a taxa de câmbio atual para a rúpia paquistanesa de uma API pública. Vamos implantar isso no GitHub Pages.

Primeiro, vamos criar um novo repositório GitHub.

As páginas do GitHub são servidas a partir de um branch chamado gh-pages então vamos criar um para o meu projeto.

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

E vamos empurrar o site para cima:

 $ 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 terminamos! Neste ponto, o site estará disponível em https://amingilani.github.io/price-check com SSL grátis:

Coisas importantes a serem observadas:

• As páginas do GitHub fornecem o arquivo index.html no branch gh-pages do seu projeto
• O site é servido em USERNAME.github.io/REPOSITORY-NAME

Personalizando o nome de domínio.

Servir o site fora do GitHub é bom, mas qualquer site decente precisa de um nome de domínio personalizado. Felizmente, o GitHub permite que você traga seu próprio domínio para a festa!

Primeiro, vamos criar um arquivo CNAME especial e colocar nosso nome de domínio lá. Isso permitirá que o GitHub saiba qual nome de domínio rotear para o repositório.

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

Segundo, vamos apontar um CNAME para nosso subdomínio para o DNS do GitHub em USERNAME.github.io :

Cuidado: NÃO use isso para um domínio apex! Adicionar um CNAME à raiz do seu domínio desativará seus registros MX e TXT . Use isso apenas para seu subdomínio. Os domínios do Apex são discutidos posteriormente.

Neste ponto, nosso site deve ser executado em nosso domínio personalizado em HTTP:

Coisas importantes a serem observadas:

• O domínio padrão *.github.io é servido por meio de HTTPS.
• Nosso nome de domínio personalizado é servido por meio de HTTP inseguro.
• NÃO use um CNAME em seu domínio apex, a menos que queira eliminar seus e-mails.

Limitações das páginas do GitHub:

• Os repositórios devem ter menos de 1 GB de tamanho de arquivo.
• Os sites devem ter menos de 1 GB de tamanho de arquivo.
• O limite mensal de largura de banda é de 100 GB. Vamos ignorar isso mais tarde.

Como usar um domínio apex como seu domínio personalizado

A maneira mais fácil de contornar essa limitação é usar www como seu subdomínio e redirecionar todo o tráfego HTTP do apex para www . No meu exemplo, eu redirecionaria gilani.me para www.gilani.me , que aponta para o meu site estático, mas não gosto de fazer as coisas da maneira mais fácil.

Se você realmente deseja usar um domínio apex, verifique se seu provedor de DNS permite definir registros ANAME . Estes são (simplificados) a meio caminho entre os registros CNAME , pois permitem que você aponte para domínios e registros A , pois não anulam outros registros na mesma zona.

Não ANAME ? A última opção é mudar para um provedor de DNS que suporte isso: digite Cloudflare. A Cloudflare fornece nivelamento de CNAME em domínios apex, que é o equivalente a um registro ANAME . É melhor fazer a troca agora, pois abordaremos a Cloudflare na próxima seção.

TLDR : Mude para o DNS gratuito da Cloudflare e defina um CNAME em seu domínio apex. Eles fazem algo especial com seu CNAME que o faz funcionar.

SSL e Cloudflare

Bem-vindo à era pós-Snowden. Todos os nossos piores temores de espionagem e hacking sancionados pelo governo foram confirmados, e o mundo está lutando para proteger dados em trânsito e em repouso.

Como um administrador da Web moderno, espera-se que você forneça pelo menos SSL em seu site, sem conteúdo misto .

Chegou ao ponto em que o Google Chrome marca sites HTTPS simples como inseguros e a Pesquisa do Google está começando a favorecer sites HTTPS de forma mais favorável em seus rankings. Discutiremos ainda mais estratégias para tornar seu front-end seguro mais tarde, mas, por enquanto, abordaremos apenas o SSL.

Felizmente, agora temos Let's Encrypt.

É uma Autoridade de Certificação (CA) sem fins lucrativos e totalmente automatizada que permite emitir certificados SSL de 90 dias de forma programática para qualquer domínio que você controle. É fácil de usar; é de código aberto; e o projeto é apoiado por uma infinidade de empresas, incluindo a Mozilla e a Electronic Frontier Foundation.

Fazendo bom uso do Cloudflare

Cloudflare é um serviço de proteção DNS, CDN e DDoS.

Ele armazena em cache seu site e o serve para usuários de servidores geograficamente próximos, tornando seu site mais rápido. Ele tem o benefício adicional de mantê-lo abaixo do limite de largura de banda de 100 GB do GitHub, porque mesmo que seu site se torne incrivelmente popular, a maioria das solicitações atingirá o cache e nunca chegará ao servidor.

Além disso, a Cloudflare oferece um serviço chamado Universal SSL, onde eles emitem um certificado SSL gratuito de seus parceiros de CA, para que você receba HTTPS de graça… para sempre.

Por que Cloudflare?

Eu sei o que você está pensando: Gilani, você acabou de me dizer como o Let's Encrypt é incrível. Por que você está falando sobre Cloudflare? Bem, tudo se resume à simplicidade.

Como um exercício mental, imagine configurar vários caches Nginx e proxies reversos em todo o mundo, fornecendo a todos os certificados SSL válidos e atendendo as páginas da Web dos usuários em seus locais mais próximos.

Isso faz com que seu site seja servido via SSL, mesmo que o servidor de origem não tenha um certificado SSL, embora a Cloudflare forneça certificados autoassinados especiais que você pode colocar em seu servidor de origem para proteger a conexão com os servidores da Cloudflare. É isso que a Cloudflare oferece com um plano gratuito e você nem precisa renovar seu certificado a cada 90 dias.

Como freelancer, recebo clientes que desejam um site funcionando para seus negócios o mais rápido possível. Eles não entendem ou se preocupam com questões de segurança, assolando a web moderna ou criptografia durante o trânsito. Alguns clientes lutam para entender a ideia de nomes de domínio e acham irritante quando precisam pagar uma taxa anual de US $ 15 “apenas para manter meu site funcionando”. Então, tente explicar a eles por que eles têm que pagar por um cluster de proxies reversos protegendo seu site que é executado em hospedagem gratuita.

Configurando o SSL da Cloudflare

Vamos sujar as mãos novamente. A primeira coisa a fazer é passar a rotear todo o seu tráfego pela Cloudflare:

Em seguida, em Crypto, defina o nível SSL como “Full”.

Forçar “Automatic HTTPS Rewrite” para eliminar avisos de conteúdo misto.

Neste ponto, nosso site funcionará em HTTP e HTTPS. Vamos forçar o HTTPS para tudo em nosso domínio.

Tudo feito. Nosso site deve sempre carregar por HTTPS com uma classificação verde “Seguro” no Chrome.

Palavras finais e considerações de segurança

Há algumas coisas que eu não discuti acima, e eu gostaria de tirar um momento para esclarecer alguns pontos.

Os mais astutos apontarão que existem alguns problemas de segurança gritantes com essa configuração, a saber, que não há cabeçalhos HTTP seguros como:

• Content-Security-Policy : carrega scripts e ativos de uma lista branca de hosts e pode não permitir js embutidos.
• X-Frame-Options : desativa o carregamento do seu site em um iframe.

E você está certo. As páginas do GitHub e até mesmo o Cloudflare não permitem que você personalize seus cabeçalhos HTTP . No entanto, você pode definir um CSP usando a meta HTML.

Basta inserir isso em sua página da web:

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

No entanto, no momento, não há uma maneira prática de definir o cabeçalho X-Frame-Options nas páginas do GitHub, o que significa que um invasor pode carregar sua página da Web em um iframe especialmente criado e realizar um ataque XSS. No entanto, se você for dedicado, poderá solucionar esse problema solicitando aos usuários que confirmem sua senha ou token 2FA em cada ação confidencial ou passando um token CSRF em cada solicitação autenticada.

Uma grande preocupação para alguns é que, ao usar os repositórios públicos gratuitos no GitHub, seu site e código-fonte estão disponíveis para qualquer pessoa que queira fazer um fork ou baixá-lo. Então eu acho que a preocupação aqui está equivocada.

O conteúdo estático não é código-fonte no sentido de que não é compilado ou processado como um script antes de ser entregue ao usuário. Seu usuário obterá exatamente a mesma cópia estática do site se executar um rastreador da Web apontado para seu site. Embora hospedar o código em um repositório do GitHub certamente facilite o download de uma cópia do seu site, ele não expõe nada que ainda não seja público.

Dimensionamento, dimensionamento ilimitado

As ideias apresentadas neste artigo não se limitam à hospedagem gratuita na web de pequenos aplicativos.

Você pode criar uma camada de front-end com base em uma estrutura JavaScript moderna, conectá-la a um Backend-as-a-Service (BaaS) baseado em nuvem de grande escala, como Firebase, e criar aplicativos complexos sem se preocupar com servidores, tempo de atividade, ou qualquer outro problema relacionado à infraestrutura.

Fazendo um novo jogo emocionante baseado na web?! Confira GameSparks, e você está pronto para ir.

Resumo, confissão e links

Neste artigo, fiz parecer que publiquei manualmente meu aplicativo React em gh-pages . Eu não fiz tal coisa. Trabalhei no master e, quando chegou a hora de implantar, executei npm run deploy que iniciou um script de compilação e empurrou a compilação para gh-pages . Por favor, veja o branch master do meu repositório para ver como ele funciona.

Aprendizado

Prós:

• Implantação instantânea
• Colaboração fácil
• Ambiente de hospedagem seguro

Ressalvas:

• Sem acesso a cabeçalhos HTTP
• Fácil de baixar uma cópia do site
• Necessário conhecimento GitHub
• Depende dos fornecedores de tecnologia

Links:

• Você encontrará o código-fonte do meu aplicativo em amingilani/price-check
• Este aplicativo está disponível em pricecheck.gilani.me e deve estar disponível indefinidamente.