Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
O Apigee Edge oferece vários tipos diferentes 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 do Edge, APIs de gerenciamento ou ferramentas que usam APIs de gerenciamento e por usuários com os papéis e permissões de pré-requisito. 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 recurso
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 no Apigee Edge apenas de acordo com o estado atual deles. 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
O Apigee Edge fornece recursos de auditoria e API, produto e histórico que podem ser úteis em cenários de solução de problemas. Esses recursos permitem visualizar informações como quem executou operações específicas (criar, ler, atualizar, excluir, implantar e cancelar a implantação) e quando as operações foram realizadas nos recursos do Edge. No entanto, se alguma operação de atualização ou exclusão for executada em qualquer um dos recursos do Edge, as auditorias não poderão fornecer os dados mais antigos.
Antipadrão
Como gerenciar os recursos do Edge (listados acima) diretamente pela IU do Edge ou pelo API Management sem usar o sistema de controle de origem
Há uma ideia errada de que o Apigee Edge poderá restaurar recursos para o estado anterior após modificações ou exclusões. No entanto, o Edge Cloud não fornece restauração dos recursos ao estado anterior. Portanto, é responsabilidade do usuário garantir que todos os dados relacionados aos recursos do Edge sejam administrados 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 as alterações precisem ser revertidas. Isso é particularmente importante para ambientes de produção em que esses dados são necessários para o tráfego de tempo 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, Node.js 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 do Edge for excluído, não vai ser possível recuperar o recurso e o conteúdo dele do Apigee Edge.
- As solicitações de API podem falhar, com erros inesperados, levando à interrupção até que o recurso seja restaurado ao estado anterior.
- É difícil procurar interdependências entre proxies de API e outros recursos no Apigee Edge.
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 do Edge, incluindo produtos de API,
caches, KVMs, servidores de destino, hosts virtuais e keystores.
- Se houver recursos do Edge, use as APIs de gerenciamento para ver os detalhes de configuração deles como um payload JSON/XML e armazene-os no gerenciamento do controle de origem.
- Gerencie as novas atualizações desses recursos no gerenciamento do controle de origem.
- Se for necessário criar novos recursos do Edge ou atualizar os atuais, use o payload JSON/XML apropriado armazenado no gerenciamento do controle de origem e atualize a configuração no Edge usando APIs de gerenciamento.
* 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.