Esta página foi traduzida pela API Cloud Translation.

Adicionar várias organizações híbridas a um cluster

Este tópico aborda como adicionar uma segunda organização (org) híbrida do Apigee a um cluster do Kubernetes existente. Nesta configuração com várias organizações, ambas as organizações usam e partilham o mesmo anel do Cassandra. Cada organização pode ter vários ambientes e grupos de ambientes configurados.

Limitações

Uma configuração de várias organizações por cluster é suportada com as seguintes limitações. Até que estas limitações sejam atenuadas, não recomendamos que use esta configuração:

Se vai ter várias instâncias híbridas do Apigee, cada instância deve ter o seu próprio cluster. A execução de várias instâncias híbridas do Apigee no mesmo cluster do Kubernetes pode originar problemas de instabilidade que podem causar tempo de inatividade.
Todos os registos dos pods são enviados para o primeiro projeto do Google Cloud que foi configurado. Esta limitação é mais evidente na ferramenta Registos na nuvem. Os registos das outras organizações do Apigee não são enviados para o projeto do Google Cloud correspondente. Os registos continuam a ser capturados ao nível do pod e podem ser obtidos com comandos kubectl. No entanto, não são enviadas para o projeto na nuvem correto através do Cloud Logging.
Não é possível eliminar dados da organização na base de dados Cassandra apenas para uma organização. Isto significa que não pode remover organizações seletivamente. Qualquer modificação à configuração da base de dados afeta todas as organizações implementadas nesse cluster.
O procedimento de atualização híbrida atualiza todo o cluster de uma só vez.
A cópia de segurança e o restauro são feitos como um cluster e não podem ser feitos para uma organização específica.
A funcionalidade Apigee API Monitoring (Linha cronológica, Recente, Investigar) só funciona para a primeira organização que foi configurada e implementada. Não funciona para as outras organizações num cluster com várias organizações.

Opções de várias organizações

Esta secção descreve como o apoio técnico do Apigee processa os clusters multi-org existentes e as recomendações para implementações futuras:

Se tiver clusters Kubernetes multi-org existentes implementados em contextos de não produção e produção, o apoio técnico do Apigee vai continuar a suportá-los. No entanto, tenha em atenção as limitações técnicas descritas na secção seguinte. Recomendamos que altere todas as implementações de produção futuras para usar uma organização do Apigee por cluster.
Se tiver clusters multi-org existentes em contextos de não produção, o apoio técnico do Apigee vai continuar a suportá-los. Recomendamos que migre todos os clusters de produção para uma nova configuração que use uma organização do Apigee por cluster.

Pré-requisitos

Antes de continuar, tenha em atenção o seguinte:

Tem de ter uma organização híbrida existente com um ou mais ambientes instalados e configurados num cluster do Kubernetes existente. Consulte as instruções de instalação híbrida.
Quando combina várias organizações num único cluster, as versões híbridas têm de corresponder. Antes de adicionar uma segunda organização a um cluster, atualize a instalação híbrida existente, se necessário. Consulte o artigo Atualizar o Apigee Hybrid.

Crie uma organização para adicionar ao cluster existente

Para criar a organização adicional, siga os passos na Parte 1: configuração do projeto e da organização.

Configure a nova organização

Nos passos seguintes, vai criar um novo ficheiro de substituições e configurá-lo para a nova organização. Um ficheiro overrides.yaml só pode suportar as informações de uma organização. Por conseguinte, tem de criar um novo ficheiro overrides.yaml e aplicá-lo ao cluster do Kubernetes existente.

Crie contas de serviço para utilização com a nova organização. Consulte o artigo Crie contas de serviço.
Tome nota dos ficheiros de certificado TLS (.key e .pem) no diretório certs. Se precisar de criá-los novamente, pode seguir as instruções em Crie certificados TLS.
Copie o seu ficheiro overrides.yaml existente para um novo ficheiro para usar como ponto de partida para configurar a sua nova organização. Por exemplo: new-overrides.yaml.

Edite o novo ficheiro de substituições com as seguintes configurações:

org: "new-org-name"
instanceID: "instance-id"   ## Must match the instanceID of your existing org.

multiOrgCluster: true ## Enables exporting metrics for this org to the Google Cloud Project named with gcp:projectID

k8sCluster:
  name: "existing-cluster-name"
  region: "existing-cluster-analytics-region"

gcp:
  projectID: "new-project-id"
  name: "new-project-id"
  region: "new-project-default-location"

namespace: namespace ## must be the same for both new and existing orgs

virtualhosts:
  - name: new-environment-group-name
    selector:
      app: apigee-ingressgateway
      ingress_name: old-ingress-name
    sslCertPath: ./certs/cert-file-name # .crt or .pem
    sslKeyPath: ./certs/key-file-name # .key

