Esta página foi traduzida pela API Cloud Translation.

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

Neste tópico, discutimos como adicionar uma segunda organização híbrida da Apigee (org) a um cluster atual do Kubernetes. Nessa configuração multi-org, as duas organizações usam e compartilham o mesmo anel 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 é compatível com as limitações a seguir. Até que essas limitações sejam reduzidas, não recomendamos que você use essa configuração.

Se você tiver várias instâncias da Apigee híbrida, cada uma precisará ter o próprio cluster. Várias instâncias da Apigee híbrida em execução no mesmo cluster do Kubernetes podem levar a problemas de instabilidade que podem causar inatividade.
Todos os registros dos pods são enviados para o primeiro projeto do Google Cloud configurado. Essa limitação é mais aparente na ferramenta Cloud Logging. Os registros das outras organizações da Apigee não serão enviadas para o projeto correspondente do Google Cloud. Os registros ainda são capturados no nível do pod e podem ser recuperados com comandos kubectl. No entanto, eles não são enviados para o projeto do Cloud correto pelo Cloud Logging.
Não é possível excluir dados da organização no banco de dados do Cassandra para apenas uma organização. Isso significa que não é possível remover organizações de maneira seletiva. Qualquer modificação na configuração do banco de dados afeta todas as organizações implantadas no cluster.
O procedimento de upgrade híbrido atualiza todo o cluster de uma só vez.
O backup e a restauração são feitos como um cluster e não podem ser feitos para uma organização específica.
O recurso de monitoramento da API Apigee (linha do tempo, recente, investigar) só funciona para a primeira organização que foi configurada e implantada. Ele não vai funcionar para as outras organizações em um cluster de várias organizações.

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

Nesta seção, descrevemos como o suporte da Apigee lida com clusters e recomendações de várias organizações para implantações futuras:

Se você tiver clusters do Kubernetes de várias organizações implantados em contextos de não produção e produção, o suporte da Apigee continuará a oferecer suporte a eles. No entanto, observe as limitações técnicas descritas na próxima seção. Recomendamos que você mude todas as implantações de produção futuras para usar uma organização da Apigee por cluster.
Se você tiver clusters de várias organizações em contextos de não produção, o suporte da Apigee continuará a oferecer suporte a eles. Recomendamos que você migre todos os clusters de produção para uma nova configuração que use uma organização da Apigee por cluster.

Pré-requisitos

Antes de continuar, observe o seguinte:

É necessário ter uma organização híbrida com um ou mais ambientes instalados e configurados em um cluster do Kubernetes. Consulte as instruções de instalação híbrida.
Ao combinar várias organizações em um único cluster, todas as versões híbridas precisam ser correspondentes. Antes de adicionar uma segunda organização a um cluster, faça o upgrade da instalação híbrida atual, se necessário. Consulte Como fazer upgrade da Apigee híbrida.

Criar uma organização para adicionar ao cluster atual

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

Configurar a nova organização

Nas etapas a seguir, você vai criar um novo arquivo de modificações que vai ser configurado para a nova organização. Um arquivo overrides.yaml é compatível apenas com informações de uma organização. Portanto, você precisa criar um novo arquivo overrides.yaml e aplicá-lo ao cluster atual do Kubernetes.

Crie contas de serviço para usar com a nova organização. Consulte Criar contas de serviço.
Anote os arquivos de certificado TLS (.key e .pem) no diretório certs. Se precisar criá-los novamente, siga as instruções em Criar certificados TLS.
Copie o overrides.yaml atual em um novo arquivo para usar como ponto de partida para configurar a nova organização. Por exemplo: new-overrides.yaml.

Edite o novo arquivo de modificaçõ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
    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 a seguir descreve cada um dos valores de propriedade que você precisa fornecer no arquivo de modificações. Para mais informações, consulte 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 nesse cluster precisam ter o mesmo ID de instância. Portanto, ela precisa corresponder à entrada `instanceID` no arquivo de modificações da organização original. No caso de instalações multirregionais, cada região requer o próprio cluster. Os clusters individuais não abrangem regiões. Portanto, cada cluster precisa ter o próprio ID de instância exclusivo compartilhado por cada organização no cluster.
`existing-cluster-name`	O nome do cluster ao qual você está adicionando esta organização. Ele precisa corresponder à entrada `k8sCluster.name` no arquivo de modificações do cluster original.
`existing-cluster-analytics-region`	A região onde o cluster original é provisionado. Ele precisa corresponder à entrada `k8sCluster.region` no arquivo de modificações do cluster original.
`new-project-id`	O ID 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 análise que você especificou ao criar a nova organização. Ela não precisa ser a mesmo que a região da organização atual.
`namespace`	Todas as organizações no cluster precisam compartilhar o mesmo namespace. É importante usar o mesmo namespace usado para a organização original. O namespace da maioria das instalações é `apigee`.
`new-environment-group-name`	O novo grupo de ambientes que você criou para a nova organização. Cuidado: os nomes dos grupos de ambientes da nova organização não podem ser iguais aos nomes dos grupos de ambientes de outras organizações. Os nomes das versões do Helm para ambientes seriam os mesmos, o que dificultaria o gerenciamento dos gráficos.
`cert-file-name` e `key-file-name`	Os arquivos de certificado e de chave TLS do cluster que você verificou ou criou na etapa 1 nesta seção.
`new-environment-name`	O nome do ambiente que você criou para a nova organização. Cuidado: os nomes dos ambientes da nova organização não podem ser iguais aos nomes de ambientes de outras organizações.
`new-service-accounts-directory`	O diretório em que os arquivos de chave da conta de serviço que você criou para a nova organização estão localizados.

Aplique a configuração

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

Faça uma instalação de simulação para verificar se há problemas:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run=server
```
Observação: é recomendável fazer uma simulação antes de aplicar a configuração para determinar se há algum problema.
Se não houver problemas, aplique os componentes no nível da organização. Esta etapa instala os jobs do Cassandra (usuário e esquema), Apigee Connect, Apigee Watcher e MART:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```

Instale o ambiente. Nesta etapa, os componentes do ambiente de execução da Apigee, sincronizador e UDCA são instalados:

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

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. Esta etapa configura a entrada para detectar os novos hosts virtuais da segunda organização:

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

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

Ative o acesso do sincronizador à nova organização seguindo as etapas em Ativar acesso do sincronizador.
Por padrão, quando você instala o ambiente de execução híbrido da Apigee pela primeira vez, o componente Telemetry é configurado com multiOrgCluster desativado. Use as etapas a seguir para ativar a telemetria de várias organizações em cada organização do cluster:
1. Exclua o componente Telemetry existente com os seguintes comandos:
```
helm delete telemetry
```
  Observação: a exclusão do componente Telemetry interrompe a exportação das métricas para o Google Monitoring. Siga as etapas abaixo para reativar as métricas.
2. Adicione a seguinte linha ao arquivo overrides.yaml da sua organização:
```
multiOrgCluster: true
```
3. Aplique as alterações para instalar o componente Telemetry para a organização.
  Faça primeiro uma simulação:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run=server
```
  Se a simulação for bem-sucedida, aplique as alterações e instale o componente Telemetry:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. Verifique se a linha a seguir está no arquivo overrides.yaml de cada nova organização.
```
multiOrgCluster: true
```
5. Aplique as alterações para instalar o componente Telemetry para cada nova organização. Repita o procedimento para cada nova organização no cluster de várias organizações.
  Faça primeiro uma simulação:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run=server
```
  Se a simulação for bem-sucedida, aplique as alterações e instale o componente Telemetry:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```