Direnv for DevOps

For DevOps engineers, working on many different projects and different clouds is a reality of life. We have developed many tools to help us manage and switch between the different contexts and projects, each one with its ups and downs. Today we explore the one that, IMHO, is the best of them all: direnv.

How it works

Direnv has a very simple premise: each time you cd into a directory with a .envrc file, a new environment is started for that particular directory using the environment from that file. When you leave the directory, the environment is re-established. Technically, this works by starting a subshell and injecting the variables defined on the file in this new subshell, but we won't dig into details for now.

For example, if all the resources on a project exist in the eu-central-1 region, I have this file at the root of the project

export AWS_REGION=us-central-1

So each time I cd to this directory, my aws-cli will operate on the us-central-1 region by default.

How I use it

In a fast-paced work environment, you require extra work and care to use your admin superpowers securely, so my goal is to minimize the work while keeping the security at the highest. For this, I keep a folder structure like this:

Workspaces/

/ClientA

.envrc

/Project1

.envrc

/Project2

.envrc

/ClientB

/ClientC

#+end_example

On the root of each client, I define the global settings, like the SSH keys I'm using for that client or the git id. Then, in each project folder, I define the environment specific for that project, which often includes the project name or location of kubeconfig files for Kubernetes.