envs:
  - name: new-environment-name
    serviceAccountPaths:
      runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json
      synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json
      udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json

connectAgent:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

mart:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

metrics:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json

watcher:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json

A tabela seguinte descreve cada um dos valores das propriedades que tem de fornecer no ficheiro de substituições. Para mais informações, consulte a referência da propriedade de configuração.

Variável	Descrição
`new-org-name`	O nome da nova organização.
`instance-id`	Todas as organizações neste cluster têm de ter o mesmo ID da instância. Por conseguinte, tem de corresponder à entrada `instanceID` no ficheiro de substituições da sua organização original. Para instalações em várias regiões, cada região requer o seu próprio cluster, porque os clusters individuais não abrangem regiões. Por conseguinte, cada cluster tem de ter o seu próprio ID de instância exclusivo partilhado por todas as organizações no cluster.
`existing-cluster-name`	O nome do cluster ao qual está a adicionar esta organização. Tem de corresponder à entrada `k8sCluster.name` no ficheiro de substituições do cluster original.
`existing-cluster-analytics-region`	A região onde o cluster original é aprovisionado. Tem de corresponder à entrada `k8sCluster.region` no ficheiro de substituições para o seu cluster original.
`new-project-id`	O ID do projeto do seu novo projeto. O ID do projeto e o nome da organização são os mesmos.
`new-project-default-location`	A região de estatísticas que especificou quando criou a nova organização. Não tem de ser igual à região da organização existente.
`namespace`	Todas as organizações no cluster têm de partilhar o mesmo espaço de nomes. Certifique-se de que usa o mesmo espaço de nomes que foi usado para a organização original. O espaço de nomes para a maioria das instalações é `apigee`.
`new-environment-group-name`	O novo grupo de ambientes que criou para a nova organização. Atenção: os nomes dos grupos de ambientes da nova organização não devem ser iguais aos nomes dos grupos de ambientes de qualquer outra organização. Os nomes das versões do Helm para os ambientes seriam os mesmos, o que dificultaria a gestão dos gráficos.
`cert-file-name` e `key-file-name`	Os ficheiros de chave e certificado TLS para o cluster que verificou ou criou no passo 1 desta secção.
`new-environment-name`	O nome do ambiente que criou para a nova organização. Atenção: os nomes dos ambientes da nova organização não devem ser iguais aos nomes dos ambientes de qualquer outra organização.
`new-service-accounts-directory`	O diretório onde se encontram os ficheiros de chaves da conta de serviço que criou para a nova organização.

Aplique a configuração

Aplique a nova configuração da organização ao cluster:

Faça uma instalação de teste para verificar se existem problemas:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run
```
Nota: é recomendável fazer uma experiência antes de aplicar a configuração para determinar se existem problemas.
Se não houver problemas, aplique os componentes ao nível da organização. Este passo instala as tarefas do Cassandra (utilizador e esquema), os serviços do Apigee Connect, do Apigee Watcher e do MART:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```

Instale o ambiente. Este passo instala os componentes apigee-runtime, synchronizer e UDCA, por ambiente:

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml

Aplique as alterações do balanceador de carga. Este passo configura a entrada para ouvir os novos anfitriões virtuais para a segunda organização:

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f NEW_OVERRIDES_FILE.yaml

Ative o acesso do sincronizador para a sua nova organização seguindo os passos em Ative o acesso do sincronizador.
Por predefinição, quando instala o tempo de execução híbrido do Apigee pela primeira vez, o componente Telemetry é configurado com o multiOrgCluster desativado. Siga estes passos para ativar a telemetria de várias organizações para cada organização no seu cluster:
1. Elimine o componente de telemetria existente com os seguintes comandos:
```
helm delete telemetry -n APIGEE_NAMESPACE
```
  Nota: a eliminação do componente de telemetria impede a exportação das métricas para o Google Monitoring. Siga os passos seguintes para reativar as métricas.
2. Adicione a seguinte linha ao ficheiro overrides.yaml da sua organização existente.
```
multiOrgCluster: true
```
3. Aplique as alterações para instalar o componente de telemetria para a organização.
  Faça uma execução de ensaio primeiro:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run
```
  Se a execução de teste for bem-sucedida, aplique as alterações e instale o componente de telemetria:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. Certifique-se de que a seguinte linha está no ficheiro overrides.yaml para cada nova organização.
```
multiOrgCluster: true
```
5. Aplique as alterações para instalar o componente de telemetria para cada nova organização. Repita este processo para cada nova organização no cluster com várias organizações.
  Faça uma execução de ensaio primeiro:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run
```
  Se a execução de teste for bem-sucedida, aplique as alterações e instale o componente de telemetria:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```