Wow! This year during ChefConf 2019 I was awarded as an “Awesome Community Chef” by the Chef community! For the past 2 years or so, I’ve been putting in a lot of personal time and effort to contribute back to the Habitat project, by way of the central core-plans repository. From here, I’m able to help maintain, update, fix and strengthen software that is used by countless developers and operators around the world.
Nginx is a truly powerful, efficient, configurable web server. I’ve been using it for over 12 years. But for the longest time, I’ve been relying on simple configuration and basic rule sets to get by. While that’s no problem, I wanted to share what I have learned recently with map and geo usage in Nginx configuration. I feel the Nginx documentation is loosely sufficient, but could do with some more examples.
You’ve got a modern server, its got systemd, journalctl, and you have Habitat supervisor running a Caddy webserver. What an amazing setup of great technology! Gluing these pieces together is easy, but I’ve found a couple of places where I wish documentation had been better. This post serves as a notice to myself and anyone else that is interested in how to get goaccess working in this new modern ecosystem.
Habitat’s core-plans is the central repository for packages/plans maintained by a group of volunteers. These plans form the basis of pretty much everything built with Habitat. From low level libraries and tools such as GCC, glibc, openssl to high level applications like Jenkins, Artifactory, and a whole range of others. The full list can be seen in the Github repository. Theres a bunch of things that happens behind the scenes of your pull request on the Habitat core-plans repository.
I’ve posted a few times on the topic of Habitat. I feel its the most promising solution for software package management, and deployment available today. If I have managed to help sway you, and thus you’re interested in adopting Habitat, you may find yourself faced with a relatively daunting task. Migrating a working, functional system from one underlying layer to another is risky, potentially disruptive, and time consuming. All these reasons are why successful financial and enterprise businesses tend to have a slow rate of change.
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.
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!