Como organizar arquivos de configuração

ID da região

REGION_ID é um código abreviado que o Google atribui com base na região que você seleciona ao criar seu app. O código não corresponde a um país ou uma província, mesmo que alguns IDs de região possam parecer semelhantes aos códigos de país e província mais usados. A inclusão de REGION_ID.r nos URLs do App Engine é opcional para apps atuais e, em breve, será necessária para todos os novos apps.

Para garantir uma transição tranquila, estamos atualizando gradativamente o App Engine para usar IDs de região. Se ainda não tivermos atualizado seu projeto do Google Cloud, você não verá um ID da região para o app. Como o ID é opcional para os apps atuais, não é necessário atualizar os URLs ou fazer outras alterações quando o ID da região está disponível para eles.

Saiba mais sobre IDs da região.

Use este documento para entender como estruturar os serviços e recursos relacionados do seu aplicativo do App Engine.

Estrutura do diretório

Cada versão do serviço do App Engine é definida em um arquivo de configuração app.yaml. Para aplicativos simples, o requisito mínimo para implantação é definir o arquivo app.yaml. O arquivo app.yaml atua como um descritor de implantação e define o tipo de escalonamento, além dos recursos de CPU, disco e memória para a versão específica de um serviço. Se você pretende implantar várias versões de um serviço, é possível criar vários arquivos YAML no mesmo diretório para representar a configuração de cada uma.

Quando você está desenvolvendo localmente, é possível criar diretórios separados para cada serviço na raiz do aplicativo. Se você hospedar o aplicativo em um sistema de controle de versão (VCS, na sigla em inglês), como o GitHub, também poderá estruturá-lo para usar diretórios separados em um repositório ou usar repositórios separados para cada serviço. Cada diretório ou repositório precisa representar um único serviço e conter o arquivo app.yaml desse serviço com o código-fonte associado.

Você tem a opção de especificar um nome exclusivo para cada arquivo app.yaml do serviço. Por exemplo, é possível nomear um arquivo de configuração com o mesmo nome do serviço ou usar nomes exclusivos para representar cada versão deste serviço específico, como service1.yaml ou app.flexible.yaml.

É necessário que os outros arquivos de configuração opcionais residam no diretório raiz ou no repositório do serviço default do seu aplicativo. Esses arquivos aplicam configurações de todo o aplicativo que não sejam específicas de um determinado serviço, incluindo os arquivos dispatch.yaml e cron.yaml.

Exemplos

O exemplo a seguir demonstra como fica um aplicativo com três serviços se ele estiver sendo desenvolvido localmente. O dispatch.yaml opcional foi adicionado a esse aplicativo no diretório raiz. Na raiz, também há três diretórios para cada um dos serviços do aplicativo. O subdiretório para service1 inclui os arquivos de origem e configuração para esse serviço. Da mesma forma, ambos service2 e service3 estão em diretórios separados, que contêm os arquivos de cada serviço, ainda que service3 inclua duas versões do arquivo de configuração YAML:

Gráfico hierárquico de serviços YAML

Para um único aplicativo de serviço, este aplicativo incluirá apenas o serviço default e todos os arquivos poderão residir no mesmo diretório, na raiz deste aplicativo. No exemplo a seguir, a estrutura possível de um único aplicativo de serviço é demonstrada e inclui o arquivo de configuração dispatch.yaml opcional e dois arquivos de configuração que representam versões diferentes deste serviço, service1.yaml e service2.yaml:

Gráfico hierárquico de pequenos serviços YAML

Considerações de design sobre o tempo de atividade da instância

Falhas de hardware ou software que causam o encerramento antecipado ou reinicializações frequentes da instância podem ocorrer sem qualquer aviso e levar muito tempo para serem solucionadas. O aplicativo precisa ser capaz de lidar com essas falhas.

Confira algumas boas estratégias para evitar a inatividade devido a reinicializações da instância:

  • Reduza o tempo necessário para a reinicialização das instâncias ou para que novas instâncias sejam inicializadas.
  • Para cálculos de longa duração, crie checkpoints periodicamente para que seja possível retomar a partir desse estado.
  • O aplicativo precisa ser "sem estado" para que nada seja armazenado na instância.
  • Use filas para executar tarefas assíncronas.
  • Se você configurar as instâncias para escalonamento manual:
    • Use o balanceamento de carga em várias instâncias.
    • configure mais instâncias do que o necessário para processar o tráfego normal;
    • Grave a lógica de fallback que usa resultados em cache quando uma instância de escalonamento manual não está disponível.

Saiba mais sobre instâncias em Como as instâncias são gerenciadas.

O serviço default

Cada aplicativo do App Engine inclui um serviço default. É preciso implantar a versão inicial do seu aplicativo no serviço default antes de criar e implantar mais serviços no seu aplicativo.

O serviço padrão pode ser especificado opcionalmente em app.yaml com a configuração service: default.

As solicitações enviadas ao app usando o projeto do Cloud são enviadas para o serviço default, por exemplo, https://PROJECT_ID.REGION_ID.r.appspot.com. Para saber mais sobre como segmentar outros serviços, consulte Comunicação entre serviços.

Arquivos de configuração opcionais

Os arquivos de configuração a seguir controlam recursos opcionais que se aplicam a todos os serviços em um determinado app. Consulte os tópicos a seguir para mais detalhes sobre cada um dos recursos opcionais:

Considerações sobre armazenamento de dados e arquivos

No App Engine, é possível acessar facilmente outros serviços do Google Cloud, como Datastore, Cloud SQL e Cloud Storage.

Também é possível usar um banco de dados externo ou de terceiros caso ele seja compatível com sua linguagem e possa ser acessado na instância do App Engine.

Para saber detalhes sobre como armazenar arquivos no Google Cloud ou externamente, consulte Noções básicas sobre armazenamento de dados e arquivos.

Também é possível escolher como exibir o conteúdo estático. É possível exibir o conteúdo estático do app diretamente desse aplicativo no App Engine, hospedá-lo em uma opção do Google Cloud, como o Cloud Storage, ou usar uma rede de fornecimento de conteúdo (CDN, na sigla em inglês) de terceiros. Para mais informações sobre a exibição de conteúdo estático, consulte este artigo.