Escolher o modelo de configuração do App Hub

Organize os recursos de infraestrutura em aplicativos do App Hub usando uma pasta ativada por apps (pré-lançamento) ou um projeto host.

Pasta ativada para apps

Recomendado

Uma pasta habilitada para apps é uma Google Cloud pasta que permite agrupar recursos de infraestrutura como serviços e cargas de trabalho em aplicativos do App Hub. As pastas habilitadas para apps provisionam o gerenciamento de aplicativos em todos os projetos na pasta. As pastas com apps ativados também têm acesso a recursos como o App Design Center e o Gemini Cloud Assist. Para mais informações sobre como configurar seus aplicativos do App Hub em uma pasta habilitada para apps, consulte Configurar o App Hub para uma pasta habilitada para apps.

Projeto host

Um projeto host é um projeto do Google Cloud que permite agrupar recursos de infraestrutura como serviços e cargas de trabalho em aplicativos do App Hub. Para mais informações, consulte Configurar o App Hub para um projeto host.

Planejar a estrutura da hierarquia de recursos

A base para organizar os aplicativos do App Hub é a pasta com app ativado ou o projeto host, dependendo do modelo de configuração escolhido. O modelo de dados do App Hub é criado com base na hierarquia de recursosGoogle Cloud padrão, mantendo as mesmas regras hierárquicas e políticas de herança.

É possível combinar os benefícios da hierarquia de recursos Google Cloud com os recursos de aplicativos do App Hub mapeando os limites esperados do aplicativo para a pasta ou projeto host fundamental ativado por app do modelo de configuração. Pense no modelo de dados do App Hub como uma sobreposição na hierarquia de recursos padrão do Google Cloud :

  • Pastas e projetos são limites:pastas e projetos no Resource Manager agrupam recursos para herança de políticas e organização da mesma forma que pastas ativadas para apps ou projetos host definem os limites administrativos para aplicativos.
  • Os papéis e as permissões são herdados:os papéis e as permissões do IAM para o App Hub são concedidos no projeto de gerenciamento, na pasta ativada para apps ou no projeto host, seguindo as regras de herança do IAM padrão.
  • Os metadados são centralizados:o projeto de gerenciamento ou host centraliza os metadados do aplicativo, adicionando uma camada compatível com aplicativos ao gerenciamento de recursos.

Para mais detalhes sobre a organização de recursos, consulte Conceitos de organização de recursos e Configurar uma pasta para gerenciamento de apps.

Considerações sobre a hierarquia de recursos

Confira abaixo as considerações recomendadas para sua hierarquia de recursos ao escolher o modelo de configuração para gerenciar aplicativos:

Se estiver usando projetos host:

  • Todos os recursos precisam estar nos projetos de serviço específicos que você anexa manualmente ao projeto host para serem registráveis nos aplicativos do App Hub.

Se estiver usando pastas ativadas para apps:

  • Os serviços e as cargas de trabalho precisam estar em projetos na pasta habilitada para apps ou nos descendentes dela para serem registrados em aplicativos do App Hub dentro do limite administrativo da pasta.
  • A descoberta automática de serviços e cargas de trabalho opera dentro do limite da pasta específica habilitada para apps e dos projetos descendentes dela.

  • Planeje cuidadosamente a estrutura de pastas:

    • Use uma única pasta ativada para apps para gerenciar aplicativos em vários projetos nela.
    • Crie pastas aninhadas ativadas para apps e delegue o gerenciamento de aplicativos a diferentes equipes ou unidades de negócios, oferecendo um controle mais granular sobre os aplicativos.

Como ilustrado em Gerenciar aplicativos em uma pasta, ativar o gerenciamento de aplicativos em uma pasta mãe, como F1, permite que aplicativos nessa pasta incluam recursos de projetos diretamente nela, como P10 e P11, bem como de projetos em pastas aninhadas, como P20 e P21 em F2.

Um aplicativo com projetos P10 e P20, abrangendo níveis de pasta.

Se você ativar o gerenciamento de aplicativos apenas na pasta aninhada F2, os aplicativos nessa pasta só poderão usar recursos de projetos nela, como P20 e P21. Os recursos na pasta mãe F1, como P10 e P11, não estão disponíveis para aplicativos em F2. Para incluir recursos de um projeto na pasta mãe, você precisaria mover esse projeto para F2.

Um aplicativo com projetos P10 e P20, mas P10 foi movido para a pasta F2.

Padrões para estruturas de recursos

Confira a seguir padrões comuns que recomendamos para um planejamento cuidadoso da estrutura de pastas e projetos:

  • Uma única pasta habilitada para apps:comece a configuração em pequenas organizações ou para adoção inicial, consolidando o gerenciamento de aplicativos em um único limite administrativo.
  • Uma pasta com um app ativado por ambiente:aplique um isolamento forte entre ambientes de desenvolvimento, permitindo políticas diferentes e reduzindo o risco.
  • Uma pasta ativada para apps por unidade de negócios ou equipe:alinha o gerenciamento à estrutura organizacional e às responsabilidades da equipe, promovendo a autonomia. É possível implementar essa prática estruturando várias pastas separadas ativadas para apps.
  • Crie uma estrutura aninhada de pastas ativadas por apps:organize por unidades de negócios, equipes ou ambientes com controle hierárquico. Por exemplo, crie pastas de nível superior para unidades de negócios, com pastas aninhadas para ambientes de desenvolvimento, preparação e produção em cada unidade. Esse padrão usa as estruturas de pastas habilitadas para apps descritas em Considerações sobre a hierarquia de recursos.
  • Um projeto host por aplicativo ou grupo de aplicativos:organize recursos atuais dos seus projetos padrão, adequados para organizações acostumadas à separação de interesses baseada em projetos ou que já têm aplicativos gerenciados dessa forma.

A seguir