Share via

Locais personalizados

  • Artigo

Como uma extensão da construção de local do Azure, um local personalizado fornece uma referência como um destino de implantação que os administradores podem configurar ao criar um recurso do Azure. O recurso de local personalizado abstrai os detalhes da infraestrutura de back-end de desenvolvedores de aplicativos, usuários administradores de banco de dados ou outros usuários na organização. Esses usuários podem então fazer referência ao local personalizado sem precisar estar ciente desses detalhes.

Os locais personalizados podem ser usados para habilitar clusters Kubernetes habilitados para Azure Arc como locais de destino para implantar instâncias de serviços do Azure. As ofertas do Azure que podem ser implantadas em locais personalizados incluem bancos de dados, como a Instância Gerenciada SQL habilitada pelo Azure Arc e o servidor PostgreSQL habilitado para Azure Arc.

Em clusters Kubernetes habilitados para Arc, um local personalizado representa uma abstração de um namespace dentro do cluster Kubernetes habilitado para ArcGIS do Azure. Os locais personalizados criam os RoleBindings granulares e ClusterRoleBindings necessários para que outros serviços do Azure acessem o cluster.

Permissões de localização personalizadas

Como o local personalizado é um recurso do Azure Resource Manager que dá suporte ao controle de acesso baseado em função do Azure (Azure RBAC), um administrador ou operador pode determinar quais usuários têm acesso para criar instâncias de recurso em:

  • Um namespace dentro de um cluster Kubernetes para direcionar a implantação da Instância Gerenciada do SQL habilitada pelo Azure Arc ou pelo servidor PostgreSQL habilitado para Azure Arc.
  • Os recursos de computação, armazenamento, rede e outros recursos do vCenter ou do Azure Stack HCI para implantar e gerenciar VMs.

Por exemplo, um operador de cluster pode criar um local personalizado Contoso-Michigan-Healthcare-App representando um namespace em um cluster Kubernetes no Michigan Data Center da sua organização. O operador pode atribuir permissões do Azure RBAC a desenvolvedores de aplicativos nesse local personalizado para que eles possam implantar aplicativos Web relacionados à assistência médica. Os desenvolvedores podem implantar esses aplicativos no Contoso-Michigan-Healthcare-App sem precisar saber detalhes do namespace e do cluster Kubernetes.

Arquitetura para Kubernetes habilitado para Arc

Quando um administrador habilita o recurso de locais personalizados em um cluster, um ClusterRoleBinding é criado, autorizando o aplicativo Microsoft Entra usado pelo Provedor de Recursos de Locais Personalizados (RP). Uma vez autorizado, o RP de Locais Personalizados pode criar ClusterRoleBindings ou RoleBindings necessários para outros RPs do Azure criarem recursos personalizados neste cluster. As extensões de cluster instaladas no cluster determinam a lista de RPs a autorizar.

Diagram showing custom locations architecture on Arc-enabled Kubernetes.

Quando o usuário cria uma instância de serviço de dados no cluster:

  1. A solicitação PUT é enviada para o Gerenciador de Recursos do Azure.
  2. A solicitação PUT é encaminhada para o RP de Serviços de Dados habilitado para Azure Arc.
  3. O RP busca o arquivo associado ao cluster Kubernetes habilitado para Azure Arc, no qual o kubeconfig local personalizado existe.
    • O local personalizado é referenciado como extendedLocation na solicitação PUT original.
  4. O RP de Serviços de Dados habilitado para Azure Arc usa o para se comunicar com o cluster para criar um recurso personalizado do tipo Azure Arc-enabled Data Services no namespace mapeado para o kubeconfig local personalizado.
    • O operador de Serviços de Dados habilitado para Arco do Azure foi implantado por meio da criação de extensão de cluster antes que o local personalizado existisse.
  5. O operador de Serviços de Dados habilitado para Arco do Azure lê o novo recurso personalizado criado no cluster e cria o controlador de dados, traduzindo-se na realização do estado desejado no cluster.

A sequência de etapas para criar a instância gerenciada SQL ou a instância PostgreSQL é idêntica à sequência de etapas descrita acima.

Próximos passos