{0} ok boot

[okboot]

UUID Cheating in Bash

Did this at work today:

sha=$(echo -n "<some string>" | sha256sum | awk '{print $1}'); echo ${sha:0:8}-${sha:8:4}-${sha:12:4}-${sha:16:4}-${sha:20:12}

Transforms a SHA256 into a UUID. Not technically correct ;)

[okboot]

Easy Shell Arrays

I find the ‘correct’ syntax for arrays in Bash a bit annoying to remember and/or work with, and I recently found a nice workaround:

for item in $(echo -n foo bar) do   echo “item is $item” done

[okboot]

Getting Shell in a Brand-new Triton Container in About 30 Seconds

Getting shell in a new Triton container is very fast:

https://gist.github.com/bixu/28059772f42f9dcb92227ccd0a62299f

[okboot]

loading a custom `.toml` file into a Habitat service

Passing a single environment variable to a Habitat service is pretty straightforward, but if you need to pass in a larger number of vars it can simplify things to wrap it all up in a tiny shell script. Here’s how I did it for my work with Postgres replication. First, the variables themselves in TOML format:

https://gist.github.com/bixu/c909aa09299a345fa14f1247e55f17eb

Then, the wrapper that (in this case) gets called by systemd’s service management:

https://gist.github.com/bixu/9ced3b8456dddf9033135a38e581b599

And finally, the systemd service definition that starts/stops the Habitat-manged Postgres:

https://gist.github.com/bixu/2c5922cd1bae8d18743328eeb5e1246e

[okboot]

running postgres with habitat and docker

Habitat is the build system/supervisor/config management tool that fills in the gaps Docker leaves for me. Still, running a “habitized” app in Docker is really useful (Habitat’s own build studio runs in a Docker container). When hacking on Postgres, I found I needed to launch my Postgres Habitat package this way to get around container limitations:

https://gist.github.com/bixu/444ab5fe94a008515d7aab0e4359a746

[okboot]

three reasons i use the best cloud you’ve never heard of

I’ve been running workloads in the cloud since fairly early days in the industry (circa 2007), and like most of us in the industry started on AWS, yet I left AWS and have spent the better part of a decade running most of my production workloads on Joyent infrastructure and software. (Not pet projects either: many millions of dollars and many millions of users/clients/customers.)

So why Joyent and not AWS, Azure or Google Cloud?

1. I’m pro-choice. The big cloud and *aaS providers are Microsoft-in-the-90s all over again. Instead of proprietary software and data-format lock-in we now get trapped by services lock-in. Open-source software won the battle against closed binaries and formats (liberating our data for a short while), but our bits are now tangled up in services that the provider, not the customer, controls. Joyent is an exception here; their stack is entirely open-source (even their hardware builds), so lock-in is impossible.

2. Efficiency matters. Planet Earth has always been a closed system, it’s just more obvious now. The new imperative that we lower the environmental and financial footprint of our compute workloads demands a focus on effeciency. Joyent CTO Bryan Cantrill jokes that running workloads with multiple nested layers of virtualization “makes God angry”—it should make you angry too! Joyent’s stack lets us run directly on the metal, and their Dtrace-everywhere approach means you can safely lower your operating footprint through performance optimization in live production. (And you can save a shit-ton of money.)

3. Tools should reward the user. I get satisfaction from using well-designed (Containers-and-Dtrace-everywhere), effective  (ZFS-and-Crossbow-everywhere) tools and I’d hazard that all serious engineers feel the same way. I strongly believe this sense of satisfaction is one of the biggest reasons the OSS and Unix movements prevailed against all odds—users put up with steep learning curves and sharp edges in the early days because the tools were their own reward. If you’re an engineer, don’t be shy about admitting that good tools get you buzzed (c’mon, admit it, this may not be true of the business logic in your e-commerce app). If you’re leading an engineering team or if your business depends on engineers, acknowledge that satisfied tool-users will yield substantial payoffs in engagement, retention and product quality. If you’re either an implementer or a leader (or both!), you owe it to yourself to give Joyent’s stack a try.

[okboot]

testing (slow) docker builds with serverspec

One needs to extend Excon timeouts to keep the docker-api gem from timing out waiting for long builds:

https://gist.github.com/bixu/299e1e642a7ec3afd39f

And an example of specs running against our Dockerfile:

https://gist.github.com/bixu/9b73da8e7a3a61c1ff72