Azure CycleCloud is an Azure service that allows to orchestrate HPC cluster in Azure Cloud leveraging on standard HPC schedulers like Slurm, OpenPBS and many more.
Once a cluster is created through Azure CycleCloud, it will expose as a default a scheduler and eventually some login nodes where the users have the possibility to login in SSH or using standard scheduler APIs (e.g. SlurmAPI).
This project is aimed to provide an easy way to deploy a web portal improving user experience for job submission, SSH sessions and remote visualization.
The web portal in scope is the OpenSource project Open OnDemand
Azure CycleCloud provides the flexibility of defining in a modular way customized projects.
Azure CycleCloud projects are composed by three key elements:
- Cluster templates, containing the relevant parameters that the users can specify in the UI during configuration.
- Cluster-init scripts, containing a set of tasks that are executed on the node preparation
- Blobs, binaries which are usually installers on the compute nodes
Using this integration framework of Azure CycleCloud, this project contains a whole integration to deploy Open OnDemand portal automatically in Azure CycleCloud.
The project requires a working installazion of Azure CycleCloud.
At the same time, Open OnDemand portal is meant to be attached to an existing Slurm or OpenPBS cluster in this context. Further support is planned to be available in future releases.
The project has been tested on the following matrix:
| Azure CycleCloud Version | Scheduler | Scheduler Version | Azure CycleCloud Project Version |
| 8.4.1-3154 | Slurm | 22.05.9 / 23.02.05 | 3.0.4 |
| 8.4.1-3154 | OpenPBS | 18.1.4 / 20.0.1 / 22.05.11 | 2.0.19 |
| 8.5.0-3196 | Slurm | 22.05.10 / 23.02.06 | 3.0.5 |
| 8.5.0-3196 | OpenPBS | 18.1.4 / 20.0.1 / 22.05.11 | 2.0.20 |
| 8.6.1-3248 | Slurm | 22.05.11 / 23.02.07 | 3.0.6 |
| 8.6.1-3248 | OpenPBS | 18.1.4 / 20.0.1 / 22.05.11 | 2.0.21 |
In order to store the secrets involved in OnDemand Portal configuration, an Azure Key Vault will be required to be configured. This Azure Key Vault will be accessed during configuration through a managed identity.
The use of Basic Authentication and the use of self-signed certificate option should be considered only in non-production environment because of the related security concerns.
- In order to leverage OIDC authentication, you can check the guide about creating an app registration in Entra ID
- In order to use OIDC LDAP Dex, it is important that the account in use as the least priviledge on Active Directory, like read only account and all security policies for service accounts. This account only needs permission to read and perform LDAP queries.
To create a Managed Identity for Azure OnDemand portal project, just run the following command in an Azure Cloud Shell or an Azure CLI enabled terminal (the Managed Identity can also be created by Azure Portal or by any other method):
az identity create --name MyIdentity --resource-group MyResourceGroupwhere MyIdentity and MyResourceGroup are respectively the identity name and the resource group where this should be placed. Azure CycleCloud VM should have access to this resource group with the identity used to interact with Azure Subscription.
It is important to assign the Key Vault Secrets User to this Managed Identity on the Azure Key Vault that will be used to store the portal secrets.
Secrets and certificates can be uploaded from the commandline directly or using Azure Portal.
The secrets / certificates name should then be used in the configuration of the project.
The preferred format for this project to store in the Azure Key Vault the certificate for SSL termination of the OnDemand portal is pfx.
In case you have already a certificate with a separate private key file and certificate file, you can convert this to pfx with:
openssl pkcs12 -export -out on-demand.pfx -inkey <private_key_name>.key -in <certificate_name>.crt
In case of intermediate certificates, you can create a bundle before exporting to pfx:
cat <certificate_name>.crt root_ca.crt >> on-demand.crt
openssl pkcs12 -export -out on-demand.pfx -inkey <private_key_name>.key -in on-demand.crt
This certificate can then be imported from commandline directly.
The Root CA is supposed to be stored as an Azure Secret using the following CLI commands from an az login instance:
az keyvault secret set --vault-name <NAME OF THE KEY VAULT> --name <TARGET_SECRET_NAME> -f <LDAP_CA_FILE>.crt
The secrets for OIDC Client or for LDAP Bind Password should be stored as secret in the Azure KeyVault. Fasted way is to use Azure Portal.
In order to import the project in the current Azure CycleCloud instance, two steps will be required:
- Importing the cluster template
- Adding the reference to the cluster-init specs in Azure CycleCloud configuration
The prerequisite to import the project in an existing Azure CycleCloud instance is to have an Azure CycleCloud CLI. This can be also the Azure CycleCloud VM itself with an SSH access.
git clone https://github.com/wolfgang-desalvador/cyclecloud-ondemand.git
cd cyclecloud-ondemand
git checkout 0.1.4
cyclecloud import_template -f templates/ondemand.txtThere are two options to achieve this:
- Through Azure CycleCloud Web UI
- Importing the configuration through a text file placed in Azure CycleCloud installation directories
In order to import the cluster-init specs through the UI, it is sufficient to go to Settings > Records > CycleCloud > Cluster-Init Projects and to create a new project definition as displayed in the following pictures.
The URL for the project is https://github.com/wolfgang-desalvador/cyclecloud-ondemand/releases/0.1.4
It is possible to do the same operation from commandline on the Azure CycleCloud VM.
First of asll let's elevate the permission as root on the VM
sudo suThen, let's insert the following content into a file named /opt/cycle_server/config/data/ondemand.txt:
AdType = "Cloud.Project"
Version = "0.1.4"
ProjectType = "Application"
Url = "https://github.com/wolfgang-desalvador/cyclecloud-ondemand/releases/0.1.4"
AutoUpgrade = false
Name = "ondemand"If import has been successful, after a few seconds the template name should change with the “imported” extension attached:
ls /opt/cycle_server/config/data/
marketplace_site_id.txt.imported ondemand.txt.imported settings.txt.imported theme.txt.importedAfter having completed the steps mentioned above, the option to create the OnDemand Portal will appear inside the available cluster types.
Clicking on the project, the wizared for the creation will start:
The configuration wizard allows to configure the different aspects of the OnDemand portal instance, more specifically:
- Volume mounts
- Authentication
- SSL Termination
- Scheduler integration and OS configuration
- Networking
Let's describe the details of the different sections in order.
This section will be used to define the name of the cluster, also the terms and conditions are defined here below.
In the required settings, the following properties can be configured:
| Property Name | Description |
| Region | The region in which the node should be deployed |
| Server VM Type | The SKU type to be used for the server |
| Subnet ID | The Subnet where the portal should be attached to. Be aware that this subnet will need to be able to communicate with the scheduler head node meant to be integrated on the dedicated scheduler ports |
In the Network Attached Storage, the configuration of the cluster shared storage for home and applications (/shared), as well as for scheduler configuration (/sched).
| Property Name | Description |
| Scheduler mount | Allows to define the IP Address, export point (on the NFS Server side) and the NFS Mount Options for /sched volume. It will mount this on the server on the /sched mount point |
| Shared mount | Allows to define the IP Address, export point (on the NFS Server side) and the NFS Mount Options for /shared volume. It will mount this on the server on the /shared mount point |
| Additional NFS Mount | Allows to define the IP Address, export point (on the NFS Server side), the NFS Mount Options for an additional volume. |
| Property Name | Description |
| Portal IP | The IP address to be assigned to the portal NIC. This should be available in the designated Subnet |
| Server name | This should be the FQDN through which the portal will be reached out. All the server endpoints will rely on this. This is important for SSL authentication. In case you are opting for a self-signed SSL certificate (insecure) you can set this equal to the Portal IP. |
| Extra configuration | This will be directly appended to the OnDemand configuration YAML. Refer to the official documentation |
| MSI Identity | This allows to select a Managed Identity to be assigned to the OnDemand portal. This is used by the portal to interact with Secrets in a dedicated Key Vault (the MSI should be assigned the Key Vault Secret Users). It is required in case authent |
| Vault Name | This is the Vault Name that will be used to store the secrets required by OnDemand portal. The server will access them thanks to the MSI identity defined above. |
| Authentication | In this sector, the authentication configuration will be defined. The options are Basic (not suggested and insecure), OIDC Dex, OIDC AD. For more details refer to OnDemand documentation |
| SSL | This can be a self-signed certificate (it will be presented as insecure by the browser) generated automatically by the configuration scripts during installation (according to the Server Name specified), or a signed certificate in the Azure Key Vault that can be referenced as name. |
| Property Name | Description |
| Scheduler type | It can be OpenPBS or Slurm |
| Scheduler host | The IP Address of the scheduler with whom the OnDemand portal should be integrated |
| Scheduler version | Version of the scheduler according to the compatibility matrix described above. |
| Property Name | Description |
| Credentials | Account to be used to deploy resources as configured in Azure CycleCloud Subscriptions. |
| Portal OS | The OS system to be used in the portal |
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.