Doing anything at scale has been a challenge throughout history, whether it was building the ancient pyramids or architecting a modern enterprise WAN. With an onslaught of new applications and services, evolving security, and global infrastructure shifting to the cloud, automation is fast becoming key to success. SD-WAN has evolved with automation as a core tenet, enabling networking teams to architect, test, and deploy more rapidly than ever. With automation, IT teams recover invaluable time to plan and architect (and occasionally document), rather than toiling with manual configurations and troubleshooting.
While some automation is built into most SD-WAN platforms, these capabilities often don’t start until the appliance has been deployed and powered on. Deploying Aruba EdgeConnect SD-WAN physical appliances is relatively simple, but deploying EdgeConnect virtual can require more hands-on intervention, an option gaining popularity as public IaaS instances continue to gain importance.
In this blog, I will describe an easy way to deploy EdgeConnect virtual into Amazon Web Services (AWS) leveraging publicly available tools.
What is Ansible?
By using Red Hat Ansible automated provisioning tools, IT can scale automation, manage complex deployments and speed productivity with an enterprise automation platform that can be used across entire IT teams. For the task of deploying an EdgeConnect virtual instance in AWS, it will take care of the entire AWS configuration portion, including creating a VPC, defining security groups, creating network interfaces, etc.
For this example, I’ve taken the steps from the Aruba EdgeConnect deployment guide for AWS and converted them into an Ansible playbook.
Is it worth your time to learn this?
As with everything, it depends. The obligatory XKCD certainly applies here:
One of my peers who regularly builds (and rebuilds as part of QA) cloud images estimates it takes roughly an hour to deploy an EdgeConnect virtual instance. Using Ansible reduces deployment time to a fraction of that by automating the process with a tool that can also be used for other projects. That’s the power of using an existing tool – knowledge gained here (or perhaps already in place) helps with other projects. Aruba continues to look toward technology alliance partners to help customers successfully execute no-compromise WAN transformation, be it through ecosystem partners or using an existing framework such as Ansible.
Overview
For this example, I’ll use an Ubuntu instance in AWS to run Ansible. To follow along, download and extract this zip to your own Ansible server, and make sure to have access to Aruba Orchestrator release 8.8.5 or newer (older versions will work, but require adjustments).
Figure 2: Ansible Workflow
- Ansible deploys to AWS – using standard Ansible modules, administrators can specify the region, size, and more for the instance
- CloudInit (ZTP) – once the appliance is powered on; it will reach out to the Orchestrator (via the Cloud Portal) and show up in discovered appliances
- Preconfiguration (ZTC) – YAML formatted zero touch configuration files kept in Orchestrator; administrators can either select files to push to an appliance or match based on custom tags
Let’s look at this workflow in reverse order.
3. Preconfiguration (ZTC)
Preconfiguration allows for the staging of EdgeConnect virtual appliances in Aruba Orchestrator.
This has several benefits:
- Bulk staging of configuration for large-scale rollouts
- Configuration cloning capabilities to reduce risk of human error
- Ongoing config changes through a standard, centralized format
Go to Configuration>Templates and create a new template group called “AutomationDemo”. This enables Ansible to log in to the appliance for the initial configuration. Be sure to drag over the User Management and CLI templates.
Next, on the User Management template, add a new user called “automation” and a secure password. Save this for later use.
Figure 3: Template Creation
On the CLI page, make sure that SSH is on with “ssh server listen”.
Figure 4: CLI configuration to enable SSH on the appliance
Save the Template Group at the bottom.
Next, go to Configuration>Preconfiguration and create a new file. From the file download, copy the contents of ~/speak-aws-ec-blog_files/orch_preconfig.yml to the right-hand side. Give it a name, match it on the tag AutomationDemo, enable Auto Approve, and paste in the file content. Click validate and fix any errors.
Figure 5: Preconfiguration file
2. CloudInit (ZTP)
CloudInit is a way to run commands upon a VM’s initialization (User data in the AWS GUI), allowing for configuration of appliances without human interaction. Simply specify which account the EdgeConnect virtual belongs to (Account Name/Key) and a tag (e.g. AutomationDemo above) to match on.
The configuration will be handled by Ansible in the next section, make sure you have the account name and key, found under Orchestrator>Cloud Portal.
- Ansible deploys to AWS
After installing Ansible and the AWS dependencies, it’s time to deploy to AWS.
sudo apt update sudo apt install software-properties-common sudo apt-add-repository --yes --update ppa:ansible/ansible sudo apt install ansible python-pip -y pip install boto boto3 botocore
Description: Install Ansible on Ubuntu
To run commands in your AWS environment, a programmatic user’s credentials must be specified. Create a user with programmatic access if not already present, and then open the ~/speak-aws-ec-blog_files/roles/aws_ec/defaults/main.yml file. Replace the example information with your own or create an Ansible Vault file for added security (beyond the scope of this overview).
- access_key and secret_key – AWS programmatic user information
- loginPassword – from the “automation” user created in the User Management template
- speak_account_name and speak_account_key – From the Orchestrator information discussed in the CloudInit section.
Run the command “sudo ansible-playbook ~/speak-aws-ec-blog_files/demo.yml” from the terminal. From there, it will create a VPC, necessary subnets, and deploy a device into US-WEST-1. After about 10 minutes, the fully configured appliance will be in Orchestrator with the tunnels built to other appliances, sending traffic to and from AWS. Voila!
Summary
If you only are building a single instance, it might be OK to just follow the guide and use the GUI. But, if your plan is to use the cloud for dev (which easily becomes prod), or your entire business is moving to IaaS, this is a great way to quickly scale and automate the configuration. Aruba is focused on providing our customers with the ability to deliver the highest quality of experience across their WANs, using automation for cloud deployments is just one more way to lighten the workload for IT.
This blog was originally published by Silver Peak, which was acquired by Aruba, a Hewlett Packard Enterprise Company.
