Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
ARM64 Support #1043
Comments
|
AFAIK PHP isn't running best on ARM (e.g. JIT not supported). I may be wrong, but it might be worth digging into that? |
|
I think the first step is to wait Cloudformation support? aws-cloudformation/cloudformation-coverage-roadmap#926 |
|
@deleugpn for Lambda layers yes, but I think there should not be anything holding up pushing the ARM images to Docker Hub for container lambda functions? |
|
@deleugpn people claim in aws-cloudformation/cloudformation-coverage-roadmap#926 (comment) that CloudFormation API already supports the @mnapoli maybe, this helps to melt your concern about running PHP on ARM -- https://aws.amazon.com/tr/blogs/compute/improving-performance-of-php-for-arm64-and-impact-on-amazon-ec2-m6g-instances/ |
|
@dytyniuk definitely, thank you. I was wrong, ARM can be interesting for PHP. Also relevant: https://twitter.com/sebastienhouze/status/1443742924534132843
Also FYI: CloudFormation support is in (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html#cfn-lambda-function-architectures) and we're planning to add support in Serverless Framework early next week. |
|
So if the roadblocks to this were cloudformation and the serverless framework supporting arm - both of which now do.. is there any remaining issue or is this good to go now? And if so.. how so? I'm about to dig into a new project and I think I'd like to use the graviton lambdas if possible. |
|
Compiling php is not a trivial process. I've been looking into simplifying it and only now realized that remi-collect does not support aarch64 builds which put a wrench in my experiment. |
|
Hey @deleugpn |
|
I have been pointed that address but I haven't figured out what to do with it. I tried enabling it and installing packages following remi-collect naming convention and no luck |
|
I managed to install php with |
|
Another thing that might be relevant, if I understand https://repo.drpixel.fr/ correctly, it only support PHP 8.0.1, which is 10 point-releases behind so even if I did manage to install with it, it seems it would be very slow to move forward with PHP upgrades. I'm open to suggestions and considering our options. I might have to dig deep into our current compile php ourselves and abort the attempt to simplify it with a pre-package distribution |
|
@deleugpn yeah, now I feel your shoes. At least, to some extent. IMHO, any effort to reuse pre-built binaries for this or that repository will bring a concrete PHP version and lock further updates. From this point of view, layers' updates will be postponed until maintainers of the repository incorporate an update. Despite the pain of the compilation, I think, this is the only way to provide best layers. |
|
remi-collect offers blazing-fast compilation and even release-candidate binaries. The only problem is that there's no arm64 support there. Swapping our current (complex) compilation process with a much-simpler process (https://github.com/deleugpn/bref-runtime-internal/blob/main/PHP80.Dockerfile#L6-L11) without arm64 support kinda feels like touching what doesn't need to be touched. OTOH, if I do use remi-collect as a simplified packaging and then use |
|
@deleugpn I might be wrong, but I thought the point of a compilation is to install everything to the same path ( |
|
The folks at Vercel are doing some amazing stuff that works great (https://github.com/deleugpn/bref-runtime-internal/blob/main/php80.build.sh#L31). I copied this strategy from https://github.com/juicyfx/libphp/blob/master/libs/amazon-linux-2-v80/Makefile#L53 |
|
@deleugpn okay, I understand there's a way to extract an artefact from any place in the container. But, is an explicit listing more convenient rather than copying every binary/module installed on a build time? Imagine you have an auxiliary module of a file built for an extension, and it's missing from your list. How long will it take to pinpoint a root cause of a broken extension? |
|
I guess that's subjective. I have some extensive experience on PHP, but I find the code compiling PHP hard to read / understand / maintain. The copy/paste strategy seems much more straightforward / easier to read and understand. It gets boring, but you can always run |
|
How can I help getting this shipped? PHP 8.1 just released which has native support for the JIT on ARM. |
|
I've been working on #1078 for quite a while now but docker-compose bug on ARM prevents it from building arm layers at the moment. In the meantime I'm trying to finish up how to integrate the console layer into the new proposal so that we can start beta test it while we wait on docker/compose#8804 If you're interested, I can post the arn on the x86 layers that needs some QA testing before we're confident to move forward with the new runtime. |
|
@deleugpn interested in testing the x86 layers |
|
arn:aws:lambda:us-east-1:978790411843:layer:prototype-arm64-php74-function:1 |
|
@deleugpn do you have them in 8.0 by chance ? our code base use some 8.x-only features :) |
|
I will look into building it this week. Sorry for the short answer, I'm on holidays between Christmas and new years |
|
no problem, enjoy your vacations :) |
|
sorry the long time without replies. I have actually tried to release ARM64 prototype layers across regions multiple times in the past 3 weeks and no luck as of yet. Some exotic AWS regions seems to be bugged when trying to publish Graviton layers because it always gives "The security token in the request is invalid" even though the build process is a perfect replica between x86 and arm64. I tried disabling these regions and now there is an unknown error crashing the build process just after the layers are published which I'm still unable to track down. In the meantime, docker-compose is still bugged on arm64 when trying to build using buildkit, so builds are much slower for arm64. Unfortunately the progress here is a bit slow as there's a lot of moving parts that are still not working well with arm64 and sometimes don't even give clear errors. |
|
thanks for keeping us updated , especially as it looks like a very tedious and "death by a thousand cut" work , hope you will succeed :) |
|
@deleugpn I'm going to have some focus time at work to dedicate to this, happy to collab on what you have done so far and help push this over the finish line. |
Please note that Graviton2 processor support for Lambda is not available in all regions (see):
@deleugpn Are there any errors when deploying in the supported regions? |
|
@wlami Thank you very much for that list! Unfortunately I just tried that and it did not solve the issue deleugpn#53 |
|
If anybody can figure out why this script fails at the end, please I'm open to any ideas AWS CodeBuild Logs |
|
Thanks very much for your work on this @deleugpn Given we see "Network utils_default Created", I assume the build got as far in the makefile as I suspect a return code of 255 suggests a PHP exception is being thrown by More specifically, should line 18 be looking for $cpu to equal The environment variable set in CodeBuild has CPU=arm |
|
I think some platforms output that as aarch64? |
|
@mattrenner I'm not even sure if I'm mad or hopeful (or both), but I'm running a new build fixing that. If that is the case, I still would like to try to understand why the error message doesn't show up (it would have saved me 1 month of trial-and-error). In any case I will update shortly |
|
thank you so much @mattrenner you have no idea how much that helped. Hopefully this will unblock the progress on having some ARM Layers for testing. The pull request sent by the bot should have the ARN for the Layers to be tested out. |
|
If anyone have any feedback on ARM layers, feel free to send them my way on our Slack, this issue or even at deleugyn at gmail. |
|
We are running Bref in development on lambda using Docker. I'm willing to try this out, how can I change to ARM image? Our current docker image: FROM bref/php-81-fpm
COPY --from=bref/extra-redis-php-81 /opt/bref-extra /opt/bref-extra
COPY . /var/task
CMD ["public/index.php"] |
AWS launched ARM64 support on Lambda (https://aws.amazon.com/blogs/aws/aws-lambda-functions-powered-by-aws-graviton2-processor-run-your-functions-on-arm-and-get-up-to-34-better-price-performance/).
Would be useful to get Bref functions and container images setup with ARM64 variants... Happy to assist where I can.
The text was updated successfully, but these errors were encountered: