This repository contains a PHP runtime for Google App Engine Flexible Environment and other Docker hosts. It is not covered by any SLA or deprecation policy. It may change at any time.
- See CONTRIBUTING.md
- See LICENSE
Docker images for running PHP applications on the App Engine Flexible Runtime
License: Apache License 2.0
This repository contains a PHP runtime for Google App Engine Flexible Environment and other Docker hosts. It is not covered by any SLA or deprecation policy. It may change at any time.
script may
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.
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.
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.
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.
PHP 7.1 beta1 was released ๐
Would you accept a pull request with a third runtime version?
probably with --enable-phpdbg=no
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.
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:
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.
I'm considering to stop removing the vendor
directory during the bulld.
@cedricziel FYI
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.
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.
In GAE i store my files in a storage. Can I emulate a storage in this image?
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.
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
)
while builds on jenkins are stable
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.
We can just use the phar, but it's better to install it via composer with an explicit version.
WARNING: This command is deprecated. Please use gcloud preview app versions delete
instead.
It's not being used, and should be removed.
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:
php.ini
to allow save overridesphp.cli.ini
) just for composerI 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?
See #109
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?
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.
It's odd to build into /usr/local/, we should use /opt/ if we're not integrating into /usr/local.
The current 5 is too small
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
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)
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
FROM php-nginx
, so that using local build)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.
to avoid the stale builder vm issue
@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"
}
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.
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.
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.
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.
i.e. Datastore :-)
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 :)
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.