Skip to main content

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

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_node o 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 privadosEtapa 5: criar uma chave simétrica para o cofre seguro, para conceder à função personalizada credential-service-role as permissões necessárias.

  1. Acesse Serviços de gerenciamento de chaves e selecione a chave criada em Configurar conta e VPC da AWS para dados privadosEtapa 5: criar uma chave simétrica para o cofre seguro.

  2. Clique em Política da chave e em Editar.

  3. 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.

  4. 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.

  1. 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.

  2. Selecione Tratamento de dados privados no menu de navegação esquerdo.

  3. 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.