Setting up a TFS Development Environment on Amazon EC2


Background

I’ve been using the Amazon EC2 environment for a while now, mostly for basic development or testing environments. Since these environments have all been reproducible very easily we haven’t worried too much about getting them setup to resist an instance failure.

This week however, I’ve had three separate conversations regarding how we can get environments safely built for more complex applications:

  • Team Foundation Server Beta 2
  • Microsoft CRM / SharePoint Server Development Environments
  • Oracle SE1

In each of these cases, the environment is only required for a short time while developing or demonstrating … then they will be shut down again.

Each of these needs some form of database storage … and since this will be a development environment we don’t want to be paying $1 / hour for the Amazon SQL Server instance, given that we are entitled to use our development licenses for this purpose.

One serious note about EC2 Drives

Hard drives on EC2 are split into three different categories:

  • (C:) is the system drive, and is automatically attached when an EC2 instances. It should be noted that ONLY data on the C: is persisted when an instance is bundled!
  • (D:) is a temporal storage drive, and should be used strictly for short term storage, as this does not get persisted when an instance is bundled.
  • Additional Elastic Storage Blocks (ESB) may be added. ESBs are treated as additional hard drives, but they are stored within S3 and therefore will (usually) remain intact beyond the life of an EC2 server instance. As the capacity of the EC2 system drive is so low (10GB for a small instance) it is necessary to store all programs and data that need to be persisted within ESB drives.

I make this distinction right at the start of my post – because I got caught out by the fact that the D: drive does not get bundled … and had to start all over again 😦

Initial Setup

For this configuration we’re going to need the following setup on EC2

  • 1 x 10GB ESB for storing installers and ISOs
  • 1 x 5GB ESB for database
  • 1 x EC2 instance for downloading files
  • 1 x EC2 instance for Application installation

I’m working on the assumption that everything is installed on the same instance today – though obviously one could separate the various components of the installation, and use Amazon security groups as a way to restrict access and provide layers of security.

Preparation – Download the Installers

Maybe I’m being overly cautious, but I tend to setup a specific instance just for downloading the application installers and copying them to an Elastic Storage Block drive. This way any bloat that the download causes does not affect the size of the installed application AMI when we go to bundle it later.

Note: One of the gotcha’s I ran into was that the default setting for Internet Explorer restricts access to download some of the installation files that we need. Rather than messing around with the security settings for every new instance, I decided to download Firefox and run it straight off an ESB. This gets around the security issues, and allows Firefox to be easily used on other instances just by attaching the ESB. Instructions for setting up Firefox this way can be found here: http://www.articleworld.org/index.php/How_to_run_Firefox_from_an_USB_stick

To get started download installers for the following applications:

Copy each of these installers to an ESB drive, and then shut down the current EC2 instance.

Setup the Base AMI image

I decided to base my build on the “Amazon Public Images – Basic Microsoft Windows Server 2003” image, though in theory any of the Windows based images could be used. One note of caution though – if the author of the image is not Amazon, then ask yourself whether you trust the author not to have built in any rogue elements to the image.

Once the image is fully booted, add the new ESB drive (for storing the application database files) to the instance first, followed by the ESB containing the installers. The timing and order of adding these drives is important. If you load the new ESB drive before the instance is fully booted then the instance gets a little confused and loads the ESB as D: rather than E: – causing inconsistencies later when we create new instances from the bundled AMI.

After formatting and installing the new ESBs, the instance setup should look something like this:

  • (C:) System drive containing the OS
  • (D:) 160GB Blank instance drive
  • (E:) 10GB+ Blank ESB drive for storing data
  • (G:) 10GB ESB drive containing our installation media

Other components that need to be installed before going any further are:

  • IIS
  • ASP.NET

In order to install the additional windows components, it is necessary to mount the Windows 2003 media. The following article contains a list of snapshots that can be used to create Elastic Storage Block volumes containing the windows installation disks:

Note: At this stage I’d recommend changing the Administrator password to something that you will remember next time … I had to restart my installation after finding that a bundled AMI does not seem to regenerate new passwords for instances 😦

Installing SQL Server

On our new EC2 instance install MagicDisc (or some other ISO mounting tool) and mount the SQL Server installers.

The key configuration variations from the defaults were as follows:

  • Setup the data directories for the SQL Server Instance to be stored on the E: drive.
  • Ensure that all SQL Server features you require are installed. Since this particular install is for TFS 2010, I’ve enabled Full Text Search, Analysis Services and Reporting Services.
  • Ensure that the SQL Server management studio is installed.

After the installation is complete, it pays to double check that all of the SQL Server folders on the E: drive have been assigned the correct permissions. I found with my install that I had to give the Network Service account some additional privileges in order to get the SQL Server services to start.

Installing Team Foundation Server 2010 Beta 2 (Pre-Configuration)

Installing Team Foundation Server 2010 has been described in many blog posts before, so I’m limiting the description in this post to the specifics of getting the install working on EC2.

Installation of TFS2010 is done in two steps; firstly the installer is run to setup the base application files, then the configuration tool is used to setup Team Foundation Server for use.

  1. Mount the Team Foundation Server 2010 Beta 2 ISO image
  2. Set the install location for the Features to the E: drive

