Automatic builds to incorporate upstream security fixes?

[jasonhildebrand]

Description

Thanks for your work in this project. I am aware that these are not production-ready images, and are not advertised as such. And that's fine. I use your images as base images for my development & production images, and believe it absolutely makes sense to use the same base images across dev/staging/production to minimize differences between these environments.

My question is whether you'd be open to building images more frequently (ideally automatically) in order to pick up upstream security fixes. For example, when PHP releases security updates, it would be nice to see freshly built images like markoshust/magento-php:8.2-fpm-4 as well as markoshust/magento-php:8.2.26-fpm-4 (this last one does not currently exist, but it's what I would hope to see).

If these rebuilds could be automated via github actions, would you be open to accepting a PR? I'd envision a daily job which checks for new upstream PHP images, and rebuilds if there is a new version, applying an appropriate tag.

I understand if this is not a direction you want to go, that's why I'm asking. It's important for me (and I presume many other users) to know what to expect and how to plan to push out security updates.

[rubenromao]

Hi @jasonhildebrand, interesting, I didn't even know that was possible.
@markshust any thoughts about this proposal, please?

[markshust]

I like this idea, but I'm not sure it it's needed, especially with Magento's fairly slow release cycle. There are also some updates that I purposely hold back because they either don't work, or are incompatible with Magento's system requirements (for example, pegging Composer at version 2.7, and not a more recent version, because 2.8 is not "officially" supported).

That said, I think the builds can definitely be streamlined, which would make the update process much less painful for me, which would lead to more frequent releases. For example, there will now be 4 actively-maintained PHP versions (8.1 through 8.4), and they all share a very common setup, with slightly different versions for their unique case.

In this scenario, something like multi-stage builds could lead this to a standard "base" PHP Dockerfile, and then each version can have their specific overrides. I know how to do this and would like to do it ASAP, but it's been a while since a release happened (ironically 🙃), so I'm going to push that release out first before implementing this. Additionally, I need to manually update the versions of each Dockerfile in the current GitHub Action files, for example, updating the specific tag for each new version. There is also a lot of redundancy in the build files, and I'm sure they can be streamlined.

So, I'd say that I'd probably avoid going down the auto-build rabbit hole right now, but there are many areas of improvement that can greatly simplify this setup first and are much lower-hanging fruit. They may also make auto-updates much more feasible in the future.

I'll leave this ticket open a bit so we can discuss and see where this goes.

[jasonhildebrand]

Thanks for your thoughts, Mark.

I'll just provide a concrete example of why this would be helpful. PHP released 8.2.26 a few days ago, which includes several security fixes. Magento already supports 8.2, so this is not a case where we can't yet use this version. Production sites (or publically accessible staging sites) currently running 8.2.x should be updated to this version, sooner rather than later.

My options (as someone who uses your magento-php image as my base image) are

• wait for you to push out a new release
• work around this by updating my Dockerfile to base it on upstream (php:8.2-fpm-bookworm), and copy all your Dockerfile rules into the top of mine. The downside is that I lose out on future improvements you make, and my builds take much longer.

I don't want to pressure you with need to manually push out a new release any time this happens. That's why I suggested an automated solution.

I think it is possible to parameterize the base image (e.g. using 8.2.26-fpm-bookwork instead of 8.2-fpm-bookworm) used in your Dockerfiles, so you'd still have just four PHP dockerfiles to maintain, not hundreds. But ideally the released images would be tagged with the minor version numbers (8.2.26, not just 8.2).

[markshust]

Thanks for your follow-up. I think if we keep this at the service-level (PHP, MySQL, etc.) and not the package level (specific versions of imagick, xdebug, etc.), this would probably work, so long as we could build an automatic solution to this with some kind of GitHub Action workflow.

[andkirby]

@jasonhildebrand this is why I prefer to build images locally instead pulling pre-built ones.

And as a workaround, instead of just pulling Mark's images, you may pull files from /images directory and re-build your images locally.

And I'd say this is a must-have approach for projects, as you need to build an image with the exact version for the whole dev team and all instances. E.g. for PHP-FPM, it can be 8.4.1.

[dosubot]

Hi, @jasonhildebrand. I'm Dosu, and I'm helping the docker-magento team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• You proposed automating the build process for project images to incorporate upstream security fixes using GitHub Actions.
• Markshust acknowledged the benefits but raised concerns about Magento's slow release cycle and potential compatibility issues.
• You suggested parameterizing the base image for simplicity and provided a concrete example of the need for timely updates.
• Andkirby offered a workaround by suggesting local image builds to ensure version consistency.

Next Steps:

• Please let me know if this issue is still relevant to the latest version of the docker-magento repository. If so, you can keep the discussion open by commenting on the issue.
• Otherwise, this issue will be automatically closed in 30 days.

Thank you for your understanding and contribution!

[markshust]

I really like the approach outlined by @andkirby — I actually took the same when building a related docker environment for Laravel: https://github.com/markshust/mbox-laravel

You can see how I have a "docker" directory — this is meant to go right in the root of your project. This way, you can make changes and just do a docker compose --build up command to rebuild the image anytime you want.

I'm not sure if we should make some major changes here, especially because of Magento's slow release cycle. I'll be getting Magento 2.4.8 working within the next couple weeks here and it'll be ready before release day. Even then, the current PHP 8.4 image should also work before then for testing etc.