Introduction and Problem Scope

F5 Distributed Cloud Mesh’s Secure Networking provides connectivity and security services for your applications running on the Edge, Private Clouds, or Public Clouds. This simplifies the deployment and configuration of connectivity and security services for your Multi-Cloud and Edge Cloud deployment needs across heterogeneous environments.

F5 Distributed Cloud Services leverage the “Site” construct to deploy our Secure Mesh or AppStack Site instances to manage workloads. A Site could be a customer location like AWS, Azure, Google Cloud Platform (GCP), private cloud, or an edge site. To run F5 Distributed Cloud Services, the site needs to be deployed with one or more instances of F5 Distributed Cloud Node, a software appliance that is managed by F5 Distributed Cloud Console. This site is where customer applications and F5 Distributed Cloud services are running.

To deploy a Node, different options are available: 

• Use F5 Distributed Cloud Services Console to deploy a site 
• Leverage F5 Distributed Cloud Services Terraform provider to deploy a site following F5 Distributed Cloud Services Console user experience 
• Use F5 Distributed Cloud Services Terraform modules 

Documentation of all the different deployment patterns found at https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management 

A customer may not want to leverage the above two options since they rely on using F5 Distributed Cloud Services Console. Reasons not to use the mentioned two options could be:

1. Security and Privacy Concerns
   • Data Security: Reluctance to share sensitive data with another organization. 
   • Access Keys: Not willing to share cloud provider access keys or credentials. 
   • Compliance: Need to comply with specific regulatory requirements (e.g., GDPR (General Data Protection Regulation), HIPAA) that require control over data.
2. Control and Customization
   • Customization: Need for a highly customized orchestration solution tailored to specific requirements, to create networking and service topologies considering brownfield realities 
   • Cost and Resource Management: 
   • Resource Allocation: Better control over resource allocation and optimization
3. Operational Considerations
   • Support: Preference for internal support and troubleshooting over relying on external support. 
   • Uptime and SLAs (Service Level Agreements): Concerns about meeting service level agreements (SLAs) and uptime requirements

To be able to roll out a site despite the points mentioned above, it is possible for the customer to manage the lifecycle of a site outside the F5 Distributed Cloud Services Console. 

F5 Distributed Cloud Services created a set of terraform modules to help customers manage the lifecycle of a site outside of F5 Distributed Cloud Services Console. Those modules are available at:  

• AWS module 
• Azure module 
• GCP module

The F5 Distributed Cloud Services Site Management documentation provides an overview of all available site types and their documentation on the topic of provisioning. Though many topologies could be deployed via F5 Distributed Cloud Services Console, the following AWS, Azure, GCP topologies can only be realized using Terraform modules: 

• Single Node Single NIC existing VPC / subnet and 3rd party NAT GW 
• Single Node Multi NIC existing VPC / subnet and 3rd party NAT GW 
• Three Node Single NIC existing VPC / subnet and 3rd party NAT GW 
• Three Node Multi NIC existing VPC / subnet and 3rd party NAT GW 
• Any other external resource and its attributes that are to be used, e.g. credentials from Vault systems, IAM policies, SSH keys

Deployment Scenario in AWS

The F5 DevCentral GitHub project contains Terraform templates to provision greenfield and / or brownfield Customer Edge (CE) topologies in AWS, GCP, and Azure with multiple use case script templates in respective repositories. To exemplify one of the scenarios, in this article, we walk through the journey a customer would undertake to provision a CE site in AWS using Terraform modules.

High-level Sequence workflow

All of the AWS, GCP, and Azure scenarios follow similar high-level steps, as shown in Fig.1. 

Step 1: F5 Distributed Cloud Services tenant needs to be ready and user to access tenant set up.  

Step 2: Clone the desired AWS, GCP, or Azure repo from F5 DevCentral GitHub project. For AWS, this is https://github.com/f5devcentral/terraform-xc-aws-ce. Each of these repositories contains multiple deployment scenarios called topologies. Each topology is described by its own readme "readme.md" file. The description includes 

• The resource objects that are created   
• Use instructions and all requirements to be able to create the topology. Especially in brownfield environments 

Step 3: Customize the “terraform.tfvars” file to the customer’s specific context. These include Distributed Cloud specific parameters. The parameters in this file are described in relation to the function it serves for the specific scenario. 

Step 4: Run through the Init/Plan/Deploy workflow of Terraform deployment and verify the status of the CE Site using F5 Distributed Cloud Services Console. The Terraform reconciliation functions ensure meeting the intended objectives. 

Fig. 1: High-Level Sequence Diagram

 

Customer deployment topology description

We will explain the above steps in the context of a greenfield deployment, the Terraform scripts of which are available here. The corresponding logical topology view of this deployment is shown in Fig.2.

This deployment scenario instantiates the following resources:

• Single-node CE cluster
• AWS SLO interface
• AWS VPC
• AWS SLO interface subnet
• AWS route tables
• AWS Internet Gateway
• Assign AWS EIP to SLO

The objective of this deployment is to create a Site with a single CE node in a new VPC for the provided AWS region and availability zone. The CE will be created as an AWS EC2 instance. An AWS subnet is created within the VPC. The CE Site Local Outside (SLO) interface will be attached to the VPC subnet and the created EC2 instance. SLO is a logical interface of a site (CE node) through which reachability is achieved to external (e.g. Internet or other services outside the public cloud site). To enable reachability to the Internet, the default route of the CE node will point to the AWS Internet gateway. Also, the SLO will be configured with an AWS External IP address (Elastic IP). 

 

Fig.2. Customer Deployment Topology in AWS

 

Description of input parameters in Terraform vars file 

Parameters must be customized to adapt to the customer’s environment. The definition of the parameters in the “terraform.tfvars” is as follows:

 

Configuring other environmental variables

Export the following environment variables in the working shell, setting it to customer’s deployment context. 

 

Deploy Topology

Deploy the topology with: 

• terraform init 

• terraform plan 

• terraform deploy –auto-approve 

and monitor the status of the Sites on the F5 Distributed Cloud Services Console.  

Created site object will be available in Secure Mesh Site section of the F5 Distributed Cloud Services Console.

 

Video-based description of the deployment Scenario

This demonstration video shows the procedure for provisioning the deployment topology described above in three steps.

<p><iframe src="https://www.youtube.com/watch?v=8_T3dQSEdhc" width="750" height="422" frameborder="0" allowfullscreen></iframe></p>

 

References

• https://docs.cloud.f5.com/docs-v2/platform/services/mesh/secure-networking 

• https://docs.cloud.f5.com/docs-v2/platform/concepts/site 

• https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management 

• https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/how-to/site-management/deploy-aws-site-terraform  

• https://docs.cloud.f5.com/docs-v2/multi-cloud-network-connect/troubleshooting/troubleshoot-manual-ce-deployment-registration-issues 

Note: This project is open source and actively monitored by F5 XC on a best-effort basis. While there is no formal commitment regarding service level agreements (SLA) or support assistance, we encourage the community to report any issues through GitHub. Customers and partners are warmly invited to contribute to the code, fostering a collaborative environment that enhances the project's development and usability.