Note: At this stage I’d recommend bundling an AMI from our progress so far. The configuration step for TFS (coming up next) can be a bit finicky … so having an easy rollback option is not a bad idea. If you do bundle the AMI at this stage, be sure to reload the ESB drives in the same order as last time.

Configuring Team Foundation Server

  1. Create a local service account to run the Team Foundation Service. I’ve called mine TFSServiceAccount.
  2. Start the Team Foundation Server Administration Console
  3. Enter the local user account setup in step 1 (TFS Service Account) to run the Team Foundation Server services.
  4. Select whether you are after a Basic or a Standard configuration scenario. Either way, all the defaults should be sufficient to get the installation working – though I did find I had to spend a bit of time sorting out IIS and the Reporting Server (since I’d make the mistake of installing SQL Server before IIS).

Setting up SQL Server Backups

Even though the SQL Server databases are being stored on Elastic Storage Block drives – there is still a chance that the ESB itself will fail. Don’t get me wrong … ESB is much safer than storing the data directly on the instance storage – but there is still a risk that it can be irretrievably lost. The following article by Michael Friss discusses the different backup strategies for SQL Server on an EC2 instance – and also includes a good PowerShell script for performing the backup and saving it to S3.

Any Comments …

I have to admit; I hit a number of issues performing this setup and had to restart the overall process three times. I’m sure there may be better ways to setup some of these features … especially the SQL Server components. I’d like to hear any feedback you’ve got, or what works well – so please leave a comment if you have any thoughts.

Advertisements

Author: Nick Hoggard

An architect working with the Microsoft development stack, my real interest lies in how we can utilise the tools we have to continuously improve our processes and quality.

11 thoughts on “Setting up a TFS Development Environment on Amazon EC2”

  1. Hi Nick,

    I’m looking at installing TFS on EC2 and wondered if you used Active Directory for user access control? Hod did you find it if you did?

    Are you able to point me towards some good blog posts that may help get me started?

    Cheers
    Neil

    1. Hi Neil,

      I did have a couple of attempts at building the EC2 TFS as a domain controller and using AD for UAC … however I encountered a couple of issues getting the DC running on the same box (part of my requirements were to run only one instance) so the eventual build is just based on the local windows accounts.

      That being the case I don’t have any real advice on your question. I can tell you that for the TFS 2010 beta 2 instance that we use in the office (ie, not on EC2) we are using domain based authentication reasonably smoothly. Depending on your domain configuration you should be able to add AD based users directly into the TFS security groups.

      Sorry I don’t have any useful advice for this. If you do happen to come across any useful details on this however I’d be very interested in the outcome.

      Cheers,

      Nick

  2. Hey Nick,

    Nice job getting this going in a usable fashion!

    I’ve run into a few issues as well, specifically with accessing the website from outside of ec2. Haven’t tried to connect VS to TFS yet… Has to be a security issue I’m missing somewhere. Any ideas, or would you be willing to post your base image(s) up on EC2?

    Thanks

    -Steve

    1. Hi Steve,

      Thanks for the feedback. Unfortunitely I can’t share the base image due to licensing on the box – but in general so long as you have your security group in EC2 setup to allow inbound traffic from your IP address on port 8080 (assuming default ports are used) then you should be ok.

      Are you able to reach the site in IE from your own machine? Does it get to the box and then give you a TFS permissions error … or is it just failing to get to the box at all?

      Cheers,

      Nick

      1. Hi Nick!

        I have exactly the same issue with TFS installed on EC2. I can’t access this TFS and web portal on that machine anywhere but on this machine. Did you manage to resolve this issue?

        Regards,
        Nikolay

      2. Hi Nikolay,

        Sorry for not getting back to you. Yes, I definately did manage to get the TFS access from external environments – I always had my Visual Studio instance connected from outside of Amazon into TFS. I also had the Web Access enabled.

        Did you configure port 8080 in the Amazon security groups?

        Cheers,

        Nick

  3. Hi Nick,

    I’m really interested in setting up an EC2 TFS in the same way you have, I’ve a few questions though.

    1. Are you just using TFS for source control, or do you make use TFS Build functionality?
    2. If you use TFS build how have you set-up your build controllers? Are they also in EC2?
    3. I’d also like to make use of Lab Management, but that all seems to require Hyper-V. I was thinking of getting a hosted Hyper-V environment, do you think it’s worth having an EC2 TFS server, or if we go for a hosted Hyper-v environment may as well put TFS in there too?

    Cheers,

    Jim.

    1. Hi Jim,

      Sorry – I don’t think that this will be much help to you …

      In answer to your questions above:
      1. On the EC2 instance of TFS I’m only using source control and work item functionallity. We do have the Build functionallity being used on-premise and deploying to EC2 instances however.
      2. As in 1) above, we aren’t actually using the build controllers on EC2, opting to run these from our on-premise TFS instance. The configuration is that builds are run by a local build agent, the deployed automatically using web deployment packages. In one of these cases the destination server is an Amazon EC2 instance, and we’ve found that this works just as well as deploying to a local instance. I have concidered writing some additional build tasks to stand up a new EC2 instance as part of the build, but to date this hasn’t been required.
      3. Sorry, I haven’t heard anything from MS on support for EC2. My understanding is that only Hyper-V environments are supported by lab manager. I would hope this would be extended to Azure at some stage … but that might be just wishfull thinking.

      Cheers,

      Nick

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s