Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Serverless actual combat-- Funcraft + OSS + ROS for CI/CD

2025-04-02 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/02 Report--

Preface

First of all, we introduce several important concepts that appear in this article:

Function computing (Function Compute): function computing is an event-driven service. Through function calculation, users do not need to manage the operation of the server, but only need to write code and upload. The function calculation prepares the computing resources and runs the user code in an elastic way, while the user only needs to pay according to the resources consumed by the actual code. Function to calculate more information.

Funcraft:Funcraft is a tool for supporting the deployment of Serverless applications, which can help you easily manage resources such as function computing, API gateways, log services, and so on. It assists you in developing, building, and deploying operations through a resource configuration file (template.yml). More documentation references for Fun.

OSS: object storage. Massive, secure, low-cost and highly reliable cloud storage services provide 99.9999999999% data reliability. RESTful API allows storage and access anywhere on the Internet, flexible expansion of capacity and processing capacity, and a variety of storage types to choose from to comprehensively optimize storage costs.

ROS: resource orchestration (ROS) is an easy-to-use cloud computing resource management and automated operation and maintenance service. Users describe the dependency and configuration of multiple cloud computing resources through templates, and automatically complete the creation and configuration of all resources, in order to achieve automated deployment, operation and maintenance purposes. Orchestration templates are also a standardized way of delivering resources and applications, and can be edited and modified at any time to make Infrastructure as Code possible.

CI/CD: CI/CD is a method of frequently delivering applications to customers by introducing automation during the application development phase. The core concepts of CI/CD are continuous integration, continuous delivery, and continuous deployment.

target

This article intends to take a simple function calculation project as an example, on the basis of which the test case is written and configured to support the CI/CD workflow. Achieve the following four small goals:

CI is submitted by git commit to trigger test execution (unit, integration, and end-to-end) functions are packaged and uploaded to OSS through the ROS deployment function to the Staging environment workflow flowchart

Here we take the familiar Github warehouse as an example, combined with Travis CI. When a user goes to the sample project push or PR (Pull Request), the Travis CI task is automatically triggered for unit testing, build packaging, and deployment release.

Sample project

The address of the sample project is: https://github.com/vangie/tz-time, which is a simple web function implemented based on FC Http trigger. The access function returns the current time of the specified time zone. The project directory structure is as follows

Tz-time ├── .funignore ├── .travis.yml ├── Makefile ├── bin │ ├── delRosStack.sh │ ├── deployE2EStack.sh │ └── waitForServer.sh ├── deploy.log ├── index.e2e-test.js ├── index.integration-test.js ├── index.js ├── index.test.js ├── jest.config.e2e.js ├── jest.config.integration.js ├── package-lock.json ├── package.json template.yml

Introduction to the role of some files:

Suddenly listing of files during Funcraft deployment .travis.yml-Travis CI configuration file index.js-function entry file * .test.js-unit test related file * .integraion-test.js-integration test related file * .e23-test.js-end-to-end test related file template.yml-ROS description file, used to describe functions and other cloud service automation tests

There are usually three types of testing: unit testing, integration testing, and E2E testing. In the function calculation scenario, these three types of tests can be implemented in the following ways.

Unit testing-using Mock class test functions to validate input and output parameters integration testing-using fun local invoke/start to simulate running the function E2E test-using fun deploy to deploy a test environment, and then making a simulation call through fun invoke or sending directly through curl

This example only implements unit testing, integration testing and E2E testing are similar to triggering methods for travis examples, and the implementation method can be configured by referring to the method hints above.

Unit testing

The unit test of the FC function is no different from the ordinary function. You can use a familiar unit testing framework, and in this case jest is used for testing. Let's take a look at a code snippet of a test case

Jest.mock ('moment-timezone'); const {tz} = require (' moment-timezone'); const {handler} = require ('. / index'); const EXPECTED_DATE = '2018-10-01 00-00-00-00-00-00-10-01 00 const EXPECTED_DATE TIMEZONE =' America/New_York' Describe ('when call handle', () = > {it (' Should return the expected date if the provied timezone exists', ()) = > {const mockReq = {queries: {tz: TIMEZONE}} const mockResp = {setHeader: jest.fn (), send: jest.fn ()} tz.names = () = > [TIMEZONE] Tz.mockImplementation (() = > {return {format: () = > EXPECTED_DATE}}) handler (mockReq, mockResp, null); expect (mockResp.setHeader.mock.calls.length) .tobe (1); expect (mockResp.setHeader.mock.calls [0] [0]) .toBe ('content-type') Expect (mockResp.setHeader.mock.calls [0] [1]). ToBe ('application/json'); expect (mockResp.send.mock.calls.length) .tobe (1) Expect (mockResp.send.mock.calls [0] [0]) .tobe (JSON.stringify ({statusCode: '200, message: `The time in ${TIMEZONE} is: ${EXPECTED_DATE} `}, null,'');});})

Mock the moment-timezone through jest.mock so that when tz is called, it returns a predetermined value instead of a dynamic time.

