Create Azure Site

Objective

This guide provides instructions on how to create a site using F5® Distributed Cloud Console (Console) and deploy to Azure Virtual Network (VNet). For more information, see F5 Distributed Cloud Site.

You can deploy an F5® Distributed Cloud Services Site to VNet using one of the following methods:

• Deploy using Console

• Deploy using Azure Marketplace

• Deploy using Terraform

Using the instructions provided in this guide, you can deploy an ingress gateway site or ingress/egress gateway site. For more information, see Network Topology of a Site.

Design

The Azure VNet Site automates the deployment of sites in Azure. As part of the Azure VNet Site configuration, you can indicate that new VNet, subnets, and route tables need to be created. You also can choose to provide an existing VNet. The subnet information, creation of the VNet, and subnet resources will be skipped.

Note: By default, a Site deployed in Azure supports Azure Disk Storage. You can configure storage within the Site creation form or using a Fleet. This document provides steps to configure storage using the Site configuration form. See Configure Storage in Fleet document for more information on using the Fleet method.

Azure VNet Site Deployment Types

A site can be deployed in two different modes with the Azure VNet site workflow.

1. Ingress Gateway (One Interface): In this deployment mode, the site is attached to a single VNet and single Subnet. It can provide discovery of services and endpoints reachable from this subnet to any other site configured in the Distributed Cloud Services tenant.

2. Ingress/Egress Gateway (Two Interfaces): In this deployment mode, the site is attached to a single VNet with at least two interfaces on different subnets. In this mode, the site provides security and connectivity needs for virtual machines and subnets via a default gateway through the Site Inside interface. One subnet is labeled Outside and the other is labeled Inside. This VNet can be configured in one of these two modes: Standalone VNet or Hub VNet.

Ingress Gateway (One Interface)

In this deployment mode, F5® Distributed Cloud Mesh (Mesh) needs one interface attached. Services running on the node connect to the Internet using this interface. Also, this interface is used to discover other services and virtual machines and expose them to other sites in the same tenant. For example, in the below figure, TCP or HTTP services on the DevOps or Dev Azure VM instances can be discovered and exposed via reverse proxy remotely.

As shown in the below figure, the interface is on the Outside subnet which is associated with the VNet main routing table, whose default route is pointing to the Internet gateway. That is how traffic coming from the outside interface can reach the Internet, along with other subnets associated with this routing-table object. In case of other subnets (for example, Dev and DevOps), these are associated with the VNet main routing table, which means that any newly created subnet in this VNet is automatically associated with this routing table.

Ingress/Egress Gateway (Two Interfaces)

In this deployment scenario, the Mesh nodes need two interfaces attached. The first interface is the outside interface through which services running on the node can connect to the Internet. The second interface is the inside interface which will become the default gateway IP address for all the application workloads and services present in the private subnets. There are two modes supported in this model: Standalone VNet and Hub VNet.

Standalone VNet

As a Standalone VNet, the application workloads are on private subnets, and they connect to Internet endpoints through Mesh instances, which have two legs: one on the outside network and another on the inside network.

As shown in the below figure, the outside interface is on the outside subnet which is associated with the outside subnet route table, whose default route is pointing to the Internet gateway. This interface can send and receive traffic from the Internet. In case of inside subnets, these are associated with the inside subnet route table which is also the main route table for this VNet, meaning that any newly created subnet in this VNet is automatically associated with the inside subnet route table. This private subnet route table has a default route pointing to the inside IP address of the Mesh node (192.168.0.186).

Once the Mesh site comes online, the inside network of the node will be connected to the outside network through a forward proxy and SNAT enabled on the outside interface. All traffic destined to Internet endpoints that is coming on the inside interface will be forwarded to the Internet over the forward proxy and SNAT happening on the outside interface. Now all the workloads on the private workload subnet can reach the Internet through Mesh site.

Hub VNet

