Como restaurar o Linode para VM Vagrant?

Question

Estou tentando configurar um ambiente de desenvolvimento Linux para que eu possa fazer alterações com segurança no meu site sem violar o site ao vivo.

O Linode hospeda meu site ativo. Uma solução simples seria hospedar meu servidor de desenvolvimento no Linode também, mas eu quero evitar dobrar meus custos de hospedagem.

A maneira mais barata que vejo é usar o Vagrant na minha estação de trabalho Windows para hospedar meu ambiente de desenvolvimento.

Depois de tentar restaurar o backup no Vagrant e reiniciar a VM, não consigo mais ssh no host do Vagrant.

Provavelmente porque, ao restaurar o backup, eu sobrescrevo algumas configurações especiais do Vagrant, mas não sei como evitar isso.

Como faço essa abordagem funcionar? Se minha abordagem é fundamentalmente errada, você pode sugerir uma alternativa?

Criando o backup

No Linode usei esses comandos para criar uma cópia compactada de todo o sistema de arquivos, ignorando coisas que não deveriam ser incluídas no backup:

$ sudo rsync -ahvz --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/backup/*} /* /backup/2
$ sudo tar -czf /backup/2.gz /backup/2

O arquivo de backup é chamado 2.gz porque este é o segundo backup. O primeiro backup é chamado 1.gz .

Eu uso o WinSCP para copiar o arquivo de backup para minha estação de trabalho Windows.

Configurando o host do Vagabundo

Eu preciso de uma caixa Vagrant que corresponda ao meu sistema operacional Linode (Ubuntu 12.04.3 LTS, kernel 3.9.3). Eu selecionei o jogo do armário de vagrantbox.es :

Ubuntu Server Precise 12.04.3 amd64
Kernel is ready for Docker (Docker not included)

Na minha estação de trabalho eu executei estes comandos para adicionar a caixa e inicializar e inicializar uma instância:

$ vagrant box add ubuntu-precise http://nitron-vagrant.s3-website-us-east-1.amazonaws.com/vagrant_ubuntu_12.04.3_amd64_virtualbox.box
$ mkdir linode-test
$ cd linode-test
$ vagrant init ubuntu-precise
$ vagrant up

Agora o Vagrant está executando uma máquina com SSH na porta 2222.

A versão do sistema operacional é a mesma. A versão do kernel é 3.8.0. Soa perto o suficiente.

Restaurando o backup

Com o WinSCP, copiei o arquivo de backup 2.gz para /home/vagrant/2.gz na caixa do Vagrant.

Com o PuTTY, conectei via ssh à minha nova caixa Vagrant:

Na caixa, mova o backup para a raiz do sistema de arquivos.

$ sudo mv 2.gz /

Extraia o arquivo para a raiz do sistema de arquivos:

$ sudo tar -xvpz -f 2.gz -C / --strip-components=2

(descobri que preciso usar componentes de strip porque todos os arquivos no archive têm o prefixo backup/2/ . Vou corrigir isso para o próximo backup.)

Após o comando tar terminar, eu saio da caixa.

Testando o backup

Quando eu tento fazer login novamente, ele não me deixa mais entrar como vagrant com uma senha.

Ele me faz logar como iain, meu usuário no Live Linode, com uma senha. Isso me surpreendeu porque eu desativei a autenticação de senha no meu Linode ao vivo. Eu percebi que tenho que reiniciar o serviço ssh para que a alteração entre em vigor.

Em vez de reiniciar apenas o ssh, optei por reiniciar todo o sistema.

Agora não consigo nem acessar a tela de login. PuTTY diz "conexão recusada" quando tento conectar.

O que deu errado?

    

Answer 1

A razão pela qual você não pode mais se logar como vagrant é porque você fez o backup em / etc que contém sombra . Como o arquivo shadow do linode não contém uma entrada para o usuário vagabundo, ele não permitirá que você faça login com essas credenciais. Você poderia efetuar login usando seu usuário linode porque as credenciais estão no arquivo / etc / shadow, mas o daemon ssh estava usando as configurações padrão que permitem autenticação de senha para todos. Se estava tudo bem, você poderia apenas recarregar o serviço ssh para pegar a nova configuração (aquela do seu backup que desativa a autenticação de senha).

No entanto, algo deve ter corrido mal durante a restauração. Das informações fornecidas, só posso fazer suposições sobre o quê, e gostaria de evitar isso. No entanto, se você abrir a janela de gerenciamento de caixa virtual com a caixa vagrant desligada, poderá iniciar a máquina virtual normalmente. Isso permitirá que você veja quaisquer erros apresentados no console. Se nenhum erro estiver presente, pelo menos permitirá que você efetue login usando o console (ao contrário do SSH). Você pode usar sua conta normal para ter acesso e olhar em volta para ver o que está errado. Algo em / var / log apontará você na direção correta (provavelmente / var / log / syslog).

    

Answer 2

Depois de alguns ajustes, você provavelmente fará com que sua abordagem funcione principalmente, mas sugiro uma abordagem completamente diferente.

Para manter a configuração geral dos servidores live e dev em sincronia, use o fantoche para implantar, ou apenas seja muito cuidadoso. Para sincronização de seu código da web e arquivos enviados, o rsync está OK, defina o que você deseja incluir e mantenha-o restrito. Apenas o aplicativo, não todo o sistema. Em vez de usar o rsync, você pode querer usar o git ou outro sistema de controle de revisão. Faça check-in das alterações no dev e, em seguida, verifique-as para viver. Em algum lugar da pista, você pode automatizar isso com um sistema de implantação contínua.

Você provavelmente também precisará de uma maneira de sincronizar o conteúdo do banco de dados. Não conte apenas copiando os arquivos em que o mysql armazena seus dados, a menos que você esteja preparado para usar os mecanismos de banco de dados em ambas as extremidades enquanto você faz isso, ou você tem algum tipo de mecanismo de snapshot no nível do sistema de arquivos LVM).

Você pode querer combinar a sincronização de atualizações de dados de vivo para dev com seu sistema de backup. ou seja, faça backups de live e recupere-os para dev. Isso é bom porque você está constantemente verificando seus backups, mas se você estiver fazendo o backup diariamente, a recuperação do backup de ontem poderá ser inconvenientemente antiga.

Talvez seja um exagero. Provavelmente parece um pouco mais do que realmente é agora. Pelo menos entender o modelo como algo para se mover ao longo do tempo.