Configurando uma instância de computação no Google Cloud via SSH, a sessão é fechada, todos os dados são perdidos?

Eu tenho uma nova instância do CentOS e gostaria de configurar o ambiente. Estou usando o SSH no navegador para configurar. Tudo vai bem com a instalação do apache e vários outros pacotes e eu posso usar o ip para obter a página padrão e uma página de teste php. Em algum momento, a sessão termina abruptamente. Vejo na página do Compute Engine que o IP foi alterado. Quando eu SSH nele novamente, é uma folha em branco e nenhuma das alterações que fiz estão lá. Esse comportamento é esperado? Acho que estou perdendo alguma coisa. Usuário do período de avaliação. O firewall está aberto ao tráfego http e https.

centos google-cloud-platform

— JV88V
fonte

que ponto é esse quando a sessão termina?

— Gaia

Este servidor faz parte de um grupo de dimensionamento automático (ou como o Google o chama)?

— EEAA 04/04

Sim, está em uma escala automática da CPU no limite de 80%, no mínimo 1, no máximo 6. Atualmente, a CPU está no uso de 0,00 a 0,03% - típica para uma máquina que não está servindo tráfego ao vivo. A sessão termina abruptamente, em um ponto em que terminou enquanto o yum estava instalando.

— JV88V

Passou por outra configuração e durou pelo menos 30 minutos, o que foi um bom sinal. Recarreguei a interface do site do Google Cloud e recebi a mensagem na janela SSH e o ícone de status da instância 'girou' até que um novo IP fosse exibido. A mensagem da janela SSH era "A conexão SSH com a instância da VM 'web-instance' foi perdida. Saiba mais sobre como melhorar a persistência da sessão SSH". O novo IP não contém nenhuma das atualizações ou instalações que foram feitas anteriormente.

— JV88V:

Ok, duas coisas aqui: primeiro, os servidores estão sendo desligados e substituídos provavelmente porque você tem a verificação de integridade mal configurada. Segundo, é claro que os novos servidores não transmitem suas alterações, porque são iniciados com uma imagem que não possui suas alterações.

Ao usar um grupo de dimensionamento automático, cada servidor deve: 1) ser completamente sem estado e 2) ter todo o código, configuração e dependências do aplicativo inseridos na imagem ou fazer com que o sistema se configure automaticamente na inicialização.

Eu recomendo que você dê um passo atrás em seu grupo de dimensionamento automático até conseguir entender melhor as coisas. Depois de configurar o servidor fora do grupo de dimensionamento automático, faça uma imagem dele e use-a ao configurar o grupo de dimensionamento automático.

Se você realmente deseja avançar no jogo, faça com que o servidor se configure na inicialização, usando um sistema de gerenciamento de configuração de sua escolha. Eu prefiro o Ansible por isso, mas qualquer um deles funcionará. O uso de um sistema de gerenciamento de configuração como esse não apenas permite rastrear alterações de configuração ao longo do tempo no controle de versão, mas também o mantém honesto, pois você tem certeza de que pode reconstruir um servidor a partir do zero automaticamente, dentro de minutos a qualquer momento , e quando as coisas precisam acontecer automaticamente, você não consegue configurar manualmente (isso é uma coisa muito boa).

— EEAA
fonte

Ótimos conselhos e insights. Não faço ideia por que esse problema rudimentar não é abordado nos documentos (ou pelo menos nas 6-7 horas que passei pesquisando). Estranho que o limite de 80% da CPU esteja sendo disparado.

— JV88V

Bem, provavelmente presume-se que os usuários entendam que todas as alterações feitas em uma instância são perdidas, devido ao fato de que cada instância é iniciada com a mesma imagem.

— EEAA