Posso usar o CloudFront para servir um blog WordPress do mesmo domínio, mas um servidor diferente?

3

Temos um site que servimos a partir do Elastic Beanstalk (AWS), e tudo funciona muito bem. Usamos o balanceador de carga interno para servir nosso site por HTTPS, etc. Nosso banco de dados é separado por meio do serviço RDS, não nas mesmas instâncias do EC2 que nossos servidores da Web. Estamos felizes com a configuração até agora.

Agora, gostaríamos de configurar um blog do WordPress em '/ blog' no domínio de nosso site (não separado ou subdomínio, por motivos de SEO). Nosso site é uma aplicação PHP customizada (usando o framework Laravel) e eu prefiro não hospedar o aplicativo WP e nosso site do mesmo lugar.

Acredito que podemos usar o CloudFront (CDN da Amazon) para servir apenas a parte / blog do nosso site e rotear essas solicitações para uma instalação separada do WP em diferentes instâncias do EC2. Eu usei o CloudFront para fazer tipos comuns de CDN (ativos estáticos), mas estou meio que perdendo para configurar esse tipo específico de configuração.

Primeiro, isso é uma idéia maluca, ou soa bem? Segundo, se é razoável, quais são as coisas que preciso saber para configurar isso?

    
por Sam McAfee 17.10.2015 / 21:19

1 resposta

5

Sim, você pode, se você configurar o site inteiro para ser executado por trás do CloudFront. Em seguida, você pode configurar o serviço de origem de back-end padrão para o site e criar uma exceção para seguir um caminho diferente para / blog.

Configure uma nova distribuição do CloudFront. Use o nome do host ELB ou EB do site principal como a origem. Configure o nome de domínio do site como um nome de domínio alternativo no CloudFront.

Em seguida, adicione uma segunda origem, com o destino sendo o nome do host em que a implantação do WP pode ser alcançada. Crie um comportamento com um padrão de caminho que corresponda a /blog* e usa a segunda origem.

(Se / blog * corresponde a alguma outra coisa está na raiz do site ... improvável, mas digamos que você tenha outra página na raiz chamada / blogosphere, isso seria incorretamente correspondido, então você realmente precisa criar dois patterns, / blog e / blog /*).

Gotcha: observe que ao criar uma origem, há uma caixa para caminho de origem . Isso provavelmente não faz o que você espera. Deixe em branco se não tiver certeza.

O caminho de origem é um prefixo que você deseja que a Cloudfront adicione à solicitação enviada para a origem, mesmo que ela não esteja visível no URL. Portanto, se você definir isso como / test e a solicitação do navegador for para / blog, o servidor de backend verá a solicitação chegar para / test / blog.

O caminho de origem permite que você prefixe o caminho que será solicitado, caso contrário, o caminho de entrada será enviado conforme recebido do navegador. Isso significa que na instalação do WP, a raiz do conteúdo precisa estar em /blog quando você se conectar diretamente ao servidor WP, não em / . Atualmente, o CloudFront não fornece nenhum mecanismo para remover componentes do caminho.

Lembre-se também de habilitar a string de consulta e o encaminhamento de cookies para o back-end do WordPress na medida em que for necessário para o WordPress funcionar conforme necessário. O mesmo é verdade para o seu site principal, é claro.

Você pode precisar da lista de permissões do Host: header se o seu servidor espera. Possivelmente outros, dependendo de quais cabeçalhos os servidores precisam ver, mas como regra geral, quanto mais cabeçalhos você encaminhar, menos o CloudFront pode fazer o cache, porque se ele encaminha um cabeçalho para a origem, ele deve assumir que qualquer solicitação subseqüente Cabeçalho varia pode receber uma resposta diferente do servidor, portanto, a solicitação não pode ser atendida a partir do cache, a menos que todos os cabeçalhos encaminhados correspondam.

Por fim, depois da configuração e dos testes, você apontaria seu nome de host para o ponto de extremidade do CloudFront e você estaria ativo.

    
por 17.10.2015 / 23:27