On 16th of May new major release of Ansible has landed. For a very long time I was a proponent and happy user of SaltStack. I still have a soft spot for it and some formulas lying here and there. At some point, however, I gave Ansible a chance and, while it was not exactly trouble-free (I had quite a few habits from Salt), once it clicked, it stayed and is my number one automation tool period.

It’s a huge release, so many things are mentioned in the release notes that it wouldn’t make sense to go through all of them here and now. That said, there’s one thing that I was really looking forward to: python interpreter discovery. It’s surprising how annoying this one can be in a mixed distro/version environment. Finally no need for some hacky solutions! 🎉

UPDATE (April 26, 2019): this post has been updated to include latest changes made to the project. You can jump directly to it here →

I was lucky enough that in relatively early time in my career I bet on NGINX as my default HTTP server and essentially never looked back. Sure enough, I started with using it as reverse-proxy in front of Apache, but once it matured enough and I felt confident it can be trusted with essentially any HTTP-related task, I switched entirely. It was a long time ago and NGINX has made some tremendous progress since then. While its adoption didn’t exceed Apache so far, it’s in the second place for quite some time now and growing in numbers each month. I was always fond of it being so lightweight and I preferred usage of FastCGI protocol instead of native/built-in one as it was the case with Apache at that time.

The caveat is that, while being Open Source application, there are some functionalities that are available only for the paying customers (NGINX Plus). I don’t mind this kind of business model. After all, this is a great application and I hope it will stay around for years to come and the only way to achieve that goal is to keep it sustainable, financially-wise. On the other hand, I’m not able to afford NGINX Plus subscription model (especially for private use-case like mine). Fortunately enough, there are some NGINX enthusiasts out there that are creating 3rd party modules for their favourite HTTP server. Quite a few of them.

There are so many ways these days to start a local VM on the Mac that adding yet another one seems insane. And yet, Multipass from Canonical¹ appeals to me the most. Especially when it’s just a quick check that I need to make – it’s as simple as two commands and voilà, it’s working and ready to roll.

With the new version I really am looking forward for starting automatically the instance via multipass shell command – it’s safe to say that it was the only thing I was missing.

Please note that Multipass works solely with Ubuntu instances. It is cross-platform however and one can use it on Windows, macOS and Linux.

Last time I mentioned that I was working on a central syslog. Part of the task was also possibility to easily go through the logs, preferably with some filtering and what not. ELK-stack is usually the first thing mentioned as a potential solution. Essentially the goal is to land your logs in Elasticsearch. The problem with both of these solutions is on the processing part. With Logstash things can go very wrong very quickly and there’s only handful of other things than _grokparsefailure that can seriously put me into rage mode.

Grafana is one of my favourite Open Source software of all time. I’ve been using it for years and am thrilled to see yet another great major release. I’m really looking forward to put my hands on all new workflow called Explore. Currently it integrates with Loki, but support for Elasticsearch is already on the roadmap!