Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP Docker images »

PHP Docker images

php.internals

Martins Sipenko

7 years ago
Hi, Has PHP community thought about providing official PHP Docker images? I'm aware there are php images available on Docker hub, but as their docs state those are not to be confused with any official php image provided by php upstream. I think it would be great to have official images be released on the same day as PHP, currently there is a delay. Also I think it would be great to provide nightly snapshot builds of unreleased PHP versions, these containers could then be used by frameworks/libraries/applications to test against upcoming PHP versions in CI. Let me know your thoughts, and what would the next steps be if this is something we want to do. Martins

Arvids Godjuks

7 years ago
Hello Martins, The core leaves building and packaging of PHP to distros and other community efforts and focuses their efforts on PHP itself. It's a constant tug of war here on what to maintain or not by the core because whatever is taken on means it needs to happen for years and decades going forward and someone needs to do it. And that presents a problem if there is only a single person handling it. Anyway, a suggestion like this will have to go through the PHP RFC process first: https://wiki.php.net/rfc Meanwhile, there is this project that is kinda a go to place for PHP docker images: https://github.com/docker-library/php/blob/master/README.md вт, 7 мая 2019 г. в 07:02, Martins Sipenko <martins.sipenko@gmail.com>:
> Hi, > > Has PHP community thought about providing official PHP Docker images? > > I'm aware there are php images available on Docker hub, but as their docs > state those are not to be confused with any official php image provided by > php upstream. > > I think it would be great to have official images be released on the same > day as PHP, currently there is a delay. Also I think it would be great to > provide nightly snapshot builds of unreleased PHP versions, these > containers could then be used by frameworks/libraries/applications to test > against upcoming PHP versions in CI. > > Let me know your thoughts, and what would the next steps be if this is > something we want to do. > > Martins >
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Stas Malyshev

7 years ago
Hi!
> I'm aware there are php images available on Docker hub, but as their docs > state those are not to be confused with any official php image provided by > php upstream.
Generally, nothing prevents anybody from building a set of docker images the second after PHP tag is released. The only "official" thing is always that git tag, the rest are derivative anyway. So, if you or somebody else wants to build those images, no approval of any type is required. If these prove useful and consistently available, we could link to them in the documentation, but otherwise I don't think any approval is needed for doing something like this.
-- Stas Malyshev smalyshev@gmail.com

Martins Sipenko

7 years ago
Hi, I was hoping this could be somethat that would be backed by official PHP and thus can be trusted. Currently there are some unofficial nightly builds, but I’m reluctant to use them due to trust issues. Clearly we can build nightly images in house, but doing so does not bring any benefit to the community. On the other hand, if there hasn’t been any demand for nightlies it probabbly means noone needs this. I know TravisCI do maintain a next unreleased release version of PHP on their build system, but that is not really reusable in other systems. Lastly, I think that the more real world projects grt tested against upcoming PHP version, the more bugs can caught before doing a realease. Overall, if you think this is something thats not worth the effort of writing RFC I will not proceed with this further. Martins

Pierre Joye

7 years ago
Hi, On Fri, May 10, 2019, 12:53 PM Martins Sipenko <martins.sipenko@gmail.com> wrote:
> Hi, > > I was hoping this could be somethat that would be backed by official PHP > and thus can be trusted. Currently there are some unofficial nightly > builds, but I’m reluctant to use them due to trust issues. > > Clearly we can build nightly images in house, but doing so does not bring > any benefit to the community. On the other hand, if there hasn’t been any > demand for nightlies it probabbly means noone needs this. > > I know TravisCI do maintain a next unreleased release version of PHP on > their build system, but that is not really reusable in other systems. > > Lastly, I think that the more real world projects grt tested against > upcoming PHP version, the more bugs can caught before doing a realease. > > Overall, if you think this is something thats not worth the effort of > writing RFC I will not proceed with this further.
I am sure if you provide patches to build RC or branch/tag based builds to the team at dockerhub they will support it. Doing so will give these QA images the best users coverage you can expect. best, Pierre

Peter Kokot

7 years ago
Hello, On Tue, 7 May 2019 at 07:01, Martins Sipenko <martins.sipenko@gmail.com> wrote:
> > Hi, > > Has PHP community thought about providing official PHP Docker images? > > I'm aware there are php images available on Docker hub, but as their docs > state those are not to be confused with any official php image provided by > php upstream. > > I think it would be great to have official images be released on the same > day as PHP, currently there is a delay. Also I think it would be great to > provide nightly snapshot builds of unreleased PHP versions, these > containers could then be used by frameworks/libraries/applications to test > against upcoming PHP versions in CI. > > Let me know your thoughts, and what would the next steps be if this is > something we want to do. > > Martins
The images for such C software are one of the more useless ones. Snaps or custom Linux repositories are the way to go here. Because of the installation time. Building several extensions from source is really time consuming... You will notice this one day maybe. Otherwise, PHP is really not doing enough to make the installation and life of packagers better yet. It will get worse actually from release to release each year if we don't start refactoring some things. And the manual for the installation of PHP that doesn't mention such options (but on the other hand mentions installing PHP on servers that are dead for decade) is also another story that plays a role here.
-- Peter Kokot

Pierre Joye

7 years ago
On Fri, May 10, 2019, 2:06 PM Peter Kokot <peterkokot@gmail.com> wrote:
> > The images for such C software are one of the more useless ones. Snaps > or custom Linux repositories are the way to go here. Because of the > installation time. Building several extensions from source is really > time consuming...
Maybe this is exactly why docker images are nice. You do not build them but once (on dockerhub f.e.) and users only grab them. Just maybe... best Pierre

Peter Kokot

7 years ago
On Sat, 11 May 2019 at 06:12, Pierre Joye <pierre.php@gmail.com> wrote:
> > On Fri, May 10, 2019, 2:06 PM Peter Kokot <peterkokot@gmail.com> wrote: > > > > > The images for such C software are one of the more useless ones. Snaps > > or custom Linux repositories are the way to go here. Because of the > > installation time. Building several extensions from source is really > > time consuming... > > > Maybe this is exactly why docker images are nice. You do not build them but > once (on dockerhub f.e.) and users only grab them. Just maybe... > > best > Pierre
Yes, theoretically :) There are actually more cases where you will build them more than once. Almost several times per day. For example, to build intl extension one must do: docker-php-ext-install intl and also install dependencies that belong to it. Imagine now doing this for a normal PHP environment which is about several more extensions, some pecl ones and you get to an installation time of almost 10 minutes (over the thumb). Docker registries are not that common as we think. And with building the same Docker image using Linux repositories the installation becomes a matter of seconds (without worrying which extensions need another apk add --no-cache libfoo or apt install libfoo-dev) and then also cleaning those dev packages after the build.
-- Peter Kokot