Moodle Instance Management

Revision as of 13:35, 18 June 2016 by Valery Fremaux 2 (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Back to index

The infrastructure for Moodle instances management and deployment allows an easy management of multiple virtualized Moodle instances within the same physical hosting.

Virtualization principles

Moodle virtuazlization is simple. It mostly consists of no longer relying on the physical configration file config.php for absolute initial paths and DB definition, but dynamically building a set of configuration values from a table in the database. The set of main configuration parameter values will be chosen depending on the domain name (virtual host).

For integrating the whole virtualization process within Moodle itself, the virtualization table is held by a Moodle block.

Virtualization process

The overall lifecycle of a virtualized Moodle array is usually as follows:

Setup

The whole set of used domain names must be available and pointed to the same DocumentRoot in Apache. This also can be obtained using a wildcard DNS mapping pointing to such a Virtual Host setting:

  <VirtualHost XXX.XXX.XXX.XXX>
     ServerName mastermoodle.mydomain.com
     ServerAlias *.mydomain.com
     ...
  </VirtualHost>

Once these prerequisites are available, and the PHP volume correctly accessible:

  1. proceed to the installation of the main Moodle instance (Moodle master, bound to standard configuration).
  2. install the VMoodle block as a standard block
  3. place the VMoodle configuration hook in standard config (as mentionned in quick install process)
  4. configure the master Moodle, insert generic content, make common settings
  5. IMPORTANT : place an instance of a VMoodle block somewhere so you can browse to VMoodle administration!

You now should have this somewhere in your Moodle:

Vmoodle added.jpg

Note: an adequate location is in an administration block in administration pages, but you may also use a special "administration" course in your Moodle.

Deploying virtual instances from a physically setup Moodle

  1. make a first snapshot of the master moodle. This will store a replicable backup of the whole platform.
  2. deploy a first virtual node
  3. setup and tune the first virtual node
  4. snapshot the first vitual node as node template
  5. deploy any amount of nodes using this template.

The following image gives an idea of the virtualization benefit.

Vmoodle architecture.jpg

VMoodle Configuration

To configure the VMoodle block, browse to the VMoodle block settings in Administration menu:

  1. Define a naming schema for presetting the platform deployment form.
  2. Define information for connection to database.
  3. Define information for setting up MNET.
  4. Proceed to MNET peer key renewal.

1. Defining schema

The naming schema preset allows an easy setup of master information defining a new Moodle platform. The purpose of this automation is to speed up the setup of a new Moodle instance, reduce error when entering information, and promote a consistent naming ruleset for defining multiple Moodle hosts.

Vmoodle config p1.jpg

Schema fields:

 o Automate schema : Tells VMoodle to preset the deployment form.
 o Virtual host: Gives the pattern for generating new Moodle host names.
 o Database type: Preset the type of database used (MySQL or Postgres).
 o Database host: Preset value for the database hostname.
 o Database login: Preset value for the database user login.
 o Database password: Preset value for the database user password.
 o Database name: Preset a generation pattern for naming the database.
 o Table prefix: Preset value for the table name prefix.
 o Persistant connection: Preset value. Persistant connections will not 
   close at end of the PHP script and be reused.
 o Moodledata path: Preset the generation pattern for the Moodledata path.

When a schema is automated, entering the platform token will automatically provide adequate name to host, database and moodle data path.

To setup patterns, use the <%%INSTANCE%%> tag within the pattern to be replaced with the host token.

Example :

If you set the hostname pattern such as :

  http://<%%INSTANCE%%>.mydomain.com

And you enter a token with value "moodle1", than the deployment form will replace the pattern with the final value :

  http://moodle1.mydomain.com

Same is performed with the database name field and the Moodledata path.

2. Setting up the path to database executables

Vmoodle config p3.jpg

You may only provide system path of executable for the database you want to use (MySQL or Postgres)

Path to executable will surely have to be double quoted.

 o Path to mysql terminal : full path to the mysql (Linux) command or mysql.exe (Windows)
 o Path to mysql dump : full path to mysqldump (Linux) or mysqldump.exe (Windows)
 o Path to postgres terminal : full path to psql (Linux) psql.exe (Windows)
 o Path to postgres dump : full path to pg_dump (Linux) or pg_dump.exe (Windows)

Configuration note:

On Linux common location for mySQL is:

  /usr/bin/mysql
  /usr/bin/mysqldump

For PostGreSQL :

You may get client executables by installing the client packages for PostGreSQL.

  /usr/bin/psql
  /usr/bin/pg_dump

On PostGreSQL you might use a superuser setup in the PGPASS file to allow complete execution of PG commands in a non interactive mode.

Support note : PostgreSQL has been mush less tested and validated than Mysql environments. The PostGres settings are provided for convenience and to help peer developpers to contribute to the work.

3. Configuring MNET.

Vmoodle config p2.jpg

4. MNET keys automated renewal.

Important note : this feature relies on a light change in mnet/lib.php. Patch information is provided in distribution

VMoodle is often used for Moodle arrays operating the same teaching environment, thus making big use of MNET functions. The distributed strategy of Moodle will call for developing XML-RPC adds-on for enhancing the overall behaviour. Although Moodle maintains key consistency when users roam from one Moodle to another (using jump/land mechanism), this is not the case for XML-RPC MNET calls. the risk of having broken services every 28 days is high.

This section setup an automated key renewal within a VMoodle network so there is no more fear to get web services broken by key loss. When configuring this feature, each Moodle getting awareness of his key being obsolete will renew it and force all peers to accept this renewed key. The whole VMoodle MNET network will auto-repair continuously his consistency.

 o Autorenew enable: enables or disables the key autorenewal.
 o Key obsolecence look forward delay : a delay og forwarding the Moodle cron will detect
   that his own MNET key is about to fall out of calendar. 
 o Time for renewal: the time the renewal will be proceeded after obsolescence look forward 
   has been triggered. 

Using the last parameter, you will setup a renewal time in a suitable time range so minimizing risk of users being bothered during key exchange.

Vmoodle config p4.jpg

Virtualizing moodles: the starting point

Vmoodle start point.jpg

The above picture shows the VMoodle administration GUI just after the first Moodle host (Master Moodle) has been installed.

At this time, the only possibility you will have is to snapshot the Master Moodle for further deployment. This makes a stored copy of all the Master Moodle database and stored files which other Moodle can be deployed from. You can control that the snapshot has succeeded in the "moodledata/vmoodle" directory: you should have two directories (one for SQL capture and one for all moodledata files).

The snapshot procedure is a 3 step wizard.

1st step: Setting up the storage directories.

2nd step: Dumping the database.

3rd step: Getting a copy of moodledata.

Once you get the first Moodle template stored, you will be able to make your first Virtual Moodle.

Define a new VMoodle instance

To deploy a new Moodle instance, enter with an admin account to your Master Moodle and browse to the location of your VMoodle block. Click on the 'Administrate' link.

Click upon "Define a new virtual platform" in the "Pool Management" screen.

File:add moodle 1.png

First form part:

File:add moodle 3.png

Fields:

o Name: Usual name of the new Moodle. Will be setup in the site course parameters.
o Shortname: Shortname for the new host. Use a token here that will change the 
  schema automated patterns if enabled.
o Description : A description that will be added to Moodle site course.
o Host: If schema is automated, you should not have to change this.

File:add moodle 4.png

o Database type: Change the type as desired (MySQL / PostgreSQL)
o Database host: Change here for local reasons.
o Database user login: Login d'accès à la base de données.
o Database user password: Password d'accès à la base de données.
o Database name: You may not have to change this if schema is automated. Note that 
  this database MUST NOT be created (Mysql).
o Table prefix.
o connection persistance: Change here for local reasons.

Most of those fields are already setup from your default settings.

File:add moodle 5.png