Azure App Service: Unable to deploy PHP 8.0-based applications with Composer enabled

schakko commented 3 years ago

Bug Report

The error occurs when deploying an Azure App Service with the new PHP 8.0 Runtime Stack. When changing the Runtime Stack to PHP 8.0, the log of the latest deployment in the Deployment Center produces the following output:


Command: oryx build /home/site/repository -o /home/site/wwwroot --platform php --platform-version 8.0 -i /tmp/8d972f39a05c47e --log-file /tmp/build-debug.log 

Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx

You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.20210618.2, Commit: d70100fba618b33e529c149b7d2d5f2c981ebbb1, ReleaseTagName: 20210618.2

Build Operation ID: |/Ckpf6cQHak=.9118744c_

Repository Commit : 3c381334fde76a3bd6edbefbf94e5cd4225e3358

Detecting platforms...

Detected following platforms:

  nodejs: 10.22.0

  php: 8.0.3

Using intermediate directory '/tmp/8d972f39a05c47e'.

Copying files to the intermediate directory...

Done in 0 sec(s).

Source directory     : /tmp/8d972f39a05c47e

Destination directory: /home/site/wwwroot

PHP executable: /tmp/oryx/platforms/php/8.0.3/bin/php

php: error while loading shared libraries: libonig.so.4: cannot open shared object file: No such file or directory

Composer archive: /tmp/oryx/platforms/php-composer/2.0.8/composer.phar

Running 'composer install --ignore-platform-reqs --no-interaction'...

