Upgrade to the new AWS Linux AMI 2018.03 #332
Comments
|
Maybe go straight to Amazon Linux 2? |
|
This is not mentioned in the blog post right? I would make more sense to target the AMI that will actually be used in production. |
|
You're definitely right. I noticed NodeJS 10.x will be running on Amazon Linux 2 and thought we could do the same, but we don't have control over which OS is being used by the custom Runtime. For some reason I thought that if we compiled PHP using the AL2, the layer would use AL2. |
|
@mnapoli do we Must do that? I've just opted in to the new AMI and everything is working as before. What can we do to test that we must recompile PHP for this AMI? What would be the benefits? |
|
If everything is working that is perfect! I would say that if nothing breaks that's a good sign. However we should still update the references to |
|
We gave it a try with @Guillaume-Rossignol but the compilation of PHP fails, which is very weird: After searching for this error: At the moment we install gcc frum yum. Has anyone any idea? @bubba-h57? |
|
We can fix the build to use the new AMI. We can probably make it run on AL2 as well. We will tackle that later. The current build will most likely just work due to the nature of our compartmentalized build. That being said, there are just as likely to be potential weirdness where we interact with system libraries. We recommend not running it in production on the new Linux until we get an official build. We can have a new build by early next week. Side Note: My laptop battery swole up and Apple took the machine back to work on. I might not have my machine back till Monday/Tue ... so, despite having something to fill the gap, everything I am working on is slowed down considerably until I get my workhorse back. |
|
If we do switch to a newer Docker image, I wonder if there would be advantages to using lambci/lambda It might even serve as a replacement for
|
|
@ejunker yes that's a good point! @Guillaume-Rossignol has been adding that in #367 (https://github.com/brefphp/bref/pull/367/files#diff-c52630f7c3061e64ef083ca4efa22d7aR10). The last blocker there is the compilation error with 2018.03.
Oh that's a good point! We did see that image but I didn't think about that. Might be a good way to simplify things hopefully. |
|
While they do provide some build tools, they do not provide the ones we require. We have used them for building in the past and they always came up short. We should get more mileage from building on the official images https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html and avoiding attempting the builds in such a constrained environment as lambci/lambda . That being said, lambci/lambda is a fantastic option fo testing our output. We recommend doing precisely that. To sum up, it would not add value to make the change (in either simplification or quality/reliability) and could very possibly make things more complicated than they are today. |
|
I thought |
|
@nealio82 nope, LambCI is a continuous integration system built on AWS Lambda - they created a docker image for themselves to test with, and other people started using it. They create their Docker Image by tarring the full filesystem in Lambda, uploading that to S3, and then piping into Docker to create a new image from scratch – then creating mock modules that will be required/included in place of the actual native modules that communicate with the real Lambda coordinating services. Only the native modules are mocked out – the actual parent JS/PY/Java runner files are left alone, so their behaviors don't need to be replicated (like the overriding of console.log, and custom-defined properties like callbackWaitsForEmptyEventLoop) As you may guess, tarring up a system and then mocking out modules is great for testing. |
|
Our build issue is with the Internationalization extension. Particularly the icu4c version that the intl extension builds against. There have been a handful of noteworthy bugs in the intl extension with finickiness around the icu4c version. We attempted building against a handful of versions, but have yet to nail it down. However, to demonstrate that this is indeed the root cause, I removed I'm headed out on vacation with my family for the rest of the week, so if anyone else wants to pick this up feel free to take a look at the pull request on our fork to see what has been committed/attempted so far. |
|
@bubba-h57 awesome thank you for the details and the diff! Enjoy your holidays! |
|
I've been looking into this issues for a few hours now and I think I figured out what's the problem. I started from @bubba-h57 Arithmetic with Overflow Checking were introduced into GCC in version 5 (changelog), while Amazon Linux is using GCC 4.8 (in both 2017.03 and 2018.03). We can solve everything by upgrading our GCC installation, which can be easily done with: And ta-da, bref builds again! At this point I was asking myself, why didn't it failed building it on Amazon Linux 2017.03? Compiler is the same, and PHP versions too... Why is it failing now then? If you take a look at the gcc and g++ packages using It installed gcc 7.2, but it's lacking gcc72-c++. When PHP checks for the supported features, it's doing it using gcc (because it's built in C and it uses gcc 7.2), but when we compile intl extention we need to compile C++ code, it uses g++ 4.8, and everything blows up. I've tried to remove the cpp72 package, but it is required by We could setup a restricted Final version is available in my fork, I can PR it if you want. (I started over from master because at this point it's just a few changes) |
|
@TheNodi wow this is amazing! Thank you so much for all these explanations, that's really interesting to learn about all that. A PR would be more than welcome indeed :) |
|
Nice work! I concur with sticking with GCC 7.2. PR that!
…On Fri, Jul 19, 2019, 6:18 AM Matthieu Napoli ***@***.***> wrote:
@TheNodi <https://github.com/TheNodi> wow this is amazing! Thank you so
much for all these explanations, that's really interesting to learn about
all that.
A PR would be more than welcome indeed :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#332?email_source=notifications&email_token=AAETL3TQJYKZDCPIOOPKI63QAGIGJA5CNFSM4HM5PGSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2LHKVA#issuecomment-513176916>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAETL3Q3VE4VPUDPR63ON63QAGIGJANCNFSM4HM5PGSA>
.
|
|
PR merged, thanks @TheNodi! |
AWS announced that Lambda is migrating to a new version of their Linux AMI: https://aws.amazon.com/fr/blogs/compute/upcoming-updates-to-the-aws-lambda-execution-environment/
We need to update the layers so that we compile PHP against the 2018.03 AMI.
The text was updated successfully, but these errors were encountered: