Python-docker VS runner-images

This defines which image to inherit from, In this case we are using a Python image with the Python 3.11 version running on a slim version of the Bookwork version of Debian linux. Image definitions can be viewed from the DockerHub TAG link such as the python:3.11-slim-bookworm and official images like this one typically have pretty complicated definitions in order to get them highly optimized.

> You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee.

Well, if all you need is the server to run Docker/Podman, SSH and some other limited amount of packages, it shouldn't be too bad. Of course, there are also horror stories of Alpine resulting in way worse performance in select use cases: https://github.com/docker-library/python/issues/509 and there's the fact that Alpine might be popular inside of containers, but way less so outside.

Also, because of the short EOL cycle, I personally ditched Debian on servers (and Alpine in containers) myself for Ubuntu everywhere: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... A bit of a polarizing move (though RPM distros aren't much better at the moment), but it seems to have worked out for me in the end.

Doesn't mean that someone can't try, though, maybe their use case is suitable for Alpine.

This is the actual raw Dockerfile: https://github.com/docker-library/python/blob/master/3.9/slim-bullseye/Dockerfile

I usually cannibalize Docker Community's examples: Here

Official Docker image of Python 3.10.5-slim

If you want Python v3.7, perhaps try FROM python:3.7 (link)

Navigate into the Python directory and configure and ensure enable-optimization option is added as shown in the command below.

It looks like you are running into this bug: https://github.com/docker-library/python/issues/674

Yeah this is a good option if you'd like something to deploy yourself! You can also build an AMI from GitHub's upstream image definition (https://github.com/actions/runner-images/tree/main/images/ub...) if you'd like it to match what's available in GitHub-hosted Actions.

With Depot, we're moving towards deeper performance optimizations and observability than vanilla GitHub runners - we've integrated the runners with a cache storage cluster for instance, and we're working on deeper integration with the compute platform that we built for distributed container image builds - as well as expanding the types of builds we can process beyond Actions and Docker, for instance.

But different options will be better for different folks, and the `philips-labs` project is good at what it does.

Whoa, there's a lot of stuff in there [1] that gets installed straight from vendors, without pinning content checksums to a value known-good to Github.

I get it, they want to have the latest versions instead of depending on how long Ubuntu (or, worse, Debian) package maintainers take to package stuff into their mainline repositories... but this attack surface is nuts.

[1] https://github.com/actions/runner-images/tree/main/images/ub...

I had a similar experience with ARC (actions-runner-controller).

One of the machines in the fleet failed to sync its clock via NTP. Once a job X got scheduled to it, the runner pod failed authentication due to incorrect clock time, and then the whole ARC system started to behave incorrectly: job X was stuck without runners, until another workflow job Y was created, and then X got run but Y became stuck. There were also other wierd behaviors like this so I eventually rebuilt everything based on VMs and stopped using ARC.

Using VMs also allowed me to support the use of the official runner images [0], which is good for compatibility.

I feel more people would benefit from managed "self-hosted" runners, so I started DimeRun [1] to provide cheaper GHA runners for people who don't have the time/willingness to troubleshoot low-level infra issues.

[0]: https://github.com/actions/runner-images

Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631

Used https://github.com/actions/runner-images to get the packages needed for Ubuntu 22.04 As the packer requires a builder, I used "null" builder to set it as localhost ref: https://developer.hashicorp.com/packer/docs/builders/null (It was way difficult to figure it out the 1st time) I had to modify the .pkr.hcl file to pick my provisioners. I could not understand the use of /opt/hostedtoolcache folder (which I did later)