Charms contain the intelligence necessary for connecting different applications together. These inter-application connections are called relations, and they are formed by connecting the applications’ endpoints. Endpoints can only be connected if they support the same interface and are of a compatible role (requires to provides, provides to requires, peers to peers).
For example, the ‘wordpress’ charmed operator supports, among others, an ‘http’ interface (“provides” the website) and a ‘mysql’ interface (“requires” a database). Any other application which also has such interfaces can connect to this charmed operator in a meaningful way.
Below we see WordPress with relations set up between both MySQL and Apache (a potential relation is shown with HAProxy):
Some of the above application units show unused interfaces. It is the overall purpose of the installation which will dictate what interfaces get used. Some relation types are required by the main charm (‘wordpress’ here) while some relation types are optional. A charmed operator’s entry in the Charm Store (e.g. wordpress) will expose such details.
Relations are not direct connections between charms. They’re implemented on top of the connections that the unit agents establish with the controller at startup. The Juju controller acts as a message broker within a virtual star topology. This allows units to send data via relations that might not have connectivity with each other.
Relations can also work across models, even across multiple controllers and clouds. This functionality can enable your databases to be hosted on bare metal, where I/O performance is paramount, and your applications to live within Kubernetes, where scalability and application density are more important. See Cross model relations for more information.
Last updated 29 days ago.