Padrão de hospedagem de conteúdo estático

Implante conteúdo estático em um serviço de armazenamento baseado em nuvem que possa entregá-lo diretamente ao cliente. Essa abordagem pode reduzir a necessidade de instâncias de computação potencialmente caras.

Contexto e problema

Os aplicativos geralmente fornecem conteúdo que não requer processamento para cada solicitação. Os exemplos incluem páginas HTML, imagens, folhas de estilo, arquivos JavaScript do lado do cliente, documentos PDF e pacotes de software. Você pode gerar esse conteúdo durante um processo de build ou publicação e atualizá-lo de forma independente.

Embora os servidores Web sejam otimizados para renderização dinâmica e cache de saída, eles ainda precisarão lidar com solicitações para fazer o download de conteúdo estático. Atender a essas solicitações consome a capacidade de computação que o aplicativo poderia usar para solicitações dinâmicas.

Solution

Na maioria dos ambientes de hospedagem em nuvem, você pode colocar alguns dos recursos e páginas estáticas do aplicativo em um serviço de armazenamento. O serviço de armazenamento pode atender solicitações para esses recursos, reduzindo a carga nos recursos de computação que lidam com outras solicitações da Web.

O custo do armazenamento hospedado na nuvem normalmente é muito menor do que o custo para instâncias de computação. Se esse padrão reduz os custos de hospedagem depende do custo de computação que você pode evitar e do custo de armazenar e entregar o conteúdo.

Planeje como implantar o aplicativo e seus ativos estáticos e proteger recursos que não se destinam ao acesso anônimo.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

• Exponha um ponto de extremidade HTTP ou HTTPS para clientes, diretamente do armazenamento ou por meio de uma CDN (rede de distribuição de conteúdo) ou proxy reverso. Use HTTPS por padrão para proteger dados em trânsito.

  O HTTP pode ser apropriado para a distribuição pública de artefatos quando a confidencialidade não é necessária e os clientes verificam de forma independente a autenticidade e a integridade do conteúdo, por exemplo, validando assinaturas digitais em relação a um editor confiável.

• Considere usar uma CDN para armazenar conteúdo em cache perto de clientes e reduzir solicitações para a origem do armazenamento. Se seus clientes estiverem distribuídos globalmente, considere uma CDN global que armazene em cache o conteúdo do contêiner de armazenamento em locais de borda ao redor do mundo. O benefício depende das localizações dos clientes, dos padrões de solicitação e das taxas de acerto de cache.

• Compare os custos de armazenamento e entrega com os custos de computação que você pode evitar. Estimar os custos usando o tráfego esperado, tamanhos de ativos, locais do cliente e taxas de acerto de cache. O offloading reduzirá os custos de computação somente se reduzir o uso cobrado ou permitir que você reduza a capacidade do host.

• Selecione uma opção de redundância de armazenamento que atenda aos seus requisitos de disponibilidade e recuperação. Distinga a proteção contra uma interrupção de zona da proteção contra uma interrupção regional. A replicação entre regiões pode ser assíncrona, portanto, um local secundário pode não ter os ativos mais recentes.

  Uma CDN introduz outra dependência de entrega e seu cache pode não conter todos os ativos de que os clientes precisam durante uma interrupção de origem.

• Monitore a disponibilidade dos ativos, os tempos de resposta e as solicitações com falha ou limitadas em todo o armazenamento e em qualquer CDN ou proxy. Crie alertas para problemas de entrega.

• Coordenar implantações de aplicativos e ativos. Publique ativos alterados em URLs novas e com versão antes de implantar páginas que fazem referência a eles. Manter ativos mais antigos enquanto páginas armazenadas em cache, versões de aplicativo com suporte ou procedimentos de reversão ainda dependem deles.

  Configure as chaves de cache para distinguir versões de conteúdo e variantes. Além disso, escolha os tempos de vida do navegador e do cache da CDN deliberadamente. Alterar, excluir ou restringir o acesso ao conteúdo de origem não invalida cópias armazenadas em cache. Limpe os caches quando precisar, mas contabilize o tempo de propagação e lembre-se de que as limpezas de CDN não limpam os caches do navegador. Para obter mais informações, consulte o roteamento e o controle de versão da CDN e limpar o cache no Azure Front Door.

