Antipadrão: gerenciar recursos sem usar o gerenciamento de controle de origem

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

A Apigee oferece muitos tipos de recursos, e cada um deles tem uma finalidade diferente. Há determinados recursos que podem ser configurados, ou seja, criados, atualizados e/ou excluídos, somente por meio da IU da Apigee, das APIs da Apigee ou de ferramentas que usam APIs e por usuários com os papéis e as permissões nos pré-requisitos. Por exemplo, somente administradores da organização que pertencem a uma organização específica podem configurar esses recursos. Isso significa que esses recursos não podem ser configurados por usuários finais por meio de portais de desenvolvedor nem por outros meios. Esses recursos incluem as seguintes funções:

Proxies de API
Fluxos compartilhados
Produtos de API
Caches
KVMs
Keystores e truststores
Hosts virtuais
Servidores de destino
Arquivos de recursos

Embora esses recursos tenham acesso restrito, se alguma modificação for feita até mesmo pelos usuários autorizados, os dados históricos serão substituídos pelos novos dados. Isso se deve ao fato de que esses recursos são armazenados na Apigee apenas de acordo com o estado atual. As principais exceções a essa regra são proxies de API e fluxos compartilhados.

Proxies de API e fluxos compartilhados no controle de revisão

Os proxies de API e os fluxos compartilhados são gerenciados, ou seja, criados, atualizados e implantados, por meio de revisões. As revisões são numeradas sequencialmente, o que permite adicionar novas alterações e salvá-las como uma nova revisão ou reverter uma alteração implantando uma revisão anterior do fluxo de proxy/API compartilhada. A qualquer momento, pode haver apenas uma revisão de um proxy de API/fluxo compartilhado implantado em um ambiente, a menos que as revisões tenham um caminho base diferente.

Embora os proxies da API e os fluxos compartilhados sejam gerenciados por meio de revisões, as modificações são feitas em uma revisão existente, mas não há como reverter, uma vez que as alterações antigas são simplesmente substituídas.

Auditorias e histórico

A Apigee fornece o recurso de auditorias, que pode ser útil nos cenários de solução de problemas. Esses recursos permitem que você veja informações como quem executou operações específicas, como criar, ler, atualizar, excluir, implantar e remover a implantação, e quando as operações foram realizadas nos recursos da Apigee. No entanto, se alguma operação de atualização ou exclusão for executada em qualquer um dos recursos da Apigee, as auditorias não fornecerão os dados mais antigos.

Antipadrão

Gerenciar os recursos da Apigee listados acima diretamente por meio da IU ou das APIs da Apigee, sem usar o sistema de controle de origem

Há um conceito incorreto de que a Apigee poderá restaurar recursos para o estado anterior após modificações ou exclusões. No entanto, a Apigee não fornece a restauração de recursos ao estado anterior. Portanto, é responsabilidade do usuário garantir que todos os dados relacionados aos recursos da Apigee sejam gerenciados por meio do gerenciamento do controle de origem, de modo que os dados antigos possam ser restaurados rapidamente no caso de exclusão acidental ou situações em que seja necessário fazer alterações que precisem ser revertidas. Isso é particularmente importante para ambientes de produção em que esses dados são necessários para o tráfego no ambiente de execução.

Vamos explicar isso com a ajuda de alguns exemplos e o tipo de impacto que pode ser causado se os dados não são gerenciados por meio de um sistema de controle de origem e forem modificados/excluídos de forma consciente ou inconscientemente:

Exemplo 1: exclusão ou modificação do proxy da API

Quando um proxy de API é excluído ou uma alteração é implantada em uma revisão existente, o código anterior não é recuperável. Se o proxy da API contém código Java, JavaScript ou Python que não é administrado em um sistema de gerenciamento de controle de origem (SCM, na sigla em inglês) fora da Apigee, muito trabalho e esforço de desenvolvimento podem ser perdidos.

Exemplo 2: determinação de proxies de API usando hosts virtuais específicos

Um certificado em um host virtual está expirando e ele precisa ser atualizado. Identificar quais proxies de API usam esse host virtual para fins de teste pode ser difícil se houver muitos proxies de API. Se os proxies de API forem gerenciados em um sistema SCM fora da Apigee, será fácil pesquisar no repositório.

Exemplo 3: exclusão de keystore/truststore

Se um keystore/truststore usado por um host virtual ou uma configuração de servidor de destino for excluída, não será possível restaurá-lo, a menos que os detalhes de configuração do keystore/truststore, incluindo certificados e/ou chaves privadas estejam armazenadas no controle de origem.

Impacto

Se algum dos recursos da Apigee for excluído, não será possível recuperar esse recurso nem o conteúdo dele.
As solicitações de API podem falhar com erros inesperados que levam à interrupção até que o recurso seja restaurado ao estado anterior.
É difícil pesquisar inter dependências entre proxies de API e outros recursos no Apigee.

Prática recomendada

Use qualquer SCM padrão acoplado a um pipeline de integração e implantação contínuas (CICD, na sigla em inglês) para gerenciar proxies de API e fluxos compartilhados.
Use qualquer SCM padrão para gerenciar os outros recursos da Apigee, incluindo produtos de API, caches, KVMs, servidores de destino, hosts virtuais e keystores.
- Se houver recursos da Apigee existentes, use as APIs para receber os detalhes de configuração para eles como um payload JSON/XML e armazená-los no gerenciamento de controle de origem.
- Administre novas atualizações nesses recursos no gerenciamento de controle de origem.
- Se for preciso criar novos recursos da Apigee ou atualizar recursos existentes, use o payload JSON/XML apropriado armazenado no gerenciamento de controle de origem e atualize a configuração na Apigee usando APIs.

* As KVMs criptografadas não podem ser exportadas em texto simples da API. É responsabilidade do usuário manter um registro dos valores colocados em KVMs criptografadas.