Partilhar via

Gerenciamento de configuração de carga de trabalho

Este artigo fornece diretrizes do Azure Operator Service Manager (AOSM) para otimizar o design de esquemas de grupo de configuração (CGS) e a operação de valores de grupo de configuração (CGV). Os fornecedores de funções de rede (NF), os operadores de telecomunicações e os seus parceiros devem ter estas práticas em mente quando integram e implementam 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 metaesquema dentro das propriedades do objeto ConfigurationGroupSchemaPropertiesFormat CGS schemaDefinition.
  • O AOSM permite que o designer e o editor especifiquem o esquema JSON onde o operador deve fornecer dados (Valores JSON) ao instanciar um SNS/NF.
  • O AOSM permite que as propriedades do metaesquema sejam opcionais ou obrigatórias. Quando uma propriedade é marcada como obrigatória, ela deve ser especificada nos valores Json.

Quais palavras-chave JSON são suportadas?

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

  • Para tipos de objeto, a palavra-chave suportada é limitada pela política de filtro. Consulte Esquema JSON - objeto
  • Para tipos de cadeia de caracteres, o suporte a palavras-chave não é limitado ou filtrado. Consulte Esquema JSON - string
  • Para tipos numéricos, o suporte a palavras-chave não é limitado ou filtrado. Consulte 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 manipulação de valores padrão. Quando um valor padrão é definido no metaesquema CGS, o AOSM usa esse valor onde a propriedade está ausente ou indefinida nos dados CGV de entrada. A lógica do validador AOSM essencialmente hidrata o valor CGV com o valor padrão quando nenhum valor é fornecido pelo operador.

Como definir padrões

Os valores padrão devem ser especificados dentro das propriedades ou dentro dos itens do array. O exemplo a seguir demonstra valores padrão com inteiros e tipos de propriedade de tentativa.

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

Regras para definir padrões

As regras a seguir são aplicadas ao validar um valor padrão. Considere estas 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 descendente, de onde a palavra-chave é vista pela primeira vez.
  • Quando existe um valor de propriedade na entrada do CGV, apenas as subpropriedades dessas propriedades são avaliadas para valores predefinidos.
  • Quando um valor de propriedade não existe no CGV de entrada, ele é avaliado para um valor padrão, juntamente com quaisquer elementos subsidiários.
  • Quando o valor de uma propriedade é do tipo objeto, e nem ele nem a sua chave existem no CGV de entrada, então nenhum valor padrão para o objeto é considerado.

Considerações do CGS

Com o passar do tempo, a abordagem recomendada para projetar melhor esquemas de grupo de configuração mudou. Embora a abordagem 1-CGS original continue a ser suportada, para todos os novos projetos, recomendamos agora a abordagem 3-CGS. Mais detalhes sobre a conversão de 1-CGS para 3-CGS podem ser solicitados.

Abordagem 1-CGS

Originalmente, recomendava-se a utilização de apenas um único CGS para toda a NF. Consolidaram-se os parâmetros específicos do site, da instância e da 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 sucesso os serviços usando essa abordagem e ela continua sendo suportada.

Abordagem 3-CGS

Recentemente, é recomendado usar pelo menos três CGS para toda a NF, organizando parâmetros em conjuntos de grupos de configuração específicos do site, da instância e da segurança. Exemplos de parâmetros específicos do site são endereços IP ou nomes exclusivos. Exemplos de parâmetros específicos 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 seguintes diretrizes de meta-esquema 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 valor helm.
    • Ao contrário de um parâmetro sobre o qual outro agente atua, como os dados do utilizador cloudinit.
  • Organize os parâmetros em conjuntos específicos de site, de instância e de segurança.
  • Defina parâmetros obrigatórios versus opcionais.
    • Para parâmetros opcionais, defina um valor padrão razoável.
  • Certifique-se de que não há sobreposição de parâmetros entre objetos CGS.

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

Carga útil CGS:

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

Carga útil CGV correspondente passada pelo operador:

{
"qwe": 20
}

Carga CGV resultante gerada pelo Azure Operator Service Manager:

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

Considerações sobre os valores do grupo de configuração

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

  • Last updated on