php: error while loading shared libraries: libonig.so.4: cannot open shared object file: No such file or directory\n/opt/Kudu/Scripts/starter.sh oryx build /home/site/repository -o /home/site/wwwroot --platform php --platform-version 8.0 -i /tmp/8d972f39a05c47e --log-file /tmp/build-debug.log ```

lucashfreitas commented 2 years ago

+1. Same issue here - it's breaking for a basic laravel default installation, so we can't deploy using PHP 8.

arroyc commented 2 years ago

We are looking into this .. sorry for your trouble and thanks for your patience

arroyc commented 2 years ago

@lucashfreitas would you be able to provide some sample apps for this scenario? our sample app seems to be working fine which means our sample app is not a good example to test this.

MarkoVk95 commented 2 years ago

Hi @arroyc , the default codeigniter app does not work, I've just tested

composer create-project codeigniter4/appstarter project-root

DiscoParadise commented 2 years ago

mbstring is a required PHP extention for most frameworks. Based on documentation of php.net:

Oniguruma is necessary for the regular expression functions with multibyte character support. As of PHP 7.4.0, pkg-config is used to detect the libonig library. Prior to PHP 7.4.0, Oniguruma was bundled with mbstring, but it was possible to build against an already installed libonig by passing --with-onig[=DIR].

https://www.php.net/manual/en/mbstring.installation.php

As of PHP 7.4 libary libonig aka Oniguruma needs to be installed.

lucashfreitas commented 2 years ago

Hello @arroyc thanks for getting back, sorry for the delayed reply.

As @DiscoParadise mentioned above, and I believe I've also added the same thing in the thread in Azure Forum, it seems that the lack of PHP extension is the reason why the build is failling for PHP 8.0.

I don't have a sample but you could use a basic laravel example and you should be able to reproduce it. You can follow this guide to create a new project with composer https://laravel.com/docs/8.x#installation-via-composer and it should have a new installation out of the box.

Please let me know if I can provide any other info or help to reproduce/fix it.

Thanks and have a nice day ahead!

TAgaroud commented 2 years ago

I am having the exact same problem. Laravel projects somehow can't be deployed on Azure using github and PHP version 8.0. I got the same error als the OP.

I think the only thing you could do is set your PHP runtime stack in Azure back to 7.4 untill this issue is fixed.

qianz2 commented 2 years ago

Hello @arroyc thanks for getting back, sorry for the delayed reply.

As @DiscoParadise mentioned above, and I believe I've also added the same thing in the thread in Azure Forum, it seems that the lack of PHP extension is the reason why the build is failling for PHP 8.0.

I don't have a sample but you could use a basic laravel example and you should be able to reproduce it. You can follow this guide to create a new project with composer https://laravel.com/docs/8.x#installation-via-composer and it should have a new installation out of the box.

Please let me know if I can provide any other info or help to reproduce/fix it.

Thanks and have a nice day ahead!

Hello @lucashfreitas,

I'm trying to reproduce the case by following the steps to create a basic laravel example, but I didn't see the same error message. I'm curious if the issue is resolved by recent check-in changes. Here is what I get locally using the latest oryx version:


root@bd57d36e55f6:/example-app# oryx build --platform=php --platform-version=8.0.3
Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.0.0, Commit: c7474d9b6ecd63498f8bc96c82ddd3ba2a4f0102, ReleaseTagName:

Build Operation ID: |7YVRCQJ42Xo=.53a08209_

Detecting platforms...
Detected following platforms:
  nodejs: 14.17.6
  python: 3.8.12
  php: 8.0.3
Version '8.0.3' of platform 'php' is not installed. Generating script to install it...

Source directory     : /example-app
Destination directory: /example-app

Downloading and extracting 'php' version '8.0.3' to '/tmp/oryx/platforms/php/8.0.3'...
Downloaded in 1 sec(s).
Verifying checksum...
Extracting contents...
performing sha512 checksum for: php...
Done in 2 sec(s).

PHP executable: /tmp/oryx/platforms/php/8.0.3/bin/php
Composer archive: /opt/php-composer/2.0.8/composer.phar
Running 'composer install --ignore-platform-reqs --no-interaction'...

Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fruitcake/laravel-cors
Discovered Package: laravel/sail
Discovered Package: laravel/sanctum
Discovered Package: laravel/tinker
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
77 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

Removing existing manifest file
Creating a manifest file...
Manifest file created.

Done in 3 sec(s).

lucashfreitas commented 2 years ago

Hello @qianz2.

Sorry for taking long to reply - What php codebase are you using to reproduce this issue? I was able to reproduce it again today when I was trying to deploy a laravel demo app to PHP 8.

I see that we have a pull request with a fix for that? So I assume this issue will be fixed as soon as the PR gets merged?

Thanks

schakko commented 2 years ago

@qianz2 Is there any ETA when the fix will go live?

qianz2 commented 2 years ago

I was able to resolve the issue by running following commands:

**ln -s /usr/lib/x86_64-linux-gnu/libonig.so /usr/lib/x86_64-linux-gnu/libonig.so.4 apt-get update apt-get install software-properties-common apt-get update

echo "deb http://ppa.launchpad.net/xapienz/curl34/ubuntu bionic main" | tee /etc/apt/sources.list.d/docker.list apt-get update

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys D1DAC98AF575D16E

apt-get update

apt-get remove curl apt-get remove libcurl4

//apt-cache showpkg curl //apt-cache showpkg libcurl4 apt-get install libcurl4=7.58.0-2ubuntu3.13ppa2 apt-get install curl=7.58.0-2ubuntu3.13ppa2 oryx build apps/yutobo-php8 --platform=php --platform-version=8.0**


root@01c51886ad1c:/# oryx build apps/yutobo-php8 --platform=php --platform-version=8.0
Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.0.0, Commit: c7474d9b6ecd63498f8bc96c82ddd3ba2a4f0102, ReleaseTagName:

Build Operation ID: |E1kbI5qqOUg=.efaba46_
Repository Commit : 0efe4e596b092f925c6eaa93044412804f584326

Detecting platforms...
Detected following platforms:
  php: 8.0.13
Version '8.0.13' of platform 'php' is not installed. Generating script to install it...

Source directory     : /apps/yutobo-php8
Destination directory: /apps/yutobo-php8

Downloading and extracting 'php' version '8.0.13' to '/tmp/oryx/platforms/php/8.0.13'...
Downloaded in 0 sec(s).
Verifying checksum...
Extracting contents...
performing sha512 checksum for: php...
Done in 1 sec(s).

Downloading and extracting 'php-composer' version '2.0.8' to '/tmp/oryx/platforms/php-composer/2.0.8'...
Downloaded in 0 sec(s).
Verifying checksum...
Extracting contents...
performing sha512 checksum for: php-composer...
Done in 0 sec(s).

PHP executable: /tmp/oryx/platforms/php/8.0.13/bin/php
Composer archive: /tmp/oryx/platforms/php-composer/2.0.8/composer.phar
Running 'composer install --ignore-platform-reqs --no-interaction'...

php: Symbol `OnigEncodingEUC_JP' has different size in shared object, consider re-linking
php: Symbol `OnigEncodingUTF8' has different size in shared object, consider re-linking
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Generating autoload files

Removing existing manifest file
Creating a manifest file...
Manifest file created.

Done in 1 sec(s).

peven commented 2 years ago

+1 on this issue

I'm currently experiencing the same issue with an Azure App Service that's been upgraded from PHP 7 to 8. My company has a dozen more to migrate to PHP 8 (in Production) and is desperately waiting for this fix.

@qianz2 : Thanks for the tentative fix, it looks promising ! Hopefully it will go into production soon.

ManuelLlorens commented 2 years ago

+1 here

My composer.json:

{
    "name": "noobe/php-8-test",
    "type": "project",
    "require": {
        "mongodb/mongodb": "^1.11"
    }
}

ln -s /usr/lib/x86_64-linux-gnu/libonig.so /usr/lib/x86_64-linux-gnu/libonig.so.4 has not worked for me.

ZANZAAA commented 2 years ago

+1 None of the solution mentioned above worked for me.

Do we need to get back to PHP 7.4 to make the deployment work?

"require": {
        "php": "^7.3|^8.0",
        "doctrine/dbal": "^3.1",
        "eway/eway-rapid-php": "^1.3",
        "fideloper/proxy": "^4.4",
        "fruitcake/laravel-cors": "^2.0",
        "guzzlehttp/guzzle": "^7.0.1",
        "haruncpi/laravel-user-activity": "^1.0",
        "intervention/image": "^2.5",
        "lab404/laravel-impersonate": "^1.7",
        "laravel/framework": "^8.12",
        "laravel/tinker": "^2.5",
        "laravel/ui": "^3.2",
        "maatwebsite/excel": "^3.1",
        "spatie/laravel-permission": "^4.0"
    }

TAgaroud commented 2 years ago

As far as I know, this issue isn't fixed and the best thing to do for now is to revert back to PHP 7.4 or use a different host than Azure to host your PHP 8 application.

filipewellpack commented 2 years ago

Hi,

It's not fixed because on azure web app linux for php8, debian 10 buster is installed and libonig is in number 5 debian-libonig

d13r commented 2 years ago

Same here ☹️ (Laravel 9, so downgrading to PHP 7.4 is not an option):

Executing pre-build command...
Finished executing pre-build command.
PHP executable: /tmp/oryx/platforms/php/8.0.13/bin/php
Composer archive: /tmp/oryx/platforms/php-composer/2.0.8/composer.phar
Running 'composer install --ignore-platform-reqs --no-interaction'...

php: error while loading shared libraries: libonig.so.4: cannot open shared object file: No such file or directory

JanMisker commented 2 years ago

As a workaround I am deploying using zip file, basically making a big zipfile of all code (including vendor directory but excluding git and other local dev dirs) and deploying that. As a bash script it's something like

#!/bin/sh

npm run prod

zip ../deploy.zip -qr . -x ".git**" -x ".env*" -x ".vscode**" -x "node_modules**" -x "*.publishsettings" -x "storage/framework/cache/**" -x "storage/framework/sessions/**" -x "storage/framework/views/**" -x "storage/logs/**" 

az webapp deploy --resource-group XXXX --name XXXX --src-path ../deploy.zip

This is of course very much suboptimal compare to a normal pipeline, but at least it works for now...

qianz2 commented 2 years ago

The issue occurred in the github-actions buster based image. We've tried to build the same php apps in the lts-versions buster based image or full build image and it worked. We're discussing with App Service team and see if they're able to switch to the lts-versions buster based image. One thing that'll be helpful to try out is to set up the app settings, this will switch to the full build image: SCM_DISABLE_BUSTER_KUDU=true

d13r commented 2 years ago

@qianz2 That fixed the Composer issue - thanks.

However, it seems to run Nginx rather than Apache. I'm not actually sure if that's true for the default PHP 8.0 build image as well, since I never got it working, but the docs still say it's Apache. Any idea how to tell App Service to change the document root in Nginx? Thanks.

2022-02-24T08:17:53.771201886Z Running oryx create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh     -bindPort 8080 -startupCommand 'azure/startup.sh; php-fpm;'
2022-02-24T08:17:53.786552931Z Found build manifest file at '/home/site/wwwroot/oryx-manifest.toml'. Deserializing it...
2022-02-24T08:17:53.788390072Z Build Operation ID: |PzgDJ5/yUEc=.f813ed36_
2022-02-24T08:17:54.635794103Z Writing output script to '/opt/startup/startup.sh'
2022-02-24T08:17:55.157312709Z Starting nginx: nginx.
2022-02-24T08:17:55.248552820Z [24-Feb-2022 08:17:55] NOTICE: fpm is running, pid 49
2022-02-24T08:17:55.249046232Z [24-Feb-2022 08:17:55] NOTICE: ready to handle connections

JanMisker commented 2 years ago

@davejamesmiller

Any idea how to tell App Service to change the document root in Nginx? Thanks.

You can run a custom startup script that adjusts the nginx config, see here for a full example: https://www.schakko.de/2021/09/08/deploying-php-8-0-applications-with-azure-app-service/

d13r commented 2 years ago

Thanks @JanMisker

horihiro commented 2 years ago

PHP executable: /tmp/oryx/platforms/php/8.0.3/bin/php

This php executable seems to refer libonig.so.4 in Kudu container and there is not the .so file in this container. So the php` execution during the oryx build process fails.

