Skip to main content

App Builder dans AWS

Ce guide vous explique comment configurer App Builder dans AWS et activer l'analyse automatique des données ainsi que la génération d'insights. Suivez les étapes pour configurer et optimiser votre configuration de manière efficace.

Condition préalable

Configuration du compte

Étape 1 : Configurer l'IAM

Étape 1a : Créer une politique IAM App Builder

Note

AAC_AppBuilder_SA_Policy est un exemple de nom de politique. Vous pouvez choisir n'importe quel nom pour la politique, mais il doit commencer par AAC_AppBuilder.

Vous devez créer une politique IAM personnalisée. Nommez-la AAC_AppBuilder_SA_Policy et rattachez le document de politique suivant. Nous vous recommandons d'utiliser l'onglet JSON au lieu de l'éditeur visuel. Alteryx One a besoin d'autorisations * pour s'exécuter. Attendez-vous à recevoir des avertissements de sécurité lorsque vous créez la politique.

Étape 1b : Marquer la politique IAM
Marquez la politique IAM personnalisée créée à l'étape 1a.
Nom de la balise
Valeur
AACResource
aac_sa_custom_policy
Étape 1c : Rattacher la politique IAM
Rattachez la politique IAM AAC_AppBuilder_SA_Policy au compte de service aac_automation_sa créé à la page Configurer un compte AWS et un VPC pour les données privées.
Étape 2 : Configurer le sous-réseau
Note
Designer Cloud partage une configuration de sous-réseau avec Machine Learning, Auto Insights et App Builder. Si vous déployez plusieurs de ces applications, vous n'avez besoin de configurer les sous-réseaux qu'une seule fois.
Designer Cloud dans un environnement de traitement de données privé, jusqu'à 3 groupes de sous-réseaux sont nécessaires. Chaque groupe contient 3 sous-réseaux individuels, chacun dans une zone de disponibilité différente.
  • Groupe eks_control (requis) : le plan de contrôle EKS utilise ce sous-réseau pour accepter les demandes d'exécution de tâche entrantes.
  • Groupe eks_node (requis) : le cluster EKS utilise ce sous-réseau pour exécuter des tâches logicielles Alteryx (par exemple, connectivité, conversion, traitement et publication).
  • Groupe public (requis) : ce groupe n'exécute aucun service, mais le groupe eks_node l'utilise pour les flux sortants du cluster.
  • Groupe private (requis) : ce groupe exécute des services privés sur le traitement des données privé.
