PHP 8.1 support

[IonBazan]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave "+1" or "me too" comments. They generate extra noise for issue followers and do not help prioritize the request.

Tell us about your request What do you want us to build?

PHP 8.1 has officially been released on 25 November 2021, yay! Here are the changes and features introduced in this release: https://www.php.net/releases/8.1/en.php. It would be great to see it supported natively by Elastic Beanstalk.

Are you currently working around this issue?

Staying on PHP 8.0 or installing the 8.1 manually during startup.

[christian-manrique]

New issue is coming during update

Could not retrieve mirrorlist https://amazonlinux-2-repos-ap-south-1.s3.dualstack.ap-south-1.amazonaws.com/2/extras/php8.1/latest/x86_64/mirror.list error was
14: HTTPS Error 403 - Forbidden

Looks like they have blocked access to the rpms

Despite my ec2 instance is pulling php8.1 as available through amazon-linux-extras i am having the same issue Could not retrieve mirrorlist https://amazonlinux-2-repos-ap-south-1.s3.dualstack.ap-south-1.amazonaws.com/2/extras/php8.1/latest/x86_64/mirror.list error was 14: HTTPS Error 403 - Forbidden , the CPU Architecture of my ec2 instance is aarch64 (64x) and only the support provided by amazon-linux-extras remis is for x86_64 CPU, seems theres not any builder for aarch64 CPUs this link provide more information https://forum.remirepo.net/viewtopic.php?id=4016, the remis repositories for php8.1 only has available x86_64/ folder https://fr2.rpmfind.net/linux/remi/enterprise/7/php81/, any advice is very pleased

[RahulDey12]

New issue is coming during update

Could not retrieve mirrorlist https://amazonlinux-2-repos-ap-south-1.s3.dualstack.ap-south-1.amazonaws.com/2/extras/php8.1/latest/x86_64/mirror.list error was
14: HTTPS Error 403 - Forbidden

Looks like they have blocked access to the rpms

Despite my ec2 instance is pulling php8.1 as available through amazon-linux-extras i am having the same issue Could not retrieve mirrorlist https://amazonlinux-2-repos-ap-south-1.s3.dualstack.ap-south-1.amazonaws.com/2/extras/php8.1/latest/x86_64/mirror.list error was 14: HTTPS Error 403 - Forbidden , the CPU Architecture of my ec2 instance is aarch64 (64x) and only the support provided by amazon-linux-extras remis is for x86_64 CPU, seems theres not any builder for aarch64 CPUs this link provide more information https://forum.remirepo.net/viewtopic.php?id=4016, the remis repositories for php8.1 only has available x86_64/ folder https://fr2.rpmfind.net/linux/remi/enterprise/7/php81/, any advice is very pleased

Remi doesn't provide any build for ARM CPU.

[laurent-le-graverend]

It finally appeared today: amazon-linux-extras list | grep php

On what AMI do you see it @peachesontour ?

I don't see it yet on the latest Arm64 AMI (Amazon Linux 2 LTS Arm64 Kernel 5.10 AMI 2.0.20221004.0 arm64 HVM gp2 ami-081dc0707789c2daf)

[peachesontour]

Amazon Linux 2 AMI 2.0.20210427.0 x86_64 HVM gp2

But I get the Could not retrieve mirrorlist error mentioned above while trying to update too. Does anyone have a solution?

[RahulDey12]

This is now ridiculous guys, my production deployment is stuck for 2 months. I and my team member's patients are breaking now. What a terrible experience. I think this is the time when I am gonna switch to some other distro.

[KZeni]

@laurent-le-graverend:

It finally appeared today: amazon-linux-extras list | grep php

On what AMI do you see it @peachesontour ?

I don't see it yet on the latest Arm64 AMI (Amazon Linux 2 LTS Arm64 Kernel 5.10 AMI 2.0.20221004.0 arm64 HVM gp2 ami-081dc0707789c2daf)

This is weird.

I'm seeing the same thing (PHP 8.1 isn't listed via amazon-linux-extras.) Oddly, I saw PHP 8.1 being offered via amazon-linux-extras on this same EC2 instance a week ago or so back when people were reporting it was made available.

So... did AWS remove PHP 8.1 from amazon-linux-extras just a few days after adding it? Or why else is it no longer being shown when this same instance was showing it as offered last week (didn't make the transition during the few days it was available [and kinda glad I didn't if they removed that offering for a good reason])? Is it planning to be made available again?

[Ben-CA]

Looking at upgrading from PHP 7.4 to PHP 8.1 on AWS EB - is there a way to upgrade this yet (preferably from the console) without needing to setup an entirely new environment? Like, surely by now there is some sort of a quick "migration upgrade" path?

Why can't I upgrade to one of these with a few clicks?

[JvH69]

Looking at upgrading from PHP 7.4 to PHP 8.1 on AWS EB - is there a way to upgrade this yet (preferably from the console) without needing to setup an entirely new environment? Like, surely by now there is some sort of a quick "migration upgrade" path?

The solution as described by andyexeter worked for me

[faizanakram99]

@Ben-CA it is risky to do inplace upgrade, create a new environment and then swap cname ... see blue green deployment docs of aws beanstalk

[Ben-CA]

I know there's the command line option that some people have had success with, and in the past I've created a new environment - but my environment has a lot of environment variables, and to my knowledge these all need to be manually copied and pasted to the new one. At least last time I did it (months ago) while you could save the configuration, it won't let you pick the updated platform version if you try to use the saved configuration - so that's not useable.

I find it bizarre that AWS doesn't have a better way of doing this - why isn't there a "change environment platform" option in the console, that could automate creating a blue/green deployment with all the same settings?

