Tags added to projects and cloud templates function as constraint tags when they are used to match capability tags on infrastructure resources, profiles, and cloud zones. In the case of cloud templates, Automation Assembler uses this matching functionality to allocate resources for deployments.
Automation Assembler enables you to use constraint tags in two primary ways. The first way is when configuring projects and images. You can use tags as constraints to associate resources with the project or image. The second is in cloud templates where tags specified as constraints are used to select resources for deployments. Constraints applied in both of these ways are merged in cloud templates to form a set of deployment requirements that define resources available for a deployment.
How constraint tags work on projects
When configuring Automation Assembler resources, cloud administrators can apply constraint tags on projects. In this way, administrators can apply governance constraints directly at the project level. All constraints added at this level are applied to every cloud template requested for the applicable project, and these constraint tags take precedence over other tags.
If constraint tags on the project conflict with constraint tags on the cloud template, 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 cloud template, the former will take precedence and the resource is deployed to infrastructure containing the location:london tag.
There are three types of constraints tags that users can apply on projects: network, storage, and extensibility. You can apply as many instances of each tag type as needed. 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 cloud templates
In cloud templates, 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 under a constraint heading in the cloud template YAML code. Constraint tags from projects are added to the constraint tags created in cloud templates.
Automation Assembler supports a simple string formatting to make using constraints easier in YAML files:
[!]tag_key[:tag_value][:hard|:soft]
By default Automation Assembler creates a positive constraint with hard enforcement. The tag value is optional, though recommended, as in the rest of the application.
key:value format. Attempting to use other delimiters will likely cause errors.
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 cloud templates, see Part 3: Design and deploy the example Automation Assembler template.
How hard and soft constraints work in projects and cloud templates
Constraints in both projects and cloud templates 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 cause a deployment to 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, 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.
