App Builder na AWS
Este guia orienta você sobre a configuração do App Builder na AWS, habilitando a análise automática de dados e os insights. Siga as etapas para definir e otimizar sua configuração de forma eficiente.
Pré-requisito
Ter configurado uma VPC dedicada ao Alteryx One conforme mencionado na seção Criar VPC.
Ter conectado a conta de serviço e a política base do IAM à conta de serviço, conforme descrito em Etapa 2: configurar o IAM.
O provisionamento do PDP foi acionado com sucesso, conforme mencionado em Etapa 7: acionar o provisionamento do tratamento de dados privados.
Configuração da conta
Etapa 1: configurar o IAM
Etapa 1a: criar uma política do IAM do App Builder
Nota
AAC_AppBuilder_SA_Policy é um nome de política de exemplo. Você pode escolher qualquer nome para a política, mas ele deve começar com AAC_AppBuilder.
Você precisa criar uma política do IAM personalizada. Dê a ela o nome AAC_AppBuilder_SA_Policy e anexe o seguinte documento de política. Recomendamos usar a guia "JSON" em vez do editor visual. O Alteryx One requer algumas permissões * para ser executado. Ao criar a política, você deverá receber alguns avisos de segurança.
Etapa 1b: marcar a política do IAM
Marque a política do IAM personalizada criada na Etapa 1a.
Nome da tag | Valor |
|---|---|
AACResource | aac_sa_custom_policy |
Etapa 1c: anexar a política do IAM
Anexe a política do IAM AAC_AppBuilder_SA_Policy à conta de serviço aac_automation_sa criada na página Configurar conta e VPC da AWS para dados privados.
Etapa 2: configurar a sub-rede
Nota
Designer Cloud compartilha uma configuração de sub-rede com o Machine Learning, Auto Insights e o App Builder. Se você estiver implantando mais de um desses aplicativos, precisará configurar as sub-redes apenas uma vez.
O Designer Cloud em um ambiente de processamento de dados privados requer grupos de até três sub-redes. Cada grupo contém três sub-redes individuais, cada uma em uma zona de disponibilidade diferente.
Grupo eks_control (obrigatório): o plano de controle do EKS usa essa sub-rede para aceitar solicitações de execução de trabalhos recebidas.
Grupo eks_node (obrigatório): o cluster do EKS usa essa sub-rede para executar trabalhos de software do Alteryx (por exemplo, conectividade, conversão, processamento e publicação).
Grupo público (obrigatório): esse grupo não executa nenhum serviço, mas o grupo
eks_nodeo usa para sair do cluster.Grupo privado (obrigatório): esse grupo executa serviços privados para o processamento de dados privados.
Etapa 2a: criar sub-redes na VPC
Configure sub-redes na VPC aac_vpc.
Crie e marque sub-redes seguindo o exemplo abaixo. Você pode ajustar os CIDRs e os valores de sub-rede para se ajustarem à sua arquitetura de rede.
Os grandes espaços de endereço são projetados para acomodar um cluster totalmente dimensionado. Se necessário, você pode escolher um espaço de endereço menor, mas pode ter problemas de dimensionamento sob cargas de processamento pesadas.
Importante
Você deve marcar as sub-redes com Nome da tag e Valor da tag, conforme mencionado na tabela.
CIDRs | Nome da sub-rede | Sub-rede | AZ | Nome da tag | Valor da tag | Observação |
|---|---|---|---|---|---|---|
10.64.0.0/18 | eks_node | 10.64.0.0/21 | AZa | AACSubnet | eks_node | |
eks_node | 10.64.8.0/21 | AZb | AACSubnet | eks_node | ||
eks_node | 10.64.16.0/21 | AZc | AACSubnet | eks_node | ||
10.64.24.0/21 | RESERVADO | |||||
10.64.32.0/19 | RESERVADO (pode ser configurado para atualização azul/verde posteriormente) | |||||
10.10.0.0/21 | eks_control | 10.10.0.0/27 | AZa | AACSubnet | eks_control | |
eks_control | 10.10.0.32/27 | AZb | AACSubnet | eks_control | ||
eks_control | 10.10.0.64/27 | AZc | AACSubnet | eks_control | ||
10.10.0.96/27 | RESERVADO | |||||
pública | 10.10.0.128/27 | AZa | AACSubnet | pública | ||
pública | 10.10.0.160/27 | AZb | AACSubnet | pública | ||
pública | 10.10.0.192/27 | AZc | AACSubnet | pública | ||
10.10.0.224/27 | RESERVADO | |||||
privada | 10.10.1.0/25 | AZa | AACSubnet | privada | ||
privada | 10.10.1.128/25 | AZb | AACSubnet | privada | ||
privada | 10.10.2.0/25 | AZc | AACSubnet | privada | ||
10.10.1.128/25 | RESERVADO |
Etapa 2b: tabelas de rotas de sub-rede
Crie a tabela de rotas para suas sub-redes. Estas são as entradas da tabela de rota para as sub-redes:
Nota
O <gateway id> pode ser um gateway NAT de zona que foi criado por AZ ou um gateway de trânsito, dependendo da arquitetura da sua rede. Em caso de gateway NAT, crie um gateway NAT por AZ para sub-redes públicas.
Nome da sub-rede | Destino da rota | Alvo | Comentários |
|---|---|---|---|
eks_node | Bloco CIDR /18 Bloco CIDR /21 <s3 prefix id> 0.0.0.0/0 | Local Local <vpce endpoint id> <gateway id> | Configure as mesmas rotas para todas as três tabelas de roteamento de sub-rede de AZs. |
eks_control | Bloco CIDR /18 Bloco CIDR /21 <s3 prefix id> 0.0.0.0/0 | Local Local <vpce endpoint id> <gateway id> | Configure as mesmas rotas para todas as três tabelas de roteamento de sub-rede de AZs. |
pública | Bloco CIDR /18 Bloco CIDR /21 0.0.0.0/0 | Local Local <gateway id> | Configure as mesmas rotas para todas as três tabelas de roteamento de sub-rede de AZs. |
privada | Bloco CIDR /18 Bloco CIDR /21 <s3 prefix id> 0.0.0.0/0 | local local <vpce endpoint id> <gateway id> | Configure as mesmas rotas para todas as três tabelas de roteamento de sub-rede de AZs. 0.0.0.0/0 deve sair para a rede pública. |
Etapa 3: atualizar a política da chave KMS
Quando o processamento de dados privados é criado com sucesso, uma função personalizada chamada credential-service-role é estabelecida na conta para permitir que a conta de serviço de credenciais do Kubernetes acesse credenciais de dados privados no cofre de chaves. Além disso, atualize a política da chave KMS, que foi criada em Configurar conta e VPC da AWS para dados privados – Etapa 5: criar uma chave simétrica para o cofre seguro, para conceder à função personalizada credential-service-role as permissões necessárias.
Acesse Serviços de gerenciamento de chaves e selecione a chave criada em Configurar conta e VPC da AWS para dados privados – Etapa 5: criar uma chave simétrica para o cofre seguro.
Clique em Política da chave e em Editar.
Exclua a permissão padrão e faça a atualização com as permissões mencionadas abaixo:
{ "Version": "2012-10-17", "Id": "key-consolepolicy-3", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<account id>:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<account id>:role/credential-service-role" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" } ] }Nota
<accountId>– número da conta da AWS para a qual o tratamento do ambiente de processamento de dados privado foi provisionado.Selecione Salvar alterações.
Processamento de dados privados
Cuidado
Modificar ou remover quaisquer recursos de nuvem pública provisionados pelo Alteryx One depois que o tratamento de dados privados for configurado poderá causar inconsistências. Essas inconsistências podem levar a erros durante a execução do trabalho ou ao desprovisionamento da configuração do tratamento de dados privados.
Etapa 1: acionar a implantação do App Builder
O provisionamento do App Builder é acionado a partir do console de administração no Alteryx One. Você precisa de Privilégios do Administrador do espaço de trabalho dentro de um espaço de trabalho para vê-lo.
Na página de chegada do Alteryx One, selecione o ícone de círculo no canto superior direito com suas iniciais. No menu, selecione Console de administração.
Selecione Tratamento de dados privados no menu de navegação esquerdo.
Marque a caixa de seleção Auto Insights e clique em Salvar.
A seleção de Atualizar aciona a implantação do cluster e dos recursos na conta da AWS. Isso executa um conjunto de verificações de validação da configuração correta da conta da AWS.
Quando as verificações de validação iniciais forem concluídas, o provisionamento será iniciado. Uma caixa de mensagem na tela será atualizada periodicamente com atualizações do status.
Nota
O processo de provisionamento leva aproximadamente de 35 a 40 minutos para ser concluído.
Após a conclusão do provisionamento, você pode visualizar os recursos criados (por exemplo, instâncias de EC2 e grupos de nós) por meio do console da AWS. É muito importante que você não os modifique por conta própria. As alterações manuais podem causar problemas com a função de processamento de dados privados.