CMR scenario #1
This page refers to Cross model relations. See that page for background information.
In this example, we build a simple CMR infrastructure in step by step fashion, explaining each step along the way. A method of verifying the deployment is provided at the end.
This scenario describes a MediaWiki deployment, based within the same controller; used by the admin user, and consumed by multiple models.
The controller is called 'aws-cmr' and the model name is 'cmr-model'.
Deploy the application
Deploy the application in the usual way. Extra resources have been requested via constraints, since this shared MySQL should be capable of servicing several remote applications.
juju deploy mysql --constraints "cores=4 mem=16G root-disk=1T"
The output to juju status
will eventually look similar to:
Model Controller Cloud/Region Version SLA
cmr-model aws-cmr aws/us-east-1 2.3-beta2.1 unsupported
App Version Status Scale Charm Store Rev OS Notes
mysql 5.7.19 active 1 mysql jujucharms 58 ubuntu
Unit Workload Agent Machine Public address Ports Message
mysql/0* active idle 0 54.81.205.47 3306/tcp Ready
Machine State DNS Inst id Series AZ Message
0 started 54.81.205.47 i-0f9f15e276ec3b5c2 xenial us-east-1a running
Relation provider Requirer Interface Type Message
mysql:cluster mysql:cluster mysql-ha peer
Now make the mysql application, and only that application, available to other
models by referring to interface 'mysql:db' with the juju offer
command:
juju offer mysql:db
Note:
See Managing relations for how to determine the
interface used in the juju offer
command.
The output will include the shared application's endpoint:
Application "mysql" endpoints [db] available at "admin/cmr-model.mysql"
Where the offer URL is admin/cmr-model.mysql
.
All available offer endpoints (per model) can be listed like so:
juju find-offers
In this example, the output is:
Store URL Access Interfaces
aws-cmr admin/cmr-model.mysql admin mysql:db
Add a first consumer model and application
Add a consumer model and application. The application in this example will
require a MySQL database and the objective is that it will use the one in the
shared (CMR) model. The application we've chosen here is WordPress and we'll
refer to the MySQL offer URL in the juju add-relation
command:
juju add-model wordpress-model
juju deploy wordpress
juju expose wordpress
juju add-relation wordpress:db admin/cmr-model.mysql
The last command has made use of a cross model relation.
The output to juju status
for this model will eventually settle down to look
very much like:
Model Controller Cloud/Region Version SLA
wordpress-model aws-cmr aws/us-east-1 2.3-beta2.1 unsupported
SAAS Status Store URL
mysql unknown aws-cmr admin/cmr-model.mysql
App Version Status Scale Charm Store Rev OS Notes
wordpress active 1 wordpress jujucharms 5 ubuntu exposed
Unit Workload Agent Machine Public address Ports Message
wordpress/0* active idle 0 54.198.91.120 80/tcp
Machine State DNS Inst id Series AZ Message
0 started 54.198.91.120 i-00332775f5f83d886 trusty us-east-1a running
Relation provider Requirer Interface Type Message
mysql:db wordpress:db mysql regular
wordpress:loadbalancer wordpress:loadbalancer reversenginx peer
Notice how the remote MySQL application shows up as a SAAS object. The relation is also described:
Relation provider Requirer Interface Type Message
mysql:db wordpress:db mysql regular
Applying the juju status
command to the CMR model we see that the offer is
now connected:
juju status -m cmr-model
Output:
.
.
.
Offer Application Charm Rev Connected Endpoint Interface Role
mysql mysql mysql 58 1/1 db mysql provider
Add a second consumer model and application
Add a second consumer model and MySQL-based application. The application we've chosen now is MediaWiki.
juju add-model mediawiki-model
juju deploy mediawiki
juju expose mediawiki
juju add-relation mediawiki:db admin/cmr-model.mysql
The output to juju status
for this model will eventually become:
Model Controller Cloud/Region Version SLA
mediawiki-model aws-cmr aws/us-east-1 2.3-beta2.1 unsupported
SAAS Status Store URL
mysql unknown aws-cmr admin/cmr-model.mysql
App Version Status Scale Charm Store Rev OS Notes
mediawiki 1.19.14 active 1 mediawiki jujucharms 19 ubuntu exposed
Unit Workload Agent Machine Public address Ports Message
mediawiki/0* active idle 0 54.80.49.62 80/tcp Ready
Machine State DNS Inst id Series AZ Message
0 started 54.80.49.62 i-0b7530071c6242c19 trusty us-east-1a running
Relation provider Requirer Interface Type Message
mysql:db mediawiki:db mysql regular
The new juju status
output for model 'cmr-model' is not surprising. There are
now two connections to the original offer:
.
.
.
Offer Application Charm Rev Connected Endpoint Interface Role
mysql mysql mysql 58 2/2 db mysql provider
juju offers -m cmr-model
Offer User Relation id Status Endpoint Interface Role Ingress subnets
mysql admin 1 joined db mysql provider 54.198.91.120/32
admin 2 joined db mysql provider 54.80.49.62/32
Verification
Verify that the remote application has responded to the two cross model relations by creating/preparing the necessary resources. In this example, we log in to the mysql unit via SSH, connect to MySQL, and list its databases:
juju ssh -m cmr-model mysql/0
mysql -u root --password=$(sudo cat /var/lib/mysql/mysql.passwd)
mysql> show databases;
The output should look similar to:
+-----------------------------------------+
| Database |
+-----------------------------------------+
| information_schema |
| mysql |
| performance_schema |
| remote-9414c94f21db456d822045bb216c3b33 |
| remote-9cc8d09e87674e3487442a64751eb386 |
| sys |
+-----------------------------------------+
6 rows in set (0.00 sec)
From the output we can see evidence of two databases that got created, one for each consumer application.