Balanceamento de carga na Amazon (AWS) e manter-se atualizado

Question

Eu gostaria de ter um balanceador de carga para o meu site e ter o site atualizado. O balanceador de carga levará a AMI que eu selecionar e aumentará mais dessas instâncias quando o poder de processamento atingir um determinado nível. O problema é que a AMI pode não estar atualizada, então vou ter algumas instâncias atualizadas e outras não. Quando implanto, posso implantar em todas as instâncias do balanceador de carga sem problemas, mas precisaria saber sempre que o balanceador de carga gira uma nova instância para acionar essa implantação. Também haveria um período de tempo em que as atualizações acontecem diminuindo muito sua capacidade de resposta. Então eu criei um plano.

Meu plano:

Após implantar:

    identify one of the instances and
        get instance id
    identify volume of instance id
    ec2-create-snapshot vol-yyyyyyyy
        get snapshot volume id
    ec2reg -s snap-zzzzzzzz -a x86 -d Description -n imagename
        get image id
    as-delete-launch-config existinglaunchconfig
    as-create-launch-config mylaunchconfig --image-id IMAGEID --instance-type m1.small --key mykey --group mysecuritygroup
    as-update-auto-scaling-group --launch-configuration mylaunchconfig

Antes de eu ir e passar muitas horas tentando descobrir isso e escrever tudo, testar e tudo mais, minha pergunta é: isso funcionará? Existe uma maneira melhor? Existe um tutorial ou post que alguém sabe que iria acelerar meus esforços sobre esta questão? Obrigado.

    

Answer 1

Uma abordagem diferente que pode funcionar com a AWS é armazenar o site / data / config atualizado em algum lugar como o S3. Configure a AMI (ou especifique o script de dados do usuário apropriado) para que, quando uma nova instância for girada, ela se atualize. Você pode impedir que ele seja adicionado ao balanceador de carga por não responder positivamente à verificação de integridade até que as atualizações sejam concluídas.

Caso contrário, se você precisar que as instâncias surjam mais rapidamente, sua abordagem parece razoável. Apenas certifique-se de suspender o dimensionamento automático antes de começar a atualizar as instâncias ativas e continuar após a nova configuração de inicialização. Você não quer que ele inicie instâncias que não são atualizadas.

Eu também não tenho certeza se você pode excluir uma configuração de inicialização que está em uso por um ELB. Esse passo pode ter que esperar até depois de ter sido substituído. Poste uma atualização aqui quando descobrir.

    

Answer 2

Eu tive o mesmo problema que você. Eu tenho um grupo de escalonamento automático que aumenta um pouco com o tráfego e eu envio atualizações o tempo todo, mesmo sob carga de pico. Minha solução é um pouco mais complicada, pois preciso de uma área de teste para poder testar minhas atualizações de código antes que elas atinjam os servidores ativos. Em seu nível mais simples, aqui está como eu construo / atualizo meus servidores.

Criar base AMI - Esta é a AMI sem nenhum código-fonte. Essa AMI pode ser agrupada com aplicativos de terceiros que você precisa ou não. Por exemplo, um dos meus servidores eu preciso de AppFabric, IIS, AWSSDK.NET e .NET 4.0. Eu instalo todas essas ferramentas e salvo o ami. Meus servidores linux eu faço isso em tempo de execução, pois é muito mais rápido.

Armazenar código-fonte no S3 ou SVN - Quando o servidor inicia, ele pega o código mais recente do SVN ou S3. Para atualizar os servidores existentes, basta terminá-los um de cada vez ou em grupos, e o grupo Auto Scaling iniciará outro com o código mais recente.

Dependendo de quão tolerante o seu serviço é para falhas, você também pode implementar um servidor de armazenamento temporário como se eu tivesse que testar o novo código antes que os pedidos começassem a ser enviados. Minha configuração requer dois grupos de dimensionamento automático. O primeiro grupo é basicamente minha camada de segurança e autenticação, que usa o código php. Depois que a solicitação é validada, ela é encaminhada para outro grupo de escalonamento automático.

Atualizações na camada de autenticação de segurança ainda exigem as etapas explicadas por mim e por Eric Hammond. No entanto, tento não atualizar muito esse código, ele não contém nenhuma lógica de negócios e quase nunca muda. As alterações nessa camada sempre devem ser compatíveis com versões anteriores, de modo que, se você fizer atualizações, poderá ter duas versões dos servidores on-line ao mesmo tempo, sem problemas.

Atualizações na camada de negócios é onde aplico todas as alterações de código para atualizar recursos, corrigir bugs etc. O truque é criar outro grupo de dimensionamento automático / balanceador de carga ao fazer atualizações com seus próprios servidores e código (novamente SVN ou S3). ). Depois de testado, você atualiza o servidor dns local (supondo que você tenha um) e a camada de autenticação de segurança começa a usar automaticamente os novos servidores.

Editar: Esqueceu de adicionar este link link . Tem algumas informações muito boas sobre como resolver esse tipo de problema e algumas outras coisas que você pode ou não saber sobre o aws.