Modelos deterministas de instância

Nesta página, descrevemos quando e por que é necessário criar modelos deterministas de instância. Esses modelos deixam bastante claro quando o modelo de instância é implantado, em termos de tipo de serviços ou aplicativos de terceiros que precisam ser instalados em suas instâncias. Ao criá-los, você minimiza a ambiguidade e o comportamento inesperado de seus modelos de instância.

Por que criar modelos deterministas de instância?

Em geral, recomendamos que você defina as propriedades do modelo de instância da maneira mais explícita e determinista possível. Se você decidir empregar scripts de inicialização que instalem ou usem serviços de terceiros nos seus modelos de instância, verifique se informações explícitas, como a versão do aplicativo a ser instalado, são fornecidas. O Compute Engine depende das informações definidas no modelo. Ele não tem nenhum controle sobre os serviços de terceiros referenciados. O modelo de instância pode apresentar comportamentos inesperados quando ele é muito vago.

Por exemplo, pense no comando a seguir para criar um modelo de instância com um script de inicialização que instale o apache2 e use 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/'

Há dois possíveis problemas nesse script de inicialização:

  • O script não define explicitamente qual versão do apache2 será instalada, ele depende da versão atual disponível no repositório apt.
  • O script depende de um arquivo hospedado em um serviço de terceiros sem controle de versão. Esse arquivo pode ter sido alterado depois que o modelo de instância foi usado pela última vez.

Ao usar um escalonador automático com um modelo de instância não determinista, novas instâncias podem acabar sendo adicionadas a um grupo de instâncias gerenciadas com uma configuração diferente, como outra versão do apache2.

De maneira semelhante, se você aplica esse modelo a um grupo de instâncias gerenciadas, atualiza o grupo para um modelo diferente e decide revertê-lo ao modelo anterior, pode acabar com instâncias que usam uma versão do apache2 ou do arquivo index.php diferente daquela usada antes da atualização, já que na inicialização as instâncias sempre buscam a versão mais recente.

Como evitar comportamento ambíguo ou inesperado do modelo de instância

Para evitar comportamento inesperado do modelo, use um destes métodos:

  • Use imagens otimizadas para contêiner ou do Docker, com tags do Docker. Por exemplo, recomendamos que você atribua novas tags a cada versão nova da imagem do Docker. Além disso, use essas tags nos modelos de instância, em vez da tag padrão mais recente. Para imagens otimizadas para contêiner, faça uma referência explícita a uma versão específica da imagem no arquivo de manifesto. O exemplo abaixo usa a imagem do Docker "myimage" na versão com a tag "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 ser usada como a imagem do modelo. Dê preferência a essa opção, porque você consegue garantir que as instâncias sejam idênticas. Ao usar um script de inicialização, os resultados podem ser diferentes, dependendo das atualizações do pacote de distribuição. Use scripts de inicialização nos modelos de instância para criar protótipos e fazer um desenvolvimento rápido. Escolha as imagens personalizadas quando estiver tudo pronto para implantar os serviços de produção-qualidade.

  • Caso precise usar os scripts de inicialização, verifique se é possível torná-los deterministas. Por exemplo, crie uma nova versão do modelo anterior e especifique um script de inicialização determinista 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/'

    "version_2_1_3" é um subdiretório com scripts PHP para a versão 2.1.3 do seu serviço.

A seguir