This post has been a long time coming. For about 2 years, configuration plans (Also known as wrapper plans) have been a critical part of how I use and deploy Habitat plans/artifacts in the wild. They’re a super easy way to encapsulate some required software and bundle your own configuration. For some reason, finding information about this approach has previously been difficult due to a lack of documentation.
Here’s an example of configuration plans for Habitat.
Monitoring is easy. Monitoring is also very difficult.
At what point do you stop adding checks to your service? And where can you start if you have none?
My process is simple, but by no means the only way to assess and monitor your systems. Everyone has their own special requirements, environments and experience. This is how I break up service checks for a networked service hosting some application. Its worked well for me, but I’d love to hear how other people approach the same problem.
I’ve been contributing to Habitat for a little while now. Mostly in the capacity of contributions to core-plans, but occasionally some changes to the on-premise-builder and the Habitat project itself. I’ve posted about my reasons for preferring Habitat previously, today I want to focus on the evolution of my testing for Habitat.
Initial testing, no automation The initial testing is similar to what all developers would currently be doing as they engage in Habitat day to day:
I recently did a complete overhaul of my website.
The previous version was built with CakePHP, as a demonstration as I was working closed with CakePHP. Times change, and so do trends, and I try to keep ahead of it. Static site generators are gaining more popularity. I’ve been eyeing Hugo for some time, and decided it was time to refresh my website and try some new deployment options while I was at it.
I’ve been using Habitat (by Chef) since its initial release. That makes it approximately 2 years. I’ve been using it more seriously in the past year, after a visit from Habitat engineers, and opportunities to engage with it in my regular work. Additionally I’ve been able to sink a bit of personal time into it. But what is it?
Habitat is 3 primary things to me:
Portable application builds! Networked, cluster-aware process supervisor Release / deployment management These are all HUGE for any application developer.
I’m increasingly interested in the use and application of Perlin and Simplex style noise generation to real world problems, and even moreso for the simulation of real world environments. This has come from my personal side projects in game development. If you’re not familiar with noise generation like Perlin and Simplex noise, a quick Google Search will show you all you need.
All you really need to know about Perlin noise for article is that it can be used and manipulated to generate random terrain thats reasonably smooth and realistic.
Yeah yeah.. You’ve heard it all before. Terrain generation. Perlin noise. All that jazz. Yes, well, I have gone and done it again, and I have used this attempt at 2D terrain generation to try and get a better understanding of the control I have over Perlin noise, and how to sculpt it to represent terrain that looks and feels real.
I’m using Processing in this example, as its a nice and quick way to get some graphics output and lets me focus on the math side of things.
