Docker, Kubernetes and everything else related to containers are gaining every day more traction and after a somewhat slow start this seems to be “the next big thing” and everybody is rushing to support it. Microsoft, a late adopter, is now throwing everything it has to it while Red Hat and Google already have a solid offerings with OpenShift and GKE.
On a smaller scale I’m using plain Docker “in production” on my VPS since 2015 and it really changes your workflow, thus making really easy having multiple applications running on the same VPS without interferences. At first it’s quite painful but once that everything runs smoothly your continuous deployment pipeline works like a charm and you don’t have to worry about strange interactions caused by sharing the same OS.
The step up from Docker is using it with an orchestrator to manage multiple nodes. I used my MSDN Azure credits to try Docker Swarm, OpenShift Origin and Kubernetes but I always felt that something was missing: it works, it works great but you can’t really understand what’s going on under the hood. At the Voxxed Lugano I watched Nicola Ferraro’s presentation on OpenShift (a must see if you haven’t seen it) and he was talking about, among other things, about a Raspberry Pi cluster. That’s when something clicked in my mind and I decided to build my own following a couple of very well done tutorials that I found around.
Almost two years since the last post it’s time to refresh my website and write about something else. Most of these two years have been spent on my first true and mid-sized open source project along with two friends: Lavagna.
Lavagna is “an open-source issue/project management tool designed for small teams. Lightweight, pure Java, easy to install, easy to use.” This project allowed me to explore many areas and I’d like to write some posts about the most interesting topics because I find them useful to everybody who wants to start an open source project.
The first post is about wrapping a Spring application in a Windows Service, this is must have if you want to deploy your project also on Windows and surprisingly I didn’t find many articles about it.
Everybody has is preferred cloud storage provider, there are so many out there that almost every person uses more than one. As main provider I used Wuala for years, the client side encryption give them an edge over the competitors. Unfortunately Wuala’s weak spot is the client, I use a Mac and every time I upgrade the OS there is some strange issue related to the fact that you have to install Java 6 (7 or 8 are simply ignored). As soon as I installed Yosemite Wuala stopped working so I headed to their forums to ask for help but the only thing that I found was a “you’re using a beta, it’s your fault” attitude. This prompted me to search for alternatives but I didn’t like the idea to send my personal files to a provider that can easily read them. After Googling around I stumbled in OwnCloud and I decided to try it on my Linode VPS.
I just discovered Vagrant thanks to a great talk of Thijs Feryn at the Techorama. If you don’t know it Vagrant is a software to “Create and configure lightweight, reproducible, and portable development environments” and since I wanted to test different databases without having to install them on my machine I decided to try it.
One of the best advantages of running your own VPS is that you have complete freedom on what you can run on it. In my case I installed Jenkins and SonarQube because since the last free upgrade from Linode (SSDs and double RAM!) I can run them without problems. This post is about configuring these services to use SSL thanks to NGINX.
Since a friend showed me SonarQube I loved it: the amount of reports that you can gather from it and the immediate impact on improving the code is simply awesome. As an example in just a couple of weeks at work we’ve been able to gain a +10% of code coverage and remove all the complexity on a critical area.
Ever since NCrunch had gone commercial I searched for a cheaper alternative and some time ago I came across a great article named “Building .NET Coverage Tool”. After reading the article I decided to try to implement a similar tool that I named AutoCover.