Acho que você tem algum mal-entendido e a resposta correta (da visão externa) depende da sua configuração exata.
- O processo de destruir uma caixa (VM) é acionado por
vagrant destroy
. Isso joga todos os dados de distância. No seu caso, você desliga a VM (usandovagrant down
). - Como você marcou esta postagem com o chefe , parece que seu servidor é provisionado por meio do Chef e também da pilha inteira para executar o Django nele, não é?
- Se as receitas de seu chef forem escritas corretamente (ou: com a intenção de atualizar seu aplicativo), a execução de um provisionamento atualizará seu código na VM. Nas versões antigas do Vagrant (IIRC < 1.3), o provisionamento é feito em
vagrant reload
. Em versões mais recentes, você teria que adicionar a opção--provision
, no entanto, isso nem é necessário. Para acionar uma corrida de chef, basta ligar paravagrant provision
. Isso acaba com o chef sem recarregar a caixa inteira (ou seja, se as receitas do chef estiverem corretas, não são necessárias). - A frase usada com frequência "se as receitas do seu chef estiverem corretas" significa que as receitas devem, obviamente, fazer o que for necessário para não apenas trazer as alterações de código para a caixa, mas também fazer as coisas necessárias para ativá-las (liberando caches, reiniciando serviços, etc.). Mas isso depende muito ... eu diria no Django. Se isso estiver faltando, o
down
/up
pode ter ajudado você porque, por exemplo, parou e iniciou o Apache (após a reinicialização). - Você só precisa ter certeza de que a mesma coisa que agora executa manualmente via SSH também é acionada pela receita do Chef.
Não tenho certeza de onde o comando run
está vindo. Não encontrei nada relacionado ao Django.
Sem mais código, é difícil fornecer dicas detalhadas.
Mas provisionar seu código na VM e recarregar as coisas é exatamente um caso de uso para o Vagrant.