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 charmed operator’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.
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”.
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.