• Defina e verifique as propriedades HTTP, como Content-Type, Content-Encodinge Cache-Control ao implantar ativos para que os clientes interpretem e armazenem arquivos em cache corretamente. Para obter diretrizes específicas Azure, consulte as propriedades HTTP do Blob.

• Manipular URLs ao mover arquivos entre locais de armazenamento. Utilize o roteamento ou a reescrita de URL para manter os links existentes funcionando quando apenas o layout de armazenamento for alterado. Se uma URL pública precisar ser alterada, configure um redirecionamento na CDN, proxy reverso ou outro componente de serviço HTTP que dê suporte aos mapeamentos necessários. Para obter diretrizes relacionadas, consulte Preservar links quando o conteúdo for movido.

• Decida se os recursos estáticos devem usar a origem pública do aplicativo ou um nome de host separado. Um proxy reverso pode rotear caminhos de mesma origem para o armazenamento, portanto, o armazenamento separado nem sempre requer URLs absolutas distintas.

  Para solicitações de navegador entre origens que exigem CORS (compartilhamento de recursos entre origens), configure os cabeçalhos de resposta necessários. Para obter mais informações, consulte Usar Azure Front Door com blobs Armazenamento do Azure e suporte a CORS para Armazenamento do Azure.

• Permitir acesso de leitura anônimo somente para conteúdo que você pretende tornar público. A entrega pública pode usar uma origem de armazenamento que somente uma CDN ou proxy pode acessar. Restrinja o acesso de origem direta quando ele ignoraria os controles da camada de entrega.

  Mantenha o conteúdo privado em contêineres que exigem autorização. Restrinja as permissões para carregar, substituir ou excluir conteúdo hospedado a identidades de implantação confiáveis. Para obter mais informações, consulte Acesso seguro a origens de Azure Front Door.

• Considere usar uma chave de serviço ou um token para controlar o acesso a recursos que não devem estar disponíveis de forma anônima. Para downloads protegidos entregues por meio de uma CDN, desabilite o cache compartilhado, a menos que a camada de entrega valide as permissões de acesso em cada solicitação, mesmo ao servir uma resposta armazenada em cache. Para obter mais informações, consulte Valet Key pattern e Autenticação para conteúdo do Armazenamento de Blobs fornecido por meio do Azure Front Door.

Quando usar esse padrão

Esse padrão é útil para:

• Minimizar o custo de hospedagem de sites e aplicativos que contêm alguns recursos estáticos.

• Minimizar o custo de hospedagem de sites compostos somente por conteúdo e recursos estáticos. Dependendo das funcionalidades do sistema de armazenamento do provedor de hospedagem, seria possível hospedar inteiramente um site totalmente estático em uma conta de armazenamento.

• Expor os recursos e conteúdo estático para aplicativos em execução em outros ambientes de hospedagem ou nos servidores locais.

• Distribuir artefatos predefinidos, como pacotes de software, que os clientes podem baixar sem processamento por solicitação. Para artefatos públicos entregues por HTTP, os clientes devem ser capazes de verificar independentemente a autenticidade e a integridade. Para obter um exemplo dessa abordagem, consulte Segurança do Windows Update.

• Distribuindo conteúdo em mais de uma área geográfica usando uma rede de distribuição de conteúdo que armazena em cache o conteúdo da conta de armazenamento em vários datacenters ao redor do mundo.

• Monitorar os custos e uso de largura de banda. Usar uma conta de armazenamento separada para parte ou todo o conteúdo estático permite que os custos sejam separados mais facilmente dos custos de hospedagem e de runtime.

Esse padrão pode não ser adequado quando:

• O aplicativo deve processar ou personalizar o conteúdo de cada solicitação antes de entregá-lo. Por exemplo, talvez seja necessário inserir dados específicos do usuário em um documento.

• O volume do conteúdo estático é muito pequeno. A sobrecarga de recuperar o conteúdo do armazenamento separado pode superar o benefício de custo de separá-lo do recurso de computação.

Design de carga de trabalho

Avalie como usar o padrão de Hospedagem de Conteúdo Estático no design de uma carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:

