Brief introduction: The introduction of the instance command line function hopes to eliminate the “last mile” of users using Serverless, and directly show the real function running environment to users. After that, Serverless will no longer be a “black box”. Users can trust and rely more on the Serverless platform to scale more business scenarios and scale.

Author: Cong Xiao (Ali Cloud Function computing R&D engineer)

background

Fully hosted Serverless computing platform can bring users less operation and maintenance costs, stronger stability and faster flexibility. In the process of Serverless implementation, a great challenge is how Serverless platform can give developers enough security. Making it easy for developers to use and trust Serverless is our goal.

The original intention of full hosting is to reduce the usage and operation complexity of developers, but it reduces the control power of users over their own services to some extent. For example, in many scenarios, users will want to know, how can I keep track of the actual performance of my application? How can I quickly determine if there is a problem with my application or the cloud platform? If it is a cloud platform problem, how to quickly restore services, timely stop losses?

The root cause of these problems is that users cannot fully trust the cloud platform, which further hinders them from migrating applications and expanding business scenarios. So we are also thinking about how to break down this mistrust and give the user more control at the resource level, but away from the complex operations at the resource level.

Under such background and requirements, ali Cloud function computing innovation launched the function instance command line operation function in Serverless scenario, which supports users to log in to the function instance on the console interface, or use tools to execute specified commands on the instance. ** This article will explain how to use this feature and how to use it.

Exec function positioning and use

Example command line operation provides the same experience as K8s Pod Exec and Docker Container Exec, and supports the execution of specific commands in the actual running environment of function instances.

At the same time, due to the extreme flexibility of Serverless, charging by volume and other features, the instance Exec function in the Serverless scenario has some essential differences with K8s and Docker:

  1. The Exec operation can only be performed on ** instances that are still alive (including reserved resident instances and active instances by volume). If the idle time of the instance by volume is released, the Exec operation cannot be performed.

  2. InstanceExec requests do not consume the concurrency of the instance. So you can execute both InvokeFunction and InstanceExec operations even if the function instance concurrency is set to 1.

  3. An operation by InstanceExec is treated as an InvokeFunction request invocation. As long as the Websocket connection requested by InstanceExec is not disconnected from the function instance, the function instance will remain active under the same billing rules as InvokeFunction. Users can set the idleTimeout parameter of InstantceExec to allow clients to actively disconnect after being idle for a specified time.

You can log in to the instance from the console, use the Serverless Devs tool to execute commands, or invoke the SDK interface to execute commands.

Console login instance

On the function details – Monitoring Indicators – instance indicators page on the console of function computing official website, you can log in to the instance on the right side.

Click “Login Instance”, the interface will switch to a terminal interface, you can immediately log in to the instance, execute commands to troubleshoot problems.

Click the instance ID to enter the instance details page of the function on the page of function details-Monitoring Indicator – Instance indicator. There is a button on the upper right of the interface for instance login. Click to enter the instance.

The SDK call

In the case of the Golang SDK, most other SDKS are called similarly.

SDK encapsulates the InstanceExec API. When calling the interface, it needs to use OnStdout and OnStderr to pass in two callback functions. The callback function defines the specific logic for processing the data returned by the Exec channel. You can also use the returned execConn to enter the STDIN message for transmission to the remote Exec channel.

command := []string{"/bin/bash"} execConn, err := client.InstanceExec( fc.NewInstanceExecInput( serviceName, functionName, instanceID, command, ).WithStdin(true) .WithStdout(true) .WithStderr(true) .WithTTY(true) .WithIdleTimeout(120) .OnStdout( func(data []byte) { fmt.Printf("STDOUT: %s\n", data) }, ).OnStderr( func(data []byte) { fmt.Printf("STDERR: %s\n", data) }, )) if err ! = nil { fmt.Printf("%v", err) } if err := execConn.WriteStdin([]byte("ls\r")); err ! = nil { fmt.Println("Write Stdin error", err) }Copy the code

Applicable scenario

Troubleshoot online problems

In some daily scenarios, example command line operations provide more efficient and convenient troubleshooting methods that meet user habits.

User Wang is Serverless small white user, after writing a program deployment to the function calculation, it is found that the environment variables set in the function do not take effect, if further investigation, it is necessary to modify the code, print the log, redeploy, view the log, using such a tedious way of investigation. Now, with the help of the example command line operation, Wang can directly command: S exec {instance_id} ENV to locate the problem in one step.

** instance command line operations provide convenient login experience and help users solve application problems in complex scenarios. ** In some cases, users cannot locate faults based on function logs and monitoring indicators, and need to use tools such as Coredump, tcpdump, and Jmap to perform in-depth troubleshooting.

For example, the user Xiao Li found that his online program will recently appear some function errors, error content is connected to a remote service timeout. Xiao Li suspected that the network connection between the function instance and the remote service was unstable, and wanted to enter the internal instance to investigate and analyze the network situation between the instance and the remote service. He can follow these steps:

  • After logging in to the instance, run the apt-get update and apt-get install tcpdump commands to install the tcpdump tool.

  • After the installation is complete, run the tcpdump command to capture packets for remote service IP addresses and save the captured packets in the tcpdump.cap file.

  • After capturing packets, use the OSS command line tool ossutil64 to upload the tcpdump.cap file to the OSS and download it to the local PC for analysis using wireshark.

Program performance optimization

Many times, developers need various profiling tools to analyze performance, resource usage, and so on. For example, the CPU and memory usage of application instances is not expected. Application performance is lower than expected, bottlenecks are found through profiling tools, and so on. Using the example command line, developers can easily run profiling tools provided by the language and framework to optimize application performance and resource usage.

For example, autonavi’s autonomous output behavior running on function calculation can reach hundreds of thousands of levels of peak TPS. As a real-time online application, the service can accept the request delay in tens of milliseconds. Given the cost pressures, they expected to measure the maximum TPS and corresponding call latency for a single instance to assess the number of instances needed before going live.

However, Autonavi found that the average/long tail latency for single instances was not as expected during the pressure test, with request latency skyrocketing when the single-instance TPS reached 300 TPS. They want to determine, is there a performance bottleneck somewhere in their application, or is there a performance problem with the function computation run time? Using the instance command line, they can log in to the instance, find performance issues through profiling, and finally optimize application performance to bring it online.

The following uses custom Runtime as an example: The demo sample program is written using Golang and deployed to the function calculation:

  • After logging in to the instance, download the Golang installation package:

  • And unzip to install go:

  • Perform go tool pprof command, and generate analysis file: / root/pprof/pprof bootstrap. Samples. CPU. 001. The pb. Gz,

  • Finally, run the./ossutil64 cp command with the OSS command line tool ossutil64 to upload the analysis file to your OWN OSS Bukcet, which can be downloaded to the user’s local computer for visual analysis.

conclusion

The introduction of the instance command line function hopes to eliminate the “last mile” of users using Serverless, and directly show the real function running environment to users. After that, Serverless will no longer be a “black box”. Users can trust and rely more on the Serverless platform to scale more business scenarios and scale.

Author profile: Cong Xiao, Ali Cloud function computing r&d engineer, focusing on cloud native Serverless, distributed system stability and other fields.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.