Implementação em azul / verde - AWS Cloudfront com ELB como origem personalizada

Question

Eu tenho a seguinte configuração:

Cloudfront - ELB - AutoScalingGroup - EC2s

• O Cloudfront serve file-[hash].js arquivos (com chunkhash em seus nomes) de origem personalizada (ELB).
• Os EC2s veiculam o arquivo file-[hash].js para o arquivo index.html gerado pela nuvem, além de que o arquivo .js apropriado é exibido na Cloudfront.
• o ELB tem a drenagem de conexão ativada.

Tudo funciona bem até que uma implantação do Cloudformation com um ativo alterado seja acionada (digamos de file-1.js para file-2.js ) - quando a nova versão está sendo ativada, há uma janela de tempo curto quando o navegador obtém a nova% arquivoindex.html apontando para file-2.js , mas quando tenta baixar file-2.js obtém 404 da Cloudfront, mostrando assim um erro para o usuário.

Entendo que isso ocorre porque a implantação de azul / verde funciona - ou seja, há um tempo em que duas versões do aplicativo funcionam simultaneamente e o ELB pode redirecionar uma solicitação para a nova versão (solicitação para index.html do navegador) e segunda um para a versão antiga (solicitação para file-2.js da Cloudfront).

Os documentos da Cloudfront dizem que você deve "hospedar e servir o mesmo conteúdo em todos os servidores. ", mas como posso conseguir isso durante a implantação? É possível impor que apenas uma única versão do aplicativo seja acessível por meio do ELB a qualquer momento, para que a Cloudfront nunca obtenha 404 para os novos recursos?

Se não, existem outras opções para resolver isso, além de mudar de origem personalizada para S3? (gostaria de evitá-lo devido à complexidade de implantação / manutenção)

Observação: a mudança da política de atualização AutoScalingRollingUpdate para AutoScalingReplacingUpdate não ajudou:

 asg:
    Type: AWS::AutoScaling::AutoScalingGroup
    CreationPolicy:
      ResourceSignal:
        Count:
          Ref: 2
        Timeout: PT10M
    UpdatePolicy:
      AutoScalingReplacingUpdate:
        WillReplace: true

    

Answer 1

Acho que a solução para isso é manter os arquivos .js estáticos no S3 e manter as versões anteriores junto com as novas durante a publicação de novos aplicativos.

O CloudFront exibirá o conteúdo estático do S3 e o conteúdo dinâmico do EC2.

Publique o conteúdo estático no S3 primeiro e inicie a transição.

Nesse caso, a página de índice gerada dinamicamente se referiria a um bucket S3 na versão antiga e outro no novo. Como os dois recursos sempre resolvem no S3, não haverá 404.