Endpoint

See also: Application

In Juju, an endpoint (or application endpoint) is used to connect to another application’s endpoint in order to form a relation. An endpoint is defined in a charm’s metadata.yaml by the collection of three properties: a role, a name, and an interface.

There are three types of roles:

• requires: The endpoint can optionally make use of services represented by another charmed operator’s endpoint over the given interface.
• provides: The endpoint represents a service that another charmed operator’s endpoint can make use of over the given interface.
• peers: The endpoint can coexist with another charmed operator’s endpoint in a peer-to-peer manner (i.e. only between units of the same application). This role is often used in a cluster or high availability context.

The three types of endpoints are illustrated below.

For example, the pertinent excerpt of the metadata.yaml file for the ‘wordpress’ charmed operator is as follows:

requires:
  db:
    interface: mysql
  nfs:
    interface: mount
  cache:
    interface: memcache
provides:
  website:
    interface: http
peers:
  loadbalancer:
    interface: reversenginx

Here, there are three ‘requires’ endpoints (‘db’, ‘nfs’, and ‘cache’), one ‘provides’ endpoint (‘website’), and one ‘peers’ endpoint (‘loadbalancer’). For instance, we can say that “the ‘db’ endpoint can make use of services offered by another charm over the ‘mysql’ interface”. These endpoints and interfaces can be illustrated as follows:

Despite the term ‘requires’, the three cited endpoints are not hard requirements for the ‘wordpress’ charm. You will need to read the charmed operator’s entry in the Charmhub (e.g. wordpress) to discover actual requirements as well as how the charmed operator works. For instance, it is not obvious that the ‘wordpress’ charmed operator comes bundled with an HTTP server (nginx), making a separate HTTP-based charm not strictly necessary.

Last updated 10 months ago.