Noel noelbundick

Azure CLI extensions

Think of what you can build with Python and an always-installed, always-authenticated, extensible connection directly into Azure

Overview

Extension documentation
Azure/azure-cli-extensions - most (not all) official extensions live here
Available extensions (official list)

Some quick thoughts on using many Azure subscriptions vs many resource groups in one subscription

Limits are applied at the subscription (+ sometimes region) level. If one RG uses 500 cores, other business units may be blocked until you open a support request.
Preview features are applied at the subscription level - other RG's can't opt-in/out. Ex: if you wanted to use the AKS + VMSS preview, you need to be sure that all teams want (and can support) the feature
This is really hit & miss, but there are some actions that can't be performed based on other resources being present in the same subscription

https://docs.microsoft.com/bs-latn-ba/azure/storage/common/storage-auth-aad-rbac-portal

If your subscription includes an Azure DataBricks namespace, roles assigned at the subscription scope will be blocked from granting access to blob and queue data.

This was an experiment in WSL interop from way back in May 2018. My goal was to be able to type noel-pc123 from a bash terminal and immediately launch into an RDP session. Should still work!

msrdp-template.rdp

This file is used with mstsc.exe to launch a remote desktop session
This file must be encoded as UTF-16
Replace the following values with your own:
- DOMAIN\user: the credentials you will use for your connection
mygateway.example.com: the gateway server used for your connection (if unused - just remove the whole line)

I've got 2 flavors of launching VS Code on remote servers for you

Clean terminal, you know you want to launch code on a remote server. Check out sshcode.sh
You want to launch code on your local machine from inside an existing SSH session. This needs a bit of setup, but seems to work pretty well. Hacks inbound!

Set PermitLocalCommand yes in your SSH config (see example)
Add a LocalCommand to stash the username, IP, and current directory in a local file when you connect
Save hack.sh in your home directory

Now to connect, use the SSH escape sequence (default single tilde ~) along with !command to invoke the script

WSL2 container development with Moby

Building, pulling, pushing, and running containers is something many developers do often without even thinking. Most of my development over the past couple of years has been exclusively in a Linux environment, specifically WSL2.

Even prior to the recent licensing changes to Docker Desktop, I found myself increasingly as an engineer whose workflow didn't line up with my tools. I never used the GUI features. I never built Windows containers. I used kind or k3d instead of the Docker Kubernetes functionality. I never mounted the Windows filesystem into my containers. And I certainly didn't enjoy frequent downtime caused by updates for those features that I wasn't using. I wanted the container experience in my dev environment to match what I got on a server - just the runtime & tools.

That said, I still like shiny new (or not-so-new but I never see anyone use them

Optimizing Rust container builds

I'm a Rust newbie, and one of the things that I've found frustrating is that the default docker build experience is extremely slow. As it downloads crates, then dependencies, then finally my app - I often get distracted, start doing something else, then come back several minutes later and forget what I was doing

Recently, I had the idea to make it a little better by combining multistage builds with some of the amazing features from BuildKit. Specifically, cache mounts, which let a build container cache directories for compilers & package managers. Here's a quick annotated before & after from a real app I encountered.

Before

This is a standard enough multistage Dockerfile. Nothing seemingly terrible or great here - just a normal build stage, and a smaller runtime stage.

	# We set an environment variable in this phase so it gets picked up by pip, but we don't want to bake secrets into our container image
	FROM python:3.6-alpine AS builder

	ARG INDEX_URL
	ENV PIP_EXTRA_INDEX_URL=$INDEX_URL

	COPY requirements.txt .

	RUN pip install -U pip \
	&& pip install --user -r requirements.txt

	# syntax = docker/dockerfile:1.0-experimental

	FROM python:3.7-alpine AS builder

	WORKDIR /app
	COPY . .

	# mount the secret in the correct location, then run pip install
	RUN --mount=type=secret,id=pipconfig,dst=/etc/pip.conf \
	pip install -r requirements.txt

	MIT License

	Copyright (c) 2020 Noel Bundick

	Permission is hereby granted, free of charge, to any person obtaining a copy
	of this software and associated documentation files (the "Software"), to deal
	in the Software without restriction, including without limitation the rights
	to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
	copies of the Software, and to permit persons to whom the Software is
	furnished to do so, subject to the following conditions:

	# Get a commit hash from <gestures vaguely around> somewhere
	REPO="noelbundick/myrepo"
	SHA=$(git rev-parse HEAD)

	# Get the run associated w/ the commit
	RUN=$(gh api "repos/${REPO}/actions/runs" --jq "[.workflow_runs[] \| select(.head_sha == \"$SHA\")][0].id")

	# Watch it
	gh run watch -R $REPO $RUN