Skip to content

Latest commit

 

History

History
100 lines (79 loc) · 3.17 KB

CLOUD.md

File metadata and controls

100 lines (79 loc) · 3.17 KB

Cloud Providers

Azure

Setup

Azure Cloud should be pre-configured for yascheduler.

It is recommended to use Azure CLI. Configure it beforehand.

Run command and write down subscriptionId to the config file.

az account subscription list

Create a dedicated Resource Group. See documentation. For example, consider yascheduler-rg in westeurope location. Save the resource group and location to the cloud config.

az group create -l westeurope -g yascheduler-rg

Create a dedicated Enterprise Application for service. See documentation. Save appId as az_client_id to the cloud config.

az ad app create --display-name yascheduler

Assign roles Network Contributor and Virtual Machine Contributor in the Resource Group. Use the correct appId:

az role assignment create \
    --assignee 00000000-0000-0000-0000-000000000000 \
    --resource-group yascheduler-rg \
    --role "Network Contributor"
az role assignment create \
    --assignee 00000000-0000-0000-0000-000000000000 \
    --resource-group yascheduler-rg \
    --role "Virtual Machine Contributor"

Create an Application Registration. Add the Client Secret to this Application Registration. Use the correct appId:

az ad app credential reset --id 00000000-0000-0000-0000-000000000000 --append

Use tenant as the az_tenant_id and password as the az_client_secret cloud settings.

Create virtual networks:

az network nsg create \
    -g yascheduler-rg -l westeurope \
    -n yascheduler-nsg
az network nsg rule create \
    -g yascheduler-rg --nsg-name yascheduler-nsg \
    --name allow-ssh-rdp --priority 100 \
    --source-address-prefixes '*' \
    --destination-port-ranges 22 3389 \
    --protocol TCP --access Allow
az network vnet create \
    -g yascheduler-rg -l westeurope --nsg yascheduler-nsg \
    --name yascheduler-vnet --address-prefix 10.0.0.0/16 \
    --subnet-name yascheduler-subnet \
    --subnet-prefix 10.0.0.0/22

According to our experience, while creating the nodes, the Azure allocates the new public IP-addresses slowly and unwillingly, so we support the internal IP-addresses only. This is no problem, if yascheduler is installed in the internal network. If this is not the case, one has to setup a jump host, allowing connections from the outside:

az vm create \
    -g yascheduler-rg -l westeurope \
    --name yascheduler-jump-host \
    --image Debian11 \
    --size Standard_B1s \
    --nsg yascheduler-nsg \
    --public-ip-address yascheduler-jump-host-ip \
    --public-ip-address-allocation static \
    --public-ip-sku Standard \
    --vnet-name yascheduler-vnet \
    --subnet yascheduler-subnet \
    --admin-username yascheduler \
    --ssh-key-values "$(ssh-keygen -y -f path/to/private/key)"

Save the publicIpAddress as az_jump_host, and az_jump_user will be yascheduler.