noelbundick

automation light:
  - id: 'lights_process_desired_state'
    alias: "[Lights] Process desired state"
    mode: parallel
    max: 50
    trigger:
      - platform: state
        entity_id:
          - binary_sensor.lights_office_desired_state
          - binary_sensor.many_many_others_desires_state

noelbundick

# 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

noelbundick

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.

noelbundick

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

noelbundick

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

1. Clean terminal, you know you want to launch code on a remote server. Check out sshcode.sh

2. 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

noelbundick

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:

noelbundick

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)

noelbundick

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.

noelbundick

# 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

noelbundick

# 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