serverless-azure-functions 正在参加 2021 年度 OSC 中国开源项目评选,请投票支持!
serverless-azure-functions 在 2021 年度 OSC 中国开源项目评选 中已获得 {{ projectVoteCount }} 票,请投票支持!
2021 年度 OSC 中国开源项目评选 正在火热进行中,快来投票支持你喜欢的开源项目!
2021 年度 OSC 中国开源项目评选 >>> 中场回顾
serverless-azure-functions 获得 2021 年度 OSC 中国开源项目评选「最佳人气项目」 !
授权协议 MIT License
开发语言 JavaScript
操作系统 跨平台
软件类型 开源软件
所属分类 云计算Serverless 系统
开源组织
地区 不详
投 递 者 首席测试
适用人群 未知
收录时间 2021-12-02

软件简介

Azure Functions Serverless Plugin

This plugin enables Azure Functions support within the Serverless Framework.

Build Status Code Coverage npm version Node Integration Tests Python Integration Tests .NET Integration Tests

Quickstart

Pre-requisites

  1. Node.js 8.x or above
  2. Serverless CLI v1.9.0+. You can run npm i -g serverless if you don't already have it.
  3. An Azure account. If you don't already have one, you can sign up for a free trial that includes $200 of free credit.

Create a new Azure Function App

# Create Azure Function App from template
# Templates include: azure-nodejs, azure-python, azure-dotnet
$ sls create -t azure-nodejs -p <appName>
# Move into project directory
$ cd <appName>
# Install dependencies (including this plugin)
$ npm install

The serverless.yml file contains the configuration for your service. For more details on its configuration, see the docs.

Running Function App Locally (offline plugin)

At the root of your project directory, run:

# Builds necessary function bindings files and starts the function app
$ sls offline

The offline process will generate a directory for each of your functions, which will contain a file titled function.json. This will contain a relative reference to your handler file & exported function from that file as long as they are referenced correctly in serverless.yml.

After the necessary files are generated, it will start the function app from within the same shell. For HTTP functions, the local URLs will be displayed in the console when the function app is initialized.

To build the files without spawning the process to start the function app, run:

$ sls offline build

To simply start the function app without building the files, run:

$ sls offline start

To clean up files generated from the build, run:

$ sls offline cleanup

To pass additional arguments to the spawned func host start process, add them as the option spawnargs (shortcut a). Example:

$ sls offline -a "--cors *"

This works for sls offline or sls offline start

Dry-Run Deployment

Before you deploy your new function app, you may want to double check the resources that will be created, their generated names and other basic configuration info. You can run:

# -d is short for --dryrun
$ sls deploy --dryrun

This will print out a basic summary of what your deployed service will look like.

For a more detailed look into the generated ARM template for your resource group, add the --arm (or -a) flag:

$ sls deploy --dryrun --arm

Deploy Your Function App

Deploy your new service to Azure! The first time you do this, you will be asked to authenticate with your Azure account, so the serverless CLI can manage Functions on your behalf. Simply follow the provided instructions, and the deployment will continue as soon as the authentication process is completed.

$ sls deploy

For more advanced deployment scenarios, see our deployment docs

Get a Summary of Your Deployed Function App

To see a basic summary of your application (same format as the dry-run summary above), run:

$ sls info

To look at the ARM template for the last successful deployment, add the --arm (or -a) flag:

$ sls info --arm

You can also get information services with different stages, regions or resource groups by passing any of those flags. Example:

$ sls info --stage prod --region westus2

Test Your Function App

Invoke your HTTP functions without ever leaving the CLI using:

$ sls invoke -f <functionName>
Invoke Options
  • -f or --function - Function to Invoke
  • -d or --data - Stringified JSON data to use as either query params or request body
  • -p or --path - Path to JSON file to use as either query params or request body
  • -m or --method - HTTP method for request
Example

After deploying template function app, run

$ sls invoke -f hello -d '{"name": "Azure"}'

If you have a JSON object in a file, you could run

$ sls invoke -f hello -p data.json

If you have your service running locally (in another terminal), you can run:

$ sls invoke local -f hello -p data.json

If you configured your function app to run with APIM, you can run:

$ sls invoke apim -f hello -p data.json

Roll Back Your Function App

To roll back your function app to a previous deployment, simply select a timestamp of a previous deployment and use rollback command.