filipewellpack commented 2 years ago

see this comment : https://github.com/microsoft/Oryx/issues/1100#issuecomment-1049410372 it will work after modification.

thanks to @qianz2

ManuelLlorens commented 2 years ago

SCM_DISABLE_BUSTER_KUDU=true works for us, but the MongoDB driver is missing in the image.

The PHP 8 image does not seem ready for production at all.

lucashfreitas commented 2 years ago

@qianz2 there is any update on this? It has been 6 months and the error is still there, I just tried to deploy a default laravel installation on PHP 8.0 and the oryx build is still failing due to the problem with the libonig.so.4.

Thanks.

Henriquedn commented 2 years ago

The issue occurred in the github-actions buster based image. We've tried to build the same php apps in the lts-versions buster based image or full build image and it worked. We're discussing with App Service team and see if they're able to switch to the lts-versions buster based image. One thing that'll be helpful to try out is to set up the app settings, this will switch to the full build image: SCM_DISABLE_BUSTER_KUDU=true

This worked for me.

pilot-max commented 2 years ago

Two hundred and twenty-five days later and no update.

daniv-msft commented 2 years ago

Apologies for the slow communication here. Adding @qianz2 from our side, who I know is working on this.

@qianz2 Could you please update this thread when you have more to share, or a potential ETA for resolution?

