You add constraint tags to blueprints and various other components within Cloud Assembly to match capabilities defined on resources, cloud zones, and profiles to generate appropriate deployments.
There are two main areas in Cloud Assembly where constraint tags are applicable. The first is on the configuration side in projects and images. The second is on the deployment side in blueprints. Constraints applied in both areas are merged in blueprints to form a set of deployment requirements.
How Constraint Tags Work on Projects
When configuring cloud assembly, cloud administrators can apply constraint tags on projects and image maps. In this way, cloud administrators can apply governance constraints directly at the project level. All constraints added at this level are applied to every blueprint requested for the applicable project.
If tags on the project conflict with tags on the blueprint, the project tags take precedence, thus allowing the cloud administrator to enforce governance rules. For example, if the cloud administrators creates a
location:london tag on the project, but a developer places a
location:boston tag on the blueprint, the former will take precedence and the resource is deployed to infrastructure containing the
You can apply up to three constraints on projects. Project constraints can be hard or soft. By default they are hard. Hard constraints allow you to rigidly enforce deployment restrictions. If one or more hard constraints are not met, the deployment will fail. Soft constraints offer a way to express preferences that will be selected if available, but the deployment won't fail if soft constraints are not met.
How Constraint Tags Work in Blueprints
In blueprints, you add constraint tags to resources as YAML code to match the appropriate capability tags that your cloud administrator created on resources, cloud zones and storage and network profiles. In addition, there are other more complex options for implementing constraint tags. For example, you can use a variable to populate one or more tags on a request. This enables you to specify one or more of the tags at request time.
Create constraint tags by using the
tag label in the blueprint YAML code. Constraint tags from projects are added to the constraint tags created in blueprints.
Cloud Assembly supports a simple string formatting to make using constraints easier in YAML files:
By default Cloud Assembly creates a positive constraint with hard enforcement. The tag value is optional, though recommended, as in the rest of the application.
The following WordPress with MySQL example shows YAML constraint tags that specific location information for compute resources.
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 ...
For more information about how to work with blueprints, see WordPress use case: create and expand a blueprint.
How hard and soft constraints work in projects and blueprints
Constraints in both projects and blueprints can be hard or soft. The preceding code snippet shows examples of hard and soft constraints. By default all constraints are hard. Hard constraints allow you to rigidly enforce deployment restrictions. If one or more hard constraints are not met, the deployment will fail. Soft constraints express preferences that apply if available, but they won't fail if not met.
If you have a series of hard and soft constraints on a specific resource type, the soft constraints can also serve as tie breakers. That is, if multiple resources meet a hard constraint, the soft constraints are used to select the actual resource used in the deployment.
For example you can specify up to three constraints on a project in any combination of network, storage and extensibility items. Also, you can select whether each constraint is hard or soft. Let's say that you create a hard storage constraint with a tag of
location:boston. If no storage in the project matches this constraint, any related deployment will fail.
In projects and blueprints, the
failOnConstraintMergeConflict flag modifies the behavior of constraints. When this flag is set to true, if there is a conflict between project constraints and blueprint constraints, the request will fail. If the flag is not present or set to false, the project constraints take precedence over the blueprint constraints.