Dependent Resources

Resources that are depended on by a Workload are called Dependent Resources. They can either be Shared (available to all Workloads in an Environment) or Private (only available to a single Workload).

The outputs of a resource are defined by the type of the resource. These outputs can be referenced using placeholders from within the parts of the workload specification.

Dependent Resource IDs #

Dependent resources must have a unique ID within their scope. For example, the workload workload-1 can have a dependency on a resource of type postgres with ID my-db and workload-2 could have a dependency on a resource of type mysql and also have an ID of my-db because they are in different scopes.

These IDs can be used in placeholders to reference the outputs of a resource once provisioned. To reference the name of the database created with the ID my-db in the workload, the following Placeholder can be used:

${externals.my-db.name}

See Resource IDs of Active Resources for more details on Resource IDs.

Shared Resource dependencies #

Shared Resources Dependencies in the Humanitec Platform Orchestrator are dependencies on resources that are available to all Workloads in an Application Environment. This can be useful in a variety of scenarios, such as when multiple Workloads need to access the same database, or when different Workloads need to respond to requests for a shared domain name.

To create a Shared Resource Dependency, you can use the Humanitec UI, CLI, or API. This allows you to specify the details of the resource, such as the type of resource (for example, database, domain name), the configuration and settings, and the access controls. Once the Shared Resource has been created, it will be available to all Workloads in the Environment, so they can access and use it as needed.

Adding a Shared Resource #

• Web UI
• CLI
• API
• Terraform

humctl update delta ${DELTA_ID} add /shared/${RES_ID} '{ "type": "'${RES_TYPE}'" }'

curl "https://api.humanitec.io/orgs/${HUMANITEC_ORG}/apps/${HUMANITEC_APP}/deltas/${DELTA_ID}" \
  -X PATCH \
  -H "Authorization: Bearer ${HUMANITEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '[
  {
    "shared: [
      {
        "op": "add",
        "path": "/spec/shared/'${RES_ID}'".
        "value": { "type": "'${RES_TYPE}'" }
      }
    ]
  }
]'

Results: The shared resource are added to the list of shared resources for the Application.

Shared Resources in Score #

Score has the concept of a resource id which, from the viewpoint of an application developer, simply means “some external Resource identifier”. When two resources share the same type, class, and id, they are considered the same resource when used across related workloads, i.e. all Workloads in the same Application Environment.

A resource having an id in Score will be provisioned as a Shared Resource in the Platform Orchestrator. It will receive a resource id of shared.<id> in the Resource Graph .

All workloads in the same Environment requesting the same resource, i.e. same type, class, and id, will effectively share that same resource, as seen in these Score snippets:

# Workload 1
resources:
  my-internal-name-for-this-resource:
    type: s3
    id: s3-common
    # No class specified, so the effective class is "default"

# Workload 2
resources:
  my-different-name-for-this-resource:
    type: s3
    id: s3-common
    # No class specified, so the effective class is "default"

Note that the resource names my-internal-name-for-this-resource and my-different-name-for-this-resource are local to the respective Score file. References to ${resources.my-internal-name-for-this-resource...} in the first and ${resources.my-different-name-for-this-resource...} in the second Score file will resolve to the same resource.

This Score example shows another real-life application of Shared Resources.

Shared Resources are also used in the Delegator Resource Graph pattern .

Private Resource dependencies #

Private Resource Dependencies in the Humanitec Platform Orchestrator describe dependencies on resources that are only available to a single Workload in an Application. The main purpose of this is to make it easier to reason about which workload “owns” a particular resource, such as a database.

To create a Private Resource, you can use the Humanitec UI, CLI, or API. This allows you to specify the details of the resource, such as the type of resource (for example, database, domain name), the configuration and settings, and the access controls.

Add private Resource to an Application #

• Web UI
• CLI
• API
• Terraform

humctl update delta ${DELTA_ID} add /modules/${WORKLOAD_ID}/externals/${RES_ID} '{ "type": "'${RES_TYPE}'" }'

curl "https://api.humanitec.io/orgs/${HUMANITEC_ORG}/apps/${HUMANITEC_APP}/deltas/${DELTA_ID}" \
  -X PATCH \
  -H "Authorization: Bearer ${HUMANITEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '[
  {
    "modules: {
      "update": {
        "'${WORKLOAD_ID}'": [
          {
            "op": "add",
            "path": "/externals/'${RES_ID}'".
            "value": { "type": "'${RES_TYPE}'" }
          }
        ]
      }
    }
  }
]'