Unfurl Cloud Standard Library Overview
The Unfurl Cloud Standard library is a TOSCA library that provides building blocks and abstractions for deploying applications and services. It allows you to create high-level blueprints that can work in a variety of environments and can easily be combined with other blueprints.
If you are familiar with TOSCA or Unfurl, using the Unfurl Cloud Standard library should be straightforward – it is just a collection of type that you can use when you declare your templates or your own types. If you’re not familiar with TOSCA, then take a look at our application blueprint project template for a step-by-step guide for building an application blueprint using this library.
The type definitions Unfurl Cloud Standard library provides can be grouped into 3 categories:
Core abstractions
Types that provides a minimal set of abstract representations, and relationships, and services. Deriving classes in your blueprint from these types makes it easy for your blueprints to be interoperable with other blueprints.
Common resources and services
This includes types that define abstract types for common resources like compute instances and disk volumes and common services such as DNS, popular databases, and mail servers.
Self-hosted and cloud provider implementations
These are concrete implementations of the above abstract types including container-based implementations for self-hosting and ones that provision cloud-provider managed services. They are fairly minimal and designed to be easily customized.
Core concepts
TOSCA node templates instantiate instances when they are deployed. A resource refers the external object that TOSCA instance is modeling. Resources can be concrete or abstract.
A concrete resource corresponds to “real” resource in the external world, whether a virtual resource on a cloud provider or actual physical hardware. An abstract resource does not – its existence depends other resources.
TOSCA defines a “hostedOn” relationship between resources existential – a resource “lives” on its host resource. Abstract resources will ultimately be hosted on concrete resources, though often through intermediate resources.
A Service is a resource with one or more endpoints, such as an URL or network port. Services are a key abstraction in Unfurl Cloud Standard library. A blueprint the relies on Services to define the functionality it provides can be deployed on wide variety of architectures. A service may be implemented as a concrete resource (e.g. for example a database service provisioned directly from a cloud provider, like AWS RDS) but it usually an abstract resource.
An abstract Service needs a ServiceHost that hosts the service. It translates the abstract service’s specification so that it can be deployed on an underlying resource, e.g. generating and deploying configuration files.
A resource (such as a compute resource) can have an execution environment that can alter the state of that resource and other resources in the model.
Artifacts are representations of data from container images to configuration files. An executable environment can “execute” artifacts which may alter the state and capabilities of the environment.
A cloud provider is a service that can instantiate concrete resources.
An App is a user-facing application composed of one or more services. It is typically at the root of a deployment.
Configuration architecture
If you look at the type definitions, you may notice many of the properties and attributes have defaults set to computed values with expressions containing .configured_on and .hosted_on keys. We use these as part of our design goal of keeping the types loosely-coupled to improve reuse and composability.
In TOSCA, there are properties, which specify configuration values and are immutable, and attributes, which are values that reflect the actual state of deployed resource.
In a topology where higher-level, more abstract resource types depend on lower-level, more concrete resource types the resulting dependency graph will tend to organize into two inheritance hierarchies. Properties will flow top-down: higher-level components set properties on the lower-level components; while attributes will flow bottoms-up: the attributes of lower-level components will determine the attributes of higher-level components.
For example, consider a property like the domain name for an application. That would be set at the high level application resource and its various dependent components such as a DNS service or the application configuration files would rely on that property. But consider the ip address of a compute instance that isn’t known until that resource is provisioned – if there was a service hosted on that compute instance, the service would inherit that ip address.
You can express these relationships by declaring declaring requirements with the unfurl.relationships.Configures and tosca.relationships.HostedOn relationships. Unfurl’s expression syntax provides two keys, .configured_on and .hosted_on, for searching along these two axes (Python DSL equivalents functions are find_configured_by() and find_hosted_on().)
So, following the DNS example above, a type definition that creates an “A” DNS record might set the record’s name to .configured_by::subdomain and its value to .hosted_on::public_address.
Type Hierarchy
These two relationships are used with the core types discussed to above to form the basic patterns that application blueprints using this library follow:
Services are hosted on ServiceHosts.
ServiceHosts are hosted on Compute resources.
The ContainerService subtype of Service is used for creating services from OCI (Docker) images. It is hosted on a ContainerHost of which there are several variants – in particular, ones such as HTTPSProxyContainerHost which expose a container service via HTTPS proxy that obtaining HTTPS certificates and configures DNS for the service.
The library also defines a hierarchy of abstract and concrete subtypes for resources such as compute instances and volumes for a variety of platforms and cloud providers, including Kubernetes, Amazon Web Services, Google Cloud, Microsoft Azure and Digital Ocean.
Finally the library provides types for common services such as DNS, mail servers, and databases. For example, there’s an abstract PostgresDB service that an application blueprint would use. Deployments of that blueprint would use one of the provided concrete subtypes, such as self-hosted containerized instance or a cloud provider managed service such as Google SQL Storage and Amazon RDS.