[REQUEST] ARM Support for Lambda on ARM-based AWS Graviton2 processors

[deldrid1]

What would you like to have implemented?

Puppeteer v14 ships with native Apple Silicon (aka ARM) support. According to Amazon, you can see up to a 34% cost reduction by changing architectures to their proprietary ARM processors. I would love to see if this claim lives up to reality by adding support for an optimized ARM based chromium, in addition to the x86_64 flavor.

Several folks have done some preliminary work here - alixaxel#241 . Getting an actually maintained release that supports Puppeteer 14+, Node.js 16 (which is finally available), and can run on either architecture would allow for a lot of performance driven testing to optimize Puppeteer at scale on Lambda.

@Sparticuz - With your work on automating the build process, I'm thinking this would be a quick add? Love to know your thoughts and if you would be interested in adding this to your branch (or if I should consider making another fork).

[Sparticuz]

I wanted to do this also. My initial thoughts:

• Getting chromium built for arm should be pretty easy. I'll take a look at that PR and see if I can update the build process.
• I'm not sure if we should do this in a single package. Wouldn't that mean including both binaries? Layers would probably be the solution. More thoughts are needed.
• https://chromium.googlesource.com/chromium/src/+/main/docs/linux/chromium_arm.md
• The chromium binary is not available for arm64 puppeteer/puppeteer#7740

[deldrid1]

Yea. node-pre-gyp is usually used for this sort of thing, but since we are wanting to compile for a different target than the npm host that probably doesn't make too much sense? I've never built/maintained a package with binary dependencies.

You could do a custom downloader via scripts(probably similar to what puppeteer itself does), but I think a fork or some awkwardly named branches / versioned releases would be the easiest thing in the short term? It would come with the trade off of maintenance headache (doing everything twice) in the long term.

[ferbs]

If warnings during install are acceptable, it could use the approach taken by @ffmpeg-installer, of including a prebuilt bin package for each platform/arch combination in optionalDependencies, with only one surviving install.

Haven't implemented such things myself, just mentioning it as a potential source of inspiration.

[Sparticuz]

I've successfully built Chromium for arm64 and it is working on an EC2 instance (t4g.small), however, it's not working on the stripped down lambda instance. I believe it's not working because lambda is currently running Amazon Linux 2 which doesn't support higher glibc versions that chromium seems to require. More investigation required, see #11 for more information

[ferbs]

So close, argh! Only meh options come to mind:

• Bundle secondary glibc: Multiple glibc on a Single Linux Machine. Likely outcome is madness
• Container-only, based on amazonlinux:2022 plus their custom runtime interface That repo isn't especially well maintained/healthy but there's a commit claiming fixes for ARM and they're probably using it for the official Node 16 Lambda runtime.
• Wait on AWS to update the Lambda runtime

[Sparticuz]

Another option seems to be natively compiling chromium on arm instead of cross-compiling, but Google seems to not have that documented or supported.