Antipattern: gerir recursos sem usar a gestão de controlo de origem

Está a ver a documentação do Apigee e do Apigee Hybrid.
Veja a documentação do Apigee Edge.

O Apigee oferece muitos tipos diferentes de recursos e cada um deles tem uma finalidade diferente. Existem determinados recursos que só podem ser configurados (ou seja, criados, atualizados e/ou eliminados) através da IU do Apigee, das APIs Apigee ou de ferramentas que usam APIs, e por utilizadores com as funções e as autorizações necessárias. Por exemplo, apenas os administradores organizacionais pertencentes a uma organização específica podem configurar estes recursos. Isto significa que estes recursos não podem ser configurados pelos utilizadores finais através de portais para programadores nem por outros meios. Estes recursos incluem:

  • Proxies de API
  • Fluxos partilhados
  • Produtos API
  • Caches
  • KVMs
  • Armazenamentos de chaves e armazenamentos de confiança
  • Anfitriões virtuais
  • Servidores de destino
  • Ficheiros de recursos

Embora estes recursos tenham acesso restrito, se forem feitas modificações aos mesmos, mesmo por parte dos utilizadores autorizados, os dados do histórico são simplesmente substituídos pelos novos dados. Isto deve-se ao facto de estes recursos serem armazenados no Apigee apenas de acordo com o respetivo estado atual. As principais exceções a esta regra são os proxies de API e os fluxos partilhados.

Proxies de API e fluxos partilhados sob controlo de revisões

Os proxies de API e os fluxos partilhados são geridos, ou seja, criados, atualizados e implementados, através de revisões. As revisões são numeradas sequencialmente, o que lhe permite adicionar novas alterações e guardá-las como uma nova revisão ou reverter uma alteração implementando uma revisão anterior do proxy/fluxo partilhado da API. Em qualquer momento, só pode existir uma revisão de um proxy de API/fluxo partilhado implementado num ambiente, a menos que as revisões tenham um caminho base diferente.

Embora os proxies da API e os fluxos partilhados sejam geridos através de revisões, se forem feitas modificações a uma revisão existente, não é possível reverter, uma vez que as alterações antigas são simplesmente substituídas.

Auditorias e histórico

O Apigee fornece a funcionalidade Auditorias que pode ser útil em cenários de resolução de problemas. Estas funcionalidades permitem-lhe ver informações como quem realizou operações específicas (criar, ler, atualizar, eliminar, implementar e anular a implementação) e quando as operações foram realizadas nos recursos do Apigee. No entanto, se forem realizadas operações de atualização ou eliminação em qualquer um dos recursos do Apigee, as auditorias não podem fornecer os dados mais antigos.

Antipattern

Gerir os recursos do Apigee (indicados acima) diretamente através da IU ou das APIs do Apigee sem usar o sistema de controlo de origem

Existe uma ideia errada de que o Apigee vai poder restaurar os recursos para o respetivo estado anterior após modificações ou eliminações. No entanto, o Apigee não oferece a restauração dos recursos ao respetivo estado anterior. Por conseguinte, é da responsabilidade do utilizador garantir que todos os dados relacionados com os recursos do Apigee são geridos através da gestão do controlo de origem, para que os dados antigos possam ser restaurados rapidamente em caso de eliminação acidental ou situações em que seja necessário reverter qualquer alteração. Isto é particularmente importante para ambientes de produção onde estes dados são necessários para o tráfego de tempo de execução.

Vamos explicar isto com a ajuda de alguns exemplos e o tipo de impacto que pode ser causado se os dados não forem geridos através de um sistema de controlo de origem e forem modificados/eliminados de forma consciente ou inconsciente:

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

Quando um proxy de API é eliminado ou é implementada uma alteração numa revisão existente, não é possível recuperar o código anterior. Se o proxy de API contiver código Java, JavaScript ou Python que não seja gerido num sistema de gestão de controlo de origem (SCM) fora do Apigee, pode perder muito trabalho e esforço de desenvolvimento.

Exemplo 2: determinação de proxies de API através de anfitriões virtuais específicos

Um certificado num anfitrião virtual está a expirar e esse anfitrião virtual tem de ser atualizado. A identificação dos proxies de API que usam esse anfitrião virtual para fins de teste pode ser difícil se existirem muitos proxies de API. Se os proxies de API forem geridos num sistema SCM fora do Apigee, é fácil pesquisar no repositório.

Exemplo 3: eliminação do keystore/truststore

Se um keystore/truststore usado por uma configuração de servidor de destino ou anfitrião virtual for eliminado, não é possível restaurá-lo, a menos que os detalhes de configuração do keystore/truststore, incluindo certificados e/ou chaves privadas, estejam armazenados no controlo de origem.

Impacto

  • Se algum dos recursos do Apigee for eliminado, não é possível recuperar o recurso e o respetivo conteúdo do Apigee.
  • Os pedidos de API podem falhar com erros inesperados que levam a uma indisponibilidade até o recurso ser restaurado para o respetivo estado anterior.
  • É difícil pesquisar interdependências entre proxies de API e outros recursos no Apigee.

Prática recomendada

  • Use qualquer SCM padrão juntamente com um pipeline de integração contínua e implementação contínua (CICD) para gerir proxies de API e fluxos partilhados.
  • Use qualquer SCM padrão para gerir os outros recursos do Apigee, incluindo produtos de API, caches, KVMs, servidores de destino, anfitriões virtuais e keystores.
    • Se existirem recursos do Apigee, use as APIs Apigee para obter os detalhes de configuração dos mesmos como uma carga útil JSON/XML e armazene-os na gestão de controlo de origem.
    • Gerir novas atualizações a estes recursos na gestão de controlo de origens.
    • Se for necessário criar novos recursos do Apigee ou atualizar recursos existentes, use a carga útil JSON/XML adequada armazenada na gestão de controlo de origem e atualize a configuração no Apigee através de APIs.

* Não é possível exportar KVMs encriptados em texto simples a partir da API. É da responsabilidade do utilizador manter um registo dos valores introduzidos nos KVMs encriptados.

Leitura complementar