Richard Brunt - Today I Learned

Dockerized Lambda deployments with CloudFormation

2025-10-14T00:00:00Z

When you deploy a Lambda using a tagged docker image, updating the tagged image and redeploying the Lambda (using CloudFormation) doesn't actually update the code running in the Lambda. This happens because neither CloudFormation nor Lambda know that the tag now points somewhere else.

The solution is actually pretty simple: instead of referring to the docker image by its tag, refer to it by its digest instead.

Old way, using a tag:

# Part of a CloudFormation template in yaml format:
LambdaFunction:
  Type: AWS::Lambda::Function
  Properties:
      PackageType: Image
      Timeout: 120
      MemorySize: 512
      Code:
        ImageUri: !Sub ${DockerRegistry}/image-name@latest

New way, using a digest:

# Part of a CloudFormation template in yaml format:
LambdaFunction:
  Type: AWS::Lambda::Function
  Properties:
      PackageType: Image
      Timeout: 120
      MemorySize: 512
      Code:
        # Reference the digest (sha hash) instead of tag here, since Lambda won't pick up the new image if we just re-tag it.
        # Doing it this way ensure lambda pulls the new image.
        ImageUri: !Sub ${DockerRegistry}/image-name@${LambdaDockerDigest}

The digest comes into the template as a parameter (LambdaDockerDigest), which ultimately comes from my build step and looks something like this:

sha256:94a00394bc5a8ef503fb59db0a7d0ae9e1110866e8aee8ba40cd864cea69ea1a

In hindsight, using the sha is probably better anyway: it's the most unambiguous and immutable way of referring to a given image version.

Installing Docker Buildx on Windows without Docker Desktop

2025-07-24T00:00:00Z

If you don't install Docker Desktop for windows but just install the cli tool manually (e.g. because your company doesn't want to pay for it), it's not obvious how you get plugins like buildx installed.

It turns out that it's not actually that hard, just a bit manual:

Download the latest Windows executable from the Github Release page. Look for the file the ends with windows-amd64.exe (e.g. buildx-v0.26.1.windows-amd64.exe).
Rename the downloaded file to docker-buildx.exe.
Copy the renamed file to %USERPROFILE%\.docker\cli-plugins, creating the directories if needed.
Verify that it's working by running docker buildx --help in your Windows Terminal.

I haven't tested this for other plugins like docker compose, but I expect the procedure would be the same.

Setuptools package data setting for config files

2025-06-06T00:00:00Z

Under certain circumstances, setuptools won't copy static files like config files into the built package unless you tell it to in the build config:

# pyproject.toml
# further up, the default value of 'include-package-data = true' had been set to false.

[tools.setuptools.package-data]
my_package_name = ["config/**/*.json", "pretty_picture.jpg"]

This tripped me up because when I was building a python program for deployment in Docker, things worked fine (it was installed 'editable' so no copying of files), but when I bundled everything up for deployment in a lambda using pip install . --target dist, the config wasn't there!

pytest: start a debugger on test failure

2025-05-28T00:00:00Z

While refactoring some tests, I stumbled upon a really cool pytest feature I wish I had known about before: pytest has a command line argument (--pdb) that drops you into a pdb debug shell whenever a test fails. Really handy for inspecting the state of the test to figure out why it's failing or why your assertion isn't working as expected!

pytest --pdb # drops to debug shell on each test failure

There are more examples in the pytest docs, including --trace which drops you into a debug shell at the start of each test so you can step through it line by line.

Custom version format for Mend Renovate

2025-05-26T00:00:00Z

I use Mend Renovate to keep docker images of applications I run up-to-date.

Today I noticed that my umami analytics dashboard said it had an update available, but renovate hadn't told me about it. On closer inspection it was because the docker tag format umami use is slightly unusual: they have a prefix with the database driver to use, followed by the version number (e.g. postgresql-v1.17.0 or mysql-v1.17.0).

Renovate didn't understand how to parse this format, so I had to add a custom package rule in my renovate.json to tell it how to interpret them:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  // Rest of config here
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["ghcr.io/umami-software/umami"],
      "versioning": "regex:^postgresql-v(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)$"
    }
  ]
}

Here I've fixed it to postgres only, as otherwise renovate just picks between postgres and mysql at random, which isn't going to work well!