See also: Application
In Juju, an endpoint (or application endpoint) is used to connect to another application’s endpoint in order to form an integration (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 endpoint roles are illustrated below.
For example, the pertinent excerpt of the metadata.yaml
file for the wordpress
charm 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 charm’s entry on Charmhub (e.g. wordpress
) to discover actual requirements as well as how the charm works. For instance, it is not obvious that the wordpress
charm comes bundled with an HTTP server (nginx
), making a separate HTTP-based charm not strictly necessary.
Peer integrations happen automatically and do not need to be specified with the juju integrate
command.