Docker.io & Redis on DigitalOcean in 5mins

It all started when I casually spotted a sponsored tweet offering me $10 worth of virtual computing power from digital ocean. I had seen their ads on everything from Facebook to Gmail and thought I’d check out what the fuss was about.

I had been planning to try docker.io on something other than my macbook for a while and was tempted to run up another linode server. Instead I decided to see if I could get docker running on digitalocean.

Docker turned 0.6 over the weekend and is heading full speed towards a production grade container platform. If you are reading this post you probably already interested in docker but for the uninitiated docker allows you to ship applications as containers running in what appears to be self contained linux environments. Its is based upon linux container magic and runs within same operating system as its host.

So here is my guide to get docker 0.6.1 running on digital ocean vm (5 minutes starts now!)

First create a new droplet based upon the Ubuntu 13.04 x64 image

ImageCreate the droplet and within a minute or so you should be able to interact with your new machine. Your root password is emailed to the registered email address

Once it is created ssh directly on to the box as root, for me it was as simple as 

 ssh root@192.241.174.17

Now following docker’s install guide I ran

apt-get update
apt-get install linux-image-extra-`uname -r`

sh -c "curl http://get.docker.io/gpg | apt-key add -"

sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"

apt-get update
apt-get install lxc-docker

Which allowed me to run docker for the first time 

root@blog:~# docker version
Client version: 0.6.1
Server version: 0.6.1
Git commit: 5105263
Go version: go1.1.2
Last stable version: 0.6.1

Now to run something exciting, lets run redis

docker run -d johncosta/redis 

Install redis-cli on the host machine

apt-get install redis-server

redis-cli -h 192.241.174.17 -p 6379

Or connect from your macbook

brew install redis

redis-cli -h 192.241.174.17 -p 6379

Now time to play with redis

redis localhost:6379> set docker magic
OK
redis localhost:6379> get docker
"magic" 

5 minutes must be up by now!

Advertisements

Grails create link to homepage

After reading the Zeroturnaround’s bake off of modern jvm web framework I thought I would give Grails one last go. After all, in the report it beat the likes of Wicket, Spring, Play, etc

Intellij 12 made quick work of setting up a project and soon I had a functioning website. All good so far, I remembered my basic Rails/Grails knowledge from before and have to admit I was able to do a lot in a very short period of time. 

However one of the simplest links stopped me in my tracks and it took a disproportionate about of googling to figure it out. 

How to link to the homepage/root?

After much searching the best I got was

 <a href=”${createLink(uri: ‘/’)}”>home</a>

Easy once you see it!! Hopefully I will save you some the time too

Five Hours with ThoughtWorks Go

Introduction

