Como usar o terraform.io para mudar a imagem de um servidor com estado sem tempo de inatividade ou perda de dados?

Question

Digamos que eu tenha servidores de aplicativos, servidores de banco de dados e alguns balanceadores de carga dns-round-robin. Tudo isso alimentado por imagens criadas com Packer com implantação gerenciada com Terraform . Como eu mudo a imagem dos servidores de banco de dados sem danificar seus dados quando as instâncias são destruídas e recriadas?

A coisa mais simples que posso imaginar seria desativar as gravações, fazer o instantâneo do banco de dados e restaurar o instantâneo para os novos servidores. Mas parece muito errado contar com esse trabalho manual, e também parece errado descartar o serviço para uma atualização simples. Existe uma maneira mais limpa e melhor, né?

    

Answer 1

Não há uma resposta simples para essa pergunta.

O uso de uma arquitetura projetada em torno de imagens (comumente chamada de "infraestrutura imutável") funciona fantasticamente para serviços sem estado, como seus servidores de aplicativos.

É definitivamente possível expandi-lo para seus serviços com estado, com as ferramentas certas, sistemas de failover e caminhos de upgrade, mas esses são geralmente um exagero para sistemas simples (como o que você descreve).

Uma coisa a ter em mente ao usar essas ferramentas é que você não precisa ir all-in. Packer e Terraform são muito projetados para funcionar somente onde você os deseja. Eles não impõem um padrão em todos os seus sistemas de propósito.

Praticamente falando, a melhor maneira de lidar com esse problema é manter seus servidores de banco de dados de forma diferente, fora do Packer (construindo a imagem inicial, sim! Mas não necessariamente atualizando-os da mesma forma que os servidores da web stateless) ou terceirizando o gerenciamento do Estado para outra pessoa. Opções notáveis incluem Heroku Postgres ou AWS RDS.

Para completar, sim, é possível, mas com o nosso ferramental atual é provavelmente mais um problema do que vale a pena em menor escala ou com arquiteturas simples.

O Packer e o Terraform ainda podem ser um enorme benefício em outros aspectos da mesma infra-estrutura - o Terraform, por exemplo, poderia fornecer um banco de dados Heroku para uso em seus servidores do DigitalOcean Application de uma forma muito direta. O Packer pode lidar com a atualização e liberação de imagens do servidor de aplicativos e também para o desenvolvimento.

    

Answer 2

Acho que o Terraform agora tem os recursos necessários aqui. O padrão básico é definir seus volumes de dados separadamente e anexá-los às instâncias, para que quando a instância for destruída e uma nova criada (por exemplo, de uma nova AMI criada pelo Packer) o volume existente possa ser anexado à nova instância.

Então os passos detalhados com o Terraform seriam:

• define aws_ebs_volume resources
• anexe-as a suas instâncias com aws_volume_attachment (aqui eu usei device_name = "/dev/xvdh" )
• certifique-se de que o recurso aws_ebs_volume inclua a regra ciclo de vida prevent_destroy = true (para que eles nunca sejam excluídos por terraform)
• verifique se o recurso aws_volume_attachment inclui skip_destroy = true (em upgrade o terraform não conseguiria destruí-los enquanto o volume estiver montado, e parar as instâncias destruirá o anexo de qualquer maneira, então não há necessidade de terraform para tentar isso)

A etapa final é garantir que a instância monte o volume na inicialização. O que pode ser obtido com o seguinte no user_data do seu recurso aws_instance :

#!/bin/bash
mkdir /data #create mount point
mount /dev/xvdh /data #mount it

Para o acima funcionar, você precisará preparar o volume criando um sistema de arquivos, mas isso só é necessário uma vez:

mkfs -t ext4 /dev/xvdh

Mais detalhes estão disponíveis em edição da Terraform # 2740 .