JujuConcepts
|
Size: 2357
Comment:
|
Size: 5843
Comment: Initial draft from notes I wrote some time ago of an overview of Juju structure and concepts.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| This page assumes you have an orchestra setup already working, and discusses how to configure juju to control this setup | <<TableOfContents(2)>> |
| Line 3: | Line 3: |
| == 1. Installing juju == | = Introduction = |
| Line 5: | Line 5: |
| Starting Oneiric 11.10, juju is available in universe | This page provides an overview of Juju and in particular of the abstractions/"concept"/"terms" it uses. |
| Line 7: | Line 8: |
| {{{ sudo apt-get install juju }}} |
= Structure = |
| Line 11: | Line 10: |
| to install a daily build from PPA or to install from source code, check out the [[http://juju.ubuntu.com/docs/|juju documentation]] | == Juju concepts == |
| Line 13: | Line 12: |
| == 2. Configuring the environment == | * A Juju environment is a collection of ''services'' provided by ''nodes''. * A ''service'': * Is ''deployed'' by Juju using ''charms''. * Runs as one or more ''units''. * Can be ''related'' to other services, in which case some action is performed when the other services start or stop. * Can be given an ''alias'' name. * A ''unit'' is an instance of a ''service'': * Runs on a ''node'', it can either be: * The single ''unit'' running on that node. * One of several ''units'' each running in some kind of ''container'' (LXC, KVM) on that node. * Is setup and configured by a ''charm''. * Each ''node'': * Runs on a ''machine'' that Juju can request from a ''provider'': * A ''machine'' is supposed to have the OS already installed and running with two base attributes: * OS ''series'' (e.g. `trusty` or `win2012r2`). * System ''architecture'' (e.g. `amd64` or `ppc64el`). * A ''provider'' can belong to some categories: * ''local'' like LXC or KVM. * [[https://maas.ubuntu.com/|MAAS]] * ''private cloud'' like OpenStack. * ''public cloud'' like AWS or Azure. * Juju can be used to implement an OpenStack instance on top of the MAAS provider, or to use an OpenStack instance setup by other means as its provider. * Can have several ''containers'' that run ''units'' or it can run ''units'' directly. * It always has a ''machine'' unit. * A ''charm'' is made of: * A set of script and configuration files that setup an application. * Optionally an ''agent'' running on each ''unit'' on which the ''service'' is installed that maintains the configuration of the application if it is dynamically modifiable. The daemon's front end is as a rule an instance of the jujud daemon. * ''metadata'' refers specifically to ''tools'' and is the list of ''tool'' variants in a ''stream''. * The ''tool'' variants are version plus the ''series'' and ''architecture'' of the ''machine''s they can be installed on. * A ''stream'' is a collection of packages on a Canonical server, and it roughly the same thing as an ''archive'' for Debian packages, for example ''stable''. * The `juju` command line tool can have ''plugins'' which must be in a directory on the `$PATH` to be used. |
| Line 15: | Line 44: |
| {{{ sudo mkdir -p ~/.juju sudo vim ~/.juju/environments.yaml }}} |
== Juju node types == |
| Line 20: | Line 46: |
| And we copy the following | ''Control node'': |
| Line 22: | Line 48: |
| {{{ juju: environments environments: orchestra: type: orchestra # Specify the orchestra server's IP address orchestra-server: 10.1.2.3 # Specify storage. In this case we are using webdav installed by orchestra. storage-url: http://10.1.2.3/webdav # Specify cobbler's usr/pass orchestra-user: cobbler orchestra-pass: cobbler admin-secret: fooooo # Branch from where we will install ensemble # juju-branch: lp:juju # Mangement classes acquired-mgmt-class: orchestra-juju-acquired available-mgmt-class: orchestra-juju-available default-series: oneiric }}} |
* Usually the control node is not part of any environment and does not run any ''agents''. * Has the `juju-core` package that contains the commands to control the ''agents'' in the various environments. * Optionally has a `juju-$TYPE` package for the non-builtin type of hardware provisioning layers used by the environments. * The list of nodes is in `$JUJU_HOME/environments.yaml` and `$JUJU_HOME/environments/$ENV.jenv`. * It can have a local copy of the ''Juju tools'' repository [[https://streams.canonical.com/juju/tools/]] created by `juju sync-tools`. |
| Line 43: | Line 54: |
| == 3. Creating SSH keys == | ''State'' nodes: |
| Line 45: | Line 56: |
| Ensemble requires SSH keys to be able to access the deployed nodes. In case those keys do not exist, then we have to create them before we bootstrap our environment: | * The first ''state node'' configured is called the ''boostrap node'' and as a rule runs on ''machine'' 0 and its machine agent configuration has the admin user password of the MongoDB database (in the `oldpassword` field). * Have the `juju-mongodb` package and the `mongod` daemon running. * Have Juju MongoDB database in `/var/lib/juju/agent/machine-$HOST` in a ''replication set'' (usually 3-wide) that holds the state of the Juju environment. * All the ''agents'' in Juju ''nodes'' connect to the ''primary'' state node to update their state in the database. |
| Line 47: | Line 61: |
| {{{ ssh-keygen -t rsa }}} |
Ordinary nodes: |
| Line 51: | Line 63: |
| == 4. Bootstrapping the environment == | * Each has several ''agents'' configured under `/var/lib/juju/agents/` which are `jujud` instances that manage a specific aspect of their host. * One is the ''machine'' ''agent'' for that ''node''. * The other ''agents'' are for the local ''units'' of the ''charms'' that have a dynamic aspect. * Have the Juju ''tools''(which usually means `jujud`) under `/var/lib/juju/tools/` and these are installed by the ''agent'' for the ''machine'' ''unit''. * For ''public cloud'' providers this happens by default by fetching the relevant `.tgz` file from a simple-stream from the host `streams.canonical.com`. * The `.tgz` files can also be fetched from a local host indicated by `agent-metadata-url`. * The fetching is done by the ''agent'' daemon for each ''unit''. * The `.tgz` files are stored in the `blobstore` database on the state nodes. |
| Line 53: | Line 72: |
| After the configuration done above, we bootstrapped the environment: | = References = |
| Line 55: | Line 74: |
| {{{ juju bootstrap }}} This process will select any of the machines available to orchestra to be the zookeeper node. If you do not have full power control setup in Orchestra, then you will need to reboot the box that was selected at this time, so it will install juju. You can tell that it was selected because its 'mgmt_classes' field will now say 'orchestra-juju-acquired' instead of 'orchestra-juju-available'. In this example, the machine's name is '''mabolo''' {{{ ubuntu@orchtrasrvr:~$ juju status 2011-09-08 18:02:22,148 INFO Connecting to environment. machines: 0: {dns-name: mabolo.lan, instance-id: MTMxNDMwNzI0OS40ODkyODE2MzAuODE5ODY} }}} '''NOTE:''' Note that after executing the command we had to manually start/restart the system to PXE boot it. This can be automated if cobbler is configured to power-on the servers |
* Juju on MAAS: * [[https://help.ubuntu.com/lts/clouddocs/en/Installing-MAAS.html|Install MAAS]] and then Juju on top, from the MAAS documentation. * [[http://maas.ubuntu.com/docs/juju-quick-start.html|Install MAAS and then Juju on top by quickstart]], from the MAAS documentation. * [[https://jujucharms.com/docs/stable/config-maas|Install MAAS and then Juju on top]], from the Juju documentation. * [[https://jujucharms.com/docs/stable/howto-privatecloud|Private cloud HOWTO]] which is relevant because MAAS counts as a private cloud in particular as to ''tools'' installation. * [[https://github.com/juju/cheatsheet|Lists of control commands]] with a brief description that is usually much better than the builtin documentation. * [[http://www.metaklass.org/how-to-recover-juju-from-a-lost-juju-openstack-provider/||How to restore OpenStack and Juju]] configuration and state if one of the nodes has to be rebuilt, using the configuration and state still present on the other nodes. * [[http://voices.canonical.com/junien.fridrick/2015/06/03/changing-your-openstack-password-juju/|How to change the Juju state password]]. ---- CategoryDocumentation |
Introduction
This page provides an overview of Juju and in particular of the abstractions/"concept"/"terms" it uses.
Structure
Juju concepts
A Juju environment is a collection of services provided by nodes.
A service:
Is deployed by Juju using charms.
Runs as one or more units.
Can be related to other services, in which case some action is performed when the other services start or stop.
Can be given an alias name.
A unit is an instance of a service:
Runs on a node, it can either be:
The single unit running on that node.
One of several units each running in some kind of container (LXC, KVM) on that node.
Is setup and configured by a charm.
Each node:
Runs on a machine that Juju can request from a provider:
A machine is supposed to have the OS already installed and running with two base attributes:
OS series (e.g. trusty or win2012r2).
System architecture (e.g. amd64 or ppc64el).
A provider can belong to some categories:
Juju can be used to implement an OpenStack instance on top of the MAAS provider, or to use an OpenStack instance setup by other means as its provider.
Can have several containers that run units or it can run units directly.
It always has a machine unit.
A charm is made of:
- A set of script and configuration files that setup an application.
Optionally an agent running on each unit on which the service is installed that maintains the configuration of the application if it is dynamically modifiable. The daemon's front end is as a rule an instance of the jujud daemon.
metadata refers specifically to tools and is the list of tool variants in a stream.
The tool variants are version plus the series and architecture of the machines they can be installed on.
A stream is a collection of packages on a Canonical server, and it roughly the same thing as an archive for Debian packages, for example stable.
The juju command line tool can have plugins which must be in a directory on the $PATH to be used.
Juju node types
Control node:
Usually the control node is not part of any environment and does not run any agents.
Has the juju-core package that contains the commands to control the agents in the various environments.
Optionally has a juju-$TYPE package for the non-builtin type of hardware provisioning layers used by the environments.
The list of nodes is in $JUJU_HOME/environments.yaml and $JUJU_HOME/environments/$ENV.jenv.
It can have a local copy of the Juju tools repository https://streams.canonical.com/juju/tools/ created by juju sync-tools.
State nodes:
The first state node configured is called the boostrap node and as a rule runs on machine 0 and its machine agent configuration has the admin user password of the MongoDB database (in the oldpassword field).
Have the juju-mongodb package and the mongod daemon running.
Have Juju MongoDB database in /var/lib/juju/agent/machine-$HOST in a replication set (usually 3-wide) that holds the state of the Juju environment.
All the agents in Juju nodes connect to the primary state node to update their state in the database.
Ordinary nodes:
Each has several agents configured under /var/lib/juju/agents/ which are jujud instances that manage a specific aspect of their host.
One is the machine agent for that node.
The other agents are for the local units of the charms that have a dynamic aspect.
Have the Juju tools(which usually means jujud) under /var/lib/juju/tools/ and these are installed by the agent for the machine unit.
For public cloud providers this happens by default by fetching the relevant .tgz file from a simple-stream from the host streams.canonical.com.
The .tgz files can also be fetched from a local host indicated by agent-metadata-url.
The fetching is done by the agent daemon for each unit.
The .tgz files are stored in the blobstore database on the state nodes.
References
- Juju on MAAS:
Install MAAS and then Juju on top, from the MAAS documentation.
Install MAAS and then Juju on top by quickstart, from the MAAS documentation.
Install MAAS and then Juju on top, from the Juju documentation.
Private cloud HOWTO which is relevant because MAAS counts as a private cloud in particular as to tools installation.
Lists of control commands with a brief description that is usually much better than the builtin documentation.
http://www.metaklass.org/how-to-recover-juju-from-a-lost-juju-openstack-provider/ configuration and state if one of the nodes has to be rebuilt, using the configuration and state still present on the other nodes.
ServerTeam/JujuConcepts (last edited 2015-09-13 10:46:45 by 86)