As a Hub VNet, application workloads are on one or more Spoke VNets, and they connect to this Hub VNet using VNet (Virtual Network) Peering. This Hub VNet has Distributed Cloud Services Mesh deployed, making it the central point of networking and security control for all the spoke VNets peered to it.

Currently, only the Virtual network peering is supported with the current release. This network connects virtual networks within the same Azure region. Only intra-region Spoke VNet peering is supported with the current release.

For more information, see Azure Virtual network peering.

As shown in the figure below, the Hub VNet has Distributed Cloud Services Mesh deployed along with Azure Load Balancer resource on the inside subnet. This Hub VNet can now be the ingress/egress gateway for all the Spoke VNets that have peered with this Hub VNet. This Hub VNet has internal load balancer (Azure LoadBalancer), which the Spoke VNets use as the next hop to route traffic to the Hub VNet. To connect the Spoke VNets to the Hub VNet, there are two options: Auto routing and manual routing. With auto routing, a default route pointing to Hub VNet is created for Spoke VNets. While with manual routing, you can manually configure route prefixes that need to be routed to the Hub VNet, directly on Azure. If the spoke VNet configuration has no custom route, then you can manage it through the Auto Routing option. If the spoke VNet has a custom route, then you can manage it through the Manual Routing option.

All traffic destined to Internet endpoints that are coming on the inside interface of the Hub VNet will be forwarded to the Internet over the forward proxy and SNAT happening on the outside interface. Now the workloads on Spoke VNets can reach the Internet through the Hub VNet, which is the central point of network and security control.

Note: Currently, one Hub VNet can peer with up to 100 Spoke VNets. Based on the number of Spoke VNets peered, the time taken to deploy such a site can increase up to 90 minutes.

ExpressRoute

ExpressRoute enables you to extend your on-premises infrastructure or co-located environments to Azure datacenters using a private connection that does not use the public Internet. ExpressRoute requires a connectivity provider, in this case F5 Distributed Cloud Services, to provide the backbone for all connections. The benefits of this include low latency, reduced costs, and high reliability when transferring data between your sites and the Azure private network. For more information, see the official product overview.

ExpressRoute uses BGP to exchange routes between your on-premises networks, your instances on Azure, and Microsoft public IP addresses. The connections to the Azure private network can be established using the peering locations and access regions within a geopolitical region. For example, if you have a Hub Site in North America, then you can connect to Azure in North America with ExpressRoute. This will give you access to all Azure cloud services hosted in North America.

ExpressRoute can only be used if deploying a site with the Ingress/Egress Gateway (Two Interfaces) option.

Four main components are required to use ExpressRoute:

• Route Server: This is to dynamically exchange routes between the Customer Edge site and Azure using BGP. This connection is created inside the Hub VNet during initial configuration in Console.

• Virtual Network Gateway: Only one is required per VNet. Microsoft provides different SKUs each with different CPU and bandwidth options. This network gateway is created inside the Hub VNet during initial configuration in Console.

• ExpressRoute Circuit: This is a logical connection between an Azure Site and your on-premise datacenter or other co-located environments.

• ExpressRoute Circuit Connection: This logical connection is established between the Virtual Network Gateway and ExpressRoute Circuit.

Network Policies

Distribute Cloud Services Mesh can be your ingress/egress security policy enforcement point, as all the traffic coming from private subnets will flow through the site. If the traffic does not match the type defined in network policy, then the default action will be to deny it.

You can define which endpoint/subnet by using the network policy. You can define the egress policy by adding the egress rules from the point of endpoint to deny/allow specific traffic patterns based on intent, and you can also add ingress rules to deny/allow traffic coming toward the endpoint.

Forward Proxy Policy

Using a forward proxy policy, you can specify allowed/denied TLS domains or HTTP URLs. The traffic from workloads on private subnets toward the Internet via the Azure VNet site is allowed or denied accordingly.

More details on how to configure this is captured in the rest of this documentation.

Prerequisites

The following prerequisites apply:

• A Distributed Cloud Services Account. If you do not have an account, see Create an Account.

• A Microsoft Azure Account. See Required Access Policies for permissions needed.

• Resources required per node: Minimum 4 vCPUs and 14 GB RAM.

• UDP port 6080 needs to be opened between all the nodes of the site.

Deploy Using Console

The following video shows the Azure VNET site deployment workflow using Console:

The Azure VNet site object creation and management process involves the following:

Accept Subscription Agreement

Prior to beginning the site deployment process you must accept the Azure subscription agreement.

• Select the correct subscription:

az account set -s <subscription-id>

• For ingress gateway site:

az vm image terms accept --publisher volterraedgeservices --offer volterra-node --plan volterra-node

• For ingress/egress gateway site:

az vm image terms accept --publisher volterraedgeservices --offer entcloud_voltmesh_voltstack_node --plan freeplan_entcloud_voltmesh_voltstack_node_multinic

• For F5® Distributed Cloud App Stack site:

az vm image terms accept --publisher volterraedgeservices --offer entcloud_voltmesh_voltstack_node --plan freeplan_entcloud_voltmesh_voltstack_node

Create Azure VNet Site Object

Sites can be viewed and managed in multiple services: Multi-Cloud Network Connect, Distributed Apps, and Multi-Cloud App Connect.

Step 1: Log into Console and start Azure VNet site object creation.

• From the Console homepage, select Multi-Cloud Network Connect.

Note: The homepage is role based, and your homepage may look different due to your role customization. Select the All Services drop-down menu to discover all options.

• Select Manage > Site Management.

Note: If options are not showing available, select Show link in Advanced nav options visible in bottom left corner. If needed, select Hide to minimize options from Advanced nav options mode.

• Select Azure VNET Sites.

• Select Add Azure VNET Site.

• In the Metadata section, enter a name and optionally select a label and add a description, as needed.

Step 2: Configure site settings and VNet.

• In the Site Type Selection section, perform the following:

Step 2.1: Set region and configure VNet.

• Enter your Azure resource group in the Resource Group field. Ensure that you enter a name for a non-existent resource group.

• Select a region type from the Select Azure Region Type menu. The Recommended Azure Region Name option is selected by default. You can change it by selecting the Alternate Azure Region Name option.

Note: The Recommended Azure Region Name option is where Azure provides at least three availability zones. The Alternate Azure Region Name option does not have three availability zones. For more information, see Regions and availability zones.

• Select a region from the Recommended Azure Region Name or Alternate Azure Region Name menu per your choice of the Azure region type.

• From the Vnet menu, select an option:

  • New Vnet Parameters: Select Autogenerate Vnet Name or Choose Vnet Name from the Azure Vnet Name menu. If you choose a VNet name, enter the name in the Choose Vnet Name box. Enter the CIDR in the IPv4 CIDR block field.

  • Existing Vnet: Enter an existing resource group name and VNet name in the Existing Vnet Resource Group and Existing Vnet Name fields.

• In the IPv4 CIDR block field, enter a value.

Step 2.2: Configure the ingress or ingress/egress gateways.

From the Select Ingress Gateway or Ingress/Egress Gateway menu, select an option per the configured Azure region type from above. For example, if you selected the region type as Alternate Azure Region Name and want to configure ingress gateway node, select the Ingress Gateway (One Interface) on Alternate Region option.

Configure Ingress Gateway for One Interface

• If you selected Ingress Gateway (One Interface) on Recommended Region, performing the following:

  • Select Configure.

  • Under the Ingress Gateway (One Interface) Nodes in AZ section, click Add Item and perform the following:

  • From the Azure AZ name menu, select an option to set the number of availability zones.

Note: If you selected the Ingress Gateway (One Interface) on Alternate Region option, you need to set the number of main nodes from the Number of main nodes menu.

• From the Subnet for local interface menu, select New Subnet or Existing Subnet.

• For the New Subnet option, enter the subnet address in the IPv4 Subnet field.

• For the Existing Subnet option, enter it in the Subnet Name field, and select an option from the Subnet Resource Group menu. Use the Vnet Resource Group option to use the same resource group as that of the VNet, or select Resource Group Name and enter a name in the enabled Resource Group Name field.

• Select Add Item.

Note: You can add more than one ingress gateway using the Add Item option. The Azure Certified Hardware option is set to azure-byol-voltmesh by default.

• Optionally, configure more settings in the Advanced Options section:

  • From the Select Performance Mode menu, select an option:

  • L7 Enhanced: This option optimizes the site for Layer 7 traffic processing.

  • L3 Mode Enhanced Performance: This option optimizes the site for Layer 3 traffic processing.

  • Select Apply.

Configure Ingress/Egress Gateway for Two Interfaces

• If you selected Ingress/Egress Gateway (Two Interface) on Recommended Region, performing the following:

  • Select Configure.

Note: The Azure Certified Hardware option is set to azure-byol-multi-nic-voltmesh by default.

• In the Nodes section, click Add Item. Performing the following:

• From the Azure AZ Name menu, set the number of availability zones.

Note: If you selected the Ingress/Egress Gateway (Two Interface) on Alternate Region option, you need to set the number of main nodes from the Number of main nodes menu.

• From the Subnet for Inside Interface menu, select an option to configure the subnet for inside interface manually:

  • Select New Subnet or Existing Subnet.

  • For the New Subnet option, enter a subnet address in the IPv4 Subnet field.

  • For the Existing Subnet option, enter an existing subnet in the Subnet Name field and select an option from the Subnet Resource Group menu. Use the Vnet Resource Group option to use the same resource group as that of the VNet, or select Resource Group Name and enter a name in the enabled Resource Group Name box.

  • From the Subnet for Outside Interface menu, select an option to configure the subnet for outside interface manually. Follow the instructions for the inside interface from above.

  • Select Add Item.

• Optionally, configure the network firewall settings in the Site Network Firewall section:

  • Select Active Firewall Policies from the Manage Firewall Policy menu.

  • Select an existing firewall policy or select Create new Firewall Policy to create and apply a network policy.

  • After creating the policy, click Continue to apply.

  • From the Manage Forward Proxy menu, select an option:

  • Enable Forward Proxy with Allow All Policy.

  • Enable Forward Proxy and Manage Policies: Select an existing forward proxy policy, or select Create new forward proxy policy to create and apply a forward proxy policy. After creating the policy, click Continue to apply.

• Optionally, configure more settings in the Advanced Options section:

  • From the Select DC Cluster Group menu, select an option to set your site in a DC cluster group:

    • Not a Member of DC Cluster Group: Default option.

    • Member of DC Cluster Group via Outside Network: Select the DC cluster group from the Member of DC Cluster Group via Outside Network menu to connect your site using an outside network.

    • Member of DC Cluster Group via Inside Network: Select the DC cluster group from the Member of DC Cluster Group via Inside Network menu to connect your site using an inside network.

• From the Select Performance Mode menu, select an option:

  • L7 Enhanced: This option optimizes the site for Layer 7 traffic processing.

  • L3 Mode Enhanced Performance: This option optimizes the site for Layer 3 traffic processing.

  • Select Apply.

Note: For more information, see the Configure DC Cluster Group guide.

VNet Peering

• To create a Spoke VNet:

  • In Azure portal, create your Spoke VNets to use for virtual machine and container workloads.

• To configure an ingress/egress Site into a Hub Site:

  • Under the Advanced Options section, select Hub VNet from the Select VNet type drop-down menu. This selection converts your Azure Site into a Hub Site.

• Select Configure.

• Select Add Item.

• In the Existing Vnet Resource Group field, enter the name of the Azure resource group of the Spoke VNet.

• In the Existing Vnet Name field, enter the name of the Spoke VNet.

• From the Select automatic or manual configuration for routes menu, select the Auto Routing option to set up routing for all existing subnets on spoke VNet, or select the Manual Routing option to manually set up routing on the Spoke VNet.

• Select Add Item.

• Select Apply.

• Select Apply.

• To verify status in Console, navigate to the Hub Site and select ... > Show VNET Peering Status.

• Confirm the "peering_sync_level" and "provisioning_state" fields are set to "FullyInSync" and "Succeeded", respectively.

• To verify status in Azure portal, confirm the VNets are online and then test connectivity.

• To enable ExpressRoute:

  • From the Express Route Configuration menu, select Enabled.

• Under the Connections subsection, click Add Item.

• In the Name field, enter a name for this connection.

• From the Express Route Circuit Configuration menu, select whether this ExpressRoute is in the same subscription as the Site:

  • Circuit in same subscription: Enter the subscription name. You can find this name in the Azure portal as the Resource ID.

  • Circuit in another subscription: Enter Circuit ID. You can find this ID in the Azure portal as the Resource ID.

• For the Authorization Key option, click Configure. Enter the Authorization Key in the text box and then click Blindfold. You can find this value in the Azure portal.

• Select Apply to complete blindfold operation.

• Select Apply to complete ExpressRoute configuration.

• From the Gateway SKU menu, select an option VNet gateway performance.

• For the Subnet for Azure VNet Gateway, select an option from the Select Auto Subnet, Existing Subnet or Create New menu. Default option is Auto Subnet. If you select New Subnet, enter the IPv4 Subnet. If you select Existing Subnet, enter the Resource Group Name.

• For the Subnet for Azure Route Server, select an option from the Select Auto Subnet, Existing Subnet or Create New menu. Default option is Auto Subnet. If you select New Subnet, enter the IPv4 Subnet. If you select Existing Subnet, enter the Resource Group Name.

• From the ASN Configuration for BGP between Site and Azure Route Servers menu, select an option to configure ASN for BGP between the Site and Azure Route Servers:

  • Automatically set ASN: Default option. No extra configuration needed. Configuration is performed automatically.

  • Custom Autonomous System Number: Enter a custom ASN.

• Select Apply to apply ExpressRoute configuration.

• To view the status, go to your Azure Site and select ... > Show Express Route Status.

Configure App Stack Cluster for One Interface

• If you selected App Stack Cluster (One Interface) on Recommended Region, performing the following:

  • Select Configure.

  • In the App Stack Cluster (One Interface) Nodes in AZ section, click Add Item.

  • From the Azure AZ name menu, set the number of availability zones.

Note: If you selected the App Stack Cluster (One Interface) on Alternate Region option, you need to set the number of main nodes from the Number of main nodes menu.

• From the Subnet for local interface menu, select an option to configure the subnet for inside interface manually:

  • Select New Subnet or Existing Subnet.

  • For the New Subnet option, enter a subnet address in the IPv4 Subnet field.

  • For the Existing Subnet option, enter an existing subnet in the Subnet Name field and select an option from the Subnet Resource Group menu. Use the Vnet Resource Group option to use the same resource group as that of the VNet, or select Resource Group Name and enter a name in the enabled Resource Group Name box.

  • From the Subnet for Outside Interface menu, select an option to configure the subnet for outside interface manually. Follow the instructions for the inside interface from above.

• Select Add Item.

• Optionally, configure the network firewall settings in the Site Network Firewall section:

  • Select Active Firewall Policies from the Manage Firewall Policy menu.

  • Select an existing network policy or select Create new Firewall Policy to create and apply a firewall policy.

  • After creating the policy, click Continue to apply.

  • From the Manage Forward Proxy menu, select an option:

  • Enable Forward Proxy with Allow All Policy.

  • Enable Forward Proxy and Manage Policies: Select an existing forward proxy policy, or select Create new forward proxy policy to create and apply a forward proxy policy. After creating the policy, click Continue to apply.

• Optionally, configure more settings in the Advanced Options section:

  • From the Select DC Cluster Group menu, select an option to set your site in a DC cluster group:

    • Not a Member: Default option.

    • Member of DC Cluster Group: Select the DC cluster group from the Member of DC Cluster Group menu to connect your site using an outside network.

• In the Storage Configuration section, enable the Show Advanced Fields option.

• From the Select Configuration for Storage Classes menu, select Add Custom Storage Class.

• Select Add Item.

• In the Storage Class Name field, enter a name for the storage class as it will appear in Kubernetes.

• Optionally, enable the Default Storage Class option to make this new storage class the default class for all clusters.

• In the Storage Device section:

  • In the Replication field, enter a number to set the replication factor for the PV.

  • From the Storage Size field, set the storage in gigabyte (GB) for each node.

• Select Add Item.

• Select Apply.

Step 2.3: Set the deployment type.

Note: Refer to the Cloud Credentials guide for more information. Ensure that the Azure credentials are applied with required access policies per the Azure Credential Client Certificate or Azure Client Secret for Service Principal Credentials documents.

• From the Automatic Deployment drop-down menu, select Automatic Deployment.

• Select an existing Azure credentials object, or select Create new Cloud Credential to load form.

• In the credential creation form, perform the following:

  • In the Metadata section, enter a name. Optionally, select a label and add a description, as needed.

  • From the Select Cloud Credential Type menu, select Azure Credential Client Certificate or Azure Client Secret for Service Principal.

• Enter the required information.

• Select Configure.

• Select option from the Secret Info menu:

  • Blindfold Secret: Enter secret in box below.

  • Clear Secret: Enter secret in box in either Text or base64(binary) formats.

  • Select Apply.

• Select Continue to add the new credentials.

Step 3: Set the site node parameters.

Configuring the Site Node Parameters section is optional.

• In the Site Node Parameters section, toggle the Show Advanced Fields option.

• Set the Azure machine type by selecting an option from the Azure Machine Type for Node menu. Click See Common Values.

• Specify a disk size in GiB from the Cloud Disk Size menu. For example, 80 would be 80 GiB.

• Enter your SSH key in the Public SSH key field.

• Enter a geographic address in the Geographical Address field to determine the latitude and longitude.

• Specify the latitude and longitude using Latitude and Longitude in the Co-ordinates section.

Step 4: Set advanced configuration.

• Toggle the Show Advanced Fields option in the Advanced Configuration section.

• Select Enable Log Streaming from the Logs Streaming menu:

  • From the Enable Logs Streaming menu, select an existing log receiver, or click Create new Log Receiver.

• Form the Select F5XC Software Version menu, set the latest or a specific version for Distributed Cloud Services software:

  • F5XC Software Version: Enter the specific version in the F5XC Software Version field, if selected.

• From the Select Operating System Version menu, set the latest or a specific version for the operating system:

  • Operating System Version: Enter the specific version in the Operating System Version field, if selected.

• Select worker node configuration from the Desired Worker Nodes Selection menu:

  • Desired Worker Nodes Per AZ: To specify worker nodes per availability zone, enter the number of worker nodes per zone in the Desired Worker Nodes Per AZ field. A maximum of 21 zones is allowed.

  • Total Number of Worker Nodes for a Site: To specify the total number of worker nodes across all zones of a site, enter the number in the Total Number of Worker Nodes for a Site field.

Note: For an Azure alternate region, there is no availability zone. It is recommended to use the Total Number of Worker Nodes for a Site option.

• Optionally, you can have your site block services, like Web, DNS, and SSH:

  • Select Custom Blocked Services Configuration from the Select to Configure Blocked Services menu.

  • Select Add Item.

  • From the Blocked Services Value Type menu, select the service to block:

    • Web UI port

    • DNS port

    • SSH port

  • From the Network Type menu, select the type of network in which this service is blocked from your site.

  • Select Add Item.

• To enable the offline survivability feature for your site:

  • From the Offline Survivability Mode Choice menu, select Enable Offline Survivability Mode. This action will restart all pods for your site.

Deploy Site

Creating the Azure VNet object in Console generates the Terraform parameters.

Note: Site upgrades may take up to 10 minutes per site node. Once site upgrade has completed, you must apply the Terraform parameters to site via Action menu on cloud site management page.

• Navigate to the created Azure VNet object using the Manage > Site Management > Azure VNET Sites path.

• Find your Azure VNet object and then click Apply in the Actions column. The Status field for your Azure VNet object changes to Applying.

Note: Optionally, you can perform Terraform plan activity before the deployment. Find your Azure VNet site object and select ... > Plan (Optional) to start the action of Terraform plan. This creates the execution plan for Terraform.

• Wait for the apply process to complete and the status to change to Applied.

Note: You can check the status for the apply action. Select ... > Terraform Parameters for your Azure VNet site object and select the Apply Status tab.

• Navigate to Sites > Sites List.

• Verify status is Online. It takes a few minutes for the site to deploy and status to change to Online.

Note: When you update worker nodes for a site object, scaling happens automatically. You can log into your node’s command-line interface (CLI) via SSH with username centos and your private key.

Delete Site

Perform the following to delete the Azure VNet site:

• Select Manage > Site Management > Azure VNET Sites to navigate to your Azure VNet object.

• Locate your Azure VNet object.

• Select ... > Delete.

• Select Delete in the pop-up confirmation window.

Note: Deleting the VNet object deletes the sites and nodes from the VNet and deletes the VNet. In case the delete operation does not remove the object and returns any error, check the error from the status, fix the error, and re-attempt the delete operation. If the problem persists, contact technical support. You can check the status using the ... > Terraform Parameters > Apply status option.

Deploy Site from Azure Marketplace

The Distributed Cloud Services node is also available in the Azure Marketplace, and you can deploy the node using the Azure Marketplace image.

Perform the following to deploy the node from Azure Marketplace:

#cloud-config
write_files:
#ves
  - path: /etc/hosts
    content: |
      # IPv4 and IPv6 localhost aliases
      127.0.0.1           localhost
      ::1                 localhost
      127.0.0.1          vip
    permissions: 0644
    owner: root
  - path: /etc/vpm/config.yaml
    permissions: 0644
    owner: root
    content: |
      Vpm:
        ClusterType: ce
        Token: <TOKEN>
        MauricePrivateEndpoint: https://register-tls.ves.volterra.io
        MauriceEndpoint: https://register.ves.volterra.io
        CertifiedHardwareEndpoint: https://vesio.blob.core.windows.net/releases/certified-hardware/azure.yml
      Kubernetes:
        EtcdUseTLS: True
        Server: vip

Step 4: Deploy the node from Azure portal.

• Log into Azure cloud portal.

• Locate the node in Marketplace search using the term "Volterra".

• Select the node listed from the search results.

Note: You can also navigate to the node resource from Azure Marketplace.

• Select Get It Now. You may receive a popup window asking you to confirm marketing and contact information.

• Select Create.

• Select the Basics tab to open the configuration form.

• From the Subscription menu, select your level of subscription.

• For the Subscription/Resource group requirement, click Create new to create a new resource group.

• In the Virtual machine name field, enter a name for your virtual machine (VM).

• From the Size menu, select an option/plan per your needs.

• Select Next at the bottom of the page to go to the next tab.

• Configure the storage disks, and then click Next.

• Configure the site network settings, and then click Next.

• Configure the site management settings.

• In the Advanced tab, paste the configuration created in the previous step into the Custom data box.

• Select Next to optionally configure name and value pairs in the Tabs tab.

• Select Next. Wait for validation test to pass and turn green.

• Confirm all settings are correct in the Review + create tab.

• Select Create.

• Download the SSH key pair if the download notification is displayed.

Step 5: Perform registration.

• From the Console homepage, select Multi-Cloud Network Connect.

• Select Manage > Site Management > Registrations.

• From the displayed list, find your site and click the blue checkmark symbol to load the Registration Acceptance form.

• Enter all mandatory fields marked with the asterisk (*) symbol, and complete registration. You may need to change the cluster name.

Note: For a multi-node site, accept registration requests for all master nodes. Ensure that you set the same values for the following fields for all nodes:

• Cluster name
• Cluster size

• Select Save and Exit to complete registration.

Note: After you accept the registration, it takes a few minutes for the health and connectivity status to update in Console.

Delete Site

To delete a site from Azure Marketplace, follow the instructions at Delete a VM and attached resources.

Deploy Site Using Terraform

This chapter provides instructions on how to create a single-node or multi-node site on Microsoft Azure with Terraform.

Perform the following procedure to deploy a site using Terraform:

terraform {
  required_version = ">= 0.13.1"
  required_providers {
    volterra = {
      source = "volterraedge/volterra"
    }
  }
}
variable "site_name" {}
variable "az_client_id" {}
variable "az_subscription_id" {}
variable "az_tenant_id" {}
variable "b64_az_client_secret" {}
variable "az_region" {
  default = "westus2"
}
variable "az_vnet_cidr" {
  default = "192.168.0.0/20"
}
variable "outside_subnet_cidr_block" {
  default = "192.168.0.0/25"
}
resource "volterra_cloud_credentials" "azure_cred" {
  name      = format("%s-cred", var.site_name)
  namespace = "system"
  azure_client_secret {
    client_id       = var.az_client_id
    subscription_id = var.az_subscription_id
    tenant_id       = var.az_tenant_id
    client_secret {
      clear_secret_info {
        url = format("string:///%s", var.b64_az_client_secret)
      }
    }
  }
}
resource "volterra_azure_vnet_site" "site" {
  name           = var.site_name
  namespace      = "system"
  azure_region   = var.az_region
  resource_group = var.site_name
  azure_cred {
    name = volterra_cloud_credentials.azure_cred.name
  }
  vnet {
    new_vnet {
      name         = var.site_name
      primary_ipv4 = var.az_vnet_cidr
    }
  }
  disk_size    = 80
  machine_type = "Standard_D4_v2"
  ingress_gw {
    azure_certified_hw = "azure-byol-voltmesh"
    az_nodes {
      azure_az  = "1"
      disk_size = 100
      local_subnet {
        subnet_param {
          ipv4 = var.outside_subnet_cidr_block
        }
      }
    }
  }
  lifecycle {
    ignore_changes = [labels]
  }
}
resource "volterra_tf_params_action" "apply_azure_vnet" {
  site_name        = volterra_azure_vnet_site.site.name
  site_kind        = "azure_vnet_site"
  action           = "apply"
  wait_for_action  = true
  ignore_on_update = true
}

site_name  = <site-name>
az_region = <az-region-which-supports-availability-zone>
az_client_id = <az-client-id>
az_subscription_id = <az-subscription-id>
az_tenant_id = <az-tenant-id>

export TF_VAR_b64_az_client_secret=<base64-encoded-secret>
export VOLT_API_URL="https://<tenant>.console.ves.volterra.io/api"
export VOLT_API_P12_FILE=<path-to-credential-p12-file>
export VES_P12_PASSWORD=<password-for-credential-p12-file>

Destroy Site

Perform the following procedure to destroy the site using Terraform:

• Enter terraform destroy.

• If prompted for the access key and secret key encoded in Base64, enter both.

• Enter yes to confirm. This may take a few minutes to complete. After the process is complete, the output will state Destroy complete!.

• In Console, navigate to the list of sites and confirm the site was destroyed.

Concepts

• System Overview
• Core Concepts
• F5 Distributed Cloud Site

API References

• Azure VNet Site
• Create Azure VNet Site Spec