Como Trabalhar com Compartimentos
Saiba como usar compartimentos para organizar seus recursos de nuvem no OCI.
Quando começar a trabalhar com o Oracle Cloud Infrastructure pela primeira vez, você precisa pensar cuidadosamente sobre como deseja usar os compartimentos para organizar e isolar os recursos de nuvem. Compartimentos são fundamentais para esse processo. A maioria dos recursos pode ser movida entre os compartimentos. No entanto, é importante pensar no design do seu compartimento da sua organização desde o início, antes de implementar qualquer coisa. Para obter mais informações, consulte Conheça as Melhores Práticas para Configurar a Sua Tenancy.
A Console foi criada para exibir seus recursos por compartimento dentro da região atual. Quando você trabalha com seus recursos na Console, escolha em qual compartimento deseja trabalhar em uma lista da página. Essa lista é filtrada para mostrar somente os compartimentos na tenancy à qual você tem permissão para acessar. Se você for um administrador, terá permissão para exibir todos os compartimentos e trabalhar com recursos de compartimento, mas se for um usuário com acesso limitado, provavelmente não será possível.
Os compartimentos estão presentes em todas as tenancies, em todas as regiões. Quando você cria um compartimento, ele fica disponível em todas as regiões em que sua tenancy está inscrita. Você pode obter uma exibição de região cruzada dos seus recursos em um compartimento específico com o explorador de tenancies. Consulte Exibindo Todos os Recursos em um Compartimento.
Para segurança adicional, é possível associar um compartimento a uma zona de segurança. Para obter mais informações, consulte Zonas de Segurança.
Esta introdução abrange os seguintes tópicos.
Controle de Acesso dos Compartimentos
Depois de criar um compartimento, você precisa gravar pelo menos uma política para ele; caso contrário, ninguém poderá acessá-lo (exceto administradores ou usuários com permissões definidas no nível de tenancy). Ao criar um compartimento dentro de outro compartimento, o compartimento herda as permissões de acesso dos compartimentos superiores na hierarquia. Para obter mais informações, consulte Herança de Políticas.
Ao criar uma política de acesso, você precisa especificar a qual compartimento ela será anexada. Isso controla quem poderá modificar ou excluir posteriormente a política. Dependendo de como você projetou sua hierarquia de compartimentos, você pode anexá-la à tenancy, a um pai ou ao próprio compartimento específico. Para obter mais informações, consulte Anexação de Políticas.
Colocando Recursos em um Compartimento
Para colocar um novo recurso em um compartimento, você simplesmente especifica esse compartimento ao criar o recurso (o compartimento é uma das informações necessárias para criar um recurso). Se estiver trabalhando na Console, certifique-se de estar exibindo primeiro o compartimento no qual deseja criar o recurso. Lembre-se de que a maioria dos recursos do serviço IAM reside na tenancy (isso inclui usuários, grupos, compartimentos e qualquer política anexada à tenancy) e não pode ser criada ou gerenciada em um compartimento específico.
Descobrindo Recursos em Compartimentos
Com o serviço Resource Manager, você pode capturar recursos implantados como configuração do Terraform e arquivos de estado usando a descoberta de recursos. A pilha criada fornece uma configuração do Terraform que você pode usar para gerenciar programaticamente, controlar a versão e persistir sua infraestrutura de TI como "infraestrutura como código".
Uma pilha criada com base em um compartimento representa todos os recursos suportados em todo o compartimento, no escopo apropriado. Se você selecionar o compartimento raiz para sua tenancy, o escopo será o nível de tenancy, como usuários e grupos. Se você selecionar um compartimento não raiz, o escopo será o nível do compartimento, como instâncias de computação.
Só há suporte para a criação de pilha com base em um único compartimento. Não é possível criar pilhas com base em compartimentos aninhados.
Para obter instruções, consulte Criando uma Pilha com base em um Compartimento Existente.
Implicações para Mover Compartimentos
Você pode mover um compartimento para outro compartimento pai na mesma tenancy. Quando você move um compartimento, todo o seu conteúdo (subcompartimentos e recursos) é movido com ele. Mover um compartimento tem implicações para o conteúdo. Essas implicações são descritas nas próximas seções. Conheça essas implicações antes de mover um compartimento.
- Política do Serviço IAM Obrigatória
- Restrições na Movimentação de Compartimentos
- Noções Básicas sobre Implicações de Política ao Mover um Compartimento
- Exemplos de Política
- Grupos com Permissões no Compartimento Atual Perdem Acesso; Grupos com Permissões no Compartimento de Destino Ganham Acesso
- Atualização Automática de Políticas
- Noções Básicas sobre Implicações da Cota de Compartimento ao Mover um Compartimento
- Noções Básicas sobre Implicações de Tags ao Mover um Compartimento
Política Obrigatória de IAM
Para mover um compartimento, você deve pertencer a um grupo que tenha permissões manage all-resources no compartimento pai compartilhado mais inferior do compartimento atual e no compartimento de destino.
Restrições na Movimentação de Compartimentos
- Não será possível mover um compartimento se a origem ou o destino fizer parte de uma zona de segurança. Você deve usar a console Zonas de Segurança para gerenciar compartimentos em uma zona de segurança.
-
Não é possível mover um compartimento para um compartimento de destino com o mesmo nome do compartimento que está sendo movido.
Por exemplo, considere que o compartimento A e o compartimento B estejam ambos no compartimento raiz. No compartimento A, há um subcompartimento, também chamado compartimento B. Você não pode mover o compartimento B para o compartimento pai B.
Item Descrição 
Dois compartimentos dentro do mesmo pai não podem ter o mesmo nome. Portanto, não é possível mover um compartimento para um compartimento de destino onde já existe um compartimento com o mesmo nome.
Noções Básicas sobre Implicações de Política ao Mover um Compartimento
Depois de mover um compartimento para um novo compartimento pai, as políticas de acesso do novo pai entram em vigor, e as políticas do pai anterior não se aplicam mais. Antes de mover um compartimento, certifique-se de que:
- Você está ciente das políticas que controlam o acesso ao compartimento na posição atual.
- Você está ciente das políticas no novo compartimento pai que terão efeito ao mover o compartimento.
Em alguns casos, ao mover compartimentos aninhados com políticas que especificam a hierarquia, as políticas são atualizadas automaticamente para garantir a consistência.
Exemplos de Política
Grupos com Permissões no Compartimento Atual Perdem Acesso; Grupos com Permissões no Compartimento de Destino Ganham Acesso
A figura a seguir mostra uma hierarquia de compartimentos na qual o compartimento C, um filho de A:B é movido para a hierarquia A:D.
| Item | Descrição |
|---|---|
|
A tenancy tem as seguintes políticas definidas para os compartimentos B e D: Policy1: |
 |