After a day of looking after a sick child I had won enough brownie points to get a few solid hours of geek time on my computer. It’s the first time I have used my PC in anger since I installed Bias Lighting after reading Jeff Atwoods post earlier this month (http://www.codinghorror.com/blog/2011/11/bias-lighting.html). I bought the Antec Halo 6 LED Bias Lighting Kit and placed it on the back of my middle monitor. Two weeks later the lights have fallen off and are now doing a great job of lighting the floor underneath my desk.

But this is not a review on back lights; it’s a review on Thoughtwork’s agile release tool “Go”.  I believe it the reincarnation of Cruise Control, remember cruise control? I do, and I never liked it. Once I discovered TeamCity I was hooked and have never looked back.

However TeamCity is a build tool. It compiles code. It doesn’t care what you do with it, it doesn’t care about when you deploy, it doesn’t care about your team structure, it doesn’t care about release notes, etc. If you need any extra “team” features you will have to customize builds tools such as Ant/Gradle/Maven to accommodate your wishes. Who has the time? Well I know some teams do but the fast majority of development teams do not have the time to sit down and write custom team build tools.

What I need is to take a TeamCity style build tool but introduce the concept of

  • Environments
  • Release calendar,
  • Issue Tracker Integration
  • Team Structure
  • Release Notes
  • Code Quality View
  • Signoff

I had heard the Go was more than just a build server, it was a release management tool. It wasn’t just Cruise Control with a fancy UI, it was a one stop shop for your team’s release needs. So time to check it out…

There are two versions available, an Enterprise Server edition (no pricing on the site) and a Community Edition.  Nice to see that the community edition comes with LDAP integration, often the carrot to get development teams to purchase enterprise versions.

I wanted to get a feel for the full version so I downloaded and installed the Enterprise Version.

Installation

Installation on a Windows 7 machine was a breeze, I downloaded both the Server and Agent exe and installation was quick and painless. The server installation picked port 8153 (no option in the installation procedure to choose port) and the Agent only needed the IP address.

Once installed a browser was opened pointing to http://localhost:8153/go/home where I was asked to add a pipeline. I know, a good boy scout reads the manual (I wasn’t even able to find the manual later on!) but I hadn’t at this stage and really could have done with some on screen information explaining what a pipeline meant in this context.

I think, in Go’s parlance,  a pipeline is a grouping of units of work. For example if you had a complex procedure that included

Each stage would be modelled as a pipeline and could allow for quite elaborate release models

For this demo I originally wanted to build netty from its repository on github. Netty uses Maven and although I am not a fan of Maven I do have it on my machine. Every maven build I attempt rarely works out of the box, I always thought that was the point of maven!? Well netty didn’t work out of the box as it needed another repository added to it’s pom.xml and I had neither the will or the time to go fork the project and add it. I switched to a much simpler project called netty-examples, again maven backed but completely buildable out of the box. This is not a post on maven so back to Go!

The relationship of Pipeline to source to build step is as follows

I wonder will the limitation to only allow one source repository be considered a limitation? You can always tail on to other pipelines by selecting their source as your source.

Materials is almost the same as saying SCM but for the last option which is Pipeline. As mentioned pipeline allows you to chain on to previous pipeline’s source. The list of SCM available out of the box are

  • Git
  • Subversion
  • Mercurial
  • Perforce

Surprised not to see CVS here, it’s still very popular! Materials added it is time to add the build job

Here we can add the build job, its time to compile the code. The Tasks types can be

  • Ant / Nant
  • Rake
  • Custom Command

No Maven, this is where I started to regret picking a maven based project, but a quick custom command with maven later and we were up and running.

Before I built the project I decided to take a closer look at the environments option of the tool. Predictable no environments were present and I was expecting the ability to define exactly

what an environment meant to my team. I was disappointed!

The environment relationship is as follows

It is pretty simplistic and lacked the sophistication I was hoping for. Yes I understand you can change anything with environmental variables but I was hoping to move away from name value pairs and into something more structured. I created an environment for each of the stages in my pretend team.

I assigned the build pipeline to the development environment and pressed the build project. Several iterations later, I had dropped netty for netty-example and I had a working build

Here is a view from build console

And finally a glowing green light to give any technical a warm and fuzzy feeling

So far we have a build that is linked to an environment and looking at the environment dashboard you can get a great overview of where your different stages are at

And once you spend the time to configure everything you can start to see where Go is different to other build servers

Conclusion

I would have to spend more time with Go to really be able to give it a proper evaluation, five hours is just not enough to make an informed decision on its usefulness to a global development team. I do like the concept of environments this is probably the one killer feature of the product that sets it apart from all the other build servers I have used. I feel it could have been more sophisticated in terms of environment definition but the environment variables do allow you to achieve all I would really need.

I felt its core build infrastructure was not as mature or as powerful as TeamCity. It lacked the feature set that TeamCity has to offer out of the box. TeamCity caters for almost anything you can throw at it and has great integration with most build tools and plugins.

I don’t think I will be dropping TeamCity in favour of Go any time soon but I will continue to monitor the product. You can download a copy from http://www.thoughtworks-studios.com/go-agile-release-management