Version Configuration Instructions
Basic Configuration Instructions
Upload Method
Supports three methods: local code / code repository pull / image pull.
Method 1: Local Code
Upload the code project folder or a zip package. After successful parsing, the system will first build the code into an image, push the image to the service-bound image repository for storage, and then deploy based on that image.
This method requires you to write your own Dockerfile and include it in the code folder or zip package.
Method 2: Code Repository Pull
After obtaining your authorization, the system will pull code from your GitHub/GitLab/Gitee repository, build the code into an image, push the image to the service-bound image repository for storage, and then deploy based on that image.
This method requires you to write your own Dockerfile and include it in the code repository.
The first time you use it, you need to authorize first. After successful authorization, any service in the current environment creating a new revision will not require re-authorization.
Method 3: Image Pull
The system does not provide the service of building images from code. You can build the image using any method and manually upload it to the image repository bound to the service. Then, the system will deploy based on the image you selected.
- For how to upload images, please refer to the "Manual Image Upload" section under "Related Operations" in this document.
- Using a Demo image allows you to quickly experience the deployment process. After selecting a Demo image, there is no need to modify any configurations; you can directly start the deployment.
Listening Port
Application listening port. Default: 80.
Traffic Policy
How to enable traffic after deployment. Currently, there are two options:
- Keep traffic at 0 after deployment and manually adjust traffic later: You want to manually verify before enabling traffic after deployment, or only introduce partial traffic for a canary upgrade.
- Automatically enable 100% traffic after deployment: Enable traffic immediately after the initial deployment, or perform a full upgrade during an update.
Remarks
Optional. It will be displayed on the version list page and has no impact on deployment.
Auto-scaling Configuration Instructions
Replica Mode
Supports two modes: low-cost/high-availability.
Mode 1: Low-Cost
Suitable for businesses that are cost-sensitive and relatively insensitive to cold starts.
- The minimum number of replicas is 0. When no traffic is routed to the version, it scales in to 0, retaining no instances and incurring no costs.
- It will only scale in to 0 after half an hour of continuous no traffic (to avoid false positives caused by occasional traffic fluctuations). A cold start may cause approximately 30 seconds of service delay.
- The default recommended specification is the minimum size of 0.25 cores and 0.5GB, with the lowest unit price. You can also adjust the specifications as needed.
- Although there is no business traffic, one instance is still created during the deployment process. After the deployment completes, it scales in to 0, thus the deployment process itself incurs some resource consumption.
Setting the traffic percentage for the version to 0 is neither a necessary nor sufficient condition to trigger scaling in to 0. In Low-Cost mode, setting the version's traffic percentage to 0 will definitely trigger scaling in to 0. However, if the traffic percentage isn't 0, scaling in to 0 will only be triggered after a continuous half-hour observation period during which the version generates no actual business traffic.
Mode 2: High Availability
Suitable for businesses that are relatively cost-insensitive, require persistent services, or cannot tolerate cold starts.
- The minimum number of replicas cannot be 0 and can be set to any integer between 1 and 50. Even if no traffic is routed to the version, the minimum number of instances will still be maintained, which will incur ongoing costs.
- The default recommended specification is 1 core and 1GB. You can also adjust the specifications as needed.
- During the deployment process, instances are created based on the minimum number of replicas and specifications, incurring some resource consumption from the deployment process itself.
Specifications
Refers to the configuration of each container instance in the cluster. During auto-scaling, newly created instances will use this specification. Under the same version, the specifications of all container instances will remain consistent.
Replica Count
Refers to the maximum and minimum number of instances the current version can reach during auto-scaling. The lower limit for the minimum value is 0, and the upper limit for the maximum value is 50. If you need to modify the minimum value to 0, please first switch the replica mode to "low-cost". If you need to modify the minimum value to an integer greater than 0, please first switch the replica mode to "High Availability".
Scaling Conditions
When a certain condition is met, Cloud Hosting will automatically create/remove instances, then check if the condition is met again. If satisfied, it continues scaling until the number of instances reaches the minimum/maximum replica count or no longer meets the scaling conditions, at which point auto-scaling stops.
Currently, only CPU usage is supported as a scaling condition. More scaling metrics will be available soon.
- If after auto-scaling to the maximum replica count, the system is still insufficient to handle business traffic, no new instances will be created even if scaling conditions are met again. This may impact your business. Please set the maximum replica count appropriately after evaluating your business metrics.
- If you wish to increase the maximum limit (above 50), please submit a ticket to contact us for individual handling.
Advanced Configuration Description
Advanced configuration can be deployed directly using default values without any modifications.
InitialDelaySeconds
After the instance is created, it waits for a certain period before beginning the health check. If the health check fails, it will retry 3 times. If it still fails after retries, the service version is determined to be abnormal. Please set this value to be greater than your application startup time; otherwise, the version may remain in an abnormal state. The default value is 2 seconds.
Log Collection Path
You can set directories or files, and multiple paths are supported. Collected logs can be viewed in Log Management. Supports standard output (stdout) and * wildcard paths (e.g., /logs/*), separated by , (half-width comma). If left blank, stdout will be collected.
Environment Variables
The environment variables required by the user are directly passed into the container. Multiple key-value pairs can be configured.