Skip to main content

Running Sales Demos using Vagrant and VirtualBox

Sales Demo

Imagine you have a Java web application that you deploy via a WAR file to a Tomcat server, and you want your sales staff to be able to demo that application from their laptops. The sales folks often times go onsite to customers offices, where they don't have internet access. What options are available for running these kinds of sales demos?

Option #1 - Run Web Server Directly

One way to solve this is for the sales staff to install Tomcat and Java on their laptops, and deploy the WAR file by hand. That can work, but if your sales staff aren't that technical, having them configure web servers isn't a good use of their time. Not to mention that if your application requires a database as a dependency, then they must also install a database server such as Postgres, and configure the security settings properly to allow the app to connect.

There's too many moving parts here for sales staff to configure a demo in this way. Clearly, we want to automate this process.

Scripting the setup is one way to go about this. This wouldn't be too bad, but what if you're sales staff use a mixture of Windows, Mac and Ubuntu? Maintaining those scripts for all the different environments would be a bit of work. But doable.

Option #2 - Docker

A better approach would be to virtualize the sales demo. Docker is an option, but if there's a mix of different OSes, Docker might not be the best fit. Also, Docker is geared more towards developers than to sales folks, so Docker might be a bit much to expect sales folks to have running on their personal laptops.

Option #3 - VirtualBox

If Docker isn't a viable option for the sales demo, there's always the traditional virtualization using products such as VirtualBox. VirtualBox makes setting up VMs very simple. Having sales folks install VirtualBox and Vagrant and run a single "vagrant up" command (perhaps wrapped with a simple start.bah or start.sh script) is pretty simple.

Configuring Vagrantfile

Creating of a Sales Demo with Vagrant is pretty simple. We'll need 4 files: Vagrantfile, configure.sh, tomcat7, and SalesDemo.war.

Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-16.04"
  config.vm.network "private_network", ip: "192.168.50.4"
 
  config.vm.provider "virtualbox" do |v|
    v.name = 'Sales-Demo'
    v.memory = 2048
  end

  config.vm.provision "shell", path: "configure.sh"
end

configure.sh 
#!/usr/bin/env bash
apt-get update
apt-get install -y unzip openjdk-8-jre-headless
apt-get install -y tomcat7

rm /etc/default/tomcat7
cp /vagrant/tomcat7 /etc/default/

rm -rf /var/lib/tomcat7/webapps/ROOT
unzip -qq /vagrant/SalesDemo.war -d /var/lib/tomcat7/webapps/ROOT

service tomcat7 restart

tomcat7 
TOMCAT7_USER=tomcat7
TOMCAT7_GROUP=tomcat7
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
JAVA_OPTS="-Djava.awt.headless=true -Xmx1024m -XX:+UseG1GC"

After installing VirtualBox and Vagrant on your machine, create a folder to contain these 4 files, say Sales-Demo.


To start the demo, run the command

vagrant up

from the Sales-Demo folder.

Once that finishes, open http://192.168.50.4:8080/ in your browser to access the demo.


Vagrantfile Details

The Vagrantfile shown above is pretty straightforward. It results in a VM in VirtualBox called Sales-Demo, and runs Ubuntu 16.04, Java 8, and Tomcat 7. The VM is using private networking so that sales folks don't have to open any ports on their computers, although it can easily be switched to port forward port 8080 so the demo could run at http://localhost:8080/ instead.

In the configure.sh script that configures the Ubuntu server, I've chosen to manually explode the WAR file, overwriting ROOT in the Tomcat7/webapps folder. This allows for easy customization of the demo via scripts, say if you need to update the web.xml file, configure connection strings, etc.

The tomcat7 file overwrites the default tomcat7 configuration in /etc/default/tomcat7, using Java 8, increases the max JVM heap to 1GB, and uses the G1 garbage collector. This allows for the JVM to be tuned to suit your needs.


Potential Issues With VirtualBox


If sales folks are installing VirtualBox and Vagrant on their own, they could run into issues if their computers do not have Hardware Virtualization enabled in the BIOS. For developers and technical folks, it's quite straight forward to enable this in the BIOS, but for the less technically inclined they might need a little help.

I've seen private networking cause grief for some people, and in those cases I switched from private networking to just using port forwarding.

Running sales demos on sales folks personal laptops is a challenge. Keeping the demos up to date, ensuring everything is configured properly, diagnosing issues are all challenges, and it really isn't a good use of sales folks time to be configuring demos. 

But in the case where sales folks use the sales demo on-site where internet connection isn't available, then running sales demos on personal laptops is sometimes necessary. Virtualization ensures that all the sales folks have the demos configured in the same manner, and takes some of the pain away of having to configure web servers by hand. 

Comments

Post a Comment

Popular posts from this blog

Generating Java Mixed Mode Flame Graphs

Overview I've seen Brendan Gregg's talk on generating mixed-mode flame graphs  and I wanted to reproduce those flamegraphs for myself. Setting up the tools is a little bit of work, so I wanted to capture those steps. Check out the Java in Flames post on the Netflix blog for more information. I've created github repo ( github.com/jerometerry/perf )  that contains the scripts used to get this going, including a Vagrantfile, and JMeter Test Plan. Here's a flame graph I generated while applying load (via JMeter) to the basic arithmetic Tomcat sample application. All the green stacks are Java code, red stacks are kernel code, and yellow stacks are C++ code. The big green pile on the right is all the Tomcat Java code that's being run. Tools Here's the technologies I used (I'm writing this on a Mac). VirtualBox 5.1.12 Vagrant 1.9.1 bento/ubuntu-16.04 (kernel 4.4.0-38) Tomcat 7.0.68 JMeter 3.1 OpenJDK 8 1.8.111 linux-tools-4.4.0-38 linux-to...
235 comments
Read more

Basic Web Performance Testing With JMeter and Gatling

Introduction In this post I'll give a quick way to get some basic web performance metrics using both JMeter and Gatling . JMeter is a well known, open source, Java based tool for performance testing. It has a lot of features, and can be a little confusing at first. Scripts (aka Test Plans), are XML documents, edited using the JMeter GUI.  There are lots of options, supports a wide variety of protocols, and produces some OK looking graphs and reports. Gatling is a lesser known tool, but I really like it. It's a Scala based tool, with scripts written in a nice DSL. While the scripts require some basic Scala, they are fairly easy to understand and modify. The output is a nice looking, interactive, HTML page. Metrics   Below are the basic metrics gathered by both JMeter and Gatling . If you are just starting performance testing, these might be a good starting point . Response Time – Difference between time when request was sent and time when response has been fully re...
110 comments
Read more

Multi Threaded NUnit Tests

Recently I needed to reproduce an Entity Framework deadlock issue. The test needed to run in NUnit, and involved firing off two separate threads. The trouble is that in NUnit, exceptions in threads terminate the parent thread without failing the test. For example, here's a test that starts two threads: the first thread simply logs to the console, while the other thread turfs an exception. What I expected was that this test should fail. However, the test actually passes. readonly ThreadStart[] delegates = { () => { Console.WriteLine("Nothing to see here"); }, () => { throw new InvalidOperationException("Blow up"); } }; [Test] public void SimpleMultiThreading() { var threads = delegates.Select(d => new Thread(d)).ToList(); foreach (var t in threads) { t.Start(); } foreach (var t in threads) { t.Join(); } } Peter Provost posted an article that describes how to make this test fail. It...
139 comments
Read more