This demo will use Terraform to create F5 Distributed Cloud Nodes and public cloud resources in AWS, Azure, and Google. Once the multi-cloud environment is ready, you then choose a lab guide to explore the F5 Distributed Cloud (XC) platform. Manual steps will be performed in order to configure F5 XC and address common multi-cloud challenges.

The initial deployment will consist of the following:

• AWS
  • 1x VPC (10.0.0.0/16 CIDR)
  • 1x F5 XC Node
  • 1x NGINX app (EC2 instance)
  • TBD 1x EKS cluster
  • TBD 1x Diagnostics app (EKS container)
  • TBD 1x NGINX app (EKS container)
• Azure #1
  • 1x VNet (10.0.0.0/16 CIDR) - IP Overlap!!
  • 1x F5 XC Node
  • 1x NGINX app (VM instance)
  • TBD 1x AKS cluster
  • TBD 1x NGINX app (AKS container)
• Azure #2
  • 1x VNet (192.168.0.0/16 CIDR)
  • 1x F5 XC Node
  • 1x NGINX app (VM instance)
• TBD Google
  • 1x xxxx
  • 1x xxxx

The following is an example configuration diagram for this solution deployment.

ACME Corp has multiple business units that have independently migrated to AWS, Azure, and soon GCP. They are now required to communicate with each other securely and with minimal changes to existing environments. They have a few acquisitions in the near future and are concerned with the complexities that come with multi-cloud networking and connecting their services together. Some applications have been deployed without planning, and this resulted in services that are deployed in a different cloud or on networks with overlapping RFC1918 CIDRs. The services cannot be easily connected without deploying NATing and routing appliances.

The application teams are also trying to address scaling issues by hosting services in multiple locations and this has proven to be a challenge. Not only are they running virtual machine types, but there is also a mandate to run container workloads. As a result, they have copies of applications running as virtual machine instances and also Azure AKS and AWS EKS container workloads in the public cloud.

You need to solve this mess, and F5 XC Nodes can help. F5 Nodes are deployed as part of the SaaS service of F5 XC, and they will allow you to connect, secure, control and observe applications deployed within a single cloud location or applications distributed across multiple clouds and edge sites.

1. Deploy Terraform Code - see Prerequisites
2. Explore Use Cases - see Lab Guides

• F5 Distributed Cloud credentials
• Set AWS Environment Variables
• Create Azure Service Principal
• Create Google Service Account

• Clone the repo and open the solution's directory

git clone https://github.com/JeffGiroux/f5xc-mcn.git
cd f5xc-mcn/

• Set F5 Distributed Cloud environment variables

export VES_P12_PASSWORD="your_key"
export VOLT_API_URL="https://<tenant-name>.console.ves.volterra.io/api"
export VOLT_API_P12_FILE="/var/tmp/<example>.console.ves.volterra.io.api-creds.p12"

• Get the F5 Distributed Cloud tenant name
  • F5 XC Console > Tenant Settings > Tenant Overview
• Create the tfvars file and update it with your settings

cp admin.auto.tfvars.example admin.auto.tfvars
# MODIFY TO YOUR SETTINGS
vi admin.auto.tfvars

• Run the initial setup script (sets up a random build suffix and a virtual site)

./setup.sh

• Run the cloud specifc setup script: (remember that you are responsible for the cost of those components)

./aws-setup.sh
./azure-site1-setup.sh
./azure-site2-setup.sh
./gcp-setup.sh

Reference each cloud for steps to validate.

• AWS Test your setup
• Azure Test your setup
• Google Test your setup

• Run the cloud specific destroy script

./aws-destroy.sh
./azure-site1-destroy.sh
./azure-site2-destroy.sh
./gcp-destroy.sh

• Run the solution destroy script

./destroy.sh

See Troubleshooting document for common issues you might see when deploying this demo along with recommended fixes or alternative actions.

No modules.

For support, please open a GitHub issue. Note, the code in this repository is community supported and is not supported by F5 Networks. For a complete list of supported projects please reference SUPPORT.md.

Please refer to the F5 DevCentral Community Code of Conduct.

Apache License 2.0

Copyright 2014-2020 F5 Networks Inc.

Before you start contributing to any project sponsored by F5 Networks, Inc. (F5) on GitHub, you will need to sign a Contributor License Agreement (CLA).

If you are signing as an individual, we recommend that you talk to your employer (if applicable) before signing the CLA since some employment agreements may have restrictions on your contributions to other projects. Otherwise by submitting a CLA you represent that you are legally entitled to grant the licenses recited therein.

If your employer has rights to intellectual property that you create, such as your contributions, you represent that you have received permission to make contributions on behalf of that employer, that your employer has waived such rights for your contributions, or that your employer has executed a separate CLA with F5.

If you are signing on behalf of a company, you represent that you are legally entitled to grant the license recited therein. You represent further that each employee of the entity that submits contributions is authorized to submit such contributions on behalf of the entity pursuant to the CLA.