Open bshaffer opened 6 years ago
I assume you're referencing this template which is how we generate the Dockerfile used for an App Engine Flexible Environment deployment. The /build-scripts/composer.sh
does more than just run the composer install - it detects the requested php version and installs requested php extensions. It would be possible to break that script apart into docker cacheable steps.
Unfortunately, IIRC, container builder does not utilize docker's layer caching for user layers (as you're not guaranteed to be running on the same build instance between requests). It would benefit users who are generating this Dockerfile locally and building on their own docker instance where the layer cache is available.
If you have your own Dockerfile, you can do whatever you want :)
Maybe you can derive from one of the versioned images like gcr.io/google-appengine/php72
, and add whatever you want there.
For example, here is a minimal example of making subsequent builds faster with cache
FROM gcr.io/google-appengine/php72
COPY composer.json composer.lock ${APP_DIR}/
RUN composer install
COPY . ${APP_DIR}
# Make the app readable by www-data
RUN chown -R www-data.www-data ${APP_DIR}
RUN chmod -R 1550 ${APP_DIR}
One caveat is that, with this approach, you can not benefit from all the magics with our runtime builder, so you may need to 1) manually enable extensions 2) copy the custom nginx/php-fpm configuration files 3) enable stackdriver integration etc in your Dockerfile
We should provide instructions on how our users can build their application using our runtime without them having to dig through all the code in this repository and reverse engineer the build. Here are some suggestions:
google/app_engine/php72
)COPY composer.json
and RUN composer install
before copying the application code, so by default this is not run on every build.Write a doc on how to extend the runtime
I agree, do you want to do it?
Add the magic to the versioned builds (e.g. google/app_engine/php72)
Yeah maybe you can file a new issue for it?
Refactor the build process so that it is easier to extend. See above.
Which build process? Are you talking about the ONBUILD process defined in gcr.io/google-appengine/php
?
Running COPY composer.json and RUN composer install before copying the application code, so by default this is not run on every build.
Where? It's easy to do within your own Dockerfile as I described above.
Where? It's easy to do within your own Dockerfile as I described above.
I am requesting this as a feature for the existing runtime, as it will speed up builds.
I am requesting this as a feature for the existing runtime, as it will speed up builds.
What exactly do you mean by existing runtime
? Is it a specific docker image? or our deploy pipeline as a whole?
The images like gcr.io/google-appengine/php72
are very vanilla, so that you can extend it as you wish.
When we modify app files and run "docker build", there is a debian install step followed by composer install. In the event that an application file is modified, but
composer.json
andcomposer.lock
remain the same the build can skip these steps. This would greatly increase the speed of the build. This can be done by using something like the following: