Links

Dependencies

Resource Dependencies in Deployment Sets

Resource Dependencies in Deployment Sets

For a Workload to consume or make use of a Resource, a Dependency needs to be defined. A Resource Dependency can either be private (the resource will only be available to a single workload) or shared (the resource will be available to multiple workloads). Some Resource Types take inputs that can parameterize how a resource is provisioned.
At Deployment time, Humanitec will provision the Resource and replace Placeholders in the Workload configuration with specific outputs of the resource.

Private and Shared Resource Dependencies

Resource Dependencies can be organized such that they are private to a Workload or shared between workloads. This can be used to optimize Resource allocation and/or simplify the architecture of Apps with lots of Workloads.
Shared Resources can be accessed by any Workload in an App. In the API they are defined at the root of the Set (under the shared array) - Or via the UI on the Shared resources tab of the App Details page. For example, it's common practice in microservice applications to serve delegated routes of the API from different services. One implementation then, would be for the DNS name that the API is served from to be a shared resource that the service Workloads would define their ingress dependencies to.
Private Resources can only be accessed from the Workload that the Dependency is defined under. They can be defined via the API in the externals array of the Workload definition - Or via the Workload Details page of the UI. For example, each Workload might have its own database. As this database is solely used by one Workload, it would make sense for this Resource to be a private dependency.

Resource Inputs and Outputs

Some resources allow developers to specify inputs. These inputs will be used as hints when provisioning the resource.
Many resources produce outputs. These are values that are only known once a resource has been provisioned.

Example

A Workload has a dependency on a PostgreSQL database. The Workload uses UUIDs, so it needs the PostgreSQL uuid-ossp extension installed in the database to help generate new UUIDs for keys. In order to connect to the database the service will need a connection string. This should contain information about the host, port, user, password and database name needed to connect to the instance that the database is in.
In Humanitec, this would be represented as a Resource of type postgres. The input would list uuid-ossp as a required extension. The outputs would be 5 values:
  • the host which the PostgreSQL instance is running on
  • the port that the instance is listening on
  • the name of the database in the instance and
  • the username and password of the user with permissions on the database.

Resource Outputs as Placeholders

The variables and files fields for a container in a Workload in a Deployment Set support Placeholders. These can be used to inject resource outputs from resource dependencies into the Workload.
For example, the PostgreSQL connection string could be written as follows if the database was a shared resource dependency with id users-db:
postgresql://${shared.users-db.username}:${shared.users-db.password}@${shared.users-db.host}:${shared.users-db.port}/${shared.users-db.name}