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

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

MIT License

Copyright (c) 2019 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

MIT License

Copyright (c) 2018 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

# 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

noelbundick

MIT License

Copyright (c) 2018 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

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

# 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

MIT License

Copyright (c) 2018 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

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)