# List all deployments to know the timestamp for rollback
$ sls deploy list
Serverless:
-----------
Name: myFunctionApp-t1561479533
Timestamp: 1561479533
Datetime: 2019-06-25T16:18:53+00:00
-----------
Name: myFunctionApp-t1561479506
Timestamp: 1561479506
Datetime: 2019-06-25T16:18:26+00:00
-----------
Name: myFunctionApp-t1561479444
Timestamp: 1561479444
Datetime: 2019-06-25T16:17:24+00:00
-----------

# Rollback Function App to timestamp
$ sls rollback -t 1561479506

This will update the app code and infrastructure to the selected previous deployment.

For more details, check out our rollback docs.

Deleting Your Function App

If at any point you no longer need your service, you can run the following command to delete the resource group containing your Azure Function App and other depoloyed resources using:

$ sls remove

You will then be prompted to enter the full name of the resource group as an extra safety before deleting the entire resource group.

You can bypass this check by running:

$ sls remove --force

Creating or removing Azure Functions

To create a new Azure Function within your function app, run the following command from within your app's directory:

# -n or --name for name of new function
$ sls func add -n {functionName}

This will create a new handler file at the root of your project with the title {functionName}.js. It will also update serverless.yml to contain the new function.

To remove an existing Azure Function from your function app, run the following command from within your app's directory:

# -n or --name for name of function to remove
$ sls func remove -n {functionName}

This will remove the {functionName}.js handler and remove the function from serverless.yml

*Note: Add & remove currently only support HTTP triggered functions. For other triggers, you will need to update serverless.yml manually

Advanced Authentication

The getting started walkthrough illustrates the interactive login experience, which is recommended when getting started. However, for more robust use, a service principal is recommended for authentication.

Creating a Service Principal
  1. Install the Azure CLI

  2. Login via Azure CLI and set subscription

    # Login to Azure
    $ az login
    # Set Azure Subscription for which to create Service Principal
    $ az account set -s <subscription-id>
  3. Generate Service Principal for Azure Subscription

    # Create SP with unique name
    $ az ad sp create-for-rbac --name <my-unique-name>

    This will yield something like:

    {
      "appId": "<servicePrincipalId>",
      "displayName": "<name>",
      "name": "<name>",
      "password": "<password>",
      "tenant": "<tenantId>"
    }
  4. Set environment variables with values from above service principal

    Bash

    $ export AZURE_SUBSCRIPTION_ID='<subscriptionId (see above, step 2)>'
    $ export AZURE_TENANT_ID='<tenantId>'
    $ export AZURE_CLIENT_ID='<servicePrincipalId>'
    $ export AZURE_CLIENT_SECRET='<password>'

    Powershell

    $env:AZURE_SUBSCRIPTION_ID='<subscriptionId (see above, step 2)>'
    $env:AZURE_TENANT_ID='<tenantId>'
    $env:AZURE_CLIENT_ID='<servicePrincipalId>'
    $env:AZURE_CLIENT_SECRET='<password>'

Example Usage

Logging Verbosity

You can set the logging verbosity with the --verbose flag. If the --verbose flag is set with no value, logging will be as verbose as possible (debug mode). You can also provide a value with the flag to set the verbosity to a specific level:

  • --verbose error - Only error messages printed
  • --verbose warn - Only error and warning messages printed
  • --verbose info - Only error, warning and info messages printed
  • --verbose debug - All messages printed

Contributing

Please create issues in this repo for any problems or questions you find. Before sending a PR for any major changes, please create an issue to discuss.

We're still in the process of getting everying running 100%, but please refer to the Serverless contributing guidlines for information on how to contribute and code of conduct.

Local dev

  1. Clone this repository to your local machine
  2. Navigate to the cloned folder
  3. Run npm install
  4. Run npm run build
  5. Navigate to a folder where you created a new Serverless project, run npm install, and then run npm link {path to serverless-azure-functions folder}. Running npm install after the link command may override the link.
  6. The npm modules should now contain your local version of this plugin.

Unit Tests

We use Jest for unit tests, and it is expected that every Pull Request containing code changes have accompanying unit tests.

Run unit tests using npm test or npm run test:coverage to get coverage results.

Integration Tests

