DocsICP FilingConsole
Documentation
Home Page Alibaba Cloud DevOps Use Cases Language-specific guides Go Build and deploy a Golang application to an ECS instance

Build and deploy a Golang application to an ECS instance

Updated at:
Copy as MD
Product
My Favorites

This topic describes how to use Apsara DevOps Flow to build a Golang application and deploy it to an ECS instance.

Background

This document explains how to automate your collaborative development process if you meet the following conditions:

  • You develop applications using the Go language.

  • You deliver applications as binary files.

  • The final build output runs on ECS instances or self-managed hosts.

User requirements

The following are common host deployment scenarios:

  • Perform quality checks on the source code, such as unit tests and code scans.

  • Build the source code into a deliverable build output, such as a binary file.

  • Validate the build output in a staging environment.

  • Deploy the validated build output to the production environment.

These activities require participation from different roles, such as developers, testers, and O&M engineers. Apsara DevOps Flow pipelines are designed to solve the key challenge of enabling these participants to collaborate through a unified delivery process.

Solution

By combining the capabilities of Apsara DevOps continuous delivery pipelines and host deployment, you can establish a solid foundation for continuous application delivery, as shown in the following figure:

31

A developer commits code changes to a repository. Apsara DevOps listens for changes in the repository. When code changes are committed, a build task in the Apsara DevOps continuous deployment pipeline is automatically triggered. This process includes steps such as code scanning, building, deploying to the staging environment, validation, and production deployment. After the build is complete, a package is generated and automatically uploaded to a repository. During the deployment stages for the staging and production environments, the latest version is retrieved from the repository. The package is then deployed to different environments using various deployment policies. The resources can be Alibaba Cloud ECS instances or self-managed hosts.

Procedure

The following example uses a Golang gin-gonic repository to demonstrate how to build an application and deploy it to an Alibaba Cloud ECS instance.

Create and configure a pipeline from a template

  1. In Apsara DevOps Flow, create a new pipeline. Select the Visual Orchestration tab, select Go from the left-side categories, select the Go: Test, build, and deploy to Alibaba Cloud ECS/self-managed host template from the right-side template list, and then click Create.

  2. After the pipeline is created, on the Pipeline Configuration tab, click + Add Pipeline Source in the source stage on the left. In the right panel, select the Code Source tab, set the code source type to Sample Code Source, set the code type to Go. The system automatically populates the code repository as https://atomgit.com/flow-example/go-gonic.git with the default branch set to master. Click Add to complete the pipeline source configuration.

  3. Modify the Go build task. In the Build stage of the pipeline, open the Go Build task and configure the Upload Build Output step: set the upload method to Archive to Apsara DevOps public storage, set the artifact name to Artifacts_$(PIPELINE_ID), and add build/ and deploy.sh to the packaging paths.

  4. Next, configure the host deployment task. From the Build Output drop-down list, select the build output archived in the previous Go build step. Select the host group for deployment. If you do not have a host group, click Create Host Group. For more information, see Host group management. Then, configure the deployment script and policy:

    • Download Path: The path on the host where the compressed package from the Go build task is downloaded. In this example, the value is /home/admin/app/package.tgz.

    • Execute User: The user account that runs the script. In this example, the value is root.

    • Deployment Script: The content of the script to be executed on the host. In this example, the value is: mkdir -p /home/admin/application/ && tar zxvf /home/admin/app/package.tgz -C /home/admin/application/ && sh /home/admin/application/deploy.sh restart

    • Pause Policy: The method to pause the deployment across hosts in a host group. You can choose to pause after the first batch, after each batch, or not at all. We recommend that you pause after the first batch to monitor the online service. If no issues are found, you can continue with the remaining batches.

    • Number of Batches: The number of batches into which the hosts in the host group are divided for deployment. For example, if you have four hosts and set the number of batches to two, two hosts are deployed in each batch.

    Other host deployment configuration items:

    • Build Output: Select Download build output during deployment, and set the artifact name to Artifacts_${PIPELINE_ID}.

    • Host Group: Select Test sample host group.

    • Number of Batches: Set to 2.

Add a manual review

To ensure that only approved build outputs are deployed, you can add a manual review step. On the pipeline editing page under Pipeline Configuration, click the + button before the deployment stage to add a new stage. In the task selection panel, select the Manual Review task under the Tools category.

In the manual review configuration panel, set Approval Mode to Or-sign (one approver can approve or reject), and set Approver Type to Member.

Run the pipeline

After you complete the pipeline configuration, click Save and Run. The pipeline includes stages such as test, build, manual review, and deployment. The Manual Review task has the approval mode set to Or-sign (one approver can approve or reject), approver type set to Member, and timeout set to No timeout.

The scan, unit test, and build upload tasks are completed automatically, and the pipeline pauses at the manual review step.

Click Approve. The pipeline proceeds to the host deployment task. You can click Deployment Details to view more information.

The Host Deployment task shows Paused status with pause policy set to Pause after first batch, deployment batch 1/2, completed machines 1/2. Batch 1 (1/1) has completed deployment, batch 2 (0/1) is pending. You can click Continue in the upper-right corner to proceed with the next batch, or click Cancel to cancel the deployment.

You can click Logs to view the execution log details:

.. ...
....
.......... 92% 129M 0s
6800K ....
.........
.. ......... ..
...... .......... 93% 193M 0s
6850K .......... ..
....
.... .......... .
.......... .
......
.
.. 94% 61.6M 0s
6900K .......... .......... ..
......... .
........
. .......... 94% 5.57M 0s
6950K .....
..
... ..........
.......... ......
.... .......... 95% 93.5M 0s
7000K ..
..
........ ..........
deploy.sh
chmod: cannot access '/home/admin/application/chatroot': No such file or directory
no running chatroot
starting chatroot
started chatroot
checking health
code is 200
health check success
]
[2024-10-29 19:48:59]Execution result code:[
]
DeployCommand execution completed

Roll back a deployment

If you find issues with the online service after a deployment is complete, you need to perform a quick rollback. Apsara DevOps Flow lets you roll back directly to a previous version.

On the pipeline run page, click Deployment History and select the deployment task. You can then view all successful deployment records for that task.

Click Rollback in the Actions column of the target deployment record. In the Rollback Information - Host Deployment dialog box, confirm the current version and the rollback target version, set the Release Pause Policy (such as Pause after first batch) and Release Batches, and then click OK.

Note

The Deployment History page may not appear after the first pipeline deployment. If this occurs, refresh the page.

Notifications

To improve collaboration, Flow provides notifications at different points in the pipeline lifecycle. Development teams are typically concerned with deployment successes and failures. You can push these event notifications to a team's DingTalk group. To configure this, click Add Plugin, select DingTalk Robot Notification, and enter the webhook URL. When you run the pipeline again, you will receive the corresponding notifications. For more information, see Notifications.

Conclusion

By following these steps, you can create a pipeline that supports collaboration among multiple roles. You may also want to learn more about the following topics:

  1. Customize code scanning rules and Java test and build.

  2. Host deployment.

Previous：Build and deploy a Go application to KubernetesNext：PHP language