Esta página descreve quando e por que criar modelos de instância determinística. Os modelos de instância determinísticos deixam explicitamente claro o tipo de serviços ou aplicativos de terceiros a serem instalados em suas instâncias quando o modelo de instância é implantado. Ao criar modelos de instância determinísticos, você minimiza a ambiguidade e o comportamento inesperado de seus modelos de instância.
Por que criar modelos de instâncias determinísticas
Em geral, recomendamos que as propriedades do seu modelo de instância sejam tão explícitas e determinísticas quanto possível. Se você empregar scripts de inicialização em seus modelos de instância que instalam ou usam serviços de terceiros, certifique-se de que esses scripts forneçam informações explícitas, como a versão do aplicativo a ser instalada. O Compute Engine só pode confiar nas informações definidas no modelo e não tem controle sobre os serviços de terceiros referenciados. Se o seu modelo for muito vago, o modelo da sua instância poderá se comportar de forma inesperada.
Por exemplo, considere o seguinte comando para criar um modelo de instância com um script de inicialização que instala o Apache2 e usa um arquivo hospedado em um servidor externo:
gcloud compute instance-templates create example-template-with-startup \
--image-family debian-9 \
--image-project debian-cloud \
--metadata startup-script='#! /bin/bash
sudo apt install -y apache2
scp myuser@108.59.87.185:index.php /var/www/'
Existem dois problemas potenciais com este script de inicialização:
- O script não define explicitamente qual versão do Apache2 instalar e depende da versão atual disponível no repositório
apt
. - O script depende de um arquivo hospedado em terceiros que não tem versão e pode ter sido alterado desde a última vez que o modelo de instância foi usado.
Se você usar um autoescalador , um modelo de instância não determinístico poderá fazer com que o autoescalador adicione novas instâncias a um grupo de instâncias gerenciadas com uma configuração diferente, como uma versão diferente do Apache2.
Da mesma forma, se você aplicou esse modelo a um grupo de instâncias gerenciadas, atualizou o grupo para um serviço de modelo diferente e decidiu reverter para o modelo anterior, poderá acabar com instâncias que usam uma versão diferente do arquivo apache2 ou index.php daquela antes da atualização, porque suas instâncias sempre buscariam a versão mais recente na inicialização.
Evitando comportamento ambíguo ou inesperado do modelo de instância
Para evitar comportamento inesperado do modelo, use um dos seguintes métodos:
Use imagens otimizadas para contêineres ou Docker, com tags Docker. Por exemplo, recomendamos que você atribua novas tags para cada nova construção de sua imagem Docker e use essas tags em seus modelos de instância em vez da tag padrão mais recente. Para uma imagem otimizada para contêiner, você pode fazer referência explícita a uma compilação específica da sua imagem no arquivo de manifesto. O exemplo abaixo usa a imagem Docker "myimage" na versão marcada com "version_2_1_3":
version: v1beta2 containers: - name: simple-echo image: myimage:version_2_1_3 [ rest of your manifest file ]
Crie uma imagem personalizada para usar como imagem do modelo. Isso é preferível aos scripts de inicialização porque garante que todas as instâncias sejam iguais. Os scripts de inicialização podem ter resultados diferentes após atualizações do pacote de distribuição. Use scripts de inicialização em seus modelos de instância para prototipagem e desenvolvimento rápido e use imagens personalizadas quando estiver pronto para implantar serviços com qualidade de produção.
Se você usar scripts de inicialização, considere atualizar seus scripts para serem determinísticos. Por exemplo, crie uma nova versão do modelo anterior e especifique um script de inicialização determinístico da seguinte maneira:
gcloud compute instance-templates create example-template-with-startup-2-1-3 \ --image-family debian-9 \ --image-project debian-cloud \ --metadata startup-script='#! /bin/bash sudo apt install -y apache2=2.2.20-1ubuntu1 scp myuser@108.59.87.185:version_2_1_3/index.php /var/www/'
onde "version_2_1_3" é um subdiretório que contém scripts PHP para a versão 2.1.3 do seu serviço.