And @faizanakram99 - my apps only use a single instance - what are the risks of an in-place platform update? (I would typically do this in off-hours anyways and test afterwards; and worst case I just need to re-create the environment?) I have a number of separate applications to do, and there's just so much room for making a mistake with manually setting up a new environment, copying all the variables, etc.

[Ben-CA]

I just tested the upgrade on one of my demo environments (going from PHP 7.4) via the command line update.

Opened AWS CloudShell, and pasted in: aws elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2 v3.5.0 running PHP 8.1" --environment-id "e-XXXXXXX" --region "XX-XXXXXX-1"

Pressed enter, and it took maybe 2 minutes max - went grey in the console, then came back healthy. Had a total of perhaps 30 seconds of downtime for my application (demo). It automatically created the new instance, and once healthy, removed the old instance.

What would be the downside of using this on production environments on a weekend when nobody will notice the 30 seconds of downtime? (I've spent hours to accomplish the same thing "manually" via creating a new environment in the console.)

[faizanakram99]

@Ben-CA make sure the installed version of PHP in that demo environment is 8.1 after upgrade.

The in place upgrade command isn't always smooth, in one of our apps the installed version was stuck on PHP 8 despite beanstalk showing it as PHP 8.1 version.

I agree with you though, copying environment variables is a painful from console UI, might be a good idea to invest in IaC like pulumi, or just plain bash scripts using aws cli where you can supply env vars via a file

[Ben-CA]

Thanks @faizanakram99; I checked via PHP info() and it says it's PHP 8.1.11 now, so seems to have worked.

[Ben-CA]

Just updating this for future reference; that command worked great for 3 environments where I was going from PHP 7.4, but only "pretended" to update on the 4th one that I tried upgrading from 8.0. Like @faizanakram99 encountered, it shows in the AWS console that it's on 8.1 now:

While a php info() running on the server shows it hasn't actually been updated:

[andryska]

@Ben-CA we had the same issue and realized that there was an Image ID hardcoded on the environment:

AWSEBAutoScalingLaunchConfiguration.aws:autoscaling:launchconfiguration:
  ImageId: ami-00cf32aa5968ac2fd

This ImageId contains PHP 8.0.8 so it would never update even if ElasticBeanstalk thinks it's updating.

Save your config locally with eb config save and see if you have the same.

[Ben-CA]

@andryska - I noticed there was an AMI set for it, and wondered if perhaps that was the issue. (And haven't got around to investigating further yet) Were you able to remove that AMI from the environment config and then it worked?

[andryska]

@andryska - I noticed there was an AMI set for it, and wondered if perhaps that was the issue. (And haven't got around to investigating further yet) Were you able to remove that AMI from the environment config and then it worked?

Yes. Just remove the two lines and then eb create env-name --cfg saved-config-name and it will create it with the latest PHP version.

[Ben-CA]

Thanks; I'll have to give that a try. (I was thinking of trying from the console actually; that's where I noticed the AMI set.)

[KZeni]

For those using Amazon Linux 2 with amazon-linux-extras, it looks like PHP 8.1 has reappeared!

It's also been there for a few days now (unlike the last time it was available where it was removed a couple of days later... though, I imagine it could still disappear again while I have my doubts they'd do that a second time.)

So it seems like we now have PHP 8.1.x via amazon-linux-extras just in time for PHP 8.0.x to be entering security-only support and PHP 8.2.x having been released. Kinda wondering if they're going to keep this recent update going and also loop PHP 8.2.x into this to be available as well at some point soon, but I wouldn't be surprised if they make this a trend of only releasing the next version of PHP once the newest version is available & the PHP version they're offering via amazon-linux-extras (ex. we'll get 8.2.x once 8.1.x enters security-only support & 8.3.x is released in about a year from now... while I can't say one way or the other, the timing of this becoming available on this particular date seems like more than a coincidence.)

Meanwhile, Amazon Linux 2 appears to have extended its EOL date yet again so it's now June 30th, 2025 per https://aws.amazon.com/amazon-linux-2/faqs/ (it seems they missed a few dates still saying 2024 in some spots of the FAQ while the main date now does say 2025) so we'll likely have 2 more major PHP version releases needing to be handled via amazon-linux-extras yet (per them stating they'll still be supporting that OS & its core components [as the FAQ states as well] until then.) This is probably due to Amazon Linux 2022 (AL2022) which is the successor to AL2 still being in release candidate status (per https://aws.amazon.com/linux/amazon-linux-2022/) while then probably needing to allow for a reasonable amount of time to transition from one to the other without one being unsupported and/or one not being deemed ready for production use.

[lutzklai]

@Ben-CA To accomplish the upgrade from 8.0 to 8.1 I actually just used the AWS GUI.

Steps:

1. In the beanstalk service, save beanstalk configuration
2. goto your beanstalk s3 bucket to download the template
3. in a text editor, manually update the platform version in the template
4. upload the template back to s3
5. In the beanstalk service, load the updated template back to the same environment

and it just spins down the existing EC2 instances that contains php 8.0 and spins up an 8.1 instance. That config actually copies everything including environment variables so you could do the whole blue-green deployment under a new environment if you wanted to. But the in-place upgrade worked for my use case.

I faced a similar issue to you and @andryska where every time I deployed it reverted the instance back to the php 8.0 platform. It turned out I had the SolutionStack variable in my env.yaml file pointing to a php 8.0 stack instead of 8.1. Updating that variable to 8.1 fixed it.

[Ben-CA]

Thanks @lutzklai - I used the AWS GUI as well to change AMI (SolutionStack) that was specified in the config to an AMI that had PHP 8.1 instead. Different method than you describe, but likely accomplished essentially the same thing in the backend. (I'm not sure why this AMI is statically assigned, but I didn't find a simple way to avoid that.)