Skip to content

Make Docker workflow a bit more friendly/optimized

Christian Winther requested to merge jippi/soapbox:optimize-docker-experience into develop

Summary

As part of building a custom version of Soapbox for my Mastodon instance (recommended in #1313 (comment 1231142594)) I ended up spending a couple of hours making the Docker flow significantly faster when iterating.

It heavily utilizes BuildKit which has been included in Docker for X since last 2019 to cache the various build steps between runs, making most of the lengthy yarn install and yarn build steps instant or significantly faster than uncached.

Initially, I only wanted to fix the non-Dev flow, but as I found myself needing to test some of the things, and the Docker experience being similarly slow, I included it here as well.

I'm no webpack expert (only spent like 200h of my life on it as a Platform/Infra engineer, which is a low number of hours vs real frontend people 🤣), so unsure of any negative consequences of using filesystem cache across the broad - I couldn't really measure anything on my m1 macOS instance, but it might be beefier than the average engineering hardware.

I tried to document everything in place so it's easy to maintain going forward since some of the usages are more advanced capabilities of Docker that not everyone is comfortable working with or even knows of.

It allows me to do a custom build of the front in a simple two-liner like this

# cleanup
rm -rf /tmp/output 
# prep
mkdir -p /tmp/output

# build output
docker build \
  -t soapbox:local-build \
  --target yarn-build \
  --build-arg BACKEND_URL=https://expressional.social \
  .

# copy output
docker run \
  --rm \
  -v /tmp/output:/host \
  soapbox:local-build \
  cp -R /app/static/ /host/

The change allows us to build a multi-arch (arm/amd) version so it can natively run on a Pi and so on as well by simply using the --platform CLI flag or builx build for a true multi-arch single container image.

Inherently the Docker dev flow should also be must faster, as it will prefer the native CPU architecture version of images supporting it, so it doesn't have to emulate CPU architecture on the fly. This is also huge for IO performance on macOS for example, which generally are a problem with Docker + NodeJS

Edited by Christian Winther

Merge request reports