Remove scratch copy
This commit is contained in:
Hosung Song
Родитель
af437e0281
Коммит
50cba2fb98
|
|
@ -1,22 +0,0 @@
|
|||
# Cleanup All Resources
|
||||
|
||||
To cleanup a Moodle/LAMP deployment simply delete the Resource Group that
|
||||
contains it. The commands below will iterate over your workspace
|
||||
directory and delete all deployments.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
First we need to ensure our [environment variables](./Environment-Variables.md) are correctly configured.
|
||||
|
||||
## Remove each resource group
|
||||
|
||||
This command will delete all resources in *all* resource groups. Run
|
||||
with caution.
|
||||
|
||||
Note, that this command will not fully delete the resource group if
|
||||
you have Azure Backup enabled since the Recovery Services Vault will
|
||||
not be deleted (it's got the backups of you data!).
|
||||
|
||||
``` bash
|
||||
for filename in $MOODLE_AZURE_WORKSPACE/*; do az group delete --yes --name $(basename $filename) --no-wait; done
|
||||
```
|
||||
|
|
@ -1,168 +0,0 @@
|
|||
# Deploy Autoscaling Moodle Stack to Azure
|
||||
|
||||
After following the steps in this this document you with awill have a
|
||||
new Moodle site with caching for speed and scaling frontends to handle
|
||||
load. The filesystem behind it is mirrored for high availability and
|
||||
optionally backed up through Azure. Filesystem permissions and options
|
||||
have also been tuned to make Moodle more secure than a default
|
||||
install.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To make things consitent across different sessions managing Moodle we
|
||||
should [configure the environment](./Preparation.md).
|
||||
|
||||
|
||||
## Create Resource Group
|
||||
|
||||
When you create the Moodle cluster you will create many resources. On
|
||||
Azure it is a best practice to collect such resources together in a
|
||||
Resource Group. The first thing we need to do, therefore, is create a
|
||||
resource group:
|
||||
|
||||
```
|
||||
az group create --name $MOODLE_RG_NAME --location $MOODLE_RG_LOCATION
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```expected_similarity=0.4
|
||||
{
|
||||
"id": "/subscriptions/325e7c34-99fb-4190-aa87-1df746c67705/resourceGroups/rgmoodlearm3",
|
||||
"location": "westus2",
|
||||
"managedBy": null,
|
||||
"name": "rgmoodlearm3",
|
||||
"properties": {
|
||||
"provisioningState": "Succeeded"
|
||||
},
|
||||
"tags": null
|
||||
}
|
||||
```
|
||||
|
||||
## Create Azure Deployment Parameters
|
||||
|
||||
Your deployment will be configured using an
|
||||
`azuredeploy.parameters.json` file. It is possible to provide these
|
||||
parameters interactively via the command line by simply omitting the
|
||||
paramaters file in the command in the next section. However, it is
|
||||
more reproducible if we use a paramaters file.
|
||||
|
||||
A good set of defaults are provided in the git repository. These
|
||||
defaults create a scalable cluster that is suitable for low volume
|
||||
testing. If you are building out a production service you should
|
||||
review the section below on sizing considerations. For now we will
|
||||
proceed with the defaults, but there is one value, the `sshPublicKey`
|
||||
that **must** be provided. The following command will replace the
|
||||
placeholder in the parameters template file with an SSH key used for
|
||||
testing puporses (this is created as part of the envrionment setup in
|
||||
the prerequisites):
|
||||
|
||||
``` bash
|
||||
ssh_pub_key=`cat $MOODLE_SSH_KEY_FILENAME.pub`
|
||||
echo $ssh_pub_key
|
||||
sed "s|GEN-SSH-PUB-KEY|$ssh_pub_key|g" $MOODLE_AZURE_WORKSPACE/arm_template/azuredeploy.parameters.json > $MOODLE_AZURE_WORKSPACE/$MOODLE_RG_NAME/azuredeploy.parameters.json
|
||||
```
|
||||
|
||||
If you'd like to configure the Moodle cluster (to be deployed)
|
||||
with your own SSL certificate for your domain (siteURL) at the
|
||||
deployment time, you can do so by using [Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/)
|
||||
and following the instructions in the [SSL cert documentation](SslCert.md).
|
||||
|
||||
For more information see the [parameters documentation](Parameters.md).
|
||||
|
||||
## Deploy cluster
|
||||
|
||||
Now that we have a resource group and a configuration file we can
|
||||
create the cluster itself. This is done with a single command:
|
||||
|
||||
```
|
||||
az group deployment create --name $MOODLE_DEPLOYMENT_NAME --resource-group $MOODLE_RG_NAME --template-file $MOODLE_AZURE_WORKSPACE/arm_template/azuredeploy.json --parameters $MOODLE_AZURE_WORKSPACE/$MOODLE_RG_NAME/azuredeploy.parameters.json
|
||||
```
|
||||
|
||||
## Using the created stack
|
||||
|
||||
In testing, stacks typically took between 1 and 2 hours to finish,
|
||||
depending on spec. Once complete you will receive a JSON output
|
||||
containing information needed to manage your Moodle install (see
|
||||
`outputs`). You can also retrieve this infromation from the portal or
|
||||
the CLI.
|
||||
|
||||
Once Moodle has been created, and (where necessary) you have
|
||||
configured your custom `siteURL` DNS to point to the
|
||||
`loadBalancerDNS`, you should be able to load the `siteURL` in a
|
||||
browser and login with the username "admin" and the
|
||||
`moodleAdminPassword`. Note that the values for each of these
|
||||
parameters are avialble in the portal or the `outputs` section of the
|
||||
JSON response from the previous deploy command. See [documentation on
|
||||
how to retrieve configuration data](./Get-Install-Data.md) along
|
||||
with full details of all the output parameters avialble to you.
|
||||
|
||||
Note that by default the deployment uses a self-signed certificate,
|
||||
consequently you will recieve a warning when accessing the site. To
|
||||
add a genuine certificate see the documentation on [managing your
|
||||
cluster](./Manage.md).
|
||||
|
||||
## Sizing Considerations and Limitations
|
||||
|
||||
Depending on what you're doing with Moodle you will want to configure
|
||||
your deployment appropriately.The defaults included produce a cluster
|
||||
that is inexpensive but probably too low spec to use beyond simple
|
||||
testing scenarios. This section includes an overview of how to size
|
||||
the database and VM instances for your use case.
|
||||
|
||||
### Database Sizing
|
||||
|
||||
As of the time of this writing, Azure supports "Basic", "General Purpose" and "Memory Optimized"
|
||||
tiers for MySQL/PostgreSQL database instances. In addition the mysqlPgresVcores defines
|
||||
the number of vCores for each DB server instance, and the number of those you can use is limited by
|
||||
database tier:
|
||||
|
||||
- Basic: 1, 2
|
||||
- General Purpose: 2, 4, 8, 16, 32
|
||||
- Memory Optimized: 2, 4, 8, 16
|
||||
|
||||
This value also limits the maximum number of connections, as defined
|
||||
here: https://docs.microsoft.com/en-us/azure/mysql/concepts-limits
|
||||
|
||||
As the Moodle database will handle cron processes as well as the
|
||||
website, any public facing website with more than 10 users will likely
|
||||
require upgrading to 100. Once the site reaches 30+ users it will
|
||||
require upgrading to General Purpose for more compute units. This depends
|
||||
entirely on the individual site. As MySQL databases cannot change (or
|
||||
be restored to a different tier) once deployed it is a good idea to
|
||||
slightly overspec your database.
|
||||
|
||||
All MySQL/PostgreSQL database storage, regardless of tier, has a hard upper limit of 1
|
||||
terabyte (1024 GB), starting from 5 GB minimum, increasing by 1 GB. You gain additional iops for each added GB, so if
|
||||
you're expecting a heavy amount of traffic you will want to oversize
|
||||
your storage. The current maximum iops with a 1TB disk is 3000.
|
||||
|
||||
### Controller instance sizing
|
||||
|
||||
The controller handles both syslog and cron duties. Depending on how
|
||||
big your Moodle cron runs are this may not be sufficient. If cron jobs
|
||||
are very delayed and cron processes are building up on the controller
|
||||
then an upgrade in tier is needed.
|
||||
|
||||
### Frontend instances
|
||||
|
||||
In general the frontend instances will not be the source of any
|
||||
bottlenecks unless they are severely undersized versus the rest of the
|
||||
cluster. More powerful instances will be needed should fpm processes
|
||||
spawn and exhaust memory during periods of heavy site load. This can
|
||||
also be mitigated against by increasing the number of VMs but spawning
|
||||
new VMs is slower (and potentially more expensive) than having that
|
||||
capacity already available.
|
||||
|
||||
It is worth noting that the memory allowances on these instances allow
|
||||
for more memory than they may be able to provide with lower instance
|
||||
tiers. This is intentional as you can opt to run larger VMs with more
|
||||
memory and not require manual configuration. FPM also allows for a
|
||||
very large number of threads which prevents the system from failing
|
||||
during many small jobs.
|
||||
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. [Retrieve configuration details using CLI](./Get-Install-Data.md)
|
||||
1. [Manage the Moodle cluster](./Manage.md)
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
# Environment Variables
|
||||
|
||||
In order to configure our deployment and tools we'll set up some
|
||||
environment variables to ensure consistency. If you are running these
|
||||
scripts through SimDem you can customize these values by copying and
|
||||
editing `env.json` into `env.local.json`.
|
||||
|
||||
We'll need a unique name for our Resource Group in Azure, but when
|
||||
running in an automated mode it is useful to have a (mostly) unique
|
||||
name for your deployment and related resources. We'll use a timestamp.
|
||||
If the environmnt variable `MOODLE_RG_NAME` is not set we will
|
||||
create a new value using a timestamp:
|
||||
|
||||
|
||||
``` shell
|
||||
if [ -z "$MOODLE_RG_NAME" ]; then MOODLE_RG_NAME=moodle_$(date +%Y-%m-%d-%H); fi
|
||||
```
|
||||
|
||||
Other configurable values for our Azure deployment include the
|
||||
location and depoloyment name. We'll standardize these, but you can
|
||||
use different values if you like.
|
||||
|
||||
``` shell
|
||||
MOODLE_RG_LOCATION=southcentralus
|
||||
MOODLE_DEPLOYMENT_NAME=MasterDeploy
|
||||
```
|
||||
|
||||
We also need to provide an SSH key. Later we'll generate this if it
|
||||
doesn't already exist but to enable us to reuse an existing key we'll
|
||||
store it's filename in an Environment Variable.
|
||||
|
||||
``` shell
|
||||
MOODLE_SSH_KEY_FILENAME=~/.ssh/moodle_id_rsa
|
||||
```
|
||||
|
||||
We need a workspace for storing configuration files and other
|
||||
per-deployment artifacts:
|
||||
|
||||
``` shell
|
||||
MOODLE_AZURE_WORKSPACE=~/.moodle
|
||||
```
|
||||
|
||||
## Create Workspace
|
||||
|
||||
Ensure the workspace for this particular deployment exists:
|
||||
|
||||
```
|
||||
mkdir -p $MOODLE_AZURE_WORKSPACE/$MOODLE_RG_NAME
|
||||
```
|
||||
|
||||
## Validation
|
||||
|
||||
After working through this file there should be a number of
|
||||
environment variables defined that will be used to provide a common
|
||||
setup for all our Moodle on Azure work.
|
||||
|
||||
The resource group name defines the name of the group into which all
|
||||
resources will be, or are, deployed.
|
||||
|
||||
```bash
|
||||
echo "Resource Group for deployment: $MOODLE_RG_NAME"
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Resource Group for deployment: southcentralus
|
||||
```
|
||||
|
||||
The resource group location is:
|
||||
|
||||
```bash
|
||||
echo "Deployment location: $MOODLE_RG_LOCATION"
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Deployment location: southcentralus
|
||||
```
|
||||
|
||||
When deploying a Moodle cluster the deployment will be given a name so
|
||||
that it can be identified later should it be neceessary to debug.
|
||||
|
||||
|
||||
```bash
|
||||
echo "Deployment name: $MOODLE_DEPLOYMENT_NAME"
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Deployment name: MasterDeploy
|
||||
```
|
||||
|
||||
The SSH key to use can be found in a file, if necessary this will be
|
||||
created as part of these scripts.
|
||||
|
||||
``` shell
|
||||
echo "SSH key filename: $MOODLE_SSH_KEY_FILENAME"
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
SSH key filename: ~/.ssh/moodle_id_rsa
|
||||
```
|
||||
|
||||
Configuration files will be written to / read from a customer directory:
|
||||
|
||||
``` shell
|
||||
echo "Workspace directory: $MOODLE_AZURE_WORKSPACE"
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Workspace directory: ~/.moodle
|
||||
```
|
||||
|
||||
Ensure the workspace directory exists:
|
||||
|
||||
|
||||
``` bash
|
||||
if [ ! -f "$MOODLE_AZURE_WORKSPACE/$MOODLE_RG_NAME" ]; then echo "Workspace exists"; fi
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Workspace exists
|
||||
```
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
# Prepare cluster for LAMP applications
|
||||
|
||||
To generalize an installed Moodle cluster so you can run LAMP applications, you'll first need to login to the Moodle cluster controller virtual machine. The directory you'll need to work out of is /azlamp.
|
||||
|
||||
## Removing all Moodle content
|
||||
|
||||
Leaving the Moodle related content in place is not detrimental but if you'd like to remove all Moodle related content, please locate the directories (under /azlamp/html and /azlamp/data and delete the directory structure). If this is done after a fresh cluster installation, there's only sub-directory each (starting with 'lb') in each of the two mentioned directories:
|
||||
|
||||
```rm -rf /azlamp/html/lb-n5o57b.westus2.cloudapp.azure.com```
|
||||
```rm -rf /azlamp/data/lb-n5o57b.westus2.cloudapp.azure.com```
|
||||
|
||||
## Configuring the controller for a specific LAMP application (WordPress)
|
||||
|
||||
|
||||
### Installation Destination
|
||||
An example LAMP application (WordPress) is illustrated here for the sake of clarity. The approach is similar to any LAMP application out there.
|
||||
|
||||
First, you'd need to navigate to /azlamp/html and create a directory based on a domain name you have in mind. An example domain name is used below:
|
||||
|
||||
```cd /azlamp/html```
|
||||
|
||||
```mkdir wpsitename.mydomain.com```
|
||||
|
||||
Once that's done and you've downloaded the latest version of WordPress, please follow the instructions here to complete configuring a database and finishing a [WordPress install](https://codex.wordpress.org/Installing_WordPress#Famous_5-Minute_Installation).
|
||||
|
||||
```wget https://wordpress.org/latest.tar.gz```
|
||||
|
||||
```tar xvfz latest.tar.gz```
|
||||
|
||||
|
||||
### SSL Certs
|
||||
|
||||
The certificates for your LAMP application reside in /azlamp/certs/yourdomain or in this instance, /azlamp/certs/wpsitename.mydomain.com
|
||||
|
||||
```mkdir /azlamp/certs/wpsitename.mydomain.com```
|
||||
|
||||
Copy over the .crt and .key files over to */azlamp/certs/wpsitename.mydomain.com*
|
||||
|
||||
It's recommended that the certificate files be read-only to owner and that these files are owned by *www-data*:
|
||||
|
||||
```chown www-data:www-data /azlamp/certs/wpsitename.mydomain.com/*```
|
||||
```chmod 400 /azlamp/certs/wpsitename.mydomain.com/*```
|
||||
|
||||
|
||||
### Linking to the content/cluster data location
|
||||
|
||||
Navigate to the WordPress content directory and run the following command:
|
||||
```cd /azlamp/html/wpsitename.mydomain.com```
|
||||
```ln -s /azlamp/data/wpsitename.mydomain.com/wp-content/uploads .```
|
||||
|
||||
|
||||
At this point, your LAMP application is setup to use in the LAMP cluster. If you'd like to install a separate LAMP application (WordPress or otherwise), you'll have to repeat the process listed here with a new domain for the new application.
|
||||
|
|
@ -1,154 +0,0 @@
|
|||
# Retrieve essential install details
|
||||
|
||||
Once a deployment has completed the ARM template will output some
|
||||
values that you will need for managing your Moodle instalation. These
|
||||
are available in the portal, but in this document we will retrieve
|
||||
them using the AZ command line tools and through the AZ CLI tool. This
|
||||
document describes the available parameters and how to retrieve them.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
In order to configure our deployment and tools we'll set up some
|
||||
[environment variables](./Environment-Variables.md) to ensure consistency.
|
||||
|
||||
## Output Paramater Overview
|
||||
|
||||
The available output parameters are:
|
||||
|
||||
- **siteURL**: If you provided a `siteURL` parameter when deploying this
|
||||
will be set to the supplied value. Otherwise it will be the same as
|
||||
the loadBalancerDNS, see below.
|
||||
- **loadBalancerDNS**: This is the DNS name of your application load
|
||||
balancer. If you provided a `siteURL` parameter when deploying
|
||||
you'll need to add a DNS entry to its CNAMEs pointing to this address.
|
||||
- **moodleAdminPassword**: The generated password for the "admin" user
|
||||
in your Moodle install.
|
||||
- **controllerInstanceIP**: This is the IP address of the controller
|
||||
Virtual Machine. You will need to SSH into this to make changes to
|
||||
your Moodle code or view logs.
|
||||
- **databaseDNS**: This is the public DNS of your database instance. If
|
||||
you wish to set up local backups or access the DB directly, you'll
|
||||
need to use this.
|
||||
- **databaseAdminUsername**: The admin username for your database
|
||||
(this is not the same as your Moodle username).
|
||||
- **databaseAdminPassword**: The admin password for your
|
||||
database (this is not the same as your Moodle password).
|
||||
|
||||
## Retrieving Output Parameters Using the CLI
|
||||
|
||||
To get a complete list of outputs in json format use:
|
||||
|
||||
```bash
|
||||
az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out json --query *.outputs
|
||||
```
|
||||
|
||||
Individual outputs can be retrieved by filtering, for example, to get
|
||||
just the value of the `siteURL` use:
|
||||
|
||||
``` bash
|
||||
az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out json --query *.outputs.siteURL.value
|
||||
```
|
||||
|
||||
However, since we are reqeusting JSON output (the default) the value
|
||||
is enclosed in quotes. In order to remove these we can output as a tab
|
||||
separated list (TSV):
|
||||
|
||||
``` bash
|
||||
az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.siteURL
|
||||
```
|
||||
|
||||
Now we can assign individual values to environment variables, for example:
|
||||
|
||||
``` bash
|
||||
MOODLE_SITE_URL="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.siteURL.value)"
|
||||
```
|
||||
|
||||
### Retrieving Moodle Site URL
|
||||
|
||||
The Site URL is the value used to configure Moodle's base URL. The
|
||||
site URL can be provided as an input to the template via the parameter
|
||||
`siteURL`, in which case you will not need to retrieve this from the
|
||||
outputs. However, if you do not define this, or if you leave it as the
|
||||
default "www.example.org" you will need to retrieve this value from
|
||||
Azure using the following command:
|
||||
|
||||
```bash
|
||||
MOODLE_SITE_URL="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.siteURL.value)"
|
||||
```
|
||||
|
||||
#### Retrieving Moodle Site Load Balancer URL
|
||||
|
||||
The load balancer DNS is the publicly registered DNS name for your
|
||||
Moodle DNS. If this is different from the site URL it is important to
|
||||
ensure that you configure your DNS entry for site URL to point at the
|
||||
load balancer.
|
||||
|
||||
```bash
|
||||
MOODLE_LOAD_BALANCER_DNS="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.loadBalancerDNS.value)"
|
||||
```
|
||||
|
||||
### Retrieving Moodle Administrator Password
|
||||
|
||||
Moodle admin password (username is "admin"):
|
||||
|
||||
```bash
|
||||
MOODLE_ADMIN_PASSWORD="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.moodleAdminPassword.value)"
|
||||
```
|
||||
|
||||
### Retriving Controller Virtual Machine Details
|
||||
|
||||
The controller VM runs management tasks for the cluster, such as cron jobs and syslog.
|
||||
|
||||
```bash
|
||||
MOODLE_CONTROLLER_INSTANCE_IP="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.controllerInstanceIP.value)"
|
||||
```
|
||||
|
||||
There is no username and password for this VM since a username and SSH
|
||||
key are provided as input parameters to the template.
|
||||
|
||||
### Retreiving Database Information
|
||||
|
||||
#### Database URL
|
||||
|
||||
``` bash
|
||||
MOODLE_DATABASE_DNS="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseDNS.value)"
|
||||
```
|
||||
#### Database admin username
|
||||
|
||||
``` bash
|
||||
MOODLE_DATABASE_ADMIN_USERNAME="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseAdminUsername.value)"
|
||||
```
|
||||
|
||||
#### Database admin password
|
||||
|
||||
``` bash
|
||||
MOODLE_DATABASE_ADMIN_PASSWORD="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseAdminPassword.value)"
|
||||
```
|
||||
|
||||
### Retrieving Moodle Application VNET Information
|
||||
|
||||
First frontend VM IP:
|
||||
|
||||
``` bash
|
||||
MOODLE_FIRST_FRONTEND_VM_IP="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.firstFrontendVmIP.value)"
|
||||
```
|
||||
|
||||
# Validation
|
||||
|
||||
After having run each of the commands in this document you should have
|
||||
each of the output parameters available in environment variable:
|
||||
|
||||
``` bash
|
||||
echo $MOODLE_SITE_URL
|
||||
echo $MOODLE_LOAD_BALANCER_DNS
|
||||
echo $MOODLE_ADMIN_PASSWORD
|
||||
echo $MOODLE_CONTROLLER_INSTANCE_IP
|
||||
echo $MOODLE_DATABASE_DNS
|
||||
echo $MOODLE_DATABASE_ADMIN_USERNAME
|
||||
echo $MOODLE_DATABASE_ADMIN_PASSWORD
|
||||
echo $MOODLE_FIRST_FRONTEND_VM_IP
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. [Manage the Moodle cluster](./Manage.md)
|
||||
|
|
@ -1,196 +0,0 @@
|
|||
# Managing a Scalable Moodle Cluster in Azure
|
||||
|
||||
This document provides an overview of how to perform various
|
||||
management tasks on a scalable Moodle cluster on Azure.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
In order to configure our deployment and tools we'll set up some
|
||||
[environment variables](./Environment-Variables.md) to ensure consistency.
|
||||
|
||||
In order to manage a cluster it is clearly necessary to first [deploy
|
||||
a scalable Moodle cluster on Azure](./Deploy.md).
|
||||
|
||||
For convenience and readability this document also assumes that essential [deployment details for your cluster have been assigned to environment variables](./Get-Install-Data.md).
|
||||
|
||||
## Updating Moodle code/settings
|
||||
|
||||
Your controller Virtual Machine has Moodle/LAMP code and data stored in
|
||||
`/azlamp`. The site code is stored in `/azlamp/html/<yoursitename>/`. This
|
||||
data is replicated across dual gluster nodes to provide high
|
||||
availability. This directory is also mounted to your autoscaled
|
||||
frontends so all changes to files on the controller VM are immediately
|
||||
available to all frontend machines (when the `htmlLocalCopySwitch` in `azuredeploy.json`
|
||||
is false--otherwise, see below). Note that any updates on Moodle code/settings
|
||||
(e.g., additional plugin installations, Moodle version upgrade) have to be done
|
||||
on the controller VM using shell commands, not through a web browser, because the
|
||||
HTML directory's permission is read-only for the web frontend VMs (thus any web-based
|
||||
Moodle code updates will fail).
|
||||
|
||||
Depending on how large your Gluster disks are sized, it may be helpful
|
||||
to keep multiple older versions (/azlamp/html/site1, /azlamp/html/site1, etc) to
|
||||
roll back if needed.
|
||||
|
||||
To connect to your Controller VM use SSH with a username of
|
||||
'azureuser' and the SSH provided in the `sshPublicKey` input
|
||||
parameter. For example, to retrieve a listing of files and directories
|
||||
in the `/azlamp` directory use:
|
||||
|
||||
```
|
||||
ssh -o StrictHostKeyChecking=no azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP ls -l /azlamp
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Warning: Permanently added '52.228.45.38' (ECDSA) to the list of known hosts.
|
||||
total 32
|
||||
drwxr-xr-x 2 root root 4096 Aug 28 18:27 bin
|
||||
drwxr-xr-x 5 root root 4096 Aug 8 16:49 certs
|
||||
drwxr-xr-x 5 root root 4096 Aug 8 16:52 data
|
||||
drwxr-xr-x 5 root root 4096 Aug 8 16:48 html
|
||||
```
|
||||
|
||||
**IMPORTANT NOTE**
|
||||
|
||||
It is important to realize that the `-o StrictHostKeyChecking=no`
|
||||
option in the above SSH command presents a security risk. It is
|
||||
included here to facilitate automated validation of these commands. It
|
||||
is not recommended to use this option in production environments,
|
||||
instead run the command mannually and validate the host key.
|
||||
Subsequent executions of an SSH command will not require this
|
||||
validation step. For more information there is an excellent
|
||||
[superuser.com
|
||||
Q&A](https://superuser.com/questions/421074/ssh-the-authenticity-of-host-host-cant-be-established/421084#421084).
|
||||
|
||||
### If you set `htmlLocalCopySwitch` to true (this is the default now)
|
||||
|
||||
Originally the `/azlamp/html` directory was shared across all autoscaled
|
||||
web VMs through the specified file server (Gluster or NFS), and this is
|
||||
not good for web response time. Therefore, we introduced the
|
||||
`htmlLocalCopySwitch` that'll copy the `/azlamp/html` directory to
|
||||
`/var/www/html` in each autoscaled web VM and reconfigures the web
|
||||
server (apache/nginx)'s server root directory accordingly, when it's set
|
||||
to true. This now requires directory sync between `/azlamp/html` and
|
||||
`/var/www/html`, and currently it's addressed by simple polling
|
||||
(minutely). Therefore, if you are going to update your Moodle
|
||||
code/settings with the switch set to true, please follow the
|
||||
following steps:
|
||||
|
||||
* Put your Moodle site to maintenance mode.
|
||||
* This will need to be done on the contoller VM with some shell command.
|
||||
* It should be followed by running the following command to propagate the change to all autoscaled web VMs:
|
||||
```bash
|
||||
$ sudo /usr/local/bin/update_last_modified_time.moodle_on_azure.sh
|
||||
```
|
||||
* Once this command is executed, each autoscaled web VM will pick up (sync) the changes within 1 minute, so wait for one minute.
|
||||
* Then you can start updating your Moodle code/settings, like installing/updating plugins or upgrading Moodle version or changing Moodle configurations. Again, note that this should be all done on the controller VM using some shell commands.
|
||||
* When you are done updating your Moodle code/settings, run the same command as above to let each autoscaled web VM pick up (sync) the changes (wait for another minute here, for the same reason).
|
||||
|
||||
Please do let us know on this Github repo's Issues if you encounter any problems with this process.
|
||||
|
||||
## Getting an SQL dump
|
||||
|
||||
By default a daily sql dump of your database is taken at 02:22 and
|
||||
saved to `/moodle/db-backup.sql`(.gz). This file can be retrieved
|
||||
using SCP or similar. For example:
|
||||
|
||||
``` bash
|
||||
scp azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP:/moodle/db-backup.sql /tmp/moodle-db-backup.sql
|
||||
```
|
||||
|
||||
To obtain a more recent SQL dump you run the commands appropriate for
|
||||
your chosen database on the Controller VM. The following sections will
|
||||
help with this task.
|
||||
|
||||
#### Postgres
|
||||
|
||||
Postgress provides a `pg_dump` command that can be used to take a
|
||||
snapshot of the database via SSH. For example, use the following
|
||||
command:
|
||||
|
||||
``` bash
|
||||
ssh azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP 'pg_dump -Fc -h $MOODLE_DATABASE_DNS -U $MOODLE_DATABASE_ADMIN_USERNAME moodle > /moodle/db-snapshot.sql'
|
||||
```
|
||||
|
||||
See the Postgres documentation for full details of the [`pg_dump`](https://www.postgresql.org/docs/9.5/static/backup-dump.html) command.
|
||||
|
||||
#### MySQL
|
||||
|
||||
MySQL provides a `mysql_dump` command that can be used to take a
|
||||
snapshot of the database via SSH. For example, use the following
|
||||
command:
|
||||
|
||||
``` bash
|
||||
ssh azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP 'mysqldump -h $mysqlIP -u ${azuremoodledbuser} -p'${moodledbpass}' --databases ${moodledbname} | gzip > /moodle/db-backup.sql.gz'
|
||||
```
|
||||
|
||||
## Backup and Recovery
|
||||
|
||||
If you have set the `azureBackupSwitch` in the input parameters to `1`
|
||||
then Azure will provide VM backups of your Gluster node. This is
|
||||
recommended as it contains both your Moodle code and your sitedata.
|
||||
Restoring a backed up VM is outside the scope of this doc, but Azure's
|
||||
documentation on Recovery Services can be found here:
|
||||
https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-first-look-arm
|
||||
|
||||
## Resizing your Database
|
||||
|
||||
Note: This process involves site downtime and should therefore only be
|
||||
carried out during a planned maintenance window.
|
||||
|
||||
At the time of writing Azure does not support resizing MySQL or
|
||||
Postgres databases. You can, however, create a new database instance,
|
||||
with a different size, and change your config to point to that. To get
|
||||
a different size database you'll need to:
|
||||
|
||||
1. [Place your Moodle site into maintenance
|
||||
mode](https://docs.moodle.org/34/en/Maintenance_mode). You can do
|
||||
this either via the web interface or the command line on the
|
||||
controller VM.
|
||||
2. Perform an SQL dump of your database. See above for more details.
|
||||
3. Create a new Azure database of the size you want inside your
|
||||
existing resource group.
|
||||
4. Using the details in your /moodle/html/moodle/config.php create a
|
||||
new user and database matching the details in config.php. Make
|
||||
sure to grant all rights on the db to the user.
|
||||
5. On the controller instance, change the db setting in
|
||||
/moodle/html/moodle/config.php to point to the new database.
|
||||
6. Take Moodle site out of maintenance mode.
|
||||
7. Once confirmed working, delete the previous database instance.
|
||||
|
||||
How long this takes depends entirely on the size of your database and
|
||||
the speed of your VM tier. It will always be a large enough window to
|
||||
make a noticeable outage.
|
||||
|
||||
## Changing the SSL cert
|
||||
|
||||
The self-signed cert generated by the template is suitable for very
|
||||
basic testing, but a public website will want a real cert. After
|
||||
purchasing a trusted certificate, it can be copied to the following
|
||||
files to be ready immediately:
|
||||
|
||||
- /moodle/certs/nginx.key: Your certificate's private key
|
||||
- /moodle/certs/nginx.crt: Your combined signed certificate and trust chain certificate(s).
|
||||
|
||||
## Managing Azure DDoS protection
|
||||
|
||||
By default, every plublic IP is protected by Azure DDoS protection Basic SKU.
|
||||
You can find more information about Azure DDoS protection Basic SKU [here](https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview).
|
||||
|
||||
If you want more protection, you can activate Azure DDoS protection Standard SKU by setting
|
||||
the ddosSwith to true. You can find how to work with Azure DDoS
|
||||
protection plan [here](https://docs.microsoft.com/en-us/azure/virtual-network/manage-ddos-protection#work-with-ddos-protection-plans).
|
||||
|
||||
If you want to disable the Azure DDoS protection, you can follow the instruction
|
||||
[here](https://docs.microsoft.com/en-us/azure/virtual-network/manage-ddos-protection#disable-ddos-for-a-virtual-network).
|
||||
|
||||
Be careful, disabling the Azure DDoS protection on your vnet will not stop the fee.
|
||||
You have to delete the Azure DDoS protection plan if you want to stop the fee.
|
||||
|
||||
If you have deployed your cluster without Azure DDoS protection plan, you still can activate the
|
||||
Azure DDoS protection plan thanks to the instruction [here](https://docs.microsoft.com/en-us/azure/virtual-network/manage-ddos-protection#enable-ddos-for-an-existing-virtual-network).
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. [Retrieve configuration details using CLI](./Get-Install-Data.md)
|
||||
|
|
@ -1,762 +0,0 @@
|
|||
# Moodle on Azure Parameters
|
||||
|
||||
Our goal with these templates is to make it as easy as possible to
|
||||
deploy a Moodle on Azure cluster that can be customized to your
|
||||
specific needs. To that end we provide a great manay configuration
|
||||
options. This document attempts to document all these parameters,
|
||||
however, like all documentation it can sometimes fall behind. For a
|
||||
canonical reference you should review the `azuredeploy.json` file.
|
||||
|
||||
## Extracting documentation from azuredeploy.json
|
||||
|
||||
To make it a litte easier to read `azuredeploy.json` you might want to
|
||||
run the following commands which will extract the necessary
|
||||
information and display it in a more readable form.
|
||||
|
||||
```bash
|
||||
sudp apt install jq
|
||||
```
|
||||
|
||||
``` bash
|
||||
jq -r '.parameters | to_entries[] | "### " + .key + "\n\n" + .value.metadata.description + "\n\nType: " + .value.type + "\n\nPossible Values: " + (.value.allowedValues | @text) + "\n\nDefault: " + (.value.defaultValue | @text) + "\n\n"' azuredeploy.json
|
||||
```
|
||||
|
||||
## Available Parameters
|
||||
|
||||
### _artifactsLocation
|
||||
|
||||
The base URI where artifacts required by this template are located. When the template is deployed using the accompanying scripts, a private location in the subscription will be used and this value will be automatically generated.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: https://raw.githubusercontent.com/Azure/Moodle/master/
|
||||
|
||||
|
||||
### _artifactsLocationSasToken
|
||||
|
||||
The sasToken required to access _artifactsLocation. When the template is deployed using the accompanying scripts, a sasToken will be automatically generated.
|
||||
|
||||
Type: securestring
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### applyScriptsSwitch
|
||||
|
||||
Switch to process or bypass all scripts/extensions
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: true
|
||||
|
||||
|
||||
### azureBackupSwitch
|
||||
|
||||
Switch to configure AzureBackup and enlist VM's
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### redisDeploySwitch
|
||||
|
||||
Switch to deploy a redis cache or not. Note that certain versions of Moodle (e.g., 3.1) don't work well with Redis, so use this only for known well-working Moodle versions (e.g., 3.4).
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### vnetGwDeploySwitch
|
||||
|
||||
Switch to deploy a virtual network gateway or not
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### installObjectFsSwitch
|
||||
|
||||
Switch to install Moodle Object FS plugins (with Azure Blob storage)
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### installO365pluginsSwitch
|
||||
|
||||
Switch to install Moodle Office 365 plugins. As of May 22, 2018, O365 plugins for Moodle 3.5 haven't been released, so to set this true, you must set the moodleVersion to 3.4 or below.
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### installGdprPluginsSwitch
|
||||
|
||||
(Should be used only for Moodle 3.4 & 3.3) Switch to install Moodle GDPR plugins. Note these require Moodle versions 3.4.2+ or 3.3.5+ and these are included by default in Moodle 3.5. So if you choose MOODLE_35_STABLE as your moodleVersion, do not set this to true.
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### htmlLocalCopySwitch
|
||||
|
||||
Switch to create a local copy of /moodle/html or not
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: true
|
||||
|
||||
|
||||
### ddosSwitch
|
||||
|
||||
Switch to create a DDoS protection plan
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### enableAccelNwForCtlrVmSwitch
|
||||
|
||||
Switch to enable Azure Accelerated Networking on the controller VM. Default to false because currently the default controller VM SKU (D1) doesn't support AN. Change this to true if you set the controller VM SKU to eligibible ones (e.g., D2) for better performance.
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: false
|
||||
|
||||
|
||||
### enableAccelNwForOtherVmsSwitch
|
||||
|
||||
Switch to enable Azure Accelerated Networking on all other VMs. Default to true because currently the default controller VM SKU for all other VMS (D2) does support AN. Change this to false if you set the SKU of any other VMs to an ineligibible one (e.g., D1) to avoid deployment failure.
|
||||
|
||||
Type: bool
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: true
|
||||
|
||||
|
||||
### httpsTermination
|
||||
|
||||
Indicates where https termination occurs. 'VMSS' is for https termination at the VMSS instance VMs (using nginx https proxy). 'AppGw' is for https termination with an Azure Application Gateway. When selecting this, you need to specify all appGw* parameters. 'None' is for testing only with no https. 'None' may not be used with a separately configured https termination layer. If you want to use the 'None' option with your separately configured https termination layer, you'll need to update your Moodle config.php manually for $cfg->wwwroot and $cfg->sslproxy.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["VMSS","AppGw","None"]
|
||||
|
||||
Default: VMSS
|
||||
|
||||
|
||||
### siteURL
|
||||
|
||||
URL for Moodle site
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: www.example.org
|
||||
|
||||
|
||||
### moodleVersion
|
||||
|
||||
The Moodle version you want to install.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["MOODLE_35_STABLE","MOODLE_34_STABLE","v3.4.3","v3.4.2","v3.4.1","MOODLE_33_STABLE","MOODLE_32_STABLE","MOODLE_31_STABLE","MOODLE_30_STABLE","MOODLE_29_STABLE"]
|
||||
|
||||
Default: MOODLE_35_STABLE
|
||||
|
||||
|
||||
### sshPublicKey
|
||||
|
||||
ssh public key
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: null
|
||||
|
||||
|
||||
### sshUsername
|
||||
|
||||
ssh user name
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: azureadmin
|
||||
|
||||
|
||||
### controllerVmSku
|
||||
|
||||
VM size for the controller VM
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: Standard_DS1_v2
|
||||
|
||||
|
||||
### webServerType
|
||||
|
||||
Web server type
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["apache","nginx"]
|
||||
|
||||
Default: apache
|
||||
|
||||
|
||||
### autoscaleVmSku
|
||||
|
||||
VM size for autoscaled web VMs
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: Standard_DS2_v2
|
||||
|
||||
|
||||
### autoscaleVmCountMax
|
||||
|
||||
Maximum number of autoscaled web VMs
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 10
|
||||
|
||||
|
||||
### autoscaleVmCountMin
|
||||
|
||||
Minimum (also initial) number of autoscaled web VMs
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 1
|
||||
|
||||
|
||||
### osDiskStorageType
|
||||
|
||||
Azure storage type for all VMs' OS disks. With htmlLocalCopySwith true, Premium_LRS (SSD) is strongly recommended, as PHP files will be served from OS disks.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Premium_LRS","Standard_LRS"]
|
||||
|
||||
Default: Premium_LRS
|
||||
|
||||
|
||||
### dbServerType
|
||||
|
||||
Database type
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["postgres","mysql","mssql"]
|
||||
|
||||
Default: mysql
|
||||
|
||||
|
||||
### dbLogin
|
||||
|
||||
Database admin username
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: dbadmin
|
||||
|
||||
|
||||
### mysqlPgresVcores
|
||||
|
||||
MySql/Postgresql vCores. For Basic tier, only 1 & 2 are allowed. For GeneralPurpose tier, 2, 4, 8, 16, 32 are allowed. For MemoryOptimized, 2, 4, 8, 16 are allowed.
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: [1,2,4,8,16,32]
|
||||
|
||||
Default: 2
|
||||
|
||||
|
||||
### mysqlPgresStgSizeGB
|
||||
|
||||
MySql/Postgresql storage size in GB. Minimum 5GB, increase by 1GB, up to 1TB (1024 GB)
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 125
|
||||
|
||||
|
||||
### mysqlPgresSkuTier
|
||||
|
||||
MySql/Postgresql sku tier
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Basic","GeneralPurpose","MemoryOptimized"]
|
||||
|
||||
Default: GeneralPurpose
|
||||
|
||||
|
||||
### mysqlPgresSkuHwFamily
|
||||
|
||||
MySql/Postgresql sku hardware family. Central US is Gen4 only, so make sure to change this parameter to Gen4 if your deployment is on Central US.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Gen4","Gen5"]
|
||||
|
||||
Default: Gen5
|
||||
|
||||
|
||||
### mysqlVersion
|
||||
|
||||
Mysql version
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["5.6","5.7"]
|
||||
|
||||
Default: 5.7
|
||||
|
||||
|
||||
### postgresVersion
|
||||
|
||||
Postgresql version
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["9.5","9.6"]
|
||||
|
||||
Default: 9.6
|
||||
|
||||
|
||||
### sslEnforcement
|
||||
|
||||
MySql/Postgresql SSL connection
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Disabled","Enabled"]
|
||||
|
||||
Default: Disabled
|
||||
|
||||
|
||||
### mssqlDbServiceObjectiveName
|
||||
|
||||
MS SQL database service object names
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["S1","S2","S3","S4","S5","S6","S7","S9"]
|
||||
|
||||
Default: S1
|
||||
|
||||
|
||||
### mssqlDbSize
|
||||
|
||||
MS SQL database size
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["100MB","250MB","500MB","1GB","2GB","5GB","10GB","20GB","30GB","40GB","50GB","100GB","250GB","300GB","400GB","500GB","750GB","1024GB"]
|
||||
|
||||
Default: 250GB
|
||||
|
||||
|
||||
### mssqlDbEdition
|
||||
|
||||
MS SQL DB edition
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Basic","Standard"]
|
||||
|
||||
Default: Standard
|
||||
|
||||
|
||||
### mssqlVersion
|
||||
|
||||
Mssql version
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["12.0"]
|
||||
|
||||
Default: 12.0
|
||||
|
||||
|
||||
### fileServerType
|
||||
|
||||
File server type: GlusterFS, NFS, and NFS-HA (2-VM highly available NFS cluster)
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["gluster","nfs","nfs-ha","nfs-byo"]
|
||||
|
||||
Default: nfs
|
||||
|
||||
|
||||
### nfsByoIpExportPath
|
||||
|
||||
IP address and export path of the BYO-NFS share when fileServerType == nfs-byo. E.g., 172.16.1.8:/msazure
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### fileServerDiskSize
|
||||
|
||||
Size per disk for gluster nodes or nfs server
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 127
|
||||
|
||||
|
||||
### fileServerDiskCount
|
||||
|
||||
Number of disks in raid0 per gluster node or nfs server
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 4
|
||||
|
||||
|
||||
### fileServerVmSku
|
||||
|
||||
VM size for the gluster or NFS-HA nodes
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: Standard_DS2_v2
|
||||
|
||||
|
||||
### keyVaultResourceId
|
||||
|
||||
(VMSS https termination only) Azure Resource Manager resource ID of the Key Vault in case you stored your SSL cert in an Azure Key Vault (Note that this Key Vault must have been pre-created on the same Azure region where this template is being deployed). Leave this blank if you didn't. Resource ID example: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/xxx/providers/Microsoft.KeyVault/vaults/yyy. This value can be obtained from keyvault.sh output if you used the script to store your SSL cert in your Key Vault.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### sslCertKeyVaultURL
|
||||
|
||||
(VMSS https termination only) Azure Key Vault URL for your stored SSL cert. This value can be obtained from keyvault.sh output if you used the script to store your SSL cert in your Key Vault. This parameter is ignored if the keyVaultResourceId parameter is blank.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### sslCertThumbprint
|
||||
|
||||
(VMSS https termination only) Thumbprint of your stored SSL cert. This value can be obtained from keyvault.sh output if you used the script to store your SSL cert in your Key Vault. This parameter is ignored if the keyVaultResourceId parameter is blank.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### caCertKeyVaultURL
|
||||
|
||||
(VMSS https termination only) Azure Key Vault URL for your stored CA (Certificate Authority) cert. This value can be obtained from keyvault.sh output if you used the script to store your CA cert in your Key Vault. This parameter is ignored if the keyVaultResourceId parameter is blank.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### caCertThumbprint
|
||||
|
||||
(VMSS https termination only) Thumbprint of your stored CA cert. This value can be obtained from keyvault.sh output if you used the script to store your CA cert in your Key Vault. This parameter is ignored if the keyVaultResourceId parameter is blank.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### appGwSslCertKeyVaultResourceId
|
||||
|
||||
(App Gateway https termination only) Azure Key Vault URL for your stored SSL cert, again for App Gateway https termination case only. (Note that this Key Vault must have been pre-created on the same Azure region where this template is being deployed). Leave this blank if you didn't. Resource ID example: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/xxx/providers/Microsoft.KeyVault/vaults/yyy.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### appGwSslCertKeyVaultSecretName
|
||||
|
||||
(App Gateway https termination only) Name of the Azure Key Vault secret that's stored in the previously specified Key Vault as a PFX certificate (with no password) for your site's SSL cert. This secret must be pre-populated in the specified Key Vault with the matching name.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### appGwSkuName
|
||||
|
||||
(App Gateway https termination only) Name of the Applicate Gateway SKU
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Standard_Small","Standard_Medium","Standard_Large","WAF_Medium","WAF_Large"]
|
||||
|
||||
Default: Standard_Medium
|
||||
|
||||
|
||||
### appGwSkuTier
|
||||
|
||||
(App Gateway https termination only) Tier of the Applicate Gateway
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Standard","WAF"]
|
||||
|
||||
Default: Standard
|
||||
|
||||
|
||||
### appGwSkuCapacity
|
||||
|
||||
(App Gateway https termination only) Capacity instance count) of the Applicate Gateway
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 2
|
||||
|
||||
|
||||
### storageAccountType
|
||||
|
||||
Storage Account type. This storage account is only for the Moodle ObjectFS plugin and/or the (currently disabled) Azure Files file share option
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Standard_LRS","Standard_GRS","Standard_ZRS"]
|
||||
|
||||
Default: Standard_LRS
|
||||
|
||||
|
||||
### searchType
|
||||
|
||||
options of moodle global search
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["none","azure","elastic"]
|
||||
|
||||
Default: none
|
||||
|
||||
|
||||
### tikaService
|
||||
|
||||
options of enabling tika service for file searching in moodle
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["none","tika"]
|
||||
|
||||
Default: none
|
||||
|
||||
|
||||
### azureSearchSku
|
||||
|
||||
the search service level you want to create.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["free","basic","standard","standard2","standard3"]
|
||||
|
||||
Default: basic
|
||||
|
||||
|
||||
### azureSearchReplicaCount
|
||||
|
||||
Replicas distribute search workloads across the service. You need 2 or more to support high availability (applies to Basic and Standard only).
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 3
|
||||
|
||||
|
||||
### azureSearchPartitionCount
|
||||
|
||||
Partitions allow for scaling of document count as well as faster indexing by sharding your index over multiple Azure Search units.
|
||||
|
||||
Type: int
|
||||
|
||||
Possible Values: [1,2,3,4,6,12]
|
||||
|
||||
Default: 1
|
||||
|
||||
|
||||
### azureSearchHostingMode
|
||||
|
||||
Applicable only for azureSearchSku set to standard3. You can set this property to enable a single, high density partition that allows up to 1000 indexes, which is much higher than the maximum indexes allowed for any other azureSearchSku.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["default","highDensity"]
|
||||
|
||||
Default: default
|
||||
|
||||
|
||||
### elasticVmSku
|
||||
|
||||
VM size for the elastic search nodes
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: Standard_DS2_v2
|
||||
|
||||
|
||||
### tikaVmSku
|
||||
|
||||
VM size for the tika search nodes
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: Standard_DS2_v2
|
||||
|
||||
|
||||
### customVnetId
|
||||
|
||||
Azure Resource ID of the Azure virtual network where you want to deploy your Moodle resources. A vnet resource ID is of the following format: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx/resourceGroups/gggg/providers/Microsoft.Network/virtualNetworks/vvvv. Note that this virtual network must be on the same Azure location as this template deployment location. If this parameter is blank, a new Azure virtual network will be created and used. In that case, the address space of the newly created virtual network will be */16 of the following vNetAddressSpace parameter value below.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default:
|
||||
|
||||
|
||||
### vNetAddressSpace
|
||||
|
||||
Address range for the Moodle virtual network and various subnets - presumed /16 for a newly created vnet in case customVnetId is blank. Further subneting (a number of */24 subnets starting from the xxx.yyy.zzz.0/24 will be created on a newly created vnet or your BYO-vnet (specified in customVnetId parameter).
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: 172.31.0.0
|
||||
|
||||
|
||||
### gatewayType
|
||||
|
||||
Virtual network gateway type
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Vpn","ER"]
|
||||
|
||||
Default: Vpn
|
||||
|
||||
|
||||
### vpnType
|
||||
|
||||
Virtual network gateway vpn type
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["RouteBased","PolicyBased"]
|
||||
|
||||
Default: RouteBased
|
||||
|
||||
|
||||
### loadBalancerSku
|
||||
|
||||
Loadbalancer SKU
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: ["Basic","Standard"]
|
||||
|
||||
Default: Basic
|
||||
|
||||
|
||||
### location
|
||||
|
||||
Azure Location for all resources.
|
||||
|
||||
Type: string
|
||||
|
||||
Possible Values: null
|
||||
|
||||
Default: [resourceGroup().location]
|
||||
|
||||
|
||||
|
|
@ -1,73 +0,0 @@
|
|||
# Environment Preparation
|
||||
|
||||
This document describes how to ensure your environment is configured
|
||||
for working with Moodle on Azure.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
In order to configure our deployment and tools we'll set up some
|
||||
[environment variables](./Environment-Variables.md) to ensure consistency.
|
||||
|
||||
## Required software
|
||||
|
||||
We'll use a number of tools when working with Moodle on Azure. Let's
|
||||
ensure they are all installed:
|
||||
|
||||
``` shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install wget -y
|
||||
sudo apt-get openssh-client -y
|
||||
```
|
||||
|
||||
The [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest) is also important:
|
||||
|
||||
```bash
|
||||
AZ_REPO=$(lsb_release -cs)
|
||||
echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $AZ_REPO main" | sudo tee /etc/apt/sources.list.d/azure-cli.list
|
||||
sudo apt-key adv --keyserver packages.microsoft.com --recv-keys 52E16F86FEE04B979B07E28DB02C46DF417A0893
|
||||
sudo apt-get install apt-transport-https
|
||||
sudo apt-get update && sudo apt-get install azure-cli
|
||||
```
|
||||
|
||||
## Ensure we have a valid SSH key pair
|
||||
|
||||
We use SSH for secure communication with our hosts. The following line
|
||||
will check there is a valid SSH key available and, if not, create one.
|
||||
|
||||
```
|
||||
if [ ! -f "$MOODLE_SSH_KEY_FILENAME" ]; then ssh-keygen -t rsa -N "" -f $MOODLE_SSH_KEY_FILENAME; fi
|
||||
```
|
||||
## Checkout the Moodle ARM Template
|
||||
|
||||
The Moodle Azure Resource Manager template is hosted on GitHub. We'll
|
||||
checkout the template into our workspace.
|
||||
|
||||
```
|
||||
git clone git@github.com:Azure/Moodle.git $MOODLE_AZURE_WORKSPACE/arm_template
|
||||
```
|
||||
|
||||
# Validation
|
||||
|
||||
After completing these steps we should have, amonst other things, a
|
||||
complete checkout of the Moodle templates from GitHub:
|
||||
|
||||
``` bash
|
||||
ls $MOODLE_AZURE_WORKSPACE/arm_template
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
``` expected_similarity=0.4
|
||||
azuredeploy.json azuredeploy.parameters.json CONTRIBUTE.md docs env.json etc images LICENSE LICENSE-DOCS metadata.json nested
|
||||
README.md
|
||||
```
|
||||
|
||||
We should also have a number of applications installed, such as the Azure CLI:
|
||||
|
||||
``` bash
|
||||
if hash az 2>/dev/null; then echo "Azure CLI Installed"; else echo "Missing dependency: Azure CLI"; fi
|
||||
```
|
||||
|
||||
```
|
||||
AzureCLI Installed
|
||||
```
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
# SSL Certificate Management
|
||||
|
||||
A valid SSL (TLS) certificate should be used with your domain name for the Moodle/LAMP
|
||||
site to be deployed using the templates. By default, the templates will configure
|
||||
the HTTPS server with a self-signed SSL server certificate/private key, which can
|
||||
be manually changed with your own valid SSL server certificate/private key after
|
||||
the deployment.
|
||||
|
||||
If you'd like to configure the Moodle/LAMP cluster (to be deployed) with your own domain
|
||||
and your valid SSL server certificate/private key, then you can do so by utilizing
|
||||
[Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/) and
|
||||
configuring the related template parameters as described below. This support is
|
||||
based on [another similar work](https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-ubuntu-web-ssl)
|
||||
and adapted to our situation.
|
||||
|
||||
## Initial deployment
|
||||
|
||||
To configure the Moodle/LAMP cluster (to be deployed) with your purchased SSL certificate,
|
||||
currently the related files should be stored in an Azure Key Vault as secrets, so that
|
||||
Azure Resource Manager can reference when it deploys VMs as specified in templates.
|
||||
|
||||
You can create your own Azure Key Vault and store your purchased SSL certificate (called
|
||||
'import' in Azure Key Vault terminology) by following related documentation like
|
||||
[this](https://docs.microsoft.com/en-us/azure/key-vault/key-vault-manage-with-cli2).
|
||||
However, the related files must be stored in a specific format, so we created a
|
||||
shell script (`keyvault.sh`) that will perform all necessary steps for this purpose.
|
||||
To use this script, you'll first need to upload your SSL certificate/private key files
|
||||
(.pem) to your deployment environment you set up by following the [preparation document](Preparation.md)
|
||||
(a Linux command line). The .pem files should be as follows:
|
||||
|
||||
- `cert.pem`: The SSL certificate only in PEM format
|
||||
- `key.pem`: The private key for the SSL certificate only in PEM format
|
||||
- `chain.pem`: This is optional in case your server certificate is signed by an intermediate CA (Certificate Authority) certificate, instead of a root CA certificate. Currently only one intermediate CA certificate is supported by the script.
|
||||
|
||||
Once you updloaded the files to your deployment environment, you can run the following command
|
||||
to create an Azure Key Vault on your subscription and store your SSL certificate, private key, and optionally
|
||||
the intermediate CA certificate:
|
||||
|
||||
``` bash
|
||||
$ bash $MOODLE_AZURE_WORKSPACE/arm_template/etc/keyvault.sh <key_vault_name> <resource_group_name> <azure_region> <secret_name> cert.pem key.pem chain.pem
|
||||
```
|
||||
|
||||
Make sure to set `<azure_region>` the same as the Azure region you'll be using to deploy the Moodle template.
|
||||
Assign desired names for `<key_vault_name>`, `<resource_group_name>` (you can use an existing resource group) and `<secret_name>`.
|
||||
`<secret_name>` is not very important in our deployment. Then you'll get outputs as follows:
|
||||
|
||||
```
|
||||
...
|
||||
Specified SSL cert/key .pem files are now stored in your Azure Key Vault and ready to be used by the template.
|
||||
Use the following values for the related template parameters:
|
||||
|
||||
- keyVaultResourceId: /subscriptions/206c66fc-a48c-480d-ad06-0d429e82c586/resourceGroups/keyvault/providers/Microsoft.KeyVault/vaults/mdl-kv
|
||||
- sslCertKeyVaultURL: https://mdl-kv.vault.azure.net/secrets/mymoodlesitecert/4c88452fe72b4d469253af48348f4944
|
||||
- sslCertThumbprint: 56478E4F9555662476E2763D909F50B3DD26FF84
|
||||
- caCertKeyVaultURL: https://mdl-kv.vault.azure.net/secrets/camymoodlesitecert/684efab1f2124e71a2c809457d10808b
|
||||
- caCertThumbprint: E6A3B45B062D509B3382282D196EFE97D5956CCB
|
||||
Done
|
||||
```
|
||||
|
||||
This example outputs assumes `"keyvault"` is used for `<resource_group_name>`, `"mdl-kv"` for `<key_vault_name>`,
|
||||
and `"mymoodlesitecert"` for `<secret_name>`. Note that `caCertKeyVaultURL` and `caCertThumbprint` will be empty
|
||||
if you didn't specify `chain.pem`. Then you can copy these outputs to the template's corresponding parameters,
|
||||
and Azure Resource Manager will install the certificate and the private key on the deployed VMs and the deployed
|
||||
HTTPS server will use this certificate and private key.
|
||||
|
||||
## Certificate rotation
|
||||
|
||||
Another important benefit of using Azure Key Vault is to handle certificate expiration/rotation automatically.
|
||||
Unfortunately, the current implementation doesn't support the auto-rotation. So when it becomes near your SSL
|
||||
certificate's expiry, you'll need to manually update the deployed certificate and private key files
|
||||
(it's in `/azlamp/certs/nginx.{crt,key}` on the controller VM) and restart all the web frontend VM instances.
|
||||
We'll improve our implementation to support auto-rotation in the future.
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Test a Moodle Instance
|
||||
|
||||
## Prerequisites
|
||||
|
||||
It is obviously necessary to have a [Moodle cluster up and running](./Deploy.md).
|
||||
|
||||
## Next Steps
|
||||
|
||||
* [Delete all Resources](./Delete.md)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
{
|
||||
"MOODLE_RG_NAME": "rgmoodlearm13tagging",
|
||||
"MOODLE_RG_LOCATION": "canadacentral",
|
||||
"MOODLE_DEPLOYMENT_NAME": "MainDeployment"
|
||||
}
|
||||
Загрузка…
Ссылка в новой задаче