Copyright 2021 VMware, Inc. (2023)

<!–

–>

Ce déploiement est basé sur l'Architecture de Référence,Tanzu pour les opérations Kuberentes sur le cloud hybride Azure

Configurez votre instance Tanzu Mission Control avec les intégrations Tanzu Observability et Tanzu Service Mesh avant d'exécuter l'installation rapide.

Courir

az login./tkgm-azure.sh  cd 3_bootstrapssh -o IdentitiesOnly=yes -i ./bootstrap.pem azureuser@xxx

Exécutez la commande ssh fournie pour accéder au jumpbox. Sur la course jumpbox

cd tkg-installexport TO_URL="http://your-wavefront-url"export TO_TOKEN="your-wavefront-token"export TMC_TOKEN="your-tmc-token" chmod a+x ./finish-install.sh./ finish-install.sh  

Si vous définissezexporter SKIP_TSM=true, l'installation ignorera l'installation de Tanzu Service Mesh. Si vous ne définissez pasTO_TOKEN, l'installation ignorera l'installation de Tanzu Observability. Si vous ne définissez pasTMC_TOKEN, l'installation ignorera Tanzu Mission Control, Tanzu Observability et Tanzu Service Mesh.

Ce référentiel est divisé en quatre composants :

• Keepers - définit les composants durables utilisés par terraform
• Netsec - définit les sous-réseaux, les groupes de sécurité réseau et les VNET
• DNS - utilisé pour les déploiements Azure hybrides (pas l'installation rapide)
• Bootstrap - utilisé pour créer le jumpbox et pré-remplir le jumpbox avec les configurations pertinentes

Chaque section est documentée avec son propre README. La répartition des sections est conçue pour s'aligner sur la séparation des tâches si nécessaire pour permettre à chaque équipe d'appliquer la terraform à ses responsabilités.

Si vous ne parvenez pas à utiliser le wrapper pour installer Tanzu Kubernetes Grid Multicloud, vous pouvez suivre ce playbook pour obtenir les mêmes résultats ou modifier le code source si nécessaire pour obtenir les modifications dont vous avez besoin.

1. Appliquer le code Terraform dans 0_keepers

   • terraform appliquer -var="sub_id=..." -var="tenant_id=..."
   • où … ci-dessus représentent vos valeurs respectives

2. Exécutez les instructions de sortie run_cmd à partir de 0_keepers

   See Also

   Bases de données gérées - Démarrer le déplacement - API REST (Azure SQL Database)Gestion des changements de rotation des secrets KeyVault utilisés par une fonction Azure - Exemples de code
   • Les exigences du système d'exploitation varient
   • Par exemple,export ARM_ACCESS_KEY="$(sortie terraform -clé d'accès brute)"
   • Par exemple,$env:ARM_ACCESS_KEY=(sortie terraform -clé d'accès brute)

3. Appliquer le code Terraform dans 1_netsec

   • terraform appliquer -var="sub_id=..."
   • où … ci-dessus représentent vos valeurs respectives

4. Appliquer le code Terraform dans 2_dns (selon les besoins)

   • Cette option s'applique uniquement si vous avez besoin d'une source non-Azure pour résoudre le DNS privé Azure
   • terraform appliquer -var="sub_id=..."
   • où … ci-dessus représentent vos valeurs respectives

5. Appliquer le code Terraform dans 3_bootstrap

   • terraform appliquer -var="sub_id=..."
   • où … ci-dessus représentent vos valeurs respectives
   • La sortie ssh_cmd varie selon le système d'exploitation, alors faites attention à vos règles (si vous êtes sous Windows, vous devrez probablement corriger les ACL sur ce fichier)

TLDR

Modifiez terraform.tfvars si nécessaire pour chaque répertoire de configuration Terraform. Tout ce qui n'est pas commenté ou ajouté au fichier tfvars remplacera les valeurs par défaut et échappera efficacement au déploiement de validation qui est la valeur par défaut. Si l'architecture du code est conservée, les modifications apportées à 0_keepers seront reportées dans les étapes suivantes.

Terraform, l'infrastructure en tant que code

Les exemples donnés ont été conçus pour utiliser un compte de stockage Azure comme backend distant pour la gestion de l'état de Terraform. « Keepers » ci-dessous est une condition préalable et n'est pas stocké dans un état distant (en fait, il établit un endroit où l'état distant peut être stocké).

Les composants suivants sont divisés de manière à ce que les étapes puissent être ignorées si les réponses à ces fonctionnalités sont fournies par un autre service préexistant ou fourni par le service informatique central. Chaque composant fournit un ensemble de ressources destinées à être transmises, idéalement via un stockage secret dans un coffre-fort sécurisé.

Les composants sont les suivants :

Exécution de Terraform :

(Video) Help me raise the $70B I need to buy #vmware and stop the Broadcom via the.saasy.engineer tiktok

• Terraforme v1.17*
• hashicorp/azurerm v2.98.0*

*Consultez les répertoires de composants individuels pour les mises à jour de ces versions.

• Gardiens
• Réseau et sécurité du réseau
• DNS (Intermédiaire)
• Conditions préalables au déploiement
• Bootstrap subsidiaire

Voici quelques-unes des hypothèses au nom du consommateur au cas où la préférence devrait être modifiée.

Hypothèses

Noms des balises- En plus de ceux répertoriés dans les fichiers terraform.tfvars, "StartDate" est utilisé dans le code en tant quedate d'origineau cas où il serait important de suivre cela pour les ressources. Il est défini une fois lors de la création de la ressource et ne doit jamais être modifié par la suite (par Terraform). Des balises supplémentaires peuvent être ajoutées au type de carte var dans terraform.tfvars.

Nuage azur- Cela n'a jamais été conçu pour quoi que ce soit en dehors du "AzureCloud" standard. Votre kilométrage peut varier selon les types de Chine ou de gouvernement.

Nous- la pratique de nommage utilisée ici pourrait suivreMicrosoft Cloud Adoption Framework publié. Bref, c'est :

----###

Vous devrez probablement le modifier pour répondre aux besoins de votre client. Les libertés que j'ai prises sur ce cadre sont les suivantes :

-----###où###est utile lorsque des multiples sont générés (automatiquement). Sinon, il n'est pas utilisé. De plus, la norme de nommage est entièrement basée sur les différentspréfixevars collectées dans terraform.tfvars. Vous êtes autorisé à formater ces préfixes comme bon vous semble, donc les règles ci-dessus ne sont que des suggestions. La seule application a lieu au niveau de la ressource oùest ajouté à votre préfixe conformément aux directives de Microsoft, le cas échéant, et des suffixes sont ajoutés dans des situations pour maintenir l'unicité.

• Le type de ressource est aligné surDirectives publiées par Microsoftlorsque c'est possible
• region-abbrv peut (et devrait être) une abréviation. Ces exemples comportent le pays en premier et 4 caractères :

USA Est 2 = use2

Modules- Les modules utilisés ici sont la quintessence des hypothèses. Ces modules ont été construits pour effectuer un ensemble de tâches par rapport à des ressources catégorielles afin de produire une normalisation. En effet, ils représentent les parties d'une organisation qui peuvent effectuer des travaux au nom du propriétaire de la plate-forme Tanzu Kubernetes Grid Multicloud. Par exemple, les modules de sous-réseau peuvent créer des tables de routage et associer également des groupes de sécurité réseau. La partie importante de ces modules est en fin de compte la sortie, et vous pouvez donc arriver à ces sorties de plusieurs manières.

Gardiens

Les « gardiens » sont les ressources qui préemptent les ressources gérées par l'état déployées par Terraform pour cette solution. Ils n'ont pas besoin d'être dédiés à la solution Tanzu Kubernetes Grid Multicloud ! Les gardiens comprennent actuellement unCompte de stockagepour l'État et unCoffre de clés Azurepour le stockage secret.

IMPORTANTMise à jourterraform.tfvarspour votre environnement.

gardiens - fournisseurs

Les fournisseurs sont maintenus pour tous les répertoires de déploiement en dehors du répertoire des gardiens. provider.tftpl est utilisé pour construire ces fichiers dans les futurs répertoires, il est donc important de comprendre cette relation.

gardiens - terraform.tfvars

• sous_id: ID d'abonnement Azure
• emplacement: Région Azure (par exemple,eastus2 ou USA Est 2)
• préfixe: un préfixe pour les noms de ressources utilisant vos normes de dénomination (par exemple,vmw-use2-svcname)
• préfixe_court: Certaines ressources sont limitées en taille et en caractères - ce préfixe résout ceux (par exemple,vmwuse2svc).Peut inclure 4 chiffres d'hexadécimal randomisé à la fin

Les valeurs des balises sont par défaut les balises au niveau de l'abonnement, mais sont conçues pour être remplacées par tout ce qui est fourni ici.

• Nom du service: Texte libre pour nommer ou décrire votre application, solution ou service
• Unité commerciale: Doit s'aligner sur une liste prédéterminée de BU connues
• Environnement: Doit s'aligner sur une liste prédéterminée d'environnements
• Courriel du propriétaire: Un courriel valide pour une personne ou un groupe responsable de la ou des ressources
•  :Tels que RequestorEmail

**depuis le sous-répertoire 0_keepers**terraform initterraform validateterraform apply

Réseau et sécurité

NetSec doit être remplacé par une solution dans laquelle l'équipe informatique centrale fournit ces détails si nécessaire. Plus précisément, Central IT doit créer le VNET pour qu'il soit conforme aux exigences d'ExpressRoute et permettre à l'équipe de développement d'ajouter ses propres sous-réseaux et groupes de sécurité réseau (voirZones d'atterrissage Azure)

IMPORTANTMise à jourterraform.tfvarspour votre environnement.

• nom_compte_stockage :Compte de stockage nommé extrait du fichier keepers.json où l'état de terraform sera stocké à perpétuité
• nom_conteneur :Comme un dossier - généralement "terraform-state"
• clé:Un chemin supplémentaire pour le stockage et le nom de fichier de votre état terraform - doit être unique (par exemple,bu/product/use2-s-net.tfstate)
• clef d'accès:Cela se trouve dans votregardiens.jsonet est l'identifiant access_key utilisé pour lire et écrire sur le compte de stockage keeper - SENSITIVE

netsec - terraform.tfvars (en plus des autres listés précédemment...)

• tkg_cluster_name :Le nom passé en nommage se rapportant au tanzu cli
• core_address_space :L'espace d'adressage VNET - c'est le plus grand bloc CIDR spécifié pour un réseau
• boot_diag_sa_name :Ce nom est transmis à un compte de stockage utilisé pour les diagnostics de démarrage. Il doit être conforme aux exigences de dénomination d'Azure pour les comptes de stockage.
• nom_groupe_ressource_vault :Un nom de groupe de ressources fourni par la sortie de0_gardiens
• nom de la voûte:Le nom AKV fourni par la sortie de0_gardiens

netsec - user_subnets.tf

Ce fichier est utilisé pour définir les sous-réseaux utilisés pour Tanzu Kubernetes Grid Multicloud et configurer les sous-réseaux dans Azure. Des exemples sont fournis, mais les résultats sont les suivants (tels que définis dans les modules associés) :

IMPORTANT

Les sous-réseaux sont modifiés via la grande carte locale transmise au module de sous-réseau. Les cartes fournies de cette manière peuvent soit être transmises directement en tant que carte unique répondant à l'exigence d'argument du module, soit le module peut être parcouru en boucle lors de la lecture de chaque clé de la carte. Dans le premier cas, tous les sous-réseaux obtiendront le même groupe de sécurité réseau. Dans ce dernier, chaque sous-réseau obtient son propre groupe de sécurité réseau. Les groupes de sécurité réseau sont nommés dans la carte elle-même, il faut donc faire attention à ce paramètre.

**depuis le sous-répertoire 1_netsec**terraform initterraform validateterraform apply

DNS

IMPORTANT

DNS, dans cette solution, représente un redirecteur BIND9 pour Azure Private DNS. Pour que les ressources sur site résolvent les ressources DNS privées, le transfert conditionnel ou de zone doit être en place sur site pour pointer vers ces serveurs DNS.

Mise à jourterraform.tfvarspour votre environnement.

dns - terraform.tfvars (en plus des autres listés ci-dessus...)

• nom_sous-réseau :Nom du sous-réseau où les redirecteurs DNS alloueront des IP internes (sortie de1_netsec)
• nom_vnet :Le nom du VNET (préexistant - est sorti de1_netsec)
• netsec_resource_group :Le nom du groupe de ressources où vit le VNET préexistant
• bindvms :Nombre de VM à déployer pour héberger BIND9
• boot_diag_sa_name :Nom de compte de stockage de diagnostics de démarrage pré-généré (sortie de1_netsec)

**depuis le sous-répertoire 2_dns**terraform initterraform validateterraform apply

Filiale Kubernetes Grid Automation

Machine virtuelle d'amorçage (3_bootstrap)

IMPORTANT

La machine virtuelle Bootstrap est utilisée pour les activités de déploiement Tanzu Kubernetes Grid Multicloud et est configurée dès le départ avec la CLI Tanzu et les fichiers binaires associés.

NOTELa machine virtuelle d'amorçage doit bénéficier d'un accès sortant à Internet lors du déploiement initial pour effectuer les mises à jour et extraire les packages logiciels nécessaires à son rôle. Le déploiement par défaut dans ce guide utilise une passerelle NAT pour le VNET et les sous-réseaux associés pour l'étendre.

IMPORTANTMise à jourterraform.tfvarspour votre environnement.

boot - terraform.tfvars (en plus des autres énumérés ci-dessus...)

• nom_sous-réseau :Nom du sous-réseau où la machine virtuelle d'amorçage allouera une adresse IP interne (sortie de1_netsec)
• nom_vnet :Le nom du VNET (préexistant - est sorti de1_netsec)
• netsec_resource_group :Le nom du groupe de ressources où vit le VNET préexistant
• boot_diag_sa_name :Nom de compte de stockage de diagnostics de démarrage pré-généré (sortie de1_netsec)

**depuis le sous-répertoire 3_bootstrap**terraform initterraform validateterraform apply

NOTE

La création du premier cluster de gestion s'effectue via "kind" sur la machine virtuelle d'amorçage et les sorties d'IaC ci-dessus (capturées dans Azure KeyVault) doivent être compilées pour les fichiers de réponses résultants.

Étapes finales

Les variables d'environnement Shell devront être définies pour la configuration du proxy et peuvent également être transmises via le fichier tfvars :

exporter HTTP_PROXY="http://PROXY:PORT"exporter HTTPS_PROXY="http://PROXY:PORT"exporter NO_PROXY="CIDR_OR_DOMAIN_LIST"

La configuration du proxy Docker devra être définie. Ajoutez la section suivante à /etc/systemd/system/docker.service.d/http-proxy.conf :

[Service] Environnement="HTTP_PROXY=http://PROXY:PORT" Environnement="HTTPS_PROXY=http://PROXY:PORT" Environnement="NO_PROXY=CIDR_OR_DOMAIN_LIST"

NOTE

Docker devra être redémarré pour que ce paramètre prenne effet.

Apt n'utilise pas de configuration de proxy environnemental et utilise à la place son propre fichier. Vous devrez modifier (créer au besoin) le fichier /etc/apt/apt.conf.d/proxy.conf avec ce qui suit :

Acquérir { HTTP::proxy "http://PROXY:PORT" ; HTTPS::proxy "http://PROXY:PORT" ;}

Via Terraform, tous les autres fichiers de configuration sont écrits sur la machine virtuelle d'amorçage avec les valeurs de configuration obtenues via le déploiement Azure. Des exemples de valeurs de configuration sont également fournis pour les packages ajoutés au cluster, si vous souhaitez les tester et ajouter les packages. Le déploiement par défaut utilise l'un des tkgm-azure .ps1 ou .sh pour gérer l'automatisation du déploiement du cluster. Ce script doit avoir pris des valeurs du déploiement pour faire son travail, mais vous voudrez peut-être revoir le(s) script(s) pour plus de précision en fonction des modifications que vous avez apportées au code.