Pilar	Como esse padrão apoia os objetivos do pilar
A otimização de custos se concentra em sustentar e melhorar o retorno sobre o investimento da sua carga de trabalho.	Transferir conteúdo estático para o armazenamento pode reduzir os custos de computação se isso reduzir o uso cobrado ou permitir que você reduza a capacidade do host do aplicativo. Geralmente, o uso de uma plataforma de aplicativo para fornecer conteúdo estático não é econômico. - CO:09 Custos de fluxo - CO:10 Custos dos dados
A Eficiência de Desempenho ajuda sua carga de trabalho a atender com eficiência às demandas por meio de otimizações no dimensionamento, nos dados e no código.	Transferir a entrega de conteúdo estático ajuda a reduzir o congestionamento e deixa os recursos de computação da aplicação disponíveis para a lógica de negócios. - PE:07 Código e infraestrutura

Se esse padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Example

A hospedagem de site estático do Armazenamento de Blobs do Azure serve arquivos públicos do contêiner $web por meio de solicitações anônimas somente para leitura. Por padrão, os arquivos têm uma URL em um subdomínio core.windows.net, como https://contoso.z4.web.core.windows.net/image.png. Você pode configurar um nome de domínio personalizado e usar Azure Front Door Standard ou Premium para acessar os arquivos por HTTPS. Para obter mais informações, consulte Mapear um domínio personalizado para um endpoint do Armazenamento de Blobs do Azure.

O aplicativo está no canto superior esquerdo e o cliente está abaixo dele. Um contêiner está no canto superior direito. Uma seta rotulada como "Entregar páginas que contêm links para arquivos no serviço de armazenamento" leva do aplicativo para o cliente. O contêiner contém dois grupos de arquivos: styles.css, sitecode.js, download.doc e samples.zip à esquerda e image1.png, image2.png e image3.png à direita. Uma linha com pontas de seta em ambas as extremidades conecta o cliente ao contêiner. Seu rótulo diz "Solicitar arquivos de um serviço de armazenamento".

O ponto de extremidade do site estático não dá suporte à autenticação ou autorização. Alterar o nível de acesso do contêiner $web ou desabilitar o acesso anônimo ao Blob na conta de armazenamento não torna esse ponto de extremidade privado. Não armazene conteúdo privado em $web. Para obter mais informações, consulte Impacto da configuração do nível de acesso no contêiner da Web.

Para fornecer conteúdo privado, armazene os arquivos em um contêiner de Armazenamento de Blobs privado separado e use o ponto de extremidade do serviço Blob em vez do ponto de extremidade do site estático. Depois de autorizar o cliente, emita uma SAS (assinatura de acesso compartilhado) de delegação de usuário de curta duração e somente leitura com escopo para os blobs necessários. Trate os tokens SAS como credenciais e distribua-os apenas por HTTPS. Para mais informações, veja Melhores práticas ao usar SAS.

Habilite Transferência segura obrigatória na conta de armazenamento para rejeitar solicitações HTTP. Para obter mais informações, consulte Exigir transferência segura.

Se os arquivos estáticos forem atendidos de um domínio diferente da página, crie links para as URLs completas, como https://static.contoso.com/image.png. Se um proxy reverso atender aos arquivos no domínio do aplicativo, você poderá usar caminhos como /image.png em vez disso. Se o recurso estiver protegido com uma SAS, inclua o token SAS na URL do recurso.

O ponto de extremidade do site estático não dá suporte às regras de CORS do Armazenamento do Azure. Se o cenário do navegador exigir acesso entre origens, use uma camada de entrega que forneça os cabeçalhos CORS necessários ou um ponto de extremidade que dê suporte à configuração do CORS.

O exemplo de Hospedagem de Conteúdo Estático demonstra como um cliente recupera recursos estáticos diretamente de Armazenamento de Blobs. Ele usa Bicep e o CLI do Azure para provisionar uma conta de armazenamento, habilitar a hospedagem de sites estáticos e carregar uma folha de estilos e uma página 404 personalizada no $web contêiner.

O exemplo gera um arquivo local index.html substituindo um espaço reservado em um modelo HTML pela URL do site estático da conta de armazenamento. Quando você abre esse arquivo em um navegador, o navegador carrega a folha de estilos diretamente do armazenamento. Em uma carga de trabalho implantada, a computação do aplicativo pode servir páginas que fazem referência a esses ativos hospedados no armazenamento.

Próxima etapa

• Use o Azure Front Door com blobs do Armazenamento do Azure. Aplique esse padrão com cache de borda, HTTPS e uma origem de armazenamento restrita.

Recurso relacionado

• Padrão de Chave Limitada. Se os recursos de destino não devem estar disponíveis para usuários anônimos, use esse padrão para restringir o acesso direto.