lucashfreitas commented 2 years ago

@pilot-max we have run into other issues apart from this one and ended up giving up as it seems PHP and Microsoft App Service don't play well together unless you are using a custom image/container. We have managed to find some workarounds, please flick a message if need help. It's sad as this is quite an important issue and easy to reproduce but hasn't been fixed for almost half a year!

horihiro commented 2 years ago

@daniv-msft @qianz2 I discussed this with India team. I sent you the internal thread.

qianz2 commented 2 years ago

I was able to resolve the issue by running following commands:

**ln -s /usr/lib/x86_64-linux-gnu/libonig.so /usr/lib/x86_64-linux-gnu/libonig.so.4 apt-get update apt-get install software-properties-common apt-get update

echo "deb http://ppa.launchpad.net/xapienz/curl34/ubuntu bionic main" | tee /etc/apt/sources.list.d/docker.list apt-get update

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys D1DAC98AF575D16E

apt-get update

apt-get remove curl apt-get remove libcurl4

//apt-cache showpkg curl //apt-cache showpkg libcurl4 apt-get install libcurl4=7.58.0-2ubuntu3.13ppa2 apt-get install curl=7.58.0-2ubuntu3.13ppa2 oryx build apps/yutobo-php8 --platform=php --platform-version=8.0**


root@01c51886ad1c:/# oryx build apps/yutobo-php8 --platform=php --platform-version=8.0
Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.0.0, Commit: c7474d9b6ecd63498f8bc96c82ddd3ba2a4f0102, ReleaseTagName:

Build Operation ID: |E1kbI5qqOUg=.efaba46_
Repository Commit : 0efe4e596b092f925c6eaa93044412804f584326

Detecting platforms...
Detected following platforms:
  php: 8.0.13
Version '8.0.13' of platform 'php' is not installed. Generating script to install it...

Source directory     : /apps/yutobo-php8
Destination directory: /apps/yutobo-php8

Downloading and extracting 'php' version '8.0.13' to '/tmp/oryx/platforms/php/8.0.13'...
Downloaded in 0 sec(s).
Verifying checksum...
Extracting contents...
performing sha512 checksum for: php...
Done in 1 sec(s).

Downloading and extracting 'php-composer' version '2.0.8' to '/tmp/oryx/platforms/php-composer/2.0.8'...
Downloaded in 0 sec(s).
Verifying checksum...
Extracting contents...
performing sha512 checksum for: php-composer...
Done in 0 sec(s).

PHP executable: /tmp/oryx/platforms/php/8.0.13/bin/php
Composer archive: /tmp/oryx/platforms/php-composer/2.0.8/composer.phar
Running 'composer install --ignore-platform-reqs --no-interaction'...

php: Symbol `OnigEncodingEUC_JP' has different size in shared object, consider re-linking
php: Symbol `OnigEncodingUTF8' has different size in shared object, consider re-linking
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Generating autoload files

Removing existing manifest file
Creating a manifest file...
Manifest file created.

Done in 1 sec(s).

A PR for this workaround has been out: https://github.com/microsoft/Oryx/pull/1350

