Vous ajoutez des balises de contrainte à des Blueprints et à d'autres composants de Cloud Assembly, correspondant aux capacités définies sur les ressources, les zones de cloud et les profils afin de générer les déploiements appropriés.

Il existe deux zones principales dans Cloud Assembly, dans lesquelles des balises de contrainte sont applicables. La première se trouve du côté de la configuration, dans les projets et les images. La seconde se trouve du côté du déploiement dans les Blueprints. Les contraintes appliquées dans les deux zones sont fusionnées dans les Blueprints pour former un ensemble de conditions de déploiement.

Fonctionnement des balises de contrainte sur les projets

Lors de la configuration de Cloud Assembly, les administrateurs de cloud peuvent appliquer des balises de contrainte sur des projets et des images hypertextes. De cette manière, les administrateurs de cloud peuvent appliquer des contraintes de gouvernance directement au niveau du projet. Toutes les contraintes ajoutées à ce niveau sont appliquées à chaque Blueprint demandé pour le projet applicable.

Si des balises du projet sont en conflit avec des balises du Blueprint, les balises de 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 Blueprint, la première est prioritaire et la ressource est déployée sur l'infrastructure contenant la balise location:london.

Vous pouvez appliquer jusqu'à trois contraintes sur les projets. 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 Blueprints

Dans les Blueprints, 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 le libellé tag dans le code YAML du Blueprint. Les balises de contrainte des projets sont ajoutées aux balises de contrainte créées dans les Blueprints.

Cloud Assembly 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, Cloud Assembly 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.

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 Blueprints, reportez-vous à la section Cas d'utilisation de WordPress : créer et développer un modèle de cloud.

Fonctionnement des contraintes rigides et souples dans les projets et les Blueprints

Les contraintes des projets et des Blueprints 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'échouent 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, vous pouvez indiquer jusqu'à trois contraintes sur un projet, dans n'importe quelle combinaison d'éléments réseau, de stockage et d'extensibilité. Vous pouvez également indiquer si chaque contrainte est rigide ou souple. Supposons que vous créez une contrainte de stockage rigide avec une balise location:boston. Si, dans le projet, aucun espace de stockage ne correspond à cette contrainte, tout déploiement associé échoue.

Note : Dans les projets et les Blueprints, l'indicateur failOnConstraintMergeConflict modifie le comportement des contraintes. Lorsque cet indicateur est défini sur true, s'il existe un conflit entre les contraintes de projet et les contraintes de Blueprint, la demande échoue. Si l'indicateur n'est pas présent ou défini sur false, les contraintes de projet sont prioritaires sur les contraintes de Blueprint.