A Web App front end for Azure Automation Runbooks. Use this project as a starting point for developing custom interfaces to trigger automation tasks. Based on the Azure Static Web Apps (SWA) Free plan.
Steps to create the example application.
-
Fork this repository in Github. It can be made private if wanted.
-
Create a Resource Group in Azure as a target for the ARM template deployment. These steps use a group named
automation-gui-example
. -
Assign a Managed Identity permissions to create an App Registration with the following steps. This is used by the ARM template during deployment.
- Open a PowerShell Cloud Shell session and run the commands below to create the Managed Identity in the Resource Group.
$ResourceGroup = Get-AzResourceGroup -Name 'automation-gui-example' $Identity = New-AzUserAssignedIdentity -Name 'automation-gui-deploy-identity' -ResourceGroupName 'automation-gui-example' -Location $ResourceGroup.Location
Note If the error "The subscription is not registered to use namespace 'Microsoft.ManagedIdentity'" is raised the "Microsoft.ManagedIdentity" provider will need to be registered under Subscriptions > Resource providers.
- Wait for the identity to appear in the portal (click refresh to check), then run the commands below in the same Cloud Shell session. There should be no errors raised.
Connect-AzureAD $ManagedSp = Get-AzADServicePrincipal -Filter "displayName eq '$($Identity.Name)'" $GraphSp = Get-AzADServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" $Permissions = @('Application.ReadWrite.OwnedBy', 'Directory.Read.All') $AppRoles = $GraphSp.AppRole | ?{($_.Value -in $Permissions) -and ($_.AllowedMemberType -contains 'Application')} $AppRoles | %{New-AzureAdServiceAppRoleAssignment -ObjectId $ManagedSp.Id -PrincipalId $ManagedSp.Id -ResourceId $GraphSp.Id -Id $_.Id}
-
Click the deploy to Azure button to start a Custom Deployment in Azure. The Resource Group created previously should be the target of the deployment.
-
Once the resources are deployed successfully follow the steps to deploy the app with Github Actions.
Default values are assigned for most of the template parameters. The default values can be changed if wanted; except that the "Deployment Script Identity Name" must match the name given to the New-AzUserAssignedIdentity
command in step 3, and the "Automation Webhook Expiry Time" must be an expression that sets a date in the future (1 year using the default).
- In Azure navigate to the Static Web App resource, click on "Manage Deployment Token" and copy it.
- In Github access the settings of the forked repository, navigate to Secrets and Variables > Actions. Create a new Repository Secret named
AZURE_STATIC_WEB_APPS_API_TOKEN
and set the value to the token copied in step 1. - Still in Github click on
staticwebapp.config.json
in the root of the repository and use the "Edit this file" option to open the editor. - The
allowedRoles
property is an empty array. Add eitheranonymous
orauthenticated
to the array,authenticated
will enable Azure AD authentication,anonymous
allows unauthenticated access. For example:"allowedRoles": ["anonymous"]
. See the section on Invitations for restricting access to approved users only. - Click "Commit changes..", use the "Commit directly to the
master
branch" option. Github appears to treat this commit as a push, so it should trigger the Action to build and deploy the Static Web App. - After the Action has completed the visit the site at the unique domain name Azure assigns. This can be found in the Static Web App resource overview.
Note When authentication is used the Static Web App resource will request consent to access basic AAD account details, the data can be removed with this process.
Hybrid jobs can run on an Azure VM, or on an externally hosted server when it is connected using Azure Arc. This is one method to access services or data not managed by Azure.
The example creates a local Windows user account and syncs the local group names to an Azure Table so the "User Groups" drop-down list component can be populated. A Windows based Hybrid Worker is required to execute the jobs.
- If using an external server follow the instructions to add a server to Azure Arc. This can be skipped for Azure hosted VMs.
- Configure the server as a Hybrid Worker by adding it to a Hybrid Worker group. A group named
automation-gui-example-[suffix]
is already present in the Automation Account. - Start the Runbook named
automation-gui-example-sync
. Provide the name of the Resource Group and the Storage Account as parameters, and run it on the Hybrid Worker. Check the job status to ensure it ran successfully. - Refresh the site to pickup the change, now the "Hybrid Runbook" option on the site can be used and should create a local user.
The following steps will remove the resources and allow the template to be re-deployed.
- Remove the Hybrid Worker from the group if one was used, this will make sure the extension is uninstalled correctly.
- Delete all the resources except for the Managed Identity (
automation-gui-deploy-identity
). - Remove the
Reader
andReader and Data Access
role assignments under "Access control" on the Resource Group. - Delete the App Registration.
- The template can now be deployed to the same Resource Group again.
With the Free plan authenticated access is managed by Roles and Invitations. For example, in staticwebapp.config.json
configure the allowedRoles
property with a custom role as follows:
"allowedRoles": ["invited"]
Now for a user to access the site they must first be provided an invitation link that assigns the "invited" role.
Steps to setup a basic development environment on Linux (tested with Fedora). Vue.js and Vuetify are used to build the SWA, the Azure Functions API uses Python.
Windows is not covered here, however after the prerequisites are installed the setup should be similar.
Node.js, npm, Python 3.9 and Podman (or Docker) are required. For example:
sudo dnf install npm python3.9 podman
-
Make a local clone (
git clone
) of the forked repository created in the deployment steps. -
cd
to theaz-automation-gui-example
directory. -
Run
npm install
to install the Node.js package dependencies. -
Run
python3.9 -m venv api/.venv
to create a Python virtual environment (venv) for the Azure Functions API. -
Activate the venv with
source api/.venv/bin/activate
. -
Run
pip install -r api/requirements.txt
to install the Python package dependencies. -
Use the container option to run the Azurite storage emulator, and set a folder with
-v
to save the Azurite data into. For example:podman pull mcr.microsoft.com/azure-storage/azurite podman run -p 10000:10000 -p 10001:10001 -p 10002:10002 -v /my/data/path/here:/data:z mcr.microsoft.com/azure-storage/azurite
The
:z
suffix in the volume path correctly labels the mount point when using SELinux and avoids permission errors. -
Create a development config for the Azure Function API at
api/local.settings.json
. The file should include the following contents, with any empty/example values replaced. For reference, the live version of these settings are stored by the Static Web App at Configuration > Application Settings.{ "IsEncrypted": false, "Values": { "FUNCTIONS_WORKER_RUNTIME": "python", "AZURE_SUBSCRIPTION_ID": "", "AZURE_TENANT_ID": "", "AZURE_CLIENT_ID": "", "AZURE_CLIENT_SECRET": "", "AUTOMATION_GROUP_NAME": "my-resource-group-name", "AUTOMATION_ACCOUNT_NAME": "my-automation-account-name", "WEBHOOK_RUNBOOK": "https://my-webhook-url.example.com", "WEBHOOK_HYBRID": "https://my-webhook-url.example.com", "STORAGE_CONNECTION_STRING": "UseDevelopmentStorage=true" } }
The SWA CLI tool is used to emulate the Static Web App locally. This automatically uses the Azure Functions Core Tools to emulate Functions.
npx swa start http://localhost:5173 --run "npm run dev" --api-location api
runs the SWA directly from the Vite development server (Vite uses port5173
by default). Use this to get the Vue.js hot reload feature to work.npx swa build az-automation-gui
builds/bundles all the source files.npx swa start ./dist --api-location api
starts the SWA emulator using the bundled files in./dist
.- Ensure the Python "venv" is active when running the emulator so the correct python version and packages are available.
With either method the emulated SWA site will be available at http://localhost:4280
.
Azure Storage Explorer can connect to an emulated storage account. There a "Local storage emulator" option when adding an account. The well-known storage account and key are used to authenticate.
Using Storage Explorer any test data required can be populated.