Étape 2a : Créer des sous-réseaux dans le VPC
Configurez des sous-réseaux dans le VPC aac_vpc.
Créez des sous-réseaux et marquez-les conformément à l'exemple ci-dessous. Vous pouvez ajuster les CIDR et les valeurs de sous-réseau pour les adapter à votre architecture réseau.
Les grands espaces d'adressage sont conçus pour s'adapter à un cluster entièrement évolutif. Si nécessaire, vous pouvez choisir un espace d'adressage plus petit, mais vous risquez de rencontrer des problèmes de mise à l'échelle lors de charges de traitement importantes.
Important
Vous devez marquer les sous-réseaux avec le nom de la balise et la valeur de la balise comme indiqué dans le tableau.
CIDR
Nom du sous-réseau
Sous-réseau
AZ
Nom de la balise
Valeur de la balise
Remarque
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 (peut être configuré ultérieurement pour une mise à niveau bleu/vert)
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
publique
10.10.0.128/27
AZa
AACSubnet
publique
publique
10.10.0.160/27
AZb
AACSubnet
publique
publique
10.10.0.192/27
AZc
AACSubnet
publique
10.10.0.224/27
SPARE
privé
10.10.1.0/25
AZa
AACSubnet
privé
privé
10.10.1.128/25
AZb
AACSubnet
privé
privé
10.10.2.0/25
AZc
AACSubnet
privé
10.10.1.128/25
SPARE
Étape 2b : Tables de routage des sous-réseaux
Créez la table de routage pour vos sous-réseaux. Les entrées de la table de routage pour les sous-réseaux sont les suivantes :
Note
Votre <gateway id> pourrait correspondre à une passerelle NAT de zone ayant été créée via AZ ou à une passerelle de transit, en fonction de votre architecture réseau. S'il s'agit d'une passerelle NAT, créez une passerelle NAT via AZ pour les sous-réseaux publics.
Nom du sous-réseau
Destination de routage
Cible
Commentaires
eks_node
Bloc CIDR /18
Bloc CIDR /21
<id du préfixe s3>
0.0.0.0/0
Locale
Locale
<id du point de terminaison vpce>
<gateway id>
Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ.
eks_control
Bloc CIDR /18
Bloc CIDR /21
<id du préfixe s3>
0.0.0.0/0
Locale
Locale
<id du point de terminaison vpce>
<gateway id>
Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ.
publique
Bloc CIDR /18
Bloc CIDR /21
0.0.0.0/0
Locale
Locale
<gateway id>
Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ.
privé
Bloc CIDR /18
Bloc CIDR /21
<id du préfixe s3>
0.0.0.0/0
local
local
<id du point de terminaison vpce>
<gateway id>
Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ.
0.0.0.0/0 devrait sortir vers le réseau public.
Étape 3 : Mettre à jour la politique de clé KMS
Une fois le traitement des données privé créé avec succès, un rôle personnalisé nommé credential-service-role est établi dans le compte pour permettre au compte de service d'informations d'identification Kubernetes d'accéder aux informations d'identification privées à partir du coffre-fort de clés. En outre, mettez à jour la politique de clé KMS, créée à l'Configurer un compte AWS et un VPC pour les données privéesétape 5 : Créer une clé symétrique pour le coffre-fort sécurisé, pour accorder au rôle personnalisé credential-service-role les autorisations nécessaires.
  1. Accédez à la section Service de gestion des clés et sélectionnez la clé créée à l'Configurer un compte AWS et un VPC pour les données privéesétape 5 : Créer une clé symétrique pour le coffre-fort sécurisé.
  2. Sélectionnez Politique de clé et sélectionnez Modifier.
  3. Supprimez l'autorisation par défaut et mettez-la à jour avec les autorisations mentionnées ci-dessous :
    {
  "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": "*"
    }
  ]
}   
    Note
    <accountId> : numéro de compte AWS où la gestion de l'environnement de traitement des données privé a été provisionnée.
  4. Sélectionnez Enregistrer les modifications.
Traitement des données privées
Attention
La modification ou la suppression de ressources de cloud public provisionnées par Alteryx One après la configuration de gestion des données privées peut entraîner des incohérences. Ces incohérences peuvent causer des erreurs lors de l'exécution de la tâche ou lors du désapprovisionnement de la configuration de gestion des données privées.
Étape 1 : Déclencher le déploiement App Builder
Le provisionnement d'App Builder est déclenché à partir de la console d'administration dans Alteryx One. Vous devez disposer des privilèges Admin de l'espace de travail dans un espace de travail pour pouvoir le voir.
  1. Depuis la page d'accueil Alteryx One, sélectionnez l'icône en forme de cercle en haut à droite avec vos initiales. Sélectionnez Console d'administration dans le menu.
  2. Dans le menu de navigation de gauche, sélectionnez Gestion des données privées.
  3. Cochez la case Auto Insights, puis sélectionnez Enregistrer.
Sélectionner Mettre à jour déclenche le déploiement du cluster et des ressources dans le compte AWS. Cela permet d'exécuter une série de contrôles de validation afin de vérifier la configuration correcte du compte AWS.
Une fois les vérifications de validation initiales terminées, le provisionnement commencera. Une zone de message à l'écran s'actualise régulièrement avec les mises à jour de l'état.
Note
Le processus de provisionnement dure environ 35 à 40 minutes.
Une fois le provisionnement terminé, vous pouvez afficher les ressources créées (par exemple, les instances EC2 et les groupes de nœuds) via la console AWS. Il est essentiel de ne pas les modifier vous-même. Les modifications manuelles peuvent entraîner des problèmes avec le fonctionnement du traitement des données privé.
Dans cette section​: