Create Azure Site
On This Page:
- Objective
- Design
- Azure VNet Site Deployment Types
- Ingress Gateway (One Interface)
- Ingress/Egress Gateway (Two Interfaces)
- Network Policies
- Forward Proxy Policy
- Prerequisites
- Deploy Using Console
- Accept Subscription Agreement
- Create Azure VNet Site Object
- Deploy Site
- Delete Site
- Deploy Site from Azure Marketplace
- Delete Site
- Deploy Site Using Terraform
- Destroy Site
- Concepts
- API References
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:
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.
-
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.
-
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 labeledInside
. 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:
Phase | Description |
---|---|
Create Azure VNet Site Object | Create the Azure VNet site object in Console. |
Deploy Azure VNet Site | Deploy the site configured in the Azure VNet site object using automated method. |
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 inAdvanced nav options visible
in bottom left corner. If needed, selectHide
to minimize options fromAdvanced 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. TheRecommended Azure Region Name
option is selected by default. You can change it by selecting theAlternate Azure Region Name
option.
Note: The
Recommended Azure Region Name
option is where Azure provides at least three availability zones. TheAlternate 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
orAlternate Azure Region Name
menu per your choice of the Azure region type. -
From the
Vnet
menu, select an option:-
New Vnet Parameters
: SelectAutogenerate Vnet Name
orChoose Vnet Name
from theAzure Vnet Name
menu. If you choose a VNet name, enter the name in theChoose Vnet Name
box. Enter the CIDR in theIPv4 CIDR block
field. -
Existing Vnet
: Enter an existing resource group name and VNet name in theExisting Vnet Resource Group
andExisting 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, clickAdd 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 theNumber of main nodes
menu.
-
From the
Subnet for local interface
menu, selectNew Subnet
orExisting Subnet
. -
For the
New Subnet
option, enter the subnet address in theIPv4 Subnet
field. -
For the
Existing Subnet
option, enter it in theSubnet Name
field, and select an option from theSubnet Resource Group
menu. Use theVnet Resource Group
option to use the same resource group as that of the VNet, or selectResource Group Name
and enter a name in the enabledResource Group Name
field. -
Select
Add Item
.
Note: You can add more than one ingress gateway using the
Add Item
option. TheAzure Certified Hardware
option is set toazure-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
.
- Select
Note: The
Azure Certified Hardware
option is set toazure-byol-multi-nic-voltmesh
by default.
-
In the
Nodes
section, clickAdd 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 theNumber 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
orExisting Subnet
. -
For the
New Subnet
option, enter a subnet address in theIPv4 Subnet
field. -
For the
Existing Subnet
option, enter an existing subnet in theSubnet Name
field and select an option from theSubnet Resource Group
menu. Use theVnet Resource Group
option to use the same resource group as that of the VNet, or selectResource Group Name
and enter a name in the enabledResource 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 theManage 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 selectCreate new forward proxy policy
to create and apply a forward proxy policy. After creating the policy, clickContinue
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 theMember 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 theMember 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, selectHub VNet
from theSelect VNet type
drop-down menu. This selection converts your Azure Site into a Hub Site.
- Under the
-
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 theAuto Routing
option to set up routing for all existing subnets on spoke VNet, or select theManual 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, selectEnabled
.
- From the
-
Under the
Connections
subsection, clickAdd 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 theResource ID
. -
Circuit in another subscription
: EnterCircuit ID
. You can find this ID in the Azure portal as theResource ID
.
-
-
For the
Authorization Key
option, clickConfigure
. Enter theAuthorization Key
in the text box and then clickBlindfold
. 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 theSelect Auto Subnet, Existing Subnet or Create New
menu. Default option isAuto Subnet
. If you selectNew Subnet
, enter theIPv4 Subnet
. If you selectExisting Subnet
, enter theResource Group Name
. -
For the
Subnet for Azure Route Server
, select an option from theSelect Auto Subnet, Existing Subnet or Create New
menu. Default option isAuto Subnet
. If you selectNew Subnet
, enter theIPv4 Subnet
. If you selectExisting Subnet
, enter theResource 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, clickAdd 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 theNumber 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
orExisting Subnet
. -
For the
New Subnet
option, enter a subnet address in theIPv4 Subnet
field. -
For the
Existing Subnet
option, enter an existing subnet in theSubnet Name
field and select an option from theSubnet Resource Group
menu. Use theVnet Resource Group
option to use the same resource group as that of the VNet, or selectResource Group Name
and enter a name in the enabledResource 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 theManage 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 selectCreate new forward proxy policy
to create and apply a forward proxy policy. After creating the policy, clickContinue
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 theMember of DC Cluster Group
menu to connect your site using an outside network.
-
-
-
In the
Storage Configuration
section, enable theShow Advanced Fields
option. -
From the
Select Configuration for Storage Classes
menu, selectAdd 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, selectAutomatic 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, selectAzure Credential Client Certificate
orAzure 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 eitherText
orbase64(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 theShow Advanced Fields
option. -
Set the Azure machine type by selecting an option from the
Azure Machine Type for Node
menu. ClickSee 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
andLongitude
in theCo-ordinates
section.
Step 4: Set advanced configuration.
-
Toggle the
Show Advanced Fields
option in theAdvanced Configuration
section. -
Select
Enable Log Streaming
from theLogs Streaming
menu:- From the
Enable Logs Streaming
menu, select an existing log receiver, or clickCreate new Log Receiver
.
- From the
-
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 theF5XC 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 theOperating 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 theDesired 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 theTotal 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 theSelect 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, selectEnable Offline Survivability Mode
. This action will restart all pods for your site.
- From the
Step 5: Complete the Azure VNet site object creation.
Select Save and Exit
to complete creating the Azure VNet site. The Status
box for the VNet object displays Generated
.
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 theActions
column. TheStatus
field for your Azure VNet object changes toApplying
.
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 theApply 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 toOnline
.
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:
Step 1: Create account.
Create an account from the Marketplace by following the instructions available there. You can also create an account using the instructions in the Create an Account guide or use an existing account.
Step 2: Create a site token.
Log into Console and create a site token.
Step 3: Create custom data for deployment.
Azure Marketplace supports installation using custom data, such as a script or a configuration file.
-
Create a file and open it with a text editor or terminal text editor, such as
vi
ornano
. -
Enter the configuration using the following template:
#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
-
Replace
<TOKEN>
shown in the sample above with the token created in Step 2. -
Save the file.
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, clickCreate 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 theCustom data
box.
-
Select
Next
to optionally configure name and value pairs in theTabs
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.
Step 6: Check the site status and health.
-
Click
Sites
>Site List
and select your site from the displayed list to see the dashboard for your site. -
Select the
Site Status
tab to verify the following:-
The
Update Status
field hasSuccessful
value for theF5 OS Status
section. -
The
Update Status
field hasSuccessful
value for theF5 Software Status
section. -
The
Tunnel status
field under theRE Connectivity
section hasup
value.
-
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:
Step 1: Confirm Terraform is installed.
In a terminal, enter terraform version
. If you need to install, follow the instructions at the official guide.
Step 2: Create API credentials file.
Log into Console and create an API 12 certificate file and then download it. Use the instructions at Credentials for more help.
Step 3: Create a new directory on your system to place files for deployment.
Create a new directory on your system to place files for deployment.
Step 4: Create the deployment file.
-
Create a file and name it
main.tf
file, and place it in the newly created directory. -
Copy and paste the following information into the file:
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
}
-
Open the file and configure any necessary fields. You can change the parameters for your particular setup.
-
Save the changes and then close the file.
Step 5: Create file for variables.
-
In the same directory, create another file for variables and name it
terraform.tfvars
. -
Create and assign the following variables:
-
For your site name, type a name within double quotes:
site_name = "<site-name>"
-
For the region, type the name within double quotes:
az_region = "<az-region-which-supports-availability-zone>"
-
For the client ID, type the name within double quotes:
az_client_id = "<az-client-id>"
-
For the subscription ID, type the name within double quotes:
az_subscription_id = "<az-subscription-id>"
-
For the tenant ID, type the name within double quotes:
az_tenant_id = "<az-tenant-id>"
-
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>
Step 6: Create and export variables for credentials and secret keys.
-
In the terminal, create and export the following variables:
-
Create this variable and assign it the value of the Base64 encoded client secret:
export TF_VAR_b64_az_client_secret=<base64-encoded-secret>
-
Create this variable and assign it the URL for your tenant. For example:
export VOLT_API_URL=https://example.console.ves.volterra.io/api
-
Create this variable and assign it the path to the API credential file previously created and downloaded from Console:
export VOLT_API_P12_FILE=<path-to-local-p12-file>
-
Create this variable and assign it your API credentials password:
export VES_P12_PASSWORD=<credential-password>
-
Note: You can also create and save these variables in the
terraform.tfvars
file. However, this may pose a security risk. Use caution when working with your credentials and secret keys.
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>
Step 7: Initiate Terraform process.
Enter terraform init
.
Step 8: Apply Terraform process.
-
Enter
terraform apply
. -
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 stateApply complete!
. -
In Console, navigate to the list of sites and confirm the site was applied.
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 stateDestroy complete!
. -
In Console, navigate to the list of sites and confirm the site was destroyed.