Typically, this type of unit test is divided into three steps:

The value or parameter that mock depends on calls the test function to assert the result and the called parameter

If the dependency package does not have a native dependency (depending on the executable file or so library file under linux), you can trigger the test using npm test. If there is a native dependency, the test needs to run in the sbox simulation environment provided by fun and trigger with the following command

Fun install sbox-f tz-time-- cmd 'npm install' integration test

The integration test in this example starts the function locally with the help of the fun local start command, and because the function is configured with http trigger, you can call the function through the http request.

Integration tests are still written in the jest framework. In order to distinguish them from unit test files *. Test.js, integration test files use the. integration-test.js file suffix. In order for the jest command to run the integration test case independently instead of mixing with the unit test, the following file jest.config.integration.js needs to be compiled

Module.exports = {testMatch: ["* * /? (*.) integration-test.js"]}

Then configure scripts in package.json

"scripts": {"integration:test": "jest-c jest.config.integration.js"}

Integration tests can then be performed by executing npm run integration:test.

Then add the integration-test target to the Makefile on this basis:

Funlocal.PID: funlocal start & echo $$! > $@ integration-test: funlocal.PID bin/waitForServer.sh http://localhost:8000/2016-08-15/proxy/tz-time/tz-time/ npm run integration:test kill-2 `cat ${if (error) {fail (error);} else {const resData = JSON.parse (data) Expect (resData.statusCode) .tobe; expect (resData.message) .toContain ('Asia/Shanghai');} done ();});}); end-to-end testing

The test cases of end-to-end testing and integration testing are very similar, except that the server side of the test, end-to-end testing deploys a set of real environment, and the integration test is simulated locally by fun local.

In this example, a set of environment is deployed with the help of fun deploy-use-ros, and the name of the environment is prefixed with a timestamp, so that a new environment will be deployed for each test, and different environments will not affect each other. After the test is completed, delete the stack of ROS through the aliyun-cli tool.

The following Makefile goals for end-to-end testing:

Stack_name: = tz-e2e-$ (shell date +% s) e2e-test: # deploy e2e bin/deployE2EStack.sh $(stack_name) # run test npm run e2e:test # cleanup bin/delRosStack.sh $(stack_name) bin/deployE2EStack.sh $(stack_name) is responsible for deploying a new ROS stack. You need to use fun package to build deliverables before deployment, and you can refer to the next section on how to build deliverables. After the npm run e2e:test runs the end-to-end test bin/delRosStack.sh $(stack_name) test, cleaning up the deployed ROS stack will release the responding cloud resources. Build deliverables

The fun package command can be used to build the deliverables, and fun package needs to specify a bucket for OSS. The fun package command completes the following steps:

Compile and package the code into a Zip file. Upload the code package to OSS bucket. Generate a new file, template.packaged.yml, where the code local address is changed to the OSS bucket address.

The resulting template.packaged.yml file is the final deliverable and can be deployed under the fun deploy name.

Continuous deployment

Once the deliverables are generated in the build process, they can be deployed through fun deploy. Continuous deployment requires the following two issues to be addressed:

Support for new deployment and upgrade deployment one set of resource descriptions supports deployment of multiple sets, such as test environment, staging environment, and production environment.

With the help of ROS, fun deploy can easily solve the above problems.

Fun deploy-use-ros-stack-name tz-staging-assume-yes

Where:

-- use-ros means deployment with the help of ROS, which works by pushing template.yml to the ROS service, which performs new and update operations for each service. Without this parameter, fun parses the template.yml locally and calls API to create the resource. An added benefit of ROS is that it can be rolled back for deployment, which can be rolled back automatically if it fails. -- stack-name specifies the name of a stack. Stack is the concept of ROS and can be understood as a set of environments. -- assume-yes is used in unattended mode to skip the confirmation prompt.

Note that if the parameter-use-ros is not specified here, fun deploy will directly call the cloud resource API for deployment, which is the default deployment method of fun deploy. Although idempotent deployment is basically implemented, it only supports the deployment of limited cloud resources (FC, OTS, API Gateway, etc.), which is not as rich as ROS, and cannot be rolled back and deleted with one click, which is already supported by ROS, so it is not recommended here.

Summary

The scripted configuration of all the steps above can be seen in the Makefile and .travis.yml files. The linkage of Github and Travis CI can be realized through the above two files, and the CI/CD triggered by code submission can be realized.

This article describes the FC function.

How to test, especially how to automate unit testing, how to build deliverables, upload code files to OSS Bucket through fun package, let deliverables program a text description file template.packaged.yml how to deploy continuously, deploy multiple environments with the help of ROS, and update the same environment many times. Refer to the correct posture calculated by the tz-time development function of the source code sample project-- use ROS for resource orchestration FuncraftAliyun Serverless VSCode Extension

"Alibaba Cloud Native focus on micro-services, Serverless, containers, Service Mesh and other technology areas, focus on cloud native popular technology trends, cloud native large-scale landing practice, to be the best understanding of cloud native developers of the technology circle."

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report