How to build Flexible Environment's standard runtime locally for a deploy?

[John Del Rosario]

In this guide[1], it mentions how to specify an image url for a deploy, but not how to build the image. Does specifying an image url imply using the custom runtime?

Or is it possible to build the standard runtime locally and push that? I'm having trouble to find docs on how to build the standard runtime locally.

[1] https://cloud.google.com/appengine/docs/flexible/python/testing-and-deploying-your-app#remote-container-build

[George (Cloud Platform Support)]

Hi John,

Thank you for the interesting question.

You may build a custom runtime to your liking, and deploy it, if it satisfies a set of conditions that define a performance minimum. Your custom runtime needs to comply to the following and contain:

- An app.yaml file that describes your application's runtime configuration.

- A Dockerfile that configures the runtime environment. In many cases, this can be just one line specifying a base image.

- You need to ensure your application is listening on port 8080 and has request handlers that respond to lifecycle events, such as start, stop, and health check requests.

In fact, there is no imperative requirement that you have to use the base images supplied by Google, only that your Docker image satisfies the above minimum requirements.

Hoping the above covers your initial concern; you are welcome to ask more in-depth questions.

[John Del Rosario]

Thanks George.

Does the custom runtime use the entrypoint value of app.yaml to start the service? I want to use the same image for different services, where each service is running the same codebase, but with different commands (e.g. one service runs gunicorn+django, the other runs celery workers, both of which use the same codebase).

Or would I have to build different images for each service with a different CMD value in their Dockerfile?

Thanks.

[George (Cloud Platform Support)]

Hello John,

You are right, your second option applies: in almost all cases, you should only run a single process in a single container. The CMD instruction should be used to run the software contained by your image.

If services are to be available concurrently, you may consider building a group of containers in a pod. Using Kubernetes may come in handy here.

[John Del Rosario]

Hi George,

Ah, I wanted to stick with Flexible Environment to avoid doing orchestration on our own. Or can Kubernetes be used with Flexible Environment?

How about environment variables? Does the custom runtime use the env_variables values in the app.yaml? Or would they need to be built into the image itself as well?

I guess a better question would be, which values does the custom runtime use from app.yaml?

Thanks

[George (Cloud Platform Support)]

Hello John,

You are right, the custom environment is aware of values set by means of the app.yaml, as described here.

You may use Kubernetes to manage and deploy your containers in the flexible environment as well, and set the env_variables values to manage your instance’s environment via global variables.