horihiro commented 2 years ago

FYI: Another workaround until the above PR is merged.

By setting the following script to App Setting PRE_BUILD_SCRIPT_PATH, the PHP binary which doesn't link to libonig.so.4 is used in Oryx build process.

https://github.com/microsoft/Oryx/blob/main/doc/configuration.md#oryx-configuration

#!/bin/bash

PHP_VERSION=8.0.17
PHP_COMPOSER_VERSION=2.0.8

cd /tmp
curl -O https://oryx-cdn.microsoft.io/php/php-buster-${PHP_VERSION}.tar.gz
curl -O https://oryx-cdn.microsoft.io/php-composer/php-composer-buster-${PHP_COMPOSER_VERSION}.tar.gz

mkdir -p /tmp/oryx/platforms/php/${PHP_VERSION}
mkdir -p /tmp/oryx/platforms/php-composer/${PHP_COMPOSER_VERSION}

tar -xzf /tmp/php-buster-${PHP_VERSION}.tar.gz -C /tmp/oryx/platforms/php/${PHP_VERSION}
tar -xzf /tmp/php-composer-buster-${PHP_COMPOSER_VERSION}.tar.gz -C /tmp/oryx/platforms/php-composer/${PHP_COMPOSER_VERSION}

If you put the script prebuild.sh in {PROJECT_ROOT}/appservice/ as the following screenshot, the App Setting PRE_BUILD_SCRIPT_PATH is needed to set to appservice/prebuild.sh.

qianz2 commented 2 years ago

Closing the issue. The issue was fixed by two PRs: #1359 #1364. It will be available on our next release and App Service will update it on their end. Thanks for your patience and please let us know if there's further questions.

andysh-uk commented 2 years ago

Any ideas when this will be released to production in Azure uk-south?

I've just upgraded a 7.4 AppService app (deployment slot) to 8.0 and I'm getting the same issues as in this thread:

Command: oryx build /home/site/repository -o /home/site/wwwroot --platform php --platform-version 8.0 -i /tmp/8da5dbc80acdced --log-file /tmp/build-debug.log | tee /tmp/oryx-build.log

Oryx Version: 0.2.20220308.4, Commit: c92fa6a2d6fc14dc9646f80e2bb2e393a5cdc258, ReleaseTagName: 20220308.4

php: error while loading shared libraries: libonig.so.4: cannot open shared object file: No such file or directory\n/bin/bash -c "oryx build /home/site/repository -o /home/site/wwwroot --platform php --platform-version 8.0 -i /tmp/8da5dbc80acdced --log-file /tmp/build-debug.log | tee /tmp/oryx-build.log ; exit $PIPESTATUS

I've worked around it with the PRE_BUILD_SCRIPT_PATH script provided.

pauld-msft commented 2 years ago

@andysh-uk Apologies for the delay. It looks like App Service has not updated to the Oryx release in which this fix has been released and is still using a release from March (20220308.4). The fix has been out since our 20220427.1 release.

I will follow up with App Service and ensure that this is updated to the fixed version and send an update here once it is resolved.

horihiro commented 2 years ago

I verified php8 app deployment was succeeded without Prebuild script. The oryx version is 20220812.1 on West US.

andysh-uk commented 2 years ago

I'm still getting the same in UK South, looks like this hasn't been rolled out here yet.

root@87c2ffff5e5a:/home# oryx version  
Oryx Version: 0.2.20220329.1, Commit: 9031b36c02967bb4000645950680572a8a76fa56, ReleaseTagName: 20220329.1

pauld-msft commented 2 years ago

@andysh-uk App Service is in the process of updating the versions across regions. The rollout process is done by region and can take a few months.

pauld-msft commented 1 year ago

Hi, just wanted to quickly update here and mention that the rollout should have been complete for a little while now, so please let me know if this issue is persisting.

ManuelLlorens commented 1 year ago

The problem is solved. Thank you very much.

But there is no way to install the MongoDB driver and, so, it is useless for us.

Manuel Llorens [image: https://]about.me/ManuelLlorens https://about.me/ManuelLlorens?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links

El jue, 1 dic 2022 a las 17:08, Paul Dorsch @.***>) escribió:

Hi, just wanted to quickly update here and mention that the rollout should have been complete for a little while now, so please let me know if this issue is persisting.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/Oryx/issues/1100#issuecomment-1334003780, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUMON46LOL77XI3ZUQHVSLWLDERLANCNFSM5DVM2LOQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

microsoft / Oryx

Azure App Service: Unable to deploy PHP 8.0-based applications with Composer enabled #1100

Bug Report