Microsoft, as part of their Modern Internet Explorer project for developers (now known as Microsoft Edge, their new browser), has released a series of virtual machine images covering everything from IE6 & Windows XP (shudder) all the way up to IE 11 & Windows 10.
They’ve released these in a variety of formats, from their own virtualization technology, called HyperV, to Oracle Virtualbox. All of these can be downloaded from http://dev.modern.ie/tools/vms/
Unsatisfied with the workflow of downloading these images (all 35GB worth), I set out to leverage Vagrant to make it even easier to get started with these virtual machines. The result is modern-ie-vagrant.
How to use Vagrant in IE
git clone https://github.com/markhuber/modern-ie-vagrant.git
The Briefest Introduction to Vagrant
If you’ve never used Vagrant before, the process is straightforward. Using your favorite command-line application, work your way into the directory you cloned from GitHub and use any of the following commands.
To list the available virtual machines:
To start a new virtual machine:
vagrant up IE10-Win7
To start multiple virtual machines at once:
vagrant up IE11-Win7 IE10-Win7 IE9-Win7 IE8-Win7
To power down a virtual machine from the command line:
All machines: vagrant halt Specific machine: vagrant halt IE10-Win7
To reclaim some disk space, you may delete all or some of the images:
All machines: vagrant destroy Specific machine: vagrant destroy IE10-Win7
To purge the cache of downloaded machine images:
vagrant box list vagrant box remove [boxname]
Vagrant handles retrieving the machine images on demand.
The first time you use an image, it will automatically download from the internet which may take around 20 minutes. Once you’ve retrieved the image once, it is cached and creating the virtual machine takes under 2 minutes; restarting a previously created image can be as quick as 30 seconds.
I’ve been testing this project with Vagrant Manager with great success.
The first time you use Vagrant Manager, if you have not already created a virtual machine for testing from the command-line, it will not automatically find your project. You can use their bookmark feature to tell it where to find the Vagrantfile. From here, you can create and destroy machines right from your toolbar.
This works on both Mac OS X and Windows.
Creating this project was an unexpected wealth of learning opportunities. The project broke down into two major categories: building the images and hosting the images.
Building the images required taking the base images provided by Microsoft and adding WinRM support to it. Without WinRM support, Vagrant will hang after the box starts attempting to interact with the virtual machine.
Downloading and preparing the images was done with a combination of PhantomJS, Python, and the Python Virtualbox API. Each image was downloaded, booted, WinRM installed, and shut down.
The details of this process are beyond the scope of this post, but it’s fair to say it wasn’t the prettiest process and didn’t lend itself to complete automation. From there, the boxes were repacked with
vagrant pack and readied to be hosted.
For various reasons, I wanted to find a way to host the images in a way that would make it easy for clients to consume. This meant hosting it in a format understood by Vagrant.
I wanted to find a way to host the images in a way that would make it easy for clients to consume. This meant hosting it in a format understood by Vagrant. Thanks to a post by @jonursenbach on how to host Your own Vagrant Cloud, I learned it is possible to host your private version of the public services like VagrantCloud.
I’m not a PHP or Apache aficionado so I was unsure of how to get this going. This is where a little Docker & Vagrant magic accelerated my process tremendously.
FROM tutum/apache-php RUN apt-get update && apt-get install -yq git && rm -rf /var/lib/apt/lists/* RUN rm -rf /var/www/html && git clone https://github.com/vube/vagrant-catalog /var/www/html COPY 000-default.conf /etc/apache2/sites-available/000-default.conf WORKDIR /var/www/html RUN composer update RUN mv config.php.dist config.php RUN rm index.html EXPOSE 80 WORKDIR /app CMD ["/run.sh"]
The workflow of connecting the Docker Registry to my GitHub repository meant every commit to master of my repo was automatically built into a Docker container. This was incredibly easy and quick to setup.
By taking a portable approach with Docker and testing my changes in a Vagrant image, It was straightforward to move this setup to a EC2 hosted instance without any issue. You can see this private catalog running at http://vagrant.markhuber.net.
More details about this workflow are available in this presentation slide here.