[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-21。"],[[["\u003cp\u003eCustom runtimes in the flexible environment allow you to use alternate implementations of supported languages or even code in languages that can handle HTTP requests, with Google managing scaling, monitoring, and load balancing.\u003c/p\u003e\n"],["\u003cp\u003eTo create a custom runtime, you must provide an \u003ccode\u003eapp.yaml\u003c/code\u003e file to describe your application's runtime configuration, and add a \u003ccode\u003eDockerfile\u003c/code\u003e to configure the runtime environment.\u003c/p\u003e\n"],["\u003cp\u003eYour application code must listen on port 8080, where App Engine routes incoming requests, and you should implement handling of lifecycle events like application shutdown, during which the system sends a \u003ccode\u003eSTOP\u003c/code\u003e signal followed by a \u003ccode\u003eKILL\u003c/code\u003e signal.\u003c/p\u003e\n"],["\u003cp\u003eApplications in custom runtimes can use Google Cloud Client Libraries to access Google Cloud services, authenticate using Application Default Credentials, and leverage automatic logging to \u003ccode\u003estdout\u003c/code\u003e and \u003ccode\u003estderr\u003c/code\u003e, as well as custom logs.\u003c/p\u003e\n"],["\u003cp\u003eAfter configuring the \u003ccode\u003eapp.yaml\u003c/code\u003e and \u003ccode\u003eDOCKER\u003c/code\u003e files, you can build and deploy the container image, or you can deploy prebuilt container images of your custom runtimes, stored in Artifact Registry.\u003c/p\u003e\n"]]],[],null,["# Build custom runtimes\n\nA [custom runtime](/appengine/docs/flexible/custom-runtimes/about-custom-runtimes)\nlets you use an alternate implementation of any supported\nflexible environment language, or to customize a\nGoogle-provided one. It also lets you to write code in any other language that\ncan handle incoming HTTP requests\n([example](https://github.com/JustinBeckwith/appengine-perl)).\nWith a custom runtime, the flexible environment provides and\nmanages your scaling, monitoring, and load balancing infrastructure for you, so\nyou can focus on building your application.\n\nTo create a custom runtime you must:\n\n- [Provide an `app.yaml` file that describes your application's runtime configuration to App Engine.](#appyaml)\n- [Add a `Dockerfile` that internally configures the runtime environment.](#docker)\n- [Ensure that your code follows some basic rules.](#code)\n\n| **Note:** Google supplies some [base images](#base) that you can customize, but you aren't required to use these. You can use other images so long as they satisfy the conditions in the list above.\n\nProvide an `app.yaml` file\n--------------------------\n\nYour `app.yaml` configuration file must contain at least the following settings: \n\n runtime: custom\n env: flex\n\nFor information about what else you can set for your\napp, see [Configuring your App with app.yaml](/appengine/docs/flexible/custom-runtimes/configuring-your-app-with-app-yaml).\n\nCreate a Dockerfile\n-------------------\n\nComprehensive documentation on creating Dockerfiles is available on the\n[Docker website](https://docs.docker.com/engine/reference/builder/). If you are\nusing a custom runtime, you must provide a Dockerfile whether you are\nproviding your own base image or using one of Google's base\nimages.\n\n### Specify a base image\n\nThe first command in a Dockerfile is usually a `FROM` command specifying a base image.\nA base image is used to create the container and build your application. You\ncan author your own [base image](https://docs.docker.com/build/building/base-images/)\nor select a base image from container registries like [DockerHub](https://hub.docker.com/).\n\n### Locate the Dockerfile\n\nIn general, the Dockerfile is always named `Dockerfile` and is placed in the\nsame directory as the corresponding `app.yaml` file. In some cases, however, the\ntooling environment might have different requirements. For example, Cloud\nSDK-based Java tools such as the Maven, Gradle, Eclipse, and IntelliJ plugins\nrequire the `Dockerfile` to be in `src/main/docker/Dockerfile` and the\n`app.yaml` file to be in `src/main/appengine/app.yaml`. See the\n[documentation](/docs/overview/developer-and-admin-tools)\nfor your tooling environment for more information.\n\nCode structure\n--------------\n\nThis section describes behavior that your code must implement whether you use\na Google-provided base image or your own base image.\n\n### Listen to port 8080\n\nThe App Engine front end will route incoming requests to the appropriate\nmodule on port 8080. You must be sure that your application code is listening on\n8080.\n\n### Handle lifecycle events\n\nThe flexible environment periodically sends your application\ncertain lifecycle events.\n\n#### Application shutdown\n\nWhen an instance needs to be shut down, new incoming requests are routed to\nother instances (if any) and requests that are currently being processed are\ngiven time to complete. When shutting down an instance, flexible environment normally\nsends a `STOP` (`SIGTERM`) signal to the app container. Your app does not need\nto respond to this event, but it can use this to perform any necessary clean-up\nactions before the container is shut down. Under normal conditions, the system\nwaits up to 30 seconds for the app to stop and then sends a `KILL` (`SIGKILL`)\nsignal, immediately shutting down the instance.\n\nIn rare cases, outages can prevent App Engine from providing 30 seconds\nof shutdown time, which means the `STOP` and `KILL` signals might not be sent\nbefore an instance terminates. To handle this possibility, you should\nperiodically checkpoint the state of your instance, using it primarily as an\nin-memory cache rather than a reliable data store.\n\n#### Health check requests\n\nYou can use periodic\n[health check requests](/appengine/docs/flexible/reference/app-yaml#updated_health_checks)\nto confirm that a VM instance has been successfully deployed, and to check that\na running instance maintains a healthy status.\n\nBuild and deploy your custom runtime\n------------------------------------\n\nAfter you configure your `app.yaml` and `DOCKER` file, you can\n[build and deploy](/appengine/docs/flexible/testing-and-deploying-your-app)\nthat container image to App Engine.\n\nAlternatively, you can deploy prebuilt container images of your custom runtimes\nthat are stored in Artifact Registry. For example, you can use [Cloud Build](/build/docs/building/build-containers#use-dockerfile)\nto separately build your images and then store those images in\nArtifact Registry. For more information, see\n[Push and pull images](/artifact-registry/docs/docker/pushing-and-pulling).\n\nIntegrate your application with Google Cloud\n--------------------------------------------\n\nApplications running in custom runtimes can use the [Google Cloud\nClient Libraries](/apis/docs/cloud-client-libraries) to access Google Cloud services.\nApplications in custom runtimes can also use any third-party service using standard APIs.\n\n### Authenticate with Google Cloud services\n\n[Application Default Credentials](/docs/authentication/application-default-credentials)\nprovide the simplest way to authenticate with and call Google APIs.\n\nIf your application uses Cloud Build for compiling Docker images,\nthe [`cloudbuild`](/build/docs/build-config-file-schema#network) network hosts the\nApplication Default Credentials enabling the associated Google Cloud services to\nautomatically find your credentials.\n\nFor more information about authentication, see\n[Authentication at Google](/docs/authentication).\n\n### Logging\n\nWhen a request is sent to your application running in App Engine,\nthe request and response details are logged automatically. They can be viewed in\nthe Google Cloud console [Logs Explorer](https://console.cloud.google.com/logs).\n\nWhen your application handles a request, it can also\nwrite its own logging messages to `stdout` and `stderr`. These files are\nautomatically collected and can be viewed in the Logs Explorer. Only the\nmost recent entries to `stdout` and `stderr` are retained, in order\nto limit their size.\n\nYou can also write custom logs to `/var/log/app_engine/custom_logs`, using a\nfile ending with `.log` or `.json`.\n| **Note:** Custom logs written to `/var/log/app_engine/custom_logs` cannot use log rotation.\n\nIf you include any third-party agents in your application container, make\nsure you configure the agents to log to `stdout` and `stderr`, or to a custom log.\nThis ensures that any errors produced by these agents is visible in Cloud Logging.\n\nThe request and application logs for your app are collected by a\n[Cloud Logging](/logging) agent and are kept for a maximum of 90\ndays, up to a maximum size of 1 GB. If you want to store your logs for a longer\nperiod or store a larger size than 1 GB, you can [export your\nlogs](/logging/docs/export/configure_export#ways_to_configure_logs_export)\nto Cloud Storage. You can also export your logs to BigQuery and Pub/Sub for\nfurther processing.\n\nOther logs are also available for your use. The following are some of the logs\nthat are configured by default:"]]