๐šƒ๐š‘๐š˜๐š–๐šŠ๐šœ ๐š†๐š’๐š•๐š”๐š’๐š—๐šœ๐š˜๐š— ๐ŸŒปNov 17, 2023
I started using a Linux pod on a Kubernetes machine for builds. This has significant benefits but also a few caveats. ๐Ÿงต
Show thread๐šƒ๐š‘๐š˜๐š–๐šŠ๐šœ ๐š†๐š’๐š•๐š”๐š’๐š—๐šœ๐š˜๐š— ๐ŸŒป

Benefits:

1. It has simplified handling of multiple architectures. I develop on an `arm64` machine but deploy to `amd64`. Some container engines like Docker can handle cross-platform builds but it's trouble to manage and slower.

2. The ephemeral nature of a pod means that all I need to do to reset my environment to zero is restart the deployment.

3. It gets Docker Desktop off my computer.

4. It simplifies the path to CI/CD

5. Sometimes it puts your builds closer to your registry, speeding docker pushes

Nov 17, 2023 at 9:36pmWeb
Show thread๐šƒ๐š‘๐š˜๐š–๐šŠ๐šœ ๐š†๐š’๐š•๐š”๐š’๐š—๐šœ๐š˜๐š— ๐ŸŒปNov 17, 2023

Caveats:

1. It's not advisable to run any container engine inside a container. Instead, mount `/var/run/docker.sock` to use the hosts's docker daemon. I'm not comfortable doing this on a host with production workloads, but this is a build machine.

2. The ephemeral nature of a pod means it has to rebuild everything every time you restart the pod. Container versions of Linux tend to be bare-bones, so you'll need a lot of setup which takes time. You may either bake your setup into your container image, add startup scripts or some combination of the two. I hope you're good at scripting.

3. The host name is the name of the pod, which may change every time you restart. That can mess with scripts.

4. SSH keys will change every time you restart, which blows up scripts. Manage SSH keys in a secret so they remain consistent.

5. Get used to using rsync to upload your code and be sure to exclude `.git` and everything in `.gitignore` from your upload.