Skip to main content

App Builder en AWS

En esta guía, se te explica cómo configurar App Builder en AWS, lo que permite el análisis automático de datos y los insights. Sigue los pasos para ajustar y optimizar la configuración de manera eficiente.

Requisitos previos

Configuración de cuenta

Paso 1: Cómo configurar IAM

Paso 1a: Crear una política de IAM para App Builder

Nota

AAC_AppBuilder_SA_Policy es un nombre de política de ejemplo. Puedes elegir cualquier nombre para la política, pero el nombre debe comenzar con AAC_AppBuilder.

Debes crear una política de IAM personalizada. Nómbrala AAC_AppBuilder_SA_Policy y utiliza el siguiente documento de política. Recomendamos utilizar la pestaña JSON en lugar del editor visual. Alteryx One requiere algunos permisos de * para ejecutarse. Espera algunas advertencias de seguridad cuando crees la política.

Paso 1b: Etiquetar la política de IAM
Etiqueta la política de IAM personalizada que creaste en el paso 1a.
Nombre de la etiqueta
Valor
AACResource
aac_sa_custom_policy
Paso 1c: Adjuntar la política de IAM
Adjunta la política de IAM de AAC_AppBuilder_SA_Policy a la cuenta de servicio aac_automation_sa creada en la página Configurar la cuenta de AWS y VPC para datos privados.
Paso 2: Configurar la subred
Nota
Designer Cloud comparte una configuración de subred con aprendizaje automático, Auto Insights y App Builder. Si estás implementando más de una de esas aplicaciones, solo debes configurar las subredes una vez.
Designer Cloud en un entorno de procesamiento privado de datos requiere hasta tres grupos de subredes. Cada grupo contiene tres subredes individuales, cada una en una zona de disponibilidad diferente.
  • Grupo eks_control (obligatorio): el plano de control EKS utiliza esta subred para aceptar solicitudes de ejecución de tareas entrantes.
  • Grupo eks_node (obligatorio): el clúster de EKS utiliza esta subred para ejecutar tareas de software de Alteryx (por ejemplo, conectividad, conversión, procesamiento, publicación).
  • Grupo public (obligatorio): este grupo no ejecuta ningún servicio, pero el grupo eks_node lo utiliza para salir del clúster.
  • Grupo private (obligatorio): este grupo ejecuta servicios privados para el procesamiento privado de datos.
