Application publishing

Overview

Application publishing packages source files and start/stop scripts into a deployment artifact and deploys it to scaling group instances through a standardized release process.

Limitations

• Instance operating system: Only Linux-based ECS instances are supported.

• Scripting language: Start and stop scripts must be shell scripts.

• Deployment flow: Follows a stop-before-start principle — the system runs the stop script before the start script.

• Data risk: When you use the ECS image deployment type, the system replaces the instance's system disk. You must back up your data before you proceed.

Create a deployment artifact

1. Log on to the Auto Scaling console.

2. In the left-side navigation pane, click Scaling Groups.

3. In the top navigation bar, select the region where Auto Scaling is activated.

4. Click a Scaling Group ID to go to the scaling group details page. Choose App Release > Deployment > Create a deployment artifact.

5. Select and configure a deployment artifact type based on your use case.

   OSS file

   For application packages (JAR, WAR, ZIP) stored in OSS. During release, the system downloads files to the working directory, runs the stop script, then the start script.

   • Configuration items:

     • OSS Information: Select the OSS Region and OSS Bucket. In the OSS file field, enter the path to the file in the bucket, such as apps/sample-spring-1.0-SNAPSHOT.jar.

     • Download over internal network: Enable when the ECS instance and OSS bucket are in the same region for faster downloads.

   • Example start/stop scripts:

     Application start script:

     start_application() {
       set -e
       yum install -y maven-3.5.4
       java -jar ./sample-spring-1.0-SNAPSHOT.jar &
     }
     
     start_application

     Application stop script:

     Important

     If no stop operations are needed, leave the stop script empty. The system skips it during deployment.

     ### Stop the application (if any)
     stop_application() {
       PID=$(ps -ef | grep "sample-spring-1.0-SNAPSHOT.jar" | grep -v "grep" | awk '{print $2}')
       if [ -n "$PID" ]; then
         kill -9 $PID
       fi
     }
     
     stop_application

   ECS image

   For applications with complex environments or strict startup time requirements. During release, the system replaces instance system disks with the specified image.

   When you select the ECS image deployment artifact type, click Add and select an image from the same region as your scaling group.

   • Configuration items:

     • Region: Select the same region as the scaling group.

     • Image ID: Select a custom image that contains the deployed application and is in the same region as the scaling group.

   Important

   The ECS image deployment artifact type does not support application start/stop scripts. To start the application automatically, configure the application to start on boot or manually configure a lifecycle hook.

   Docker image

   For containerized applications. During release, the system pulls the image from ACR, runs the stop script to remove the previous container (if any), then runs the start script to launch the new container.

   Important

   This feature supports only Docker images from Enterprise Edition instances of Container Registry (ACR) . To deploy images from Personal Edition instances of ACR or third-party image repositories, use the command execution only deployment type.

   • Configuration items:

     • Docker Image Information: Set parameters such as Container Registry Region, Container Registry Instance ID, Namespace, Repository Name, and Image Tag.

     • Pull over internal network: Ensure your image repository and ECS instance are in the same VPC. Configure access control for a VPC.

   • Start/stop scripts:

     Application start script:

     Important

     • Docker must be installed on the target instances.

     • The system automatically pulls the Docker image before script execution. Do not include image pull commands in the script.

     ### During a release, the Docker image is automatically pulled to the ECS instance. You can directly start the container.
     ### Start the current version of the container.
     ### Replace <image_name> with the actual image address.
     start_application() {
       image_name="<image_name>"
       container_name="my-container"
       docker run -d -p 8080:8080 --name ${container_name} ${image_name}
     }
     
     start_application

     Application stop script:

     Important

     If no stop operations are needed, leave the stop script empty. The system skips it during deployment.

     stop_application() {
       # Find the container by its name and delete it if it exists.
       container_name="my-container"
       container_id=$(docker ps -aq -f name=${container_name}) 
       if [ -n "$container_id" ]; then
         docker rm -f $container_id
       fi
     }
     
     stop_application

   Command only

   No source file required — runs a shell script only, such as pulling code from a third-party source. The system runs the stop script, then the start script.

   • Configuration items: No deployment source needed. Specify only the Working Directory.

   • Example start/stop script (pulling a public image):

     Application Start Script:

     ### Start the current version of the application.
     start_application() {
        repo="<repo>"
        image="<image>"
        container_name="my-container"
        docker login --username=${username} --password=${password} $repo
        docker pull $image
        docker run -d -p 8080:8080 --name $container_name $image
     }
     
     start_application

     Application stop script:

     Important

     If no stop operations are needed, leave the stop script empty. The system skips it during deployment.

     ### Stop the container (if any).
     stop_application() {
       # Find the container by its name and delete it if it exists.
       container_name="my-container"
       container_id=$(docker ps -aq -f name=${container_name}) 
       if [ -n "$container_id" ]; then
         docker rm -f $container_id
       fi
     }
     
     stop_application

6. After you complete the configuration, click Create and Publish or Create Only.

   Clicking Create and Publish redirects you to the Deployment Release configuration page.

Publish a deployment artifact

1. On the App Release tab, choose Deployment Release > Publish.

2. Select the Deployment Artifact ID of the deployment artifact that you want to publish.

3. Configure the release policy:

   • Release Mode:

     • Full release: Deploys to all instances in the group.

     • Canary Release: Deploys to manually selected instances for validation.

   • Batch Policy: Set the number of Execution Batch (for example, 2) and select a Batch Mode (No Pause, Pause After First Batch, or Pause After Each Batch).

   • Scaling Scenarios: Keep automatic publishing on scale-out and graceful shutdown on scale-in enabled.

     • Automatic publishing on scale-out: Deploys the application to new instances added during scale-out. A scale-out lifecycle hook is automatically configured.

     • Graceful shutdown on scale-in: Executes the stop script before instance removal. A scale-in lifecycle hook is automatically configured.

4. Click OK to start the release. Click Details in the list to view execution status and logs.

Production best practices

Best practices for production stability:

• Reduce release risks:

  • Use a Canary Release to verify the new version on a small number of instances first.

  • For a full release, enable batch releases and select Suspend First Batch. Verify the first batch before proceeding with subsequent batches.

• Ensure business continuity: Enable graceful shutdown on scale-in with a stop script that waits for in-flight requests to complete and closes connections before termination.

• Ensure version consistency: Enable automatic publishing on scale-out so new instances always run the latest version.

FAQ

• Windows support

  No. Only Linux-based ECS instances are supported.

• Scaling during a release

  Yes. Application publishing does not block scaling activities.

• Release logs and results

  Go to the Deployment Release list and click an Execution ID to view execution status and script output logs for each instance.

• Impact of a deployment failure

  If a script fails, that instance shows a Failed status. With batch release and the Suspend Each Batch or Suspend First Batch option, subsequent batches will not be processed, limiting the scope of impact. Use a Canary Release on a small number of instances for verification first.

• Script execution directory

  Scripts execute in the Working Directory specified when creating the deployment artifact.