Part Two.. Installing team city into Rancher via docker hub

Note : If you’ve reached this page directly, it’s advised to complete part one of tutorial. Part one covers creating the environment needed to begin deployment of your first container. The installation of process of teamcity once running is also not covered.

Although containers can be installed directly onto hosts I’d advise working at the service level. Services allow more advanced rules for provisioning to be applied and generally make day to day activities easier.

The first part of the process is creating a stack. A stack can contain a range of container types and instances.

I called mine “ContinuousIntegration”Stack.PNG

This is how eventually how your stack will look. In order to create the server click “Add Service”.addservice.PNG

Creating a service looks something like this :  CreateBuildServer.png

  1. Give the service a sensible name.
  2. “Select Image” needs to be set to “aerofs/teamcity”
  3. Ensure port 8111 is open on both public host and mapped to the private container port.
  4. In the networking tab ensure a hostname is specified you’ll need this later when adding a build agent.

Click “Create”.

By default no containers will be provisioned click the “Play” button.playservice.PNG

Next click the service name to drill into the service and the finally on the container name.containerrunning.PNG

Finally paste the “Host IP” followed by “:8111” into a browser and if all’s well teamcity should appear.

In the next part I’ll cover provisioning a build agent.



Teamcity (CI), ASP.Net 5, via Docker on Linux PT(1)


Recently I’d set myself the challenge of developing and deploying applications via docker on Linux. An odd challenge yet rewarding!

This series will focus on ultimately how I managed to achieve this and also document some of the pitfalls I fell victim to on the journey.

What I’m attempting here is very much prerelease and is subject to change with some issues being focussed on specific version(s) of frameworks and applications.

Goals :

  • Everything runs / built on Linux, but continues to be cross platform.
  • Everything managed and deployed within docker.

Disclaimer : I’m a complete noob in the Linux world, what I’ve done probably isn’t 100% ideal but hey it works 🙂

Part one… How do I manage all this infrastructure?

The first piece of the puzzle is an excellent containerisation technology called “Docker”. Currently it’s purely in the non windows space but come 2016 windows will have a compatible offering.

If this is completely new I’d suggest spending a few minutes looking around :

Not being keen on managing everything via bash in Ubuntu, it was time to look for platform to assist. This tool was Rancher.

Rancher allows servers across any provider to be treated as one via an overlay network. It’s firmly aimed at managing application stacks and I love it! Needless to say I’ll be migrating everything I run onto this platform. Rancher is easy, clear and well thought out.

With this in mind I needed somewhere to host and I settled on Digital Ocean (Use the promotion code ACTIVATE10 for $10 credit) .

Account created I followed this article Multinode deployments with docker.

Upon completion this screen should greet you:


In the next post I’ll focus on installing team city as a build server.

Technical debt

What is technical debt?

Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of any system design, software architecture or software development within a code base.

Recently I’ve been hearing the phrase used much more often, sometimes it’s setting the scene by a developer before a rushed fix is put into place, or how poor code is explained in a system. I accept this as part of software development but hearing this phrase from non technical people causes me concern.

Is this acceptable? Hearing that it’s OK to incur technical debt to deliver a project early I think not. Debt used to be a word that had respect, folks didn’t want debt but a change in attitude with a pay it back later mentality is something people are more comfortable with in the modern world.

In my experience the intention is always to return and pay it back, but rarely does this happen. The realisation of reducing the ability to deliver change to a customer base isn’t acceptable. But just like any debts the issue compounds until it’s unmanageable.

Working on a code base full of technical debt is uninspiring and saps the life out of all that surround it, and once it’s acceptable to allow the debt more will almost always follow.

Don’t be afraid to re-factor and redesign, sometimes it will punch you in jewels but learn, embrace and improve. Working within an environment that holds these values close breeds a sense of ownership and pride and ultimately promotes good practice to all.

Without debt holding change back, delivery will flourish and accomplishment will bring pride and courage.

AppHarbour – Azure done right?

What is it?
App harbour is a new kid on the block providing platform as a service backed by the resilience of Amazon’s cloud platform. For sometime they boasted it was “Azure done right” a very large claim to be make.

How does it work?
Appharbour directly integrates with source control and upon checkin it will pull the latest code base, build, run unit tests and deploy.

