Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Exemplos de cenários

Esses cenários de exemplo descrevem como uma organização poderia usar modelos para padronizar a criação de clusters.

Impondo modelos: Os administradores podem querer impor uma ou mais configurações de modelo para todos se desejarem que todos os novos clusters provisionados pelo Rancher tenham essas configurações.
Compartilhando diferentes modelos com diferentes usuários: Os administradores podem fornecer modelos diferentes para usuários básicos e avançados, para que os usuários básicos tenham opções mais restritas e os usuários avançados tenham mais discrição ao criar clusters.
Atualizando configurações de modelo: Se as equipes de segurança e DevOps de uma organização decidirem incorporar as melhores práticas nas configurações exigidas para novos clusters, essas melhores práticas podem mudar ao longo do tempo. Se as melhores práticas mudarem, um modelo pode ser atualizado para uma nova revisão e os clusters criados a partir do modelo podem fazer upgrade para a nova versão do modelo.
Compartilhando a propriedade de um modelo: Quando um proprietário de modelo não deseja mais manter um modelo, ou deseja delegar a propriedade do modelo, este cenário descreve como a propriedade do modelo pode ser compartilhada.

Impondo uma Configuração de Modelo para Todos

Vamos supor que há uma organização na qual os administradores decidem que todos os novos clusters devem ser criados com a versão do Kubernetes 1.14.

Primeiro, um administrador cria um modelo que especifica a versão do Kubernetes como 1.14 e marca todas as outras configurações como Permitir Sobrescrita do Usuário.
O administrador torna o modelo público.
O administrador ativa a imposição do modelo.

Resultados:

Todos os usuários do Rancher na organização têm acesso ao modelo.
Todos os novos clusters criados por usuários padrão com este modelo usarão Kubernetes 1.14 e não poderão usar uma versão diferente do Kubernetes. Por padrão, os usuários padrão não têm permissão para criar modelos, então este modelo será o único que poderão usar, a menos que mais modelos sejam compartilhados com eles.
Todos os usuários padrão devem usar um modelo de cluster para criar um novo cluster. Eles não podem criar um cluster sem usar um modelo.

Dessa forma, os administradores impõem a versão do Kubernetes em toda a organização, enquanto ainda permitem que os usuários finais configurem todo o resto.

Modelos para Usuários Básicos e Avançados

Vamos supor que uma organização tenha tanto usuários básicos quanto avançados. Os administradores querem que os usuários básicos sejam obrigados a usar um modelo, enquanto os usuários avançados e administradores criam seus clusters da maneira que desejam.

Primeiro, um administrador ativa a imposição do modelo RKE. Isso significa que todo usuário padrão no Rancher precisará usar um modelo RKE ao criar um cluster.
O administrador então cria dois modelos:
- Um modelo para usuários básicos, com quase todas as opções especificadas, exceto pelas chaves de acesso
- Um modelo para usuários avançados, que tem a maioria ou todas as opções com Permitir Sobrescrita do Usuário ativada
O administrador compartilha o modelo avançado apenas com os usuários avançados.
O administrador torna o modelo para usuários básicos público, para que o modelo mais restritivo seja uma opção para todos que criam um cluster provisionado pelo Rancher.

Resultado: Todos os usuários do Rancher, exceto os administradores, são obrigados a usar um modelo ao criar um cluster. Todos têm acesso ao modelo restritivo, mas apenas os usuários avançados têm permissão para usar o modelo mais permissivo. Os usuários básicos são mais restritos, enquanto os usuários avançados têm mais liberdade ao configurar seus clusters Kubernetes.

Atualizando Modelos e Clusters Criados com Eles

Vamos supor que uma organização tenha um modelo que exige que os clusters usem Kubernetes v1.14. No entanto, com o passar do tempo, os administradores mudam de ideia. Eles decidem que querem que os usuários possam fazer upgrade de seus clusters para usar versões mais novas do Kubernetes.

Nesta organização, muitos clusters foram criados com um modelo que exige Kubernetes v1.14. Como o modelo não permite que essa configuração seja substituída, os usuários que criaram o cluster não podem editar essa configuração diretamente.

O proprietário do modelo tem várias opções para permitir que os criadores do cluster atualizem o Kubernetes em seus clusters:

Especificar Kubernetes v1.15 no modelo: O proprietário do modelo pode criar uma nova revisão do modelo que especifica o Kubernetes v1.15. Então, o proprietário de cada cluster que usa esse modelo pode fazer upgrade do seu cluster para uma nova revisão do modelo. Essa atualização do modelo permite que o criador do cluster atualize o Kubernetes para v1.15 em seu cluster.
Permitir qualquer versão do Kubernetes no modelo: Ao criar uma revisão do modelo, o proprietário do modelo também pode marcar a versão do Kubernetes como Permitir Sobrescrita do Usuário usando o interruptor próximo a essa configuração na interface do Rancher. Isso permitirá que os clusters que fizerem upgrade para esta revisão do modelo usem qualquer versão do Kubernetes.
Permitir a versão menor mais recente do Kubernetes no modelo: O proprietário do modelo também pode criar uma revisão do modelo na qual a versão do Kubernetes é definida como Última v1.14 (Permite atualizações de versão de patch). Isso significa que os clusters que usam essa revisão poderão receber atualizações de patch, mas atualizações de versão principal não serão permitidas.

Permitindo que Outros Usuários Controlem e Compartilhem um Modelo

Vamos supor que Alice seja uma administradora do Rancher. Ela possui um modelo RKE que reflete as melhores práticas acordadas de sua organização para criar um cluster.

Bob é um usuário avançado que pode tomar decisões informadas sobre a configuração do cluster. Alice confia em Bob para criar novas revisões de seu modelo à medida que as melhores práticas são atualizadas ao longo do tempo. Portanto, ela decide tornar Bob um proprietário do modelo.

Para compartilhar a propriedade do modelo com Bob, Alice adiciona Bob como um proprietário de seu modelo.

O resultado é que, como proprietário do modelo, Bob está encarregado do controle de versão desse modelo. Bob agora pode fazer todas as seguintes ações:

Revisar o modelo quando as melhores práticas mudarem
Desativar revisões desatualizadas do modelo para que novos clusters não possam ser criados com ele
Excluir o modelo inteiro se a organização quiser seguir em uma direção diferente
Definir uma certa revisão como padrão quando os usuários criarem um cluster com ela. Os usuários finais do modelo ainda poderão escolher com qual revisão desejam criar o cluster.
Compartilhar o modelo com usuários específicos, tornar o modelo disponível para todos os usuários do Rancher ou compartilhar a propriedade do modelo com outro usuário.