search

kubeshop / monokle-admission-controller

Kubernetes Admission Controller for enforcing policies in your clusters
https://monokle.io
MIT License
9 stars 1 forks source link

Multiplatform build #17

Closed f1ames closed 1 year ago

f1ames commented 1 year ago

This PR fixes multi-platform build for specific arm architectures. Before it got stuck on npm ci... command (e.g. https://github.com/kubeshop/monokle-admission-controller/actions/runs/6745376525/job/18337069349#step:8:399).

There is an issues with Node v19+ and arm based images. It is described in https://github.com/nodejs/docker-node/issues/1794 and https://github.com/nodejs/docker-node/issues/1335. At this moment it works with v18 based images and so I downgraded to it.

It builds fine with such changes (see this run https://github.com/kubeshop/monokle-admission-controller/actions/runs/6768309227/job/18392485679).

Changes

Fixes

Checklist

f1ames commented 1 year ago

First of all, why are we building for these many ARM versions?

MacOS, which was the source of this issue, is using arm v8 on 64-bit platforms. Therefore, the other build architectures are really useful for ppl running on Raspberry PI Model 3B and below. Again, While the good practice would be supporting that, I'm not sure it's worth pinning to a lower-than LTS image version of the node interpreter just for that sole purpose.

Secondly, Node LTS is 20, not 18, yet the image you are pinning to resolves to both Node18 as well as an older version of alpine.

Good point. Yes, I just thought of it as a good practice to provide support for multiple architectures. But as you say, it might be not needed, it's also not our target audience at this point. Now, as for pinning down to v18, it also seems to be an issue for arm v8 so dropping others will not help here (I can recheck to be 100% sure).

And the entire reason for downgrading was that for arm architecture, there is an issue with npm i starting from node v19, so that's why I downgraded to v18.

Therefore, what I suggest first removing all unused architectures (anything but arm v8 and amd64), using Node20 with a pinned version instead of using lts tags (because as you saw, some of them are not updated and you might get older image versions or you will not know which one you are on) and then either trying the Google Distroless images (as that is a best practice for these kinds of containers) or go node-slim if alpine is still not working.

Sure, it make sense. Just as I mentioned above it seems that even for linux/arm64/v8 only, it will not build with node v19+. In that case, would it make sense to build with node v18 and have production image using v20 (based on alpine or distroless you mentioned)?