On top of this a Web interface is available that allows you to scale and rollback applications as required.

A free version is available to get running so it’s a good place to test and try new ideas.

Appharbour provides integrations directly into various source control providers including :

  1. Codeplex
  2. Bitbucket
  3. Github

For other source control providers an API is available to allow custom integrations.

Something that’s particularly nice is the provider market place, from here there are many additional options that can bolted onto your account such as:

  1. Memcache
  2. Raven DB
  3. Sql Server

Each of these features also has a free option so you can try before you buy, something I find very useful.

The marketplace is also open, so new providers should have no problem integrating onto the platform.

The main benefits with the system has to revolve around the one touch deployment, the automation process of build to deployment allows for a high degree of confidence that what’s deployed matches source control.

No matter how many nodes are required to run your application deployment is dealt with, another nice feature of the whole process is that rollbacks also become a breeze. Released a version that’s got a show stopping bug, rolling back to the previous version becomes a simple click in the web interface.


Appharbour is a new kid on the block and doesn’t have the backing that other platforms have from the likes of Microsoft and Amazon.

As with anything in the cloud an investment is required and Appharbour is no different, but looking at $100 investment just to get IP-Based SSL could be a show stopper for individuals looking to boot strap an idea. The top level package at the time of writing is $199. This gets you 4 workers and Ip-Based SSL this service could be provided elsewhere for less, but I believe the benefits of the platform can outweigh this cost.


After a short amount of time the benefits of the platform quickly become apparent. Using naming conventions when naming solutions allows control over the application to be deployed. Within a single solution using a SQL Azure backend, I had a project that could be deployed either to Azure or Appharbour with almost all deployment hassle removed. With the current lowest service plan being free it’s definitely worth a look.

TransactionScope and Serializable

When using transaction scopes and SQL connections I recently tripped over a undesirable effect. By default when creating a new transaction scope the connection is raised to serializable. I can see the logic in this, as it provides the safest starting point and allows the developer to change the behaviour after careful consideration.

A quick explanation of serializable isolation level : Transactions occur isolated and sequential. However this is just an illusion and other transactions maybe running alongside but only if the database can maintain the façade of running in an isolated manner.

I first noticed the issue when monitoring the connection pool, there were many connections that had an isolation level above what I expected, it turns out that once the isolation level was raised by enlisting in the transaction scope the isolation was not being set back to read committed.

To work around this you need to Execute “SET TRANSACTION ISOLATION LEVEL” on the connection before releasing, or turn off connection pooling (Which I wouldn’t recommend without a very good reason, establishing a database connection is an expensive operation).

Saving SSD space and Mac OSX Lion

Recently I brought a new top of the line Macbook Pro and I’m very happy with it. But with prices being what they are I opted for the 128 gig SSD. I’ve moved all non essential files elsewhere and about ready to install windows 7 for my normal development environment.

While analyzing used space on the harddisk I noticed a 4.2 gig file sitting in /private/var/vm, sleepimage.

It turns out that this file is always the slightly larger than the amount of RAM in your machine, and isn’t really required for machines with SSD’s installed. Infact it can damage the life of the SSD.

As with anything like this I can’t be held responsible for any damage blah blah blah :-).

From Terminal:

  • $ pmset -g | grep hibernatemode (Hopefully the mode is set to 3, if not then don’t continue).
  • $ sudo pmset -a hibernatemode 0
  • cd /var/vm
  • sudo rm sleepimage

You should now have reclaimed some valuable space.

Fancybox with Jquery and partial views

Recently I’ve been working on a site redesign and I thought a nice little feature would be to have a fancybox (read lightbox) and inside there provide some basic site statistics, current user count etc.

So the aim is to have a fancybox appear with it’s content loaded via ajax from a partial view on the server. The content will appear when a button is clicked on the page.

I’ll be using the following :

Partial View

public PartialViewResult p_popup()
   return PartialView();


$(document).ready(function() {
   $("#menuButton").click(function() {
      // Close the overall model
      // Open a fancybox
         url: '/fb/p_popup',
         type: 'POST',
         data: '',
         success: function (data) {

And that’s it, I prefer this method to using templates on the client side. In a follow up to this I’ll deal with posting back from forms with validation.