Most people don’t like flying, I think. No one likes standing in long lines or sitting around, but I don’t mind the extra free hours. It gives me a chance to hack around on fun things I normally wouldn’t have the time for. I’m on my way back home from San Francisco, so I took advantage of the time to start hacking around with building a simple RPC protocol in OpenResty. It’s been a good chance to work with binary data and exercise the Nginx stream module. Tossing some notes and snippets in here as an outlet; I’m hoping to have a more formal follow-up in a few weekends as life starts to settle back to normal.
Recently I’ve been exploring Consul’s Events mechanism as a way to propagate broadcast data across our infrastructure. It’s a useful pipeline, given our existing use of Consul- message systems like NATS or similar might be a more purpose-built solution, but being able to leverage existing infrastructure and code lets us deploy new solutions quickly and cheaply.
Until (somewhat) recently, Nginx development was somewhat of an adventurous journey. Official documentation was largely nonexistent; Evan Miller’s decade-old guide was the often-referenced canonical source of material. Publication of an authoritative development guide came only a few years ago, significantly lowering the bar to entry for third party developers. It’s an excellent source of material, but it doesn’t cover every aspect of authoring and extending Nginx, meaning that complex or uncommon features still require a bit of blog browsing, copypasta, and diving into the Nginx source to figure out what’s going on.
Module feature testing is one of these aspects. Writing simple Nginx modules is straightforward, but discussion of module config files is often glossed over or ignored entirely. The canonical development guide does a reasonable job of touching on some of the functionality and definitions available to config files, but it’s short on examples, and it ignores a crucial aspect of developing complex modules or integrations with third party libraries: feature testing.
str1 == str2
No, really, it’s that easy.
This year I’ve moved from a systems/security engineering position, sometimes dabbling in development and hacking away at some small projects, to a full-time software engineering role. It’s a welcome change, broadening my scope significantly, and I’m looking forward to continue engaging in multiple open source projects with a fresh mindset. Doing so has been a good opportunity to examine not only new processes and paradigms, but how various styles and limitations in associated communications can impact both a project, and its members. In particular, I’ve found that code reviews, both in open and closed source environments, can bring significant challenges to interpersonal and inter-team communication; these challenges are exacerbated when communication occurs between new and experienced members on a team. Following is a smattering of thoughts on maintaining helpful, productive communication as part of the code review process:
What’s a fast way to insert a large number of elements into a Lua table? What’s the fastest way? And what’s faster than that? There’s a lot of discussion and advice floating around regarding such a primitive topic, so it’s time to dig into some implementation details. We’ll look briefly at a few idiomatic approaches, and discuss the compilation, results, and drawbacks of each.
Working on a WAF solution for the Nginx ecosystem provides a lot of opportunities for discussion, given that such work is a meeting of crossroads. Mixing high-performance engineering, WAF technologies, ModSecurity DSL, and the OpenResty community puts lua-resty-waf in a unique context. I often get asked about other WAF solutions for Nginx, including Naxsi, and how these solutions compare to ModSecurity, lua-resty-waf (and other security OpenResty libs), and commercial solutions. I haven’t spent a lot of time working with the Naxsi project, but I’ve poked at it enough to at least start putting some thoughts on paper.
OpenResty’s biggest selling point is its performance. Embedding Lua allows for some pretty cool new features to pop into a simple Nginx proxy, and the synchronous but non-blocking paradigm introduced by hooking into the event loop (thanks, epoll!) is awesome, but the OpenResty stack as a whole really shines when everything is tied together under the umbrella of approaching, crossing, and then shattering C10k. Out of the box, Lua code embedded into any number of phase handlers runs at an impressive speed, and with the flick of a switch, we can really kick things into high gear.
In recent weeks I’ve found the need to configure and deploy a proper load balancing solution for an authoritative DNS cluster. Now for most solutions (up to a certain scale, and you’d know if you were there) a single-purpose authoritative DNS resolver doesn’t really need a balancing frontend; you can reasonably expect a decent-sized box running a modern kernel to handle several hundred thousand UDP packets per second, with a minimal amount of complimentary TCP traffic. Putting a frontend load balancing tier in front of an authoritative DNS cluster is really only necessary when either hardware redundancy or significant traffic shaping is a requirement, or the generation of authoritative data is expensive and needs to be horizontally scalable. I found myself needing to satisfy a few of these conditions, and have had a wonderful time playing and poking at a purpose-built FOSS DNS load balancing solution in dnsdist.
Perhaps one of the most powerful primatives that lua-nginx-module provides out of the box is a sane, simple wrapper for regular expression operations (via PCRE). String matching, replacing (and now splitting!) via regex allows for much greater flexibility in string processing than Lua’s native string library. Recently while cleaning up an OpenResty InfluxDB client I needed to do some simple string comparison. My knee-jerk reaction was to use a simple expression in
ngx.re.find, but I had a hunch that the overhead of using the PCRE lib would be a waste, and that native Lua pattern searches would be quicker. Time for a benchmark to figure out the most sane solution!