New v5 and new roadmap

[mistraloz]

Hello Everybody,

I'm sorry because we haven't had lot of time to maintain these images from few month. We will start a new batch of feature and a new version 5. We haven't set up a date yet but it's going to happen as soon as possible (I will try to dedicate at least one day per weekon it from now).

This topic will be used as announcement wall but also for open discussions about features and organisation of this repository. If some active contributors want to join us, they are welcome to work on some part, review, give idea, ...

Minimal requirements for V5 :

1. Upgrade the base image to the last ubuntu LTS version : it will help to reduce any security issue like #342
2. Usage of https://github.com/mlocati/docker-php-extension-installer to manage installation of php extensions (very good tool, it's seem useless to duplicate the work). It supports all versions from php 5.5 and is actively maintained.
3. A good implementation a tiny process manager to avoid bad SIG signal to process and allow a well management for multiple PID in same container (this type of usage will still not be recommended for production but very useful in development) #215 #147
4. A better implementation of php-fpm (very more efficient in production that mod php) : lot of issues was related to that last year

Breaking changes

It will depend on difficulties encountered during the development. But this is what we expect:

1. Less extensions may be managed in the fat image : docker-php-extension-installer allow to manage lot of extension, we should implement all... but more used will be preinstalled, others will be just installed at first boot.
2. We can continue to have an active support onto 6 version of php, with 3 variants, and 5 version of node... and all for arm and amd. It's too much. In the other hand, theses images are very useful because we can upgrade a project in php7.1 with it and continue until 8.2. My idea is to continue with best effort support but maybe with only different mix of possibilities for deprecated versions.
3. Configuration with ARG PHP_EXTENSIONS=my_ext , ENV PHP_EXTENSIONS=my_ext and ENV PHP_EXTENSION_MY_EXT=1 are too confused. We need to find a better idea to avoid mistakes (and keep a low number of images layers : it's the main trouble with that). It may require to remove the "ON BUILD" feature to add php extensions and use instead the regular usage with docker-php-extension-installer.
4. ... this list is not exhaustive, and we can discuss it if we find solutions to bring the V4 configuration to V5

Roadmap

In addition to minimal features for V5, i have in my head, some others objectives for this version :

1. A more usable documentation for that : especially for php-fpm, it requires a good implementation of others process (nginx for file and traefik with a good translation of real user ip per example)... but this tool starts to have a lot of different features so we need to organise it
2. Manage an alpine base image (of wasm? I dont know yet what is possible with web assembly) to allow faster build time and smaller images. Especially from the support of arm, ours builds stages are very (very very) long. It's reduce the capacity of deploying new features, make security updates, etc. But migrate from ubuntu to alpine seems like a too high breaking change. I prefer using alpine as default but continue to allow ubuntu for local dev of user with less skills in sysops.
3. Focus on security support : implement more scans features and publish their result. It's a very important thing for confidence. We cannot anymore take a tool from Github and just said "it's okay", we need to provide some proof and ensure the security support. It may also require some guidance on documentation for implementation.
4. A new support way as asked here #357 : we spoke about that for a while internally but we don't know exactly how to manage that. We will see that. In addition, it can't be the only way to have more support : we need also to find more contributors (for PR, review, ... but also to challenging the features of the project).
5. Abandonment of orbit tool : it was a great tool but he lived. We need to have a more common way to manage templating (buildx seems like a better way for many things). The objective is to allow more contributions.
6. A reflexion should be conduct for the V6 about the objective of theses images. Currently we have apache+php+node+supercronic+startup command+blackfire+... whooo : we invented the macroservice? Currently we will stay like that but maybe we should have a reflexion for the v6 about the main usages and instead of one big image, suggest usage of different micro services (file http server + php-fpm + cron + mysql + reverse proxy + smtp + startup command from the manager like kube or others, etc).

That's all. Thx for reading. Please comment, i'm starting the work. Please tell me if you have suggestions, advices, if you want to join for a meeting in visio and work together, ...

[robjuz]

@mistraloz First of all thanks for the great work done so far. I'm using this images in my daily work in dev and prod. I just love how this images are easy to use and overcome all the pitfalls that come when working with docker.

I would love to support your work with v5. Just let me know how can I help!

[nguyenk]

Hello @robjuz We are truely very happy to read this message. @mistraloz is currently off, he weill be back in 3 weeks. I'm sure he will get back to you when he returns.

In any case, any help will be greatly appréciated.

[robjuz]

My first idea would be to migrate from ubuntu to the official php images based on debian and alpine. There is also a apache version. This would speedup the delivery and reduce the image size.

I'm waiting for your feedback.

[mistraloz]

Hello @robjuz sorry for the delay of my answer. You can follow the progress of the v5 dev onto https://github.com/thecodingmachine/docker-images-php/blob/v5/ROADMAP_v5.md Currently it's still not possibilible to contribute with PR because i make lof be refactor about structure of the files on the branch then i will hard reset and link the changes... BUT if you have any suggestion or advices please tell me here.

I hope to open the v5 to contribution on 2th october. After that we can split the work on the different features. We can also have a visio meeting with anyone wants to contribute (sometime it's easy to challenge the global vision or to improve the motivation).

[benjilebon]

Concerning the alpine image, i've seen discussions going around concerning the speed and raw performance around execution in alpine based environments, this thread demonstrates an example using python : https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image

While this isn't talking specifically about php, it actually affects it in some way ( TL;DR: Alpine is using a different C base library implementation called "musl", which has some differences in implementing memory allocation compared to glibc, used in debian based distros)

I agree to the idea of having a big reduced time on delivery & image size, but potentially losing about ~50% of performance on a production environment is not acceptable, maybe keeping a sort-of long term support for debian based image would be beneficial for performance-sensible projects if that kind of problem shows-up in alpine versions

(just a heads-up for now, but i'm okay to contribute in some way with benchmarks if needed in the future)

[robjuz]

Debian-slim is really small. I was a big fan of alpine, but get into some issues with python libraries and switched to debian-slim. Best move ever.

[MrMage]

@mistraloz Thank you for all the work that went into these images; I've been using them for years. I do wonder whether it would make sense to release a "small" v5 upgrade that only upgrades the Ubuntu version to 22.04, with the remaining changes being pushed out to v6 and beyond? That could already let users benefit from overall system performance improvements affecting PHP while hopefully incurring less work than making the other breaking changes.