Les balises ajoutées aux projets et aux modèles de cloud fonctionnent comme des balises de contrainte lorsqu'elles sont utilisées pour faire correspondre les balises de capacité sur des ressources d'infrastructure, des profils et des zones de cloud. Dans le cas des modèles de cloud, Automation Assembler utilise cette fonctionnalité de correspondance pour allouer des ressources aux déploiements.
Automation Assembler vous permet d'utiliser des balises de contrainte selon deux méthodes principales. La première méthode consiste à configurer des projets et des images. Vous pouvez utiliser des balises comme contraintes pour associer des ressources au projet ou à l'image. La seconde se trouve dans les modèles de cloud, où les balises spécifiées comme contraintes sont utilisées pour sélectionner des ressources pour les déploiements. Les contraintes appliquées dans ces deux méthodes sont fusionnées dans les modèles de Cloud pour former un ensemble de conditions de déploiement qui définissent les ressources disponibles pour un déploiement.
Fonctionnement des balises de contrainte sur les projets
Lorsque vous configurez des ressources Automation Assembler, les administrateurs de cloud peuvent appliquer des balises de contrainte sur les projets. Ainsi, les administrateurs peuvent appliquer des contraintes de gouvernance directement au niveau du projet. Toutes les contraintes ajoutées à ce niveau sont appliquées à chaque modèle de cloud demandé pour le projet applicable, et ces balises de contrainte sont prioritaires sur les autres balises.
Si des balises de contrainte du projet sont en conflit avec des balises de contrainte du modèle de cloud, les balises du projet sont prioritaires, ce qui permet à l'administrateur de cloud d'appliquer des règles de gouvernance. Par exemple, si les administrateurs de cloud créent une balise location:london sur le projet, mais qu'un développeur place une balise location:boston sur le modèle de cloud, la première est prioritaire et la ressource est déployée sur l'infrastructure contenant la balise location:london.
Les utilisateurs peuvent appliquer trois types de balises de contraintes aux projets : réseau, stockage et extensibilité. Vous pouvez appliquer autant d'instances de chaque type de balise que nécessaire. Les contraintes de projet peuvent être rigides ou souples. Par défaut, elles sont rigides. Les contraintes rigides vous permettent d'appliquer de façon stricte des restrictions de déploiement. Si une ou plusieurs contraintes rigides ne sont pas satisfaites, le déploiement échoue. Les contraintes souples offrent un moyen d'exprimer des préférences qui seront sélectionnées en cas de disponibilité. Toutefois, le déploiement n'échouera pas si les contraintes souples ne sont pas respectées.
Fonctionnement des balises de contrainte dans les modèles de cloud
Dans les modèles de cloud, vous ajoutez des balises de contrainte aux ressources en tant que code YAML pour qu'elles correspondent aux balises de capacité appropriées créées par votre administrateur de cloud sur les ressources, les zones de cloud et les profils de réseau et de stockage. Par ailleurs, d'autres options, plus complexes, sont disponibles pour l'implémentation de balises de contrainte. Par exemple, vous pouvez utiliser une variable pour renseigner une ou plusieurs balises sur une demande. Cela vous permet d'indiquer une ou plusieurs balises au moment de la demande.
Créez des balises de contrainte en utilisant l'étiquette tag sous un en-tête de contrainte dans le code YAML du modèle de cloud. Les balises de contrainte des projets sont ajoutées aux balises de contrainte créées dans les modèles de cloud.
Automation Assembler prend en charge une mise en forme des chaînes simple pour faciliter l'utilisation des contraintes dans les fichiers YAML :
[!]tag_key[:tag_value][:hard|:soft]
Par défaut, Automation Assembler crée une contrainte positive avec application rigide. La valeur de la balise est facultative, bien que recommandée, comme dans le reste de l'application.
key:value de balise de base. Toute tentative d'utilisation d'autres délimiteurs entraînera probablement des erreurs.
L'exemple de WordPress avec MySQL suivant montre des balises de contrainte YAML qui indiquent des informations d'emplacement spécifiques pour les ressources de calcul.
name: "wordPressWithMySql"
components:
mysql:
type: "Compute"
data:
name: "mysql"
# ... skipped lines ...
wordpress:
type: "Compute"
data:
name: "wordpress"
instanceType: small
imageType: "ubuntu-server-1604"
constraints:
- tag: "!location:eu:hard"
- tag: "location:us:soft"
- tag: "!pci"
# ... skipped lines ...
Pour plus d'informations sur l'utilisation de modèles de cloud, reportez-vous à la section Étape 3 : concevoir et déployer l'exemple de modèle Automation Assembler.
Fonctionnement des contraintes rigides et souples dans les projets et les modèles de cloud
Les contraintes des projets et des modèles de cloud peuvent être rigides ou souples. L'extrait de code précédent donne des exemples de contraintes rigides et souples. Par défaut, toutes les contraintes sont rigides. Les contraintes rigides vous permettent d'appliquer de façon stricte des restrictions de déploiement. Si une ou plusieurs contraintes rigides ne sont pas satisfaites, le déploiement échoue. Les contraintes souples expriment des préférences qui s'appliquent en cas de disponibilité, mais elles n'entraînent pas l'échec d'un déploiement pas si elles ne sont pas satisfaites.
Si vous disposez d'une série de contraintes rigides et souples sur un type de ressource spécifique, les contraintes souples peuvent être décisives. En d'autres termes, si plusieurs ressources répondent à une contrainte rigide, les contraintes souples sont utilisées pour sélectionner la ressource réelle utilisée dans le déploiement.
Par exemple, supposons que vous créez une contrainte de stockage stricte avec une balise location:boston. Si, dans le projet, aucun espace de stockage ne correspond à cette contrainte, tout déploiement associé échoue.
