-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build full chromium binary #1
base: master
Are you sure you want to change the base?
Conversation
1a0d979
to
0886f21
Compare
0886f21
to
d766091
Compare
900c165
to
cbe9ca1
Compare
6cf1128
to
8c9266c
Compare
8c9266c
to
e1e8b04
Compare
Without media remote enabled, full builds fail on Chromium. Other code paths rely on CastRemotingConnector::ConnectWithMediaRemoter whether or not enable_media_remoting is enabled, but the ninja configuration will only include the chrome/browser/chrome_content_browser_client.cc if this flag is truthy.
01a9563
to
d590c62
Compare
d590c62
to
7cb0793
Compare
This is great 😃! I was thinking about having GH Actions do the compilation, but I was worried about how long the compilation takes. Does Github have usage limits on free repos? I would love to get the Ansible requirement removed as it's basically a bottleneck on me running the compilation, and ansible fails a number of times because my dev box loses connection to the ec2 instance. Second, you'll need to take a look at All in all, I agree with you that I think the majority of the issues are because it's using the |
@Sparticuz Good points! Will take a look at those test cases once I get a working lambda deployed.
I tried with the vanilla CI machines, but they were indeed too slow / didn't have enough available disk space to clone the chromium codebase and its dependencies. I'm instead using Github's large runners - specifically the 16CPU/64GB memory box, which runs a full build in about 4 hours. That's priced at $0.064/min so roughly $15 for each compilation. It's more than a similarly configured VM from AWS, but given the rest of our CI pipeline and avoiding some of the ansible connection issues seemed worth it to me. The only snag for an OSS project is these runners can only be launched into corporate accounts. We have some lambdas running at MonkeySee, so we're happy to keep building these periodically, but that might be a limitation for other branches. |
I posted about the glibc problem a year ago :/ tracked here: aws/aws-lambda-base-images#59 |
Unfortunate this has been blocking for so long! The two most promising avenues here seem to be:
Any thoughts on the above? FWIW we're temporarily moved over to just building a separate docker image based on Ubuntu and running the lambdas on there. Bootup times are indeed slower but workable to avoid this dependency hell. Still shooting to get this PR up and running though. |
Indeed it is frustrating. My Issue on the AWS repo was originally for AL2022, which never came out. I'm skeptical they will even update the node18 image to be AL2023 at all and might just start it with the node20 image. My build currently builds with the headless.gn build options, but I guess the I would not wish the dependency hell on anyone 😆. Personally, I don't see much value in headless v2, maybe because I'm not scraping websites pretending to be a normal user agent. I understand that v2 has much better compatibility, but I've not run into those issues. As far as a separate docker image goes, my opinion is that the package is meant for running on the stock lambda containers. If you are using/want to use a separate container, then why not just install chromium at the system level instead... |
Thanks for all the info on this PR it led me to a journey I had to do to understand the whole problem. I am still looking for patchy solutions and dependency hell fix but it seems that we could use custom runtimes through AL2023 and considering that Nodejs 20 LTS is around the corner I think that should be an interesting solution: aws/aws-lambda-base-images#92 (comment) How about we offer a full build instead of headless.gn with the disclaimer that currently only custom runtimes are supported (AL2023 specifically)? Considering that it took approx. 1 month from LTS to being supported in AWS runtimes and they are fully migrating now that would be a solution that would integrate with a new runtime anyway. Thoughts? @Sparticuz @piercefreeman |
Wow, I didn't see that comment! I will be looking into quite a few options now that al2023 is available. There has also been some changes to @puppeteer/browsers that I've been interested in taking advantage of. Stay tuned! |
@iwaduarte Thanks for linking to that thread, hadn't seen the announcement about AL2023 yet. They also mentioned they're aiming to get GA out within the next couple of weeks. Fingers crossed. Right now you'd still need to use this approach within a custom container on lambda, so I'm not sure using AL2023 as your docker base image really gains you that much. Docker sizes seem to be somewhat invariant with the size of the payload. But yes, given the approaching support for this in a format runtime, it does seem like a good idea to bump the base version of this builder to the new preview. The brotli compressed artifact should then just work-as is when they get to a final release. @Sparticuz - do you want to take it from here? Or anything that would be useful on my side? |
Just leave this fork up for a bit in case I need to cherry pick any of your commits, otherwise I'll ping you if I need anything. Thanks @piercefreeman |
The goal of this PR is to:
Current status:
Notes:
The glib libraries in lambda are not modern enough to run chromium; They are still based on amazon-linux2 with ldd (GNU libc) 2.26 and Chromium needs at least 2.27 to build. This works fine to build the binary but the dynamic linking of glib won't be able to resolve on the lambda container at runtime.
libgthread-2.0 is an example of one of these dependencies that is required by chromium but not otherwise bundled in the Lambda runtime environment. This is the full list of dependencies as resolved in the build container.
Default lambda dependencies (logged by a simple
exec("ldd ${chromiumPath}")
in the lambda function):We can find these in the original /lib64 directory in the docker builder:
Running with these in the
/lib
folder will result in warnings across the board:This is because the runtime linker on the lambda (ld-linux) is still tied to the old version of glib. We can try copying over the new version and make sure our environment is pulling that. However it's important to be careful here; the rest of the system dependencies rely on LD_LIBRARY_PATH pointing to the system-wide version of glib. We can't overwrite this version or we'll see errors across the board. We can however patch the versions we're using in the executable to make sure we're finding the right ones:
This gets us some of the way there but the runtime still only resolves some of the dependencies with our desired versions (see the /tmp/aws/lib/ links). Many others are the environment default in /lib64 or otherwise not found.