Skip to main content

Deployment Failure Related

Why does it run normally locally but fail to deploy to cloud hosting?​

For local debugging, please perform it based on local Docker whenever possible. If local development and debugging are not Docker-based, the following situations may occur when directly transitioning to cloud hosting deployment:

  • When running locally, all dependency components and extensions are available locally, but the dependency installation commands are not correctly added in the Dockerfile. As a result, there are no dependency issues during local execution, but when deployed to cloud hosting, errors occur due to missing dependencies.
  • During local execution, the application connects to the local database (using local IP or localhost). However, when deployed to cloud hosting, the database address is not updated to the cloud-based one, resulting in deployment failure due to database connection issues.
  • The runtime environment used locally (JDK/python versions, etc.) is inconsistent with the runtime environment defined in the Dockerfile.

How to handle the error message "Readiness probe failed: dial tcp xx.xx.xx.xx:xxx: connect: connection refused"?​

Health check failed / port unreachable.

  • The service starts normally, but the port is misconfigured. The actual port does not match the port specified during deployment, causing the system to mistakenly report deployment failure.
  • The service starts successfully but restarts repeatedly due to process instability, resulting in unstable port access and health check failures. Please check for code issues by reviewing logs, or consider whether the selected container specification is too small, causing memory OOM.
  • If your Dockerfile contains multiple independent CMD commands, note that this is an incorrect practice. Only the last CMD command will be executed, and all previous ones will be ignored, causing application errors. Please refer to the Docker official documentation for the CMD command.

Why does the deployment fail when the application logs show it is running normally?​

Check if the port in the service settings matches the actual project port. If the service starts normally but the port is misconfigured, causing a mismatch between the actual port and the port specified during deployment, the system will mistakenly report deployment failure, and service calls will also fail.

How to handle the error message "check pod status is not ok"?​

  • The service restarts repeatedly due to code issues, resulting in unstable status. Please troubleshoot the code problems independently.
  • If the service is not restarting repeatedly, please submit a ticket for our troubleshooting team to investigate.

How to handle the error message "Back-off restarting failed container"?​

Service startup failed due to code issues. Please troubleshoot the code problems independently using service logs. If no service logs are collected, check whether the log collection path is correctly configured.

Why does the eggjs service repeatedly restart when running npm run start during deployment?​

You need to remove the process daemon parameter --daemon.

  • Before change: "start": "egg-scripts start --daemon --title=node-server",
  • After change: "start": "egg-scripts start --title=node-server"

Why are the environment variables referenced in the Dockerfile not taking effect?​

During the build or deployment phase, the service is not yet ready, and environment variables cannot be referenced at this time.

Why are the internal endpoints of other cloud products such as MySQL/Redis referenced in the Dockerfile not taking effect?​

During the build/deployment phase, the service is not yet ready, and access to other cloud products via internal endpoints is unavailable at this time.

How to handle the error message "err=[ResourceUnavailable.ClusterInAbnormalState][err=cloudrun cluster state is invalid(cluster state is deleted)]"?​

Underlying exception. Please submit a support ticket to contact us for resolution.

Does embedding webview in Mini Programs support accessing Cloud Hosting via internal endpoints?​

Unsupported. The client intranet of Mini Programs and the server intranet of Cloud Hosting are not in the same network space and cannot access each other.

How to independently troubleshoot when the pipeline executes successfully but the service fails to start?​

  • Check the service startup logs for obvious errors
  • Customers can locally use docker to deploy the verification program and check for startup issues

Error accessing service: CERTIFICATE_VERIFY_FAILED​

Refer to Usage Notes, which requires trusting the certificate in the customer's Dockerfile and code.

Why does the service run properly when listening locally on 127.0.0.1:80, but fails to start when deployed to cloud hosting?​

After modifying the listening port to 0.0.0.0:80, redeploy the service.