talkingquickly

In this post we cover how to install OpenLDAP on Kubernetes and how to test that it is working using the command line.

LDAP while an older - and in some ways more challenging to work with - approach to SSO than something like OIDC, is still the de-facto standard.

There are many popular applications which don't support OIDC but do support LDAP. This is likely to be the case for many years to come so for now, any robust SSO solution is likely to need to support LDAP.

This post is part of a series on single sign on for Kubernetes

Keycloak is a widely used open source identity and access management system. Think Okta but open source. This is where users will actually enter their username and password for services and where we'll configure which users can login to which applications. It will also provide users with a single directory of applications they can login to.

In this post - as part of the larger series on Kubernetes SSO - we cover how to install Keycloak on Kubernetes.

While creating the comprehensive guide to Kubernetes SSO, I leant heavily on many great pieces of existing content, a lot of them are included here.

One of the things VSCode has done extremely well is creating a seamless remote development experience. Using the remote extension pack, specifically the SSH development extension, it's possible to run VSCode locally, while performing all actions on a remote server completely seamlessly. This allows us to use a local VM for much faster docker development on macOS. It also means we are free to spin up powerful Cloud VM's with many cores and plenty of RAM when we're working on more intensive tasks.

With this setup I seamlessly switch between fully local development using a Virtualbox VM and a 16 core cloud VM with 64GB of RAM when I need more horsepower. In both environments this provides the level of Docker performance I associate with developing directly on Linux machines.

This is streamlined using an Ansible playbook which automatically sets up Debian VM's with sensible defaults for development, including a beautiful default ZSH configuration (inc auto-completions) and easy language version management with asdf. This post starts with the practical steps required for this setup, and then goes on to explain what's being installed and how it works.

SSH agent forwarding is kind of like magic. Say you're using VSCode remote development to develop on a remote VM and you want to pull from a private repository. By default you might either generate a new keypair on the remote machine and add them to Github. Or you might copy your existing private key to the remote development machine. The former is fiddly and the latter raises some security concerns. With SSH Agent Forwarding you can allow the remote machine to authenticate requests using the keys on your local machine, without the keys ever leaving your local machine.

One hiccup with this is that if you're a tmux user, you'll find that this works initially but then stops working in subsequent sessions. This post offers a simple solution to this.

Manual repetitive tasks are my nemesis and setting up a new Macbook from scratch is a prime example of this. Using Ansible we can completely automate this process. This is valuable both for individual efficiency and for facilitating standardised "team setups" so that new joiners avoid spending their first days googling obscure node version errors.

Ansible is a tool most commonly associated with the setup of servers and infrastructure. But more broadly it's an excellent tool for automating the setup of any computer, including laptops and workstations. Of all the configuration management tools out there it's by far the easiest one to use - requiring no devops background at all - and has an amazing community supporting it.

This posts outlines the setup I've evolved over the previous few years which means setting up a new Macbook pro for fairly broad development (Rails, Javascript, Elixir, Python, Android & iOS) now takes just a couple of commands. This includes loading all my shell customisations and GUI apps like Chrome, Office, Virtualbox etc.

A recent change to AWS NodeGroup behaviour means that some CloudFormation stacks which create EKS NodeGroups may start to fail with the error Nodegroup the-nodegroup-name failed to stabilize: Internal Failure. Googling currently doesn't return much. The problem is related to this change relating to whether or not public IP's are assigned to nodes.

An area I’m keen to experiment with batching strategies for is learning. Specifically getting “over the hump” with things that require a substantial upfront commitment before a return is delivered. Today I'm kicking off a 90 day experiment of batching together learning three such things.

One of the most high leverage tools available to us is habit. We are the sum of the things we do, our habits tend to be the things we do most and therefore we tend towards being the sum of our habits. Charles Duhigg's The Power of Habit is a great primer on this. An interplay I'm increasingly interested in is the one between habits and batching (or habits of batching).

These are the guidelines I aim to follow with the goal of maintaining a high output while still enjoying life and avoiding burnout. I can't claim to be exceptionally good at sticking to them. As per usual, the "you" here is me, this isn't advice, it's just what's worked for me whenever I've managed to stick to it. It's definitely highly influenced by the dynamics of building technology companies and is very tailored to the quirks of my psyche, ymmv.

Docker and Docker Compose reduces bringing up a development environment on any system which supports Docker to a single command. For me this means the time to a working development environment, even on a fresh machine for a project I haven't worked on for months or years, is just a few seconds.

Something most of the startup and product people I look up to have in common is that they read, a lot. They also challenge what they read. Rather than reading a chapter, then immediately trying to implement what they've read, their books are full of post-it notes and scribbles, dinners and emails are full of debates on one methodology or idea v another.

May 2016 seems like a reasonable interval to have given 2015 to sink in. 2015 was expected to begin at a Full Moon Party on one or other island off the coast of Thailand. Instead it began with a hastily booked flight back to London and a week or so recovering from three days of hallucinations and dehydration on Aonang - they really do food poisoning properly there. Can't say I'm proud for bailing due to food poisoning; live and learn.

This is, in no particular order, what I'd tell myself about startups if I could go back in time to when I first got involved. Which is probably the same as what I've learned. This is most definitely not advice, the "you" here is directed at me. So is "I". Grammar is hard.

Having reached 2015 I'm forced to acknowledge that 2013 In Review is probably not going to happen. I might even remove it from my ToDo list where it's now the oldest item after returning the copy of "Chaos" I borrowed from a public library in my first year of university, six years of fines are going to hurt. In the spirit of it probably isn't a big deal I'll dive straight into 2014 but with a scattering of confusing references to 2013 for context.