PHP Docker images

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

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 [email protected]:

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
[email protected]
Skype: psihius
Telegram: @psihius https://t.me/psihius

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
[email protected]

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

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
[email protected]

Hi,

On Fri, May 10, 2019, 12:53 PM Martins Sipenko [email protected]
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

Hello,

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

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

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