Tem efeito quando o compartimento C é movido de B para D: Policy2: |
-
O grupo G1 não pode mais gerenciar famílias de instâncias no compartimento C.
-
O grupo G2 agora pode gerenciar famílias de instâncias no compartimento C.
Saiba não só quais grupos perdem permissões ao mover um compartimento, mas também quais grupos obterão permissões.
Atualização Automática de Políticas
Ao mover um compartimento, algumas políticas serão atualizadas automaticamente. As políticas que especificam a hierarquia de compartimentos até o compartimento que está sendo movido serão atualizadas automaticamente quando a política for anexada a um antecessor compartilhado do pai atual e do alvo. Considere os seguintes exemplos:
Exemplo 1: Política atualizada automaticamente
| Item | Descrição |
|---|---|
|
Política: |
|
Política: |
 |
A política é atualizada automaticamente. O grupo G1 não perde permissões. |
Neste exemplo, você move o compartimento A de Operações:Teste para Operações:Desenvolvimento. A política que controla o compartimento A é anexada ao pai compartilhado, Operações. Quando o compartimento é movido, a instrução de política é atualizada automaticamente pelo serviço IAM para especificar o novo local do compartimento.
Não é necessária intervenção manual para permitir que o grupo G1 continue a acessar o compartimento A em sua localização.
Exemplo 2: Política não atualizada
| Item | Descrição |
|---|---|
|
Política: Permitir que o grupo G1 gerencie buckets no compartimento A |
|
Política: Permitir que o grupo G1 gerencie buckets no compartimento A |
|
A política não foi atualizada. O grupo G1 perde essa permissão. Esta política é inválida e deve ser removida manualmente. |
Neste exemplo, você move o compartimento A de Operações:Teste para Operações:Desenvolvimento. Porém, a política que controla o compartimento A aqui é anexada diretamente ao compartimento de Teste. Quando o compartimento é movido, a política não é atualizada automaticamente. A política que especifica o compartimento A não é mais válida e deve ser removida manualmente. O grupo G1 não tem mais acesso ao compartimento A em seu novo local em Dev. A menos que outra política existente conceda acesso ao grupo G1, você deverá criar uma nova política para permitir que G1 continue a gerenciar buckets no compartimento A.
Exemplo 3: A política anexada à tenancy foi atualizada
| Item | Descrição |
|---|---|
|
Política: Permitir que o grupo G1 gerencie buckets no compartimento Operations:Test:A |
|
Política: Permitir que o grupo G1 gerencie buckets no compartimento HR:Prod:A |
|
A política é atualizada automaticamente. O grupo G1 não perde permissões. |
Neste exemplo, você move o compartimento A de Operações:Teste para HR:Prod. A política que rege o compartimento A está anexada à tenancy, que é um antecessor compartilhado pelo compartimento pai original e pelo novo compartimento pai. Portanto, quando o compartimento é movido, a instrução da política é atualizada automaticamente pelo serviço IAM para especificar o local do novo compartimento.
Noções Básicas sobre Implicações da Cota de Compartimento ao Mover um Compartimento
Quando você move um compartimento para outro, as cotas de recursos no compartimento de destino não são verificadas e não são aplicadas. Portanto, se a movimentação do compartimento resultar em uma violação de cota no compartimento de destino, a movimentação não será bloqueada. Após a conclusão da movimentação, o compartimento de destino estará em um estado sobrecarregado. Não será possível criar novos recursos que estejam sobrecarregados até que você ajuste as cotas do compartimento de destino ou remova os recursos de acordo com a cota existente. Para obter mais informações sobre o gerenciamento de cotas de compartimento, consulte Visão Geral de Cotas de Compartimento.
Noções Básicas sobre Implicações de Tags ao Mover um Compartimento
As tags não são atualizadas automaticamente após uma movimentação de compartimento. Se você implementou uma estratégia de tags com base no compartimento, deverá atualizar as tags nos recursos após a movimentação. Por exemplo, imagine que o CompartmentA tenha um compartimento filho, CompartmentB. O CompartmentA é configurado com padrões de tag para que cada recurso no CompartmentA seja marcado com a TagA. Portanto, o CompartmentB e todos os seus recursos são marcados com a tag padrão, TagA. Quando você mover o CompartmentB para o CompartmentC, ele ainda terá as tags padrão do CompartmentA. Se você tiver configurado tags padrão para o CompartmentC, precisará adicioná-las aos recursos do compartimento movido.
| Item | Descrição |
|---|---|
|
Todos os recursos em CompartmentB são marcados com as tags padrão definidas para o seu compartimento principal, CompartmentA. |
|
Quando CompartmentB é movido para CompartmentC, as tags padrão não são atualizadas. CompartmentB ainda tem as tags padrão de CompartmentA aplicadas. |