Compartilhar via

Gerenciamento de configuração de carga de trabalho

Este artigo fornece diretrizes do AOSM (Azure Operator Service Manager) para otimizar o design de CGS (esquemas de grupo de configuração) e a operação de valores de grupo de configuração (CGV). Fornecedores de NF (função de rede), operadores de telecomunicações e seus parceiros devem ter essas práticas em mente ao integrar e implantar NFs.

O que é o esquema JSON?

O esquema JSON é um padrão IETF (Internet Engineering Task Force) que fornece um formato para quais dados JSON são necessários para um determinado aplicativo e como interagir com ele. A aplicação desses padrões para um documento JSON permite impor consistência e validade de dados em dados JSON

Onde o esquema JSON é usado?

  • AOSM usa a notação de esquema JSON como um meta-esquema dentro das propriedades do objeto ConfigurationGroupSchemaPropertiesFormat CGSschemaDefinition.
  • O AOSM permite que o designer e o editor especifiquem o esquema JSON em que o operador deve fornecer dados (Valores JSON) ao instanciar um SNS/NF.
  • O AOSM permite que as propriedades de meta-esquema sejam opcionais ou necessárias. Quando uma propriedade é marcada como necessária, ela deve ser especificada nos valores Json.

Quais palavras-chave JSON têm suporte?

Para o meta-esquema do CGS, o AOSM implementa suportes para palavras-chave padrão JSON em uma base tipo por tipo.

  • Para tipos de objeto, a palavra-chave com suporte é limitada pela política de filtro. Ver Esquema JSON – objeto
  • Para tipos de cadeia de caracteres, o suporte à palavra-chave não é limitado ou filtrado. Ver Esquema JSON – cadeia de caracteres
  • Para tipos numéricos, o suporte à palavra-chave não é limitado ou filtrado. Consulte o esquema JSON – numérico

Campos opcionais e obrigatórios

Uma propriedade é declarada opcional incluindo uma required palavra-chave, que omite a propriedade opcional. Se a required palavra-chave não for especificada, todas as propriedades serão consideradas necessárias. Pelo menos um tipo de propriedade necessário é necessário para dar suporte a um tipo de propriedade opcional.

{
"type": "object",
"properties": {
  "abc": {
    "type": "integer",
     "default": 30
  },
  "xyz": {
    "type": "string",
    "default": "abc123"
  }
 }
"required":  ["abc"]
}

Valores padrão no esquema JSON

Para propriedades opcionais, o AOSM implementa um método personalizado de tratamento de valor padrão. Quando um valor padrão é definido no meta-esquema CGS, o AOSM usa esse valor em que a propriedade está ausente ou indefinida nos dados CGV de entrada. A lógica do validador AOSM hidrata essencialmente o valor CGV com o valor padrão quando nenhum valor é fornecido pelo operador.

Como definir padrões

Os padrões devem ser especificados dentro de propriedades ou dentro de itens de matriz. O exemplo a seguir demonstra padrões com tipos de propriedade inteiro e tentativa.

{
"type": "object",
"properties": {
  "abc": {
    "type": "integer",
     "default": 30
  },
  "xyz": {
    "type": "string",
    "default": "abc123"
  }
 }
}

Regras para definir valores padrão

As regras a seguir são aplicadas ao validar um valor padrão. Considere essas regras ao usar valores padrão para garantir os resultados esperados:

  • Um valor padrão não deve ser aplicado a uma propriedade necessária.
  • Um valor padrão é avaliado em ordem de cima para baixo, de onde a palavra-chave é vista pela primeira vez.
  • Quando um valor de propriedade existe no CGV de entrada, somente filhos dessas propriedades são avaliados como padrões.
  • Quando um valor de propriedade não existe no CGV de entrada, ele é avaliado como um padrão, juntamente com qualquer filho.
  • Quando um valor de propriedade é um objeto de tipo e nem ele ou sua chave existem no CGV de entrada, nenhum padrão para o objeto é avaliado.

Considerações sobre CGS

Horas extras, a abordagem recomendada para os melhores esquemas de grupo de configuração de design foi alterada. Embora a abordagem 1-CGS original permaneça com suporte, para todos os novos projetos, agora recomendamos a abordagem 3-CGS. Mais detalhes sobre como converter de 1-CGS para 3 CGS podem ser solicitados.

Abordagem 1-CGS

Originalmente, era recomendável usar apenas um único CGS para toda a NF. Isso consolidou os parâmetros específicos do site, da instância e de segurança em um único conjunto de objetos de grupo de configuração. Vários conjuntos de objetos foram evitados, exceto em casos raros em que um serviço era composto por vários componentes. Muitos parceiros integraram com êxito os serviços usando essa abordagem e ela permanece com suporte.

Abordagem 3-CGS

Mais recentemente, agora é recomendável usar pelo menos três CGS para todo o NF, organizando parâmetros em conjuntos de grupos de configuração específicos do site, específicos da instância e específicos de segurança. Exemplos de parâmetros específicos do site são endereços ip ou nomes exclusivos. Exemplos de parâmetros spccific de instância são tempos limite ou níveis de depuração. Exemplos de parâmetros específicos de segurança seriam senhas ou certificados. Com parâmetros específicos de segurança, o Azure Keyvault é usado para armazenar valores seguros.

Projetando conjuntos de objetos 3-CGS

Considere as diretrizes de meta-esquema a seguir ao projetar objetos 3-CGS;

  • Escolha quais parâmetros expor.
    • Uma regra geral é expor esses parâmetros definidos usando uma operação direta, como um SKU de computação ou um valor helm.
    • Diferentemente de um parâmetro que é manipulado por outro agente, como cloudinit dados de usuário.
  • Classifique os parâmetros em conjuntos específicos do site, específicos da instância e específicos de segurança.
  • Definir parâmetros obrigatórios versus opcionais.
    • Para parâmetros opcionais, defina um valor padrão razoável.
  • Verifique se não há parâmetros sobrepostos entre objetos CGS.

O exemplo a seguir mostra um CGS de exemplo e cargas CGV correspondentes.

Conteúdo do CGS:

{ 
  "type": "object", 
  "properties": {
    "abc": { 
      "type": "integer", 
      "default": 30
    }, 
    "xyz": { 
      "type": "integer", 
      "default": 40
    },
    "qwe": {
      "type": "integer"
    }
   }
   "required": "qwe"
}

Conteúdo do CGV correspondente repassado pelo operador:

{
"qwe": 20
}

Conteúdo do CGV resultante gerado pelo Gerenciador de Serviços do Operador do Azure:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Considerações sobre Valores do Grupo de Configuração

Antes de enviar a criação de recursos do CGV, você pode validar se o esquema e os valores do arquivo YAML ou JSON subjacentes correspondem ao que o CGS correspondente espera. Para fazer isso, uma opção é usar a extensão YAML do Visual Studio Code.

  • Last updated on