Paso 2a: Crear subredes en la VPC
Configura las subredes en la VPC aac_vpc.
Crea subredes y asígnales etiquetas según el siguiente ejemplo. Puedes ajustar los valores de CIDR y de subredes para que se ajusten a tu arquitectura de red.
Los espacios de direcciones grandes están diseñados para adaptarse a un clúster totalmente escalado. Puedes elegir un espacio de direcciones más pequeño si es necesario, pero podrías tener problemas de escalado bajo cargas de procesamiento pesadas.
Importante
Debes etiquetar las subredes con Nombre de la etiqueta y Valor de la etiqueta como se menciona en la tabla.
CIDR
Nombre de la subred
Subred
AZ
Nombre de la etiqueta
Valor de la etiqueta
Nota
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
SPARE
10.64.32.0/19
SPARE (se puede configurar para una actualización azul/verde más tarde)
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
SPARE
público
10.10.0.128/27
AZa
AACSubnet
público
público
10.10.0.160/27
AZb
AACSubnet
público
público
10.10.0.192/27
AZc
AACSubnet
público
10.10.0.224/27
SPARE
privado
10.10.1.0/25
AZa
AACSubnet
privado
privado
10.10.1.128/25
AZb
AACSubnet
privado
privado
10.10.2.0/25
AZc
AACSubnet
privado
10.10.1.128/25
SPARE
Paso 2b: Tablas de ruta de subred
Crea la tabla de rutas para tus subredes. Las entradas de la tabla de rutas para las subredes son las siguientes:
Nota
Tu <id> de puerta de enlace puede ser una puerta de enlace NAT zonal creada por AZ o una puerta de enlace de tránsito, según la arquitectura de tu red. Si la puerta de enlace es NAT, crea una puerta de enlace NAT por AZ para las subredes públicas.
Nombre de la subred
Destino de la ruta
Objetivo
Comentarios
eks_node
/18 Bloque de CIDR
/21 Bloque de CIDR
<id. del prefijo s3>
0.0.0.0/0
Local
Local
<id. del punto de conexión de vpce>
<Id. de puerta de enlace>
Configura las mismas rutas en las tres tablas de enrutamiento de subred AZ.
eks_control
/18 Bloque de CIDR
/21 Bloque de CIDR
<id. del prefijo s3>
0.0.0.0/0
Local
Local
<id. del punto de conexión de vpce>
<Id. de puerta de enlace>
Configura las mismas rutas en las tres tablas de enrutamiento de subred AZ.
público
/18 Bloque de CIDR
/21 Bloque de CIDR
0.0.0.0/0
Local
Local
<Id. de puerta de enlace>
Configura las mismas rutas en las tres tablas de enrutamiento de subred AZ.
privado
/18 Bloque de CIDR
/21 Bloque de CIDR
<id. del prefijo s3>
0.0.0.0/0
local
local
<id. del punto de conexión de vpce>
<Id. de puerta de enlace>
Configura las mismas rutas en las tres tablas de enrutamiento de subred AZ.
0.0.0.0/0 debe estar saliendo a la red pública.
Paso 3: Actualizar la política de claves de KMS
Una vez creado correctamente el procesamiento privado de datos, se establece un rol personalizado llamado credential-service-role en la cuenta para permitir que la cuenta de servicio de credenciales de Kubernetes acceda a las credenciales de datos privados desde el almacén de claves. Además, actualiza la política de la clave KMS, que se creó en Configurar la cuenta de AWS y VPC para datos privados - Paso 5: Crear una clave simétrica para almacén seguro, para otorgar al rol personalizado credential-service-role los permisos necesarios.
  1. Ve a Servicios de administración de claves y selecciona la clave creada en Configurar la cuenta de AWS y VPC para datos privados - Paso 5: Crear una clave simétrica para almacén seguro.
  2. Selecciona Política de claves y selecciona Editar.
  3. Elimina el permiso predeterminado y actualiza con los permisos mencionados a continuación:
    {
  "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 de cuenta de AWS en el que se ha aprovisionado el manejo del entorno de procesamiento privado de datos.
  4. Selecciona Guardar cambios.
Procesamiento privado de datos
Atención
Cambiar o eliminar cualquier recurso de nube pública provisionado por Alteryx One después de configurar el Manejo privado de datos puede causar incoherencias. Estas incoherencias pueden provocar errores durante la ejecución de tareas o al desaprovisionar la configuración de Manejo privado de datos.
Paso 1: Activar la implementación de App Builder
El aprovisionamiento de App Builder se activa desde la consola de administrador en Alteryx One. Necesitas privilegios de administrador de espacio de trabajo para poder verlo dentro de un espacio de trabajo.
  1. En la página inicial de Alteryx One, selecciona el ícono de círculo en la parte superior derecha con tus iniciales en él. Selecciona Consola de administración en el menú.
  2. Selecciona Manejo privado de datos en el menú de navegación de la izquierda.
  3. Selecciona la casilla de verificación de Auto Insights y, a continuación, selecciona Guardar.
Al seleccionar Actualizar, se activa la implementación del clúster y los recursos en la cuenta de AWS. Esto ejecuta un conjunto de comprobaciones de validación para verificar la configuración correcta de la cuenta de AWS.
Una vez que se completen las comprobaciones de validación iniciales, comenzará el aprovisionamiento. Un cuadro de mensaje en la pantalla se recargará periódicamente con actualizaciones de estado.
Nota
El proceso de aprovisionamiento tarda aproximadamente entre 35 y 40 minutos en completarse.
Una vez finalizado el aprovisionamiento, puedes ver los recursos creados (por ejemplo, instancias de EC2 y grupos de nodos) a través de la consola de AWS. Es muy importante que no los modifiques por tu cuenta. Los cambios manuales pueden causar problemas con la función del procesamiento privado de datos.
En esta sección: