IssueTracker

Hello

Thank you for reaching out to us!

This issue seems to be outside of the scope of Issue Tracker. This Issue Tracker is a forum for end users to report bugs and request features on Google Cloud products. Please go through link to learn more about issue trackers. Also, please refer to this Stackoverflow thread regarding resolving the error that you’re getting.

I recommend you to ask the technical questions on Stack Exchange sites which are best suited for this type of questions.

I'm going to close this thread which will no longer be monitored. In case you want to report a new issue, please do not hesitate to create a new Issue Tracker describing your issue.

Thank you

FROM gcr.io/google-appengine/php:latest doesn't seem to be the bare minimum Docker file for Flex custom runtime using PHP.

Please let us know if the following Docker file works for you.

FROM gcr.io/google-appengine/php:latest
Copy . .
EXPOSE 8080

Hi, just coming back to you on this.

We have tried the suggested Dockerfile. There is no change to the behaviour, when using the latest tag.

Thanks.

Hi there!

To further troubleshoot the situation, could you share your exact Dockerfile ?

Sure. Based on our testing, the problem occurs with almost any Dockerfile, but here is an example. Sensitive values are snipped.

FROM gcr.io/google-appengine/php
ENV DOCUMENT_ROOT '/app/5fish_web/public'
ENV GCLOUD_ENV 'debug'
ENV GOOGLE_APPLICATION_CREDENTIALS '/app/grn-dev-074934c8ae86.json'
ENV GOOGLE_BUCKET_NAME '5fish-data-dev'
  # If you are using the App Engine Memcache service (currently in alpha),
  # uncomment this section and comment out the other Memcache variables.
  # USE_GAE_MEMCACHE: 1
ENV REDIS_MEMCACHED_SERVER "memcached-15411.c1.us-central1-2.gce.cloud.redislabs.com"
ENV REDIS_MEMCACHED_PORT "15411"
ENV REDIS_CACHE_SERVER "redis-19598.c1.us-central1-2.gce.cloud.redislabs.com"
ENV REDIS_CACHE_PORT "19598"
  # If you are using a Memcached server with SASL authentication enabled,
  # fill in these values with your username and password.
ENV REDIS_MEMCACHED_USERNAME "<snip>"
ENV REDIS_MEMCACHED_PASSWORD "<snip>"
ENV REDIS_CACHE_PASSWORD "<snip>"

COPY . .
EXPOSE 8080

Along with this, the codebase contains a 5fish_web/public folder. The built image contains no files in the /app folder other than what exists in the upstream image.

Previous builds within the same week using this Dockerfile results in a successful build. Pinning the upstream image to the aforementioned 2020-10-22-09-37 tag results in a successful build.

Here is a second Dockerfile related to another PHP Flex project, which has also been resolved by pinning the tag back to Oct 2020.

FROM gcr.io/google-appengine/php

ENV DOCUMENT_ROOT /app/public

COPY . .
EXPOSE 8080

Along with this, the codebase contains a public folder.

I'm able to run a custom php hello world app using the following Dockerfile. I suggested COPY . . in comment# which is probably incorrect. I think Flex has the assumption of having the application code under /app.

FROM gcr.io/google-appengine/php@sha256:81acce45d1ae1f1ba7adb1aaf76ab6f05179d8728a3b32c8224e8683dae2522a
COPY . /app
ENV SKIP_LOCKDOWN_DOCUMENT_ROOT true
ENV DOCUMENT_ROOT /app
EXPOSE 8080

app.yaml:

runtime: custom
env: flex

runtime_config:

manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10

To help us understand your situation, may I ask if you have COPY . . before or after our conversation?

We added COPY . . after our conversation, as it had never been a requirement to copy any files prior to the most recent version of this image. The code was automatically copied to the /app folder without a COPY instruction. Further, the documentation does not mention any specific folder for a copy instruction, nor does it mention an EXPOSE instruction - rather, simply the app listening on port 8080 as it is presumably already EXPOSEd in the upstream image.

If COPY . /app is now required as of the latest tag then the documentation should be updated to reflect this. It would have been beneficial to notify users of the pending change to how Dockerfiles must be defined for PHP Flex, to avoid breakages.

With COPY . /app the code is copied, but composer install is not automatically run. This again suggests that previous automatic configuration steps - one of the main benefits of making use of Google's upstream image - are no longer occurring with this latest version of the image.

Can you try testing with a composer.json and composer.lock file in the hello world app? All of our projects include both of these files and the webapp's code relies on the presence of the named Composer dependencies.

We are able to repro the dependencies missing with the composer.json and are working on it. Sharing an update below with the current state.

We have been actively working on this issue. We found that while using the latest php image, customer’s code and dependencies is not getting built into the final app image. This results in the DOCUMENT_ROOT being incomplete and users may notice one of the below errors:

1. deployment to error out with the following error “chown: cannot access ‘<directory root>: No such file or directory”
2. 404s while browsing the app

Short-term Mitigation: Below are couple of working “short-term mitigations” that customers can use to get unblocked while we work on the root-cause and “long-term fix”.

Mitigation #1: Customer can modify the dockerfile to use the following php image

FROM gcr.io/google-appengine/php:2020-10-22-09-37

Mitigation #2: Customer can still continue to use the latest docker file but will have to explicitly do the following:

1. Add COPY to copy everything to the document root. For example: COPY . /app
2. Install dependencies from the docker file (for example: running composer commands)

Sharing some updates from our investigation: We noticed that the code zip is correctly uploaded to the GCS for both the previous image (2020-10-22-09-37) and the latest image but missing in the app image.

Next Steps: We are going through the gcloud code to figure out why the code is missing in the app image

Thanks.

another update -

we noticed few interesting things while trouble-shooting:

• php-onbuild instructions are responsible for copying app and running composer. We are exactly missing the results of these instructions. Investigating further if the newer image is missing to execute php-onbuild instructions.
• Php version seems to be different between prev (v7.3.19) and latest (v7.1.33) image. Looking more to see why the newer image went to a lower version of php and if this is somehow related to the issue

The ONBUILD steps that were responsible to copy the app code and install dependencies were missing on the latest image. We have uploaded a staging image "FROM gcr.io/google-appengine/php:staging" which has the fix and includes the missing ONBUILD steps.

Could you please try verifying using the image with staging tag i.e. FROM gcr.io/google-appengine/php:staging and see if it fixes the issue? We plan to promote this to latest after some testing.

FYI - the sha for the staging image is gcr.io/google-appengine/php@sha256:acc86df075c5703030c96f96a7ff48c6a0d85f351aa209046c81b4af42b7d144

Thanks.

Thanks for the updated staging image.

I have confirmed with our application developers that the staging image does resolve the build issues for us.

Thanks for verifying the fix.

Image gcr.io/google-appengine/php@sha256:acc86df075c5703030c96f96a7ff48c6a0d85f351aa209046c81b4af42b7d144 has been promoted to the latest.