• Deploying with gcloud
  • local (--docker-build=local, and use FROM php-nginx, so that using local build)
  • remote (--docker-build=remote, upload the image with a different name)
• Web serving

AppEngines uses HTTPS almost exclusively so it's a good idea to pin HTTPS
to allow applications proper connection detection based on the current protocol.

It's odd to build into /usr/local/, we should use /opt/ if we're not integrating into /usr/local.

In order to maintain dependencies to shared PHP extensions, composer packages may define ext-* dependencies, like ext-mbstring-just like they may define a dependency on a interpreter-version.

The image build-process should be able to read those and add the corresponding extension directive to the top-level php.ini so that the developer doesn't need to add a php.ini file for already explicitly defined dependencies.

The system image should be rotating logs in /var/log/app_engine. We should integrate with that, and make any file path changes necessary for that to work.

Logging to STDOUT is not showing up in the log files. When on an instance itself, I see none of the expected logs under /var/log/app_engine, but they are instead under /var/log/app_engine/app:

If I run sudo docker logs [CONTAINER], I see the same logs as I see in the Cloud Logging UI, but none of my application logs show up here.

This is a followup issue to #18 .

Composer supports several different VCS drivers (listed here).

Git was introduced in #18, but the remaining VCS packages should be included into the images as well.

We should remove parse_str from the suhosin blacklist.

As @tmatsuo mentioned, if used in a certain way, it's possible for this function to override global variables. However, we need to keep in mind:

1. The function can be used safely when a second argument is supplied
2. The function is very common, as it's the only way (other than rolling your own) to parse a query string.
3. The dangers of using this function require the user to be doing a few other things incorrectly to do damage, namely not providing a 2nd argument to parse_str and relying on global scope throughout the app.

It would be best to remove this function from the blacklist. The best solution would be to disable the function's ability to be used without a second argument, but this is out of scope.

We added --no-scripts to the composer install commmand in #69. Why did we do this?

This could be a very way for users to run simple pre-deployment tasks (such as changing file permissions, warming up caches, etc) without having to extent the Dockerfile. We can add --no-interaction to the composer install command, to ensure the build can complete.

@cedricziel

The function libxml_disable_entity_loader is required in Symfony's XMLFileLoader, and is blacklisted in our configuration.

Symfony is using the function to make its xml file loading more safe. Wouldn't it be better to call the function (libxml_disable_entity_loader(true);) than disable it? Can suhosin be used to disable the entity loader at the php.ini level, thus rendering the function useless?

We should not run composer as root. www-data is not a valid login, so we may need to create a temporary user account with the same id, and delete it after that; or temporary chsh www-data's shell.

See also #135

The current 5 is too small

In GAE i store my files in a storage. Can I emulate a storage in this image?

• split build_deps.sh into pieces so that each step has its own layer
• change how to install extensions
  it might be better installing extensions after installing the interpreter
• Only delete /var/lib/apt/lists/* once

I just found this and I'd love to test it out. Is it ready for production use?

We're not using them, and they're becoming stale. They'll be misleading soon, we should remove them.

PHP 7.1 beta1 was released 🎉

Would you accept a pull request with a third runtime version?

The supplied composer runner doesnt respect the supplied php.ini which makes it really hard to run post-install scripts that utilize for example symfony/console to generate optimized autoloaders (example: Laravel 5.1)

[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.

I see that you've disabled the function on purpose, but really they shouldnt be limited on the CLI for one-off commands.

From my point of view, there's multiple possible solutions to the problem:

1. use the supplied php.ini to allow save overrides
2. use another php.ini (for example php.cli.ini) just for composer
3. use another ini setting on the cli
4. override the contained php.ini in the image

I know I can override the supplied php.ini - maybe just document it to make it easier for people who are not into docker very much?

Now we have the following in the Dockerfile:

ONBUILD RUN chown -R www-data.www-data $APP_DIR

It should be root.www-data so that php can not override any files.

It is too slow to compile multiple PHP versions for each Docker build. Can we pre-compile the PHP binaries, upload and download from GCS or somewhere?

to avoid the stale builder vm issue

We can just use the phar, but it's better to install it via composer with an explicit version.

script may

• install vim
• loosen php for cli access
• Other idea welcome

How you can use it,
You can ssh into the VM, get into the container and run the script, then you'll be able to debug your app easily.

Often we have to create an nginx-app.conf file just to change the name of the front controller. Some frameworks use index.php, some use app.php, etc.

We could introduce another envvar like FRONT_CONTROLLER_FILE, so that you can do:

app.yaml

runtime: php
vm: true

runtime_config:
  document_root: web

env_variables:
  WHITELIST_FUNCTIONS: libxml_disable_entity_loader
  FRONT_CONTROLLER_FILE: app.php

see GoogleCloudPlatform/php-docs-samples#190

The reason I wanted to add this info to our documentation is due to the inefficiency on reviewing the document PR on this repo, CircleCI will run our full tests for each edit. Also If we add it, I want to also add tests for that because such information can be easily become stale.

I still want to add such documentation and tests to other places; docs on https://cloud.google.com/php and tests in php-docs-samples.

In my application, I have reached a state where all needed secrets are received from the project-level metadata store - do you think that's a good practice? The description about the metadata store states that it's secure since it's close to local to the compute unit.

Another approach would be to add secrets via environment variables - but it has the implication that I need to write those down to the app.yaml file and thus need to access them on the ci server at deployment time.

Do you prefer one method over the other for AppEngine flex deployments? I guess that's more a RFC than a real issue :)

while builds on jenkins are stable

It seems like the memcached extension is not stable on PHP 7.0.

php-memcached-dev/php-memcached#213

We should prefer PHP 5.6 until it's stable enough.

It is difficult to use this runtime to deploy more than one service per app to AppEngine, due to the requirement of each service to share nginx-app.conf php.ini and supervisord.conf files.

We could add a runtime_config variable conf_dir that can be used to change the configuration dir from the default (/app) to something else (like /app/config/my_service)

• extensions
• disabled functions
• webroot configuration
• nginx.conf and nginx-app.conf

Instead of completely replacing the factory default php.ini of the image, it should be considered to use the "user ini" mechanism to allow fine grained control over just a few ini settings.

https://travis-ci.org/GoogleCloudPlatform/php-docker/builds/110488822#L8865

Fatal error: Maximum execution time of 0 seconds exceeded in phar:///usr/local/bin/composer/vendor/symfony/console/Helper/Table.php on line 196
The command '/bin/sh -c /composer.sh' returned a non-zero code: 255

We should temporary set max_input_time=0 (the error message is confusing, but the max_input_time is the cause)

I have an important question while I try to bend this image to my needs: What is the feature-complete state of this image?

The heroku buildpack for php is a really great source of inspiration in terms of what is possible and needed for running modern, sophisticated php applications on the platform side of things. I am aware that it may slightly conflict with the "many tiny applications"-paradigm Google drives, but I'm curious if you are willing to go towards that direction with this image as well.

I'd like you to take a look at the compile script of the heroku buildpack for php to see some of the features it detects. (https://github.com/heroku/heroku-buildpack-php/blob/master/bin/compile)

I am aware that I can run a docker image with a heroku buildpack on managed vms - but apart from the general, language specific features, I would also expect AppEngine features from the sandbox to get integrated in the future with this image (CloudSQL with a simple socket). If it wasn't for those, I'd just use the one of the heroku flavoured docker images with managed vms.

So basically I'm having trouble with the registered native session handler. I run an image with symfony2 3.0 and operating on the session fails silently.

I propose to add an end-to-end test for PHP7 that includes memcached operations.

WARNING: This command is deprecated. Please use gcloud preview app versions delete instead.

i.e. Datastore :-)

I am receiving the following error with the default configuration:

WARNING: [pool app] child 20 said into stderr: "NOTICE: PHP message: PHP Warning: spl_autoload_register() has been disabled for security reasons in /app/vendor/composer/autoload_real.php on line 22"

This a core function used in composer for certain types of autoloading, so it is important we allow it. It should be whitelisted by default.

Booting a simple Laravel5 application results in errors, because it wants to cache the current container to $APP_ROOT/bootstrap/cache/services.json and file_put_contents fails.

Here's an application illustrating the issue: https://github.com/cedricziel/gae-docker-writable-issue

Just deploy it to AppEngine and open up the index route.

The underlying issue seems to be that though permissions seem correct, the application cannot write to the filesystem. While this could be fixed on build-time for this particular application, one of the promises managed vms make is a writable file system so applications caching files to disk don't have to jump through hoops.

I'm considering to stop removing the vendor directory during the bulld.

@cedricziel FYI

In order to be able to execute arbitrary commands, the php binaries need to be on PATH. This applies to inheriting images as well, so it doesn't seem sufficient to export a modified PATH in the composer script, if an inheriting image would want to compile pecl extensions.

@tmatsuo first of all thanks for the helpful guide to get onto the flex runtime: https://wp.gaeflex.ninja/2016/03/14/running-wordpress-on-flex/

However, we are running into an issue with memcache and the current version of the php flex runtime. The PHP startup according to the cloud logs doesn't seem to like the path of memcache.so. Ultimately, this leads to errors when trying to use the memcached / bataches plugins.

[21-Sep-2016 13:19:07 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php56/lib/php/extensions/no-debug-non-zts-20131226/memcached.so' - /opt/php56/lib/php/extensions/no-debug-non-zts-20131226/memcached.so: cannot open shared object file: No such file or directory in Unknown on line 0
 {
 metadata: {…}   
 textPayload: "[21-Sep-2016 13:19:07 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library '/opt/php56/lib/php/extensions/no-debug-non-zts-20131226/memcached.so' - /opt/php56/lib/php/extensions/no-debug-non-zts-20131226/memcached.so: cannot open shared object file: No such file or directory in Unknown on line 0"   
 insertId: "1e89dixg83omuqn"   
 log: "appengine.googleapis.com/app"   
}

It's not being used, and should be removed.

probably with --enable-phpdbg=no

See #109