Juju deploys units of a service from a charm. The simplest way to do this is
juju deploy mysql
which will take the latest version of the MySQL charm straight from the store and create a single service unit.
By default, Juju creates a unit of a service named after the charm;
the above example.
You can specify the name for the service when deploying:
juju deploy mysql wikidb
which will create a unit of the
wikidb service. It creates the unit exactly as
before, except instead of
mysql, the service is called
Why specify names for services? The simplest reason is organizational. It lets you stay organized as your infrastructure gets more complex:
juju deploy mysql website-db juju deploy mysql app-master-db juju deploy mysql app-slave-db -n2
But there are other reasons to do this: service groups, which are nothing other than named services. They are called out as a separate feature because they're quite useful in a few different ways.
Some services acquire a role at runtime based on the relations that are joined.
A great example of this is the hadoop charm. It can instantiate services
juju deploy hadoop namenode juju deploy hadoop datacluster -n40
which are identical at this point except for the service name that Juju's using for the various units.
These services acquire roles at relation-time via
juju add-relation namenode:namenode datacluster:datanode juju add-relation namenode:jobtracker datacluster:tasktracker
The relations determine the service role.
Another example of this is mysql replication.
juju deploy mysql masterdb juju deploy mysql slavedb -n2
where the different services are related to each other
juju add-relation masterdb:master slavedb:slave
and to other services via
juju deploy mediawiki mywiki juju add-relation mywiki:db masterdb:db juju add-relation mywiki:slave slavedb:db
There are also interesting use-cases for breaking large services down into separate groups of units. Instead of a single 5000-node hadoop service named hadoop-slave, you might build that cluster from multiple smaller service groups.
juju deploy hadoop hadoop-master juju deploy hadoop hadoop-slave-A -n2500 juju deploy hadoop hadoop-slave-B -n2500 juju add-relation hadoop-master:namenode hadoop-slave-A:datanode juju add-relation hadoop-master:namenode hadoop-slave-B:datanode ...
These service groups can be managed independently by Juju for upgrades and configuration
juju set hadoop-slave-B some_param=new_value
This technique can potentially be a way for Juju to manage rolling upgrades for a service. Of course, this depends heavily on the services in question and how well they support version management, schema changes, etc.