Haven Launched!

Haven is an open source Docker container orchestration and management tool built here at Code Above Lab. We decided to open source it because there was not a similar product available for people who just want to get started on Docker. Everything was starting to require more investment in time and effort to learn and setup.

Haven was started out of necessity to let our clients manage the micro-service platform that we built for them. As common users of  micro-service architecture, we saw the tremendous complementary potential the two technologies have so our adoption started very early on. Unfortunately, as with all new technology, many issues ended up in “doh!” moments. Especially when it comes to orchestration and image management, some of our clients who have a smaller IT/DevOps teams had a harder time to deal with, partly because the expertise required are so particular. Some tried adopting Kubernetes, which is very a very popular container orchestration tool now, but the complicated setup process and the “sophisticated” features contributed to a steep learning curve. In the end, all they wanted to do is to be able to deploy, update, and remove application images.

Haven was our solution to helping our customer get up and running quickly and as painless as possible. We built it on top of Docker Swarm to take advantage of the seamless integration with the Docker base. We re-used many of the traditional clustering methodologies to avoid any steep learning barriers.  Also, we mashed together the image management capabilities onto our platform to make it easier for admins to update new images. (We could not figure out why anyone would want to separate these two areas of functionalities!)   What we ended up with is a new breed of orchestration tool.

Over the past year, we have added many new features.  We will introduce each in a subsequent blog post.  Let me start by introducing our Cluster-based Container Management:

Haven Dashboard – see all nodes/cluster and resource usages

Cluster-based Container Management

We pattern our cluster after Swarm clusters.  Everything that Swarm cluster can do you can do with Haven clusters. We added a few more features that we found lacking:

  • Having configuration for the images (with or without version) for the cluster and preferably store data in a version control system. You can store compose file for each cluster, but there are number of issues (now there is docker stack which solves some of the problems)
  • Additional policies/constraints for swarm – for example there are 4 nodes with different containers and we need to deploy 4 instance of a particular container, swarm will launch one at instance per node only if they use same port .
  • Event Auditing – Containers comes and goes, and we found the transient nature of them sometimes very disorienting.  We wanted to see what has happened with the containers within the cluster.  For example, we should know when and who restarted the Postgres container

    Cluster Event Audit Log – see all system events generated in the cluster
  • Image Update Scheduler – Each container can be scheduled to be updated to the latest version of the image.  This feature is useful especially for testing environments where latest source needs to be tested immediately.  For production, it can also be used by scheduling only certain percentage of the deployed instances be updated to the latest version so that if there are any issues, the entire system would not be down.
Update container Dialog -setup and schedule automatic version updating of images
  • Rollback support – Let user easily rollback to the previously deployed version if the new version has issues.
  • Container Cloning – This feature was sorely missed because we experiment a lot with containers’ parameters for tuning performance. This is an easy way to “clone” an existing containers but have the ability to make a few tweaks to the configuration before launching. You don’t need to create a Compose file just for that anymore.
  • Creating/deleting tags, for example: some images were tested at QA, they should be marked as ready for prod and only such images should be visible on the prod cluster,  for that registries have filters
  • Cluster Configuration Backup – We let user download the entire cluster in YML file format so the entire cluster can be re-deployed on another Haven instance.

If you’re looking to try it out, head over to our GitHub project and let us know if you have any trouble getting started by.  You can also get it off of Docker Hub.

Hello world!

Thanks for visiting Code Above Lab’s blog.   I started Code Above Lab over three years ago, pretty much accidentally.  I’ve been through 4 or so start-ups in the previous seven years and was a bit burned out.  As I was preparing to take a hibernation stint, a close college friend of mine asked if I could help with one of his outsourced UI project that was bursting in flames…

On fire!!
On fire!! (Photo Courtesy of Wikipedia)

Apparently, his predecessor thought it was a good idea to outsource to an offshore firm without the need for supervision other than a cursory look of the user interface. One look at the source code sends shivers up my spine. What the team had produced looked great from the UI, but the underlining code was so entangled and duplicated that I knew fixing one bugs was going to introduce new bugs. However, it was still somewhat salvageable if we can make some surgical separation of components, so I grudgingly signed up to help. To make a long story short, we ended up putting out the fire component-by-component, rewriting and abstracting along the way. It was the beginning of many on-fire projects that I ended up rescuing over the years.

That accidental consulting experience started the seed for Code Above Lab. I realized that there are a lot of projects that needed help. They get in trouble for some reasons, but all comes down to not following simple design principles and best practices (like following coding convention and write test cases). I was lucky to have worked with top-tier engineers early in my career (Thank you Netscape!) and continued to build upon that over the years. Now after weathering two tech booms, I, along with the team of firefighting engineers, have enough experience and tools on our utility belt help rescue companies that have projects on fire. Yes, we do feel like a superhero sometimes.