Feasibility of switching Linux images to Debian

[drpayyne]

All linux-based images (PHP, Varnish, etc.) currently use centos:8. The main issue that I came across with this is that, there are no ARM builds for PHP. Remi doesn't have ARM builder, so there's no ETA on this either. This is currently the biggest blocker that I've come across while trying to make Warden multi-platform (Intel & Apple Silicon).

My current approach: https://github.com/drpayyne/docker-php. I have rebuilt all the four images (CLI & FPM, both with & without loaders) as multi-platform Docker images. BUT. I had to switch to Fedora. Since Remi doesn't provide PHP for ARM, and neither does CentOS itself (CentOS provides some extensions, but not all). I had to switch to Fedora, which provides PHP and all its extensions for both platforms.

My question: can we either switch to Fedora... or... Debian?

Our two main dependencies in this repo are - Docker and PHP. Why not use the official PHP Docker image? Its homepage lists all the available tags and guides.

• All versions 7.3+ (enough legacy support)
• 8.1RC is already supported... (quick future support)
• Multi-platform (perfect)
• Extensions can be installed using the guide in https://github.com/mlocati/docker-php-extension-installer which is what they reccomend officially for easy installation of extensions. Looking at their extension support matrix - it has all (I think?) ref: https://github.com/mlocati/docker-php-extension-installer#supported-php-extensions

These official PHP Docker images use Debian underneath so here's my question. Is it feasible to switch to these images? For supporting both platforms, for quick updates, for official support, etc.

I currently have made Warden work with PHP 7.4 on my Apple Silicon, but 7.3 is looking very tough to make work, and I've no idea about 8.0 yet - USING Fedora. On the other hand, switching to these official PHP Docker images seem like the right way forward.

Am I blatantly missing anything? What are your thoughts? I'm actively trying to make Warden work as smooth as possible for both platforms, so any feedback is appreciated. Thank you!

[ihor-sviziev]

@davidalger, could you review?

[drpayyne]

Update - I have rebuilt all PHP images using the official PHP images based on Debian and also installed all necessary extensions using the php-extension-installer in my branch https://github.com/drpayyne/docker-php/tree/debian.

[davidalger]

Remi doesn't have ARM builder, so there's no ETA

I am aware of this, yes.

switch to Fedora

At this point 7.3 and 7.2 can be left behind (7.2 is already EOL and 7.3 is about to be in December) but at minimum 7.4 and 8.0 would need to be covered (ideally 8.1 as well). Do you know if we can cover all three of these versions?

Why not use the official PHP Docker image?

These may work for many things, but there can also be a host of issues created as a result of the use of Alpine which uses muslc instead of glibc. Early on Warden (and the base images found here) were based on these "official" Apine based php docker images, and it worked ok for some things, but was not rock solid and stable and (particularly when IonCube and/or SourceGuardian were enabled) there were weird crashes and segfaults resulting from the slight differences in C library implementations (muslc vs glibc). Could be a different story using the Debian base images, but this is the story behind why I transitioned to CentOS back in July of 2019 (away from the official images) and as for why EL vs Deb, the reasons described here explain that (TL:DR; I don't really use Deb much, I'm an EL guy and so these are the configs I know and have proven as rock solid in production systems over the years): wardenenv/warden#8 (comment)

@ihor-sviziev Caught me right as I was typing up a reply. My apologies for the delay.

@drpayyne Definitely appreciate your efforts and ideas. I wish I had an M1 Mac (or ARM based Linux) laying around to try them on myself. Need to review what you did here (wardenenv/warden#399 (comment)) and see what can be easily brought in. Time is my limiting resource atm.

[davidalger]

Looks like PHP 8.0 will be available in Fedora 35, and 8.1 planned for Fedora 36. Doesn't sound like dual version, or even keeping 7.4 support is planned. https://fedoraproject.org/wiki/Changes/php80

[ihor-sviziev]

Btw afaik GitHub actions does support arm based builds. Maybe, we can write some simple tests?

[drpayyne]

Btw afaik GitHub actions does support arm based builds. Maybe, we can write some simple tests?

yes, it does. I have been building all my images using reusable GitHub actions.

Why not use the official PHP Docker image?

About the base Docker image, I feel we can use the official PHP image which has many variants. We can use the bullseye version of Debian and no need to use Alpine or Fedora. All the available version can be found at https://github.com/docker-library/docs/tree/master/php.

was not rock solid and stable and (particularly when IonCube and/or SourceGuardian were enabled)

About the loaders having issues on Alpine, it installs well on Debian for PHP 7.4 and 8.0. The version support matric is documented at https://github.com/mlocati/docker-php-extension-installer.

Thanks for the response, @davidalger @ihor-sviziev!

[drpayyne]

At this point 7.3 and 7.2 can be left behind (7.2 is already EOL and 7.3 is about to be in December) but at minimum 7.4 and 8.0 would need to be covered (ideally 8.1 as well). Do you know if we can cover all three of these versions?

The PHP versions are definitely supported officially more than any other source, but the extensions aren't entirely ready yet for 8.1. ioncube for example, isn't supported for 8.1 using the extensions-installer method, but that's due to the unavailable upstream support, which I feel would come once 8.1 is GA.

[davidalger]

IonCube doesn't even support PHP 8.0 at this point. They're super slow to release updates for new versions of PHP. SourceGuardian is typically available very shortly after GA releases.

[drpayyne]

Interesting. In that case, installing extensions shouldn't be a problem. And we can use debian-bullseye instead of alpine since you've described it having issues.

[ihor-sviziev]

CentOS 8 already reached the end of life

Looks like we should migrate to Fedora, https://rockylinux.org/ or something similar.

[k4emic]

+1 for moving to the official docker images, both for PHP and for other services used by the warden project, for the reasons already mentioned.

I'm wondering what would be the most appropriate way to approach the distro hop in terms of image naming. Taking over the existing names is going to cause trouble for (some) users and downstream projects.

But slapping on a -debian (or -buster/-bullseye) suffix comes with some problems for the warden project, as this could end up requiring users to specify the distro in the .env file.

PHP_VERSION=8.1-bullseye
REDIS_VERSION=6-bullseye
ELASTICSEARCH_VERSION=7.6-official
...

This is still solveable, but something worth considering before settling on a naming strategy for images based on a new distro.

[ihor-sviziev]

FYI the base image has been switched to quay.io/centos/centos:stream8 in 671d2dc, but still, almost all packages are not available for aarch64 architecture 😢

[ihor-sviziev]

Hi @drpayyne,
Would you mind if I'll create a Pull Request with changes from your repo (adding Debian based images) to the main repo to make all the images available for everyone?

[drpayyne]

Sure @ihor-sviziev, I was planning to do the same but wanted to wait for @davidalger to chime in. I've added you as a collaborator to my fork of docker-php. Please create a new branch with any extra changes you feel necessary and create a PR from the new-branch so that this repo remains stable. Thank you!