Temos um site que atendemos a partir do Elastic Beanstalk (AWS) e tudo funciona muito bem. Usamos o balanceador de carga integrado para servir nosso site por HTTPS, etc. Nosso banco de dados é separado por meio do serviço RDS, não nas mesmas instâncias EC2 que nossos servidores web. Estamos felizes com a configuração até agora.
Agora, gostaríamos de configurar um blog WordPress em '/blog' no domínio do nosso site (não um subdomínio ou separado, por motivos de SEO). Nosso site é um aplicativo PHP personalizado (usando a estrutura Laravel) e prefiro não hospedar o aplicativo WP e nosso site no mesmo local.
Acredito que podemos usar o CloudFront (CDN da Amazon) para atender apenas a parte /blog do nosso site e encaminhar essas solicitações para uma instalação separada do WP em diferentes instâncias do EC2. Eu usei o CloudFront para fazer o tipo de CDN normal (recursos estáticos), mas estou meio perdido em como definir esse tipo específico de configuração.
Primeiro, essa é uma ideia maluca ou parece boa? Em segundo lugar, se for razoável, quais são as coisas que preciso saber para configurar isso?
Sim, você pode, se configurar todo o site para ser executado atrá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 de host ELB ou EB do site principal como 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 onde a implantação do WP pode ser alcançada. Crie um comportamento com um padrão de caminho que corresponda
/blog*e use a segunda origem.(Se /blog* corresponder a qualquer outra coisa na raiz do site... improvável, mas digamos que você tenha outra página na raiz chamada /blogosphere, isso seria correspondido incorretamente, então você realmente precisa criar dois padrões, / blog e /blog/*).
Pegadinha: observe que, ao criar uma origem, há uma caixa para o 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 o Cloudfront anexe à solicitação que envia para a origem, mesmo que não esteja visível na URL. Portanto, se você definir isso como /test e a solicitação do navegador for para /blog, o servidor de back-end verá a solicitação chegar para /test/blog.
O caminho de origem permite que você anexe ao caminho que será solicitado, caso contrário, o caminho de entrada é enviado conforme recebido do navegador. Isso significa que, na instalação do WP, a raiz do conteúdo precisa estar
/blogquando 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 cadeia de consulta e o encaminhamento de cookies para o back-end do WordPress na medida necessária para que o WordPress funcione conforme necessário. O mesmo vale para o seu site principal, é claro.
Você pode precisar colocar o cabeçalho na lista de permissões
Host:se o seu servidor o espera. Possivelmente outros, dependendo de quais cabeçalhos os servidores precisam ver, mas como regra, quanto mais cabeçalhos você encaminhar, menos cache o CloudFront pode fazer, porque se encaminhar um cabeçalho para a origem, ele deve assumir que qualquer solicitação subsequente em que esse cabeçalho varia pode receber uma resposta diferente do servidor, portanto, a solicitação não pode ser atendida do cache, a menos que todos os cabeçalhos encaminhados correspondam.Por fim, depois da configuração e do teste, você apontaria seu nome de host para o endpoint do CloudFront e estaria ativo.