While I was a Solutions Engineer at Virtual Bridges, part of my job was working with customers and prospects on their VDI projects, which included roll-out plans, testing, covering best practices, and deployment of the infrastructure. With the repetitive nature of deployment steps, I started writing various tools to aide/ease deployments for not only myself, but for customers as they started to expand their VDI footprint. [Keep in mind, everything I wrote was while I was still at VB and things in the software business move fast, so exact steps to achieve what I lay out below may slightly differ, now.]
One deployment project I started working on as a kind of proof-of-concept for prospective Cloud Branch customers was an +Amazon Web Services (AWS) + VERDE hybrid deployment. The basic idea being that the VERDE management side of things resides in AWS, while the Cloud Branch(es) (cluster or standalone) get deployed at the prospective customer's site(s). I wanted to make it as simple for deployment as possible (which is pretty much an inherent attribute of VERDE, anyway). This was also a way of creating an easy disaster recovery setup for customers, as my crude white-boarding skills illustrate below:
[simple AWS-based disaster recovery concept]
Deploying the AWS-based VERDE Management ConsoleThe management console (MC) is basically what you might expect. In a Cloud Branch scenario, each Cloud Branch cluster reports back to the MC. From the management console, you can specify which desktop images should be deployed out to which branch and which users should be able to launch those desktops. Each of these branch clusters sends a daily copy of the users' files to be stored at the MC site (in this case, Amazon Web Services a la Elastic Block Storage). So, first things first, we need to spin up a VERDE node with a Management Console role. One of the first things needed is to create an AWS account and obtain your credentials, which is beyond the scope of this post (you'll also want to get set up with the EC2 API tools). After that, we create a security group with the necessary VERDE required ports open (you'll be able to get this information while talking with your Virtual Bridges contact). For my proof-of-concept, I wrote a script to create this group, along with the correct rules for the required ports.
Once you have your AWS credentials (which should include a Key Pair) and a security group created (verde-ports, in my case) you can quickly spin up an Ubuntu instance that 'magically' becomes a VERDE Management Console.
ec2-run-instances ami-c7b202ae -t m1.medium -k mykeypair -g default -g verde-ports --user-data-file=verde6-cloud-config.txt --block-device-mapping "/dev/sdh=:100"
Simple enough? Now you have a fully functioning VERDE Management Console running in the Amazon cloud, ready to start managing some VERDE Cloud Branch clusters!
There's obviously the verde6-cloud-config.txt file that you'll need.
### You will need to modify the '<VERDE ....>' sections to include the download
### link. Ideally, you make this a template and use sed or a script w/sed to
### generate the actual file with the appropriate download link and package name
### amic7b202ae is the "official" Ubuntu 10.04 64-bit image, required for VERDE
# ec2-run-instances ami-c7b202ae -t <m1.medium, at least> -k <keypair> \
# -g default -g verde-ports --user-data-file=verde6-cloud-config.txt \
# --block-device-mapping "/dev/sdh=:100"
### block-device-mapping of 100 is an example,
### size appropriately for images + User data
# - VERDE required packages
- [ sdh, /mnt, "auto", "defaults", "0", "0" ]
# Create vb-verde user and group
- [ groupadd, --gid, 5000, vb-verde ]
- [ useradd, -m, --uid, 5000, --gid, 5000, -d, /mnt/vb-verde, vb-verde ]
# Get VERDE package
- [ "wget", <VERDE download link here>, "-O", "/tmp/<VERDE package name here>" ]
- [ sh, -xc, "echo 'server_role=\"CM_Only\"' >> /tmp/answer.verde" ]
- [ export, VERDE_CONFIGCMDLINE="-f /tmp/answer.verde -u" ]
- [ dpkg, --install, "/tmp/<VERDE package name here>" ]