We run our integration tests twice per day from our GitHub workflow. These tests install the beta version of the plugin, deploy a function app (with APIM), re-deploy (to make sure ARM template deployment is skipped), invoke the function directly, invoke the APIM endpoint and then remove the resource group, making assertions on the output at each step. While the number of configurations one could use in the Serverless Framework is virtually infinite, we tried to capture the main runtimes and platforms that are supported by the tool:

  • Node 10 on Linux using remote build
  • Node 10 on Linux using external package
  • Node 10 on Windows
  • Node 10 on Windows using webpack
  • Node 12 on Linux using remote build
  • Node 12 on Linux using external package
  • Node 12 on Linux using remote build and premium functions
  • Node 12 on Windows
  • Node 12 on Windows using premium functions
  • Node 12 on Windows using webpack
  • Node 14 on Windows
  • Node 14 on Windows using premium functions
  • Node 14 on Windows using webpack
  • Python 3.6 (Linux only)
  • Python 3.6 (Linux only) using premium functions
  • Python 3.7 (Linux only)
  • Python 3.8 (Linux only)
  • .NET Core 2.2 on Linux
  • .NET Core 2.2 on Windows
  • .NET Core 3.1 on Linux
  • .NET Core 3.1 on Windows

We made these configurations as minimal as possible. If you are having problems with your project, feel free to check to see if our integration tests are passing (see badge at top of readme) and then double check our configuration inside the integrationTests directory.

We use Clover to run the integration tests, and they run 2x per day in our GitHub Action, split out by runtime language.

Signing commits

All commits in your Pull Request will need to be signed. When looking at the commits in the pull request, you will see a green 'verified' icon next to your commit. Commit signature verification is discussed here.

Follow the directions here to configure commit signing.

If any of your commits are not signed, your pull request will not be able to be merged into the base branch. You can fix this by squashing any unsigned commits into signed commits using an interactive rebase, and force pushing your new commit history. More detail here.

When using Windows you may also encounter an error when trying to sign a commit, stating that a security key could not be found. Ensure that you have set the path the gpg in the git config: git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe"

License

MIT

展开阅读全文

代码

评论

点击引领话题📣
暂无内容
发表了博客
{{o.pubDate | formatDate}}

{{formatAllHtml(o.title)}}

{{parseInt(o.replyCount) | bigNumberTransform}}
{{parseInt(o.viewCount) | bigNumberTransform}}
没有更多内容
暂无内容
发表了问答
{{o.pubDate | formatDate}}

{{formatAllHtml(o.title)}}

