Modelo de dados de CDM

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. de 2024
  • 10 min. de leitura

    • O modelo de dados CDM é uma estrutura de dados padronizada que oferece suporte ao ciclo de vida mais amplo da entrega de software - automação, validação de qualidade e CSDM. CDM importa dados de configuração existentes, valida-os usando políticas definidas por você e exporta dados de configuração válidos para o pipeline DevOps existente da sua organização para implementar aplicações, serviços e infraestrutura.

    Importante:
    A partir da versão Washington DC, o Configuração de DevOps está sendo preparado para descontinuação futura. Ele ficará oculto e não será mais instalado em novas instâncias, mas continuará sendo compatível. Para obter detalhes, consulte o artigo Deprecation Process (Processo de descontinuação) [KB0867184] na Base de conhecimento do Now Support.

    CDM visão geral do modelo de dados

    O modelo de dados CDM não muda a maneira como você pensa sobre a configuração. Em vez disso, você usa a CDM REST API e a interface do usuário para mapear seus dados JSON, YAML, INI, XML e outros dados de configuração existentes em uma estrutura de dados intuitiva que oferece os seguintes benefícios:
    • Implementa controle de versão e mudança rigoroso e transparente.
    • Permite criptografar dados confidenciais e garante o controle de acesso apropriado para os dados.
    • Habilita a validação automatizada de dados de configuração.
    • Permite que você reutilize estruturas de dados de configuração usando variáveis, incluindo valores e valores sobrepostos.

    Estrutura do modelo de dados CDM

    Uma aplicação em CDM é a coleção completa de dados de configuração para um serviço de aplicações, modelo de aplicação ou grupo de IC dinâmico [infraestrutura] no CMDB. O usuário CDM cria um registro de aplicação que inclui as seguintes pastas vazias em uma estrutura hierárquica padrão. Depois que o sistema ingere os dados de configuração existentes, você estrutura os dados em componentes na pasta apropriada. Você cria coleções dos componentes e combina as coleções em um implantável - um conjunto de dados de configuração (para um ambiente de desenvolvimento, teste ou produção) que pode ser implantado pelo seu processo de entrega. Cada componente, coleção, variável e implantável é um nó na estrutura.

    Estrutura de pastas para uma nova aplicação CDM

    Componentes
    Componentes são os blocos de construção que normalmente representam os dados de configuração de um elemento lógico de uma aplicação ou de uma parte de um serviço de infraestrutura. Por exemplo, um app monolítico, um microsserviço, um servidor físico ou um modelo do Docker.

    Um componente pode incluir componentes descendentes, diretos ou incluídos. Um componente pode incluir variáveis que podem assumir valores diferentes em coleções e implantáveis.

    Você pode agrupar componentes em uma biblioteca de componentes compartilhados.

    Dica:
    Geralmente, é útil definir um valor padrão para uma variável em um componente ou coleção. Esta é uma estratégia poderosa porque você pode criar uma ampla variedade de implantáveis a partir de um pequeno conjunto de componentes e coleções. Os implantáveis que herdam um componente ou coleção podem usar substituições, sobreposições e configurações de variáveis para atender às necessidades do tipo de ambiente. Por exemplo, o Desenvolvimento implantável pode usar os mesmos componentes e coleções que o Teste implantável. O desenvolvimento usa o valor de variável de banco de dados padrão. O teste, por outro lado, usa um valor diferente que é apropriado para o ambiente de testes.
    Pasta Variáveis de componentes
    A pasta Variáveis de componentes pode conter variáveis que qualquer CDI na pasta Componentes pode usar. Há apenas uma pasta de variáveis de componentes.
    Coleções

    Uma coleção é o conjunto de componentes que, juntos, definem uma versão. Você pode pensar em uma coleção como uma composição de versão.

    Uma coleção pode incluir variáveis ou configurações de substituição que são específicas para a versão específica. Por exemplo, os dados de configuração da VM usados na versão-1 são diferentes dos dados usados na versão-2. A versão-1 pode usar o valor 2Gb para a configuração de memória ("memory": "2Gb") e a versão-2 pode especificar um valor diferente ("memory": "4Gb"). Além disso, uma coleção pode incluir definições de configuração que não aparecem em seus componentes. Esses valores são chamados de sobreposições.

    Uma coleção pode representar uma versão específica de uma aplicação, localização ou conjunto de recursos. Por exemplo, uma coleção chamada collection-2 pode incluir o conjunto de componentes ou versões de componentes que representam a funcionalidade da versão 2.0 da aplicação. Por outro lado, uma coleção chamada collection-3 que representa a funcionalidade da Versão 3.0 pode incluir o mesmo conjunto de componentes ou versões de componentes, componentes adicionais ou versões de componentes e outras configurações de variável, substituição e sobreposição.

    Pasta de variáveis de coleções
    A pasta Vars de coleção pode conter variáveis que qualquer CDI na pasta Coleções pode usar. Cada coleção tem uma pasta Vars de coleção. Uma variável de coleção tem precedência maior do que uma variável de componente.
    Implantáveis

    Você adiciona e configura implantáveis na estrutura de dados. Um implantável é um conjunto de dados de configuração (para um ambiente DEV, TEST ou PROD) que pode ser implantado pelo seu processo de entrega. Cada implantável em uma aplicação representa a configuração de um serviço no CMDB.

    Um implantável é composto pela coleção ou conjunto de coleções que definem a versão para um ambiente específico. A combinação de coleções + link de ambiente para um serviço de aplicativos no CMDB ou para um serviço de infraestrutura.

    Um implantável pode incluir variáveis ou substituir configurações específicas do ambiente. Por exemplo, a variável de banco de dados tem um valor no ambiente de desenvolvimento e um valor diferente no ambiente de produção. Um valor de substituição na produção implantável pode especificar um parâmetro de contêiner necessário que não é necessário no ambiente de desenvolvimento.

    Um exemplo implantável chamado DEV-2 incluiria a coleção-2 e especificaria configurações de variável, substituição e sobreposição que são específicas para o ambiente de desenvolvimento da versão 2.0. Por outro lado, o implantável chamado PROD-2 também incluiria a coleção-2, mas, em vez disso, especificaria configurações específicas para o ambiente de produção da versão 2.0.

    Quando estiver satisfeito com um conjunto de mudanças, você poderá salvar e confirmar as mudanças. O sistema verifica se há conflitos com os changesets confirmados de outros usuários. Se não houver conflitos, o sistema persistirá nas mudanças e gerará um snapshot de cada implantável afetado pelas mudanças. Um snapshot representa um conjunto de dados de configuração exportável em potencial. O sistema valida os dados de configuração executando políticas em cada snapshot e retornando os resultados de validação.

    Pasta de variáveis implantáveis
    A pasta Variáveis implantáveis pode conter variáveis que qualquer CDI na pasta Implantáveis pode usar. Cada implantável tem uma pasta de variáveis implantáveis. Uma variável implantável tem precedência maior do que uma variável de coleção.

    Exemplo

    No diagrama a seguir da aplicação BookStore de exemplo, os números identificam os relacionamentos entre componentes, coleções e implantáveis.
    1. Os componentes são agrupados para formar coleções que representam ambientes ou versões de ambientes. A coleção FS2 (conjunto de recursos 2) tem dados de configuração para o Core versão 2 da aplicação que está sendo desenvolvida e testada no momento. O FS1, por outro lado, contém a versão anterior do Core 1 que foi totalmente testada e está executando a aplicação no ambiente de produção.
    2. No exemplo, tanto o FS2 (a coleção usada em ambientes de teste) quanto o FS1 (a coleção usada no ambiente de produção) usam dados de configuração para S3 e um VM templateespecífico. As coleções FS1 e FS2, portanto, herdam esses dois componentes. Como as coleções representam diferentes conjuntos de recursos, provavelmente o FS1 e o FS2 usam variáveis ou substituições para especificar algumas configurações diferentes para os componentes.
    3. Cada implantável inclui a coleção apropriada para seu ambiente (desenvolvimento, teste ou produção). No exemplo, o implantável de TESTE usa a coleção FS2, a versão mais recente do conjunto de recursos e outras definições de configuração que são usadas em ambientes de teste. O implantável PROD, por outro lado, usa FS1 no ambiente de produção. FS1 é a versão anterior da coleção de dados de configuração que foi validada para produção.

      Em cada implantável, as variáveis são definidas com valores apropriados para o ambiente. Por exemplo, em PROD, a variável do banco de dados é definida como prod1 (o banco de dados de produção). O implantável de TESTE, no entanto, especifica um dos bancos de dados que é usado pela equipe de teste, test3.

    Este diagrama é simplificado. Em sua implementação, implantáveis pode incluir várias coleções, configurações de substituição e variáveis e configurações de sobreposição (configurações que não aparecem nos componentes e coleções que compõem o implantável). Além disso, você pode ter vários implantáveis para cada tipo de ambiente.

    Como componentes e coleções fornecem conteúdo que você pode criar em implantáveis para uma variedade de ambientes

    Definições

    CDI
    Um item de dados de configuração (CDI) é um nó de chave-valor simples.
    Variável
    Uma variável é um item de chave-valor que pode ser referenciado em um CDI.
    Nós primários e nós secundários (folha)
    • CDIs e variáveis são itens de chave-valor. CDIs e variáveis só podem ser nós secundários.
    • Nós de componentes, coleções, implantáveis e pastas podem ser nós primários - nós que podem ter itens de chave-valor ou outros nós primários.
    Nota:

    A partir da Gestão de dados de configuração versão 4.2, você pode definir um nó usando qualquer caractere UTF-8, incluindo a barra (/).

    Caminho do nome
    O caminho do nome é o caminho completo da pasta do nó selecionado na lista. Na REST API, você pode fornecer o caminho do nome na matriz nos seguintes formatos:
    • Formato de barra invertida: por exemplo - testApp/deployables/Development1/cdi1
      Nota:
      Se o nome do nó contiver uma barra invertida ("/"), você não poderá usar este formato.
    • Caminho do nome de back-end com caracteres de substituição: por exemplo - testApp​deployables​Development1​cdi1
    • Matriz: Por exemplo - ['testApp','deployables','Development1','cdi1']
    Componentes
    Componentes são os blocos de construção que normalmente representam os dados de configuração de um elemento lógico de uma aplicação ou de uma parte de um serviço de infraestrutura. Por exemplo, um app monolítico, um microsserviço, um servidor físico ou um modelo do Docker.

    Um componente pode conter variáveis que podem assumir valores diferentes em coleções e implantáveis. Instruções mais detalhadas aparecem em Definir ou atualizar um componente.

    Coleções

    Uma coleção é o conjunto de componentes que, juntos, definem uma versão. Você pode pensar em uma coleção como uma composição de versão.

    Uma coleção pode conter configurações variáveis ou de substituição que são específicas para a versão específica. Por exemplo, os dados de configuração da VM usados na versão-1 são diferentes dos dados usados na versão-2. A versão-1 pode usar o valor 2Gb para a configuração de memória ("memory": "2Gb") e a versão-2 pode especificar um valor diferente ("memory": "4Gb"). Além disso, uma coleção pode incluir definições de configuração que não aparecem em seus componentes. Você pode pensar nesses valores como "sobreposições".

    Implantáveis

    Um implantável é um conjunto de dados de configuração (para um ambiente de desenvolvimento, teste ou produção) que pode ser implantado no pipeline de IC/CD como um serviço. Cada implantável em uma aplicação configura um serviço no CMDB. Por exemplo, você pode criar três implantáveis, um para cada tipo de ambiente: Desenvolvimento, Teste e Produção.

    Um implantável é composto pela coleção ou conjunto de coleções que definem a versão de um ambiente específico. A combinação de coleções + link de ambiente para um serviço de aplicativos no CMDB ou um serviço de infraestrutura.

    Um implantável pode conter configurações variáveis ou de substituição que são específicas do ambiente. Por exemplo, a variável de banco de dados tem um valor no ambiente de desenvolvimento e um valor diferente no ambiente de produção. Um valor de substituição na produção implantável pode especificar um parâmetro de contêiner necessário que não é necessário no ambiente de desenvolvimento.

    Changesets e snapshots
    Quando você confirma mudanças em uma aplicação CDM, o sistema persiste nas mudanças como um changeset da aplicação. O sistema também gera um snapshot de cada implantável afetado pelas mudanças. Um snapshot representa um conjunto de dados de configuração exportável em potencial. O sistema valida os dados de configuração executando políticas em cada snapshot e retornando os resultados de validação. Os snapshots aprovados na validação e publicados podem ser exportados para o pipeline de versão como dados de configuração.
    Componentes compartilhados e bibliotecas de componentes
    Componentes compartilhados em Gestão de dados de configuração permitem que você use um componente em várias aplicações.

    Para melhor organização, esses componentes compartilhados são gerenciados em Bibliotecas de componentes. Essas bibliotecas de componentes melhoram a consistência e a manutenção, garantindo uma única fonte de verdade para os dados de configuração de um componente em todas as aplicações.

    Nós de arquivo
    Um nó de arquivo é criado quando você anexa um arquivo ao modelo de dados de configuração de um app CDM ou a uma biblioteca de componentes. Ele contém um link para o arquivo anexado. Usando nós de arquivo, você pode anexar arquivos de qualquer tipo MIME compatível em Now Platform.