{{parseInt(o.replyCount) | bigNumberTransform}}
{{parseInt(o.viewCount) | bigNumberTransform}}
没有更多内容
暂无内容
Axios 输入验证错误漏洞
输入验证不恰当
Axios是一款基于Promise(异步编程的一种解决方案)的HTTP客户端。 Axios 0.18.0及之前版本中存在安全漏洞。攻击者可利用该漏洞造成拒绝服务(应用程序崩溃)。
CVE-2019-10742 MPS-2019-4913
2022-08-08 20:22
npm dot-prop 安全漏洞
原型污染
4.2.1 之前的 dot-prop npm 包版本和 5.1.1 之前的 5.x 版本中的原型污染漏洞允许攻击者向 JavaScript 语言构造(例如对象)添加任意属性。
CVE-2020-8116 MPS-2020-1734
2022-08-08 20:22
handlebars 安全漏洞
handlebars是一款语义化的Web模板系统。 handlebars 4.7.7版本之前存在安全漏洞,该漏洞源于在选择某些编译选项来编译来自不受信任的源的模板时,handlebars容易受到远程代码执行(Remote Code Execution, RCE)的攻击。
CVE-2021-23369 MPS-2021-4548
2022-08-08 20:22
elliptic 存在竞争条件漏洞
竞争条件
elliptic 是一个简单的 javascript 实现中的快速椭圆曲线密码学。此软件包的受影响版本容易受到时序攻击。
MPS-2022-13653
2022-08-08 20:22
lodash 存在拒绝服务漏洞
拒绝服务
lodash 是一个现代 JavaScript 实用程序库,提供模块化、性能和附加功能。由于对 CVE-2020-8203 的修复不完整,此软件包的受影响版本容易受到 zipObjectDeep 中的原型污染。
MPS-2022-13841
2022-08-08 20:22
follow-redirects project信息暴露漏洞
信息暴露
Exposure of Sensitive Information to an Unauthorized Actor in NPM follow-redirects prior to 1.14.8.
CVE-2022-0536 MPS-2022-3636
2022-08-08 20:22
lodash输入验证错误漏洞
原型污染
lodash是一款开源的JavaScript实用程序库。 lodash 4.17.15及之前版本中存在输入验证错误漏洞。远程攻击者可借助'merge'、'mergeWith'和'defaultsDeep'函数利用该漏洞在系统上执行任意代码。
CVE-2020-8203 MPS-2020-15679
2022-08-08 20:22
Mikaelbr Node-notifier 操作系统命令注入漏洞
命令注入
Mikaelbr Node-notifier是Mikaelbr个人开发者的一个基于Javascript的用于为Mac、Windows、Linux发送统治的代码库。 node-notifier 9.0.0之前版本存在安全漏洞,该漏洞允许攻击者可利用该漏洞在Linux机器上运行任意命令,因为在传递数组时,选项参数没有被清除。
CVE-2020-7789 MPS-2020-17637
2022-08-08 20:22
jszip 安全漏洞
jszip是一个用于创建、读取和编辑.zip文件的JavaScript库。 jszip 3.7.0之前版本存在安全漏洞,该漏洞源于当创建一个新的zip文件,文件名设置为对象原型值时,将返回一个带有修改过的原型实例的对象。
CVE-2021-23413 MPS-2021-11050
2022-08-08 20:22
handlebars 安全漏洞
原型污染
handlebars是一款语义化的Web模板系统。 handlebars 4.7.7之前版本存在安全漏洞,该漏洞源于当选择某些编译选项来编译来自不可信源的模板时,容易受到原型污染的影响。
CVE-2021-23383 MPS-2021-6180
2022-08-08 20:22
trim-newlines 安全漏洞
拒绝服务
trim-newlines是一个修改换行符的npm包。 trim-newlines 存在安全漏洞,该漏洞源于应用于Node.js在3.0.1与4.0.1版本及之前版本中.end()方法存在相关问题。
CVE-2021-33623 MPS-2021-7398
2022-08-08 20:22
semver-regex 存在ReDoS漏洞
ReDoS
semver-regex 是用于匹配 semver 版本的正则表达式。由于 semverRegex() 函数中的正则表达式使用不当,此软件包的受影响版本容易受到正则表达式拒绝服务 (ReDoS) 的攻击。
MPS-2022-14032
2022-08-08 20:22
eslint-utils任意代码执行漏洞
eslint-utils是ESLint插件和自定义规则的实用程序。eslint-utils 1.4.1之前版本存在任意代码执行漏洞。攻击者可通过getStaticValue函数利用该漏洞执行任意代码。
CVE-2019-15657 MPS-2019-10659
2022-08-08 20:22
npm node-fetch 安全漏洞
不加限制或调节的资源分配
node-fetch 2.6.1和3.0.0-beta版本中存在安全漏洞。该漏洞源于内容大小超过限制时,将永远不会抛出FetchError。
CVE-2020-15168 MPS-2020-12719
2022-08-08 20:22
Axios 拒绝服务 漏洞
拒绝服务
Axios 是一个基于promise 网络请求库。 漏洞版本的axios 容易受到低效正则表达式复杂性的影响,从而引发拒绝服务 (ReDoS) 的攻击。
CVE-2021-3749 MPS-2021-30688
2022-08-08 20:22
flat 存在拒绝服务漏洞
拒绝服务
flat 是一个使用嵌套的 Javascript 对象并将其展平,或使用分隔键取消展平对象此包的受影响版本容易受到原型污染。
MPS-2022-13681
2022-08-08 20:22
handlebars 存在拒绝服务漏洞
拒绝服务
handlebars 是 Mustache 模板语言的扩展。此软件包的受影响版本容易受到原型污染。
MPS-2022-13735
2022-08-08 20:22
Amazon Aws-sdk-js 安全漏洞
Amazon Aws-sdk-js是美国亚马逊(Amazon)公司的一个基于Javascript用于为nodejs应用提供AWS服务支持的开发包。 Amazon Aws-sdk-js before 1.0.0-rc.9 存在安全漏洞,攻击者可利用该漏洞向应用程序提交恶意的INI文件,根据上下文进一步加以利用。
CVE-2020-28472 MPS-2021-0649
2022-08-08 20:22
lodash 存在拒绝服务漏洞
拒绝服务
lodash 是一个现代 JavaScript 实用程序库,提供模块化、性能和附加功能。此软件包的受影响版本容易通过 setWith 和 set 函数受到原型污染。
MPS-2022-13842
2022-08-08 20:22
nodejs 资源管理错误漏洞
拒绝服务
nodejs是是一个基于ChromeV8引擎的JavaScript运行环境通过对Chromev8引擎进行了封装以及使用事件驱动和非阻塞IO的应用让Javascript开发高性能的后台应用成为了可能。 nodejs-glob-parent 存在安全漏洞,该漏洞源于正则表达式拒绝服务。
CVE-2020-28469 MPS-2021-7827
2022-08-08 20:22
没有更多内容
加载失败,请刷新页面
点击加载更多
加载中
下一页
0 评论
0 收藏
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部