使用 Ansible 部署无服务（serverless）应用
serverless 无服务 Ansible

> 
> <ruby> 无服务 <rt>  serverless </rt></ruby>是<ruby> 托管服务 <rt>  managed service </rt></ruby>发展方向的又一步，并且与 Ansible 的无代理体系结构相得益彰。
> 
> 
> 


![](/data/attachment/album/201709/05/223609d2d6dxaevxo2466a.jpg)


[Ansible](https://www.ansible.com/) 被设计为实际工作中的最简化的部署工具。这意味着它不是一个完整的编程语言。你需要编写定义任务的 YAML 模板，并列出任何需要自动完成的任务。


大多数人认为 Ansible 是一种更强大的“处于 for 循环中的 SSH”，在简单的使用场景下这是真的。但其实 Ansible 是*任务*，而非 SSH。在很多情况下，我们通过 SSH 进行连接，但它也支持 Windows 机器上的 Windows 远程管理（WinRM），以及作为云服务的通用语言的 HTTPS API 之类的东西。


在云中，Ansible 可以在两个独立的层面上操作：<ruby> 控制面 <rt>  control plane </rt></ruby>和<ruby> 实例资源 <rt>  on-instance resource </rt></ruby>。控制面由所有*没有*运行在操作系统上的东西组成。包括设置网络、新建实例、供给更高级别的服务，如亚马逊的 S3 或 DynamoDB，以及保持云基础设施安全和服务客户​​所需的一切。


实例上的工作是你已经知道 Ansible 可以做的：启动和停止服务、配置文件<ruby> 模版化 <rt>  templating </rt></ruby>、安装软件包以及通过 SSH 执行的所有与操作系统相关的操作。


现在，什么是<ruby> <a href="https://en.wikipedia.org/wiki/Serverless_computing">  无服务 </a> <rt>  serverless </rt></ruby>呢？这要看你问谁，无服务要么是对公有云的无限延伸，或者是一个全新的范例，其中所有的东西都是 API 调用，以前从来没有这样做过。


Ansible 采取第一种观点。在 “无服务” 是专门术语之前，用户不得不管理和配置 EC2 实例、虚拟私有云 （VPC） 网络以及其他所有内容。无服务是托管服务方向迈出的另一步，并且与 Ansible 的无代理体系结构相得益彰。


在我们开始 [Lambda](https://aws.amazon.com/lambda/) 示例之前，让我们来看一个简单的配置 CloudFormation 栈任务：



```
- name: Build network
  cloudformation:
    stack_name: prod-vpc
    state: present
    template: base_vpc.yml
```

编写这样的任务只需要几分钟，但它是构建基础架构所涉及的最后的半手动步骤 - 点击 “Create Stack” - 这将 playbook 与其他放在一起。现在你的 VPC 只是在建立新区域时可以调用的另一项任务了。


由于云提供商是你帐户中发生些什么的真相来源，因此 Ansible 有许多方法来取回并使用 ID、名称和其他参数来过滤和查询运行的实例或网络。以 `cloudformation_facts` 模块为例，我们可以从我们刚刚创建的模板中得到子网 ID、网络范围和其他数据。



```
- name: Pull all new resources back in as a variable
  cloudformation_facts:
    stack_name: prod-vpc
  register: network_stack
```

对于无服务应用，除了 DynamoDB 表，S3 bucket 和其他任何其他功能之外，你肯定还需要一个 Lambda 函数的补充。幸运的是，通过使用 `lambda` 模块， Lambda 函数可以以上次任务的堆栈相同的方式创建：



```
- lambda:
    name: sendReportMail
    zip_file: "{{ deployment_package }}"
    runtime: python3.6
    handler: report.send
    memory_size: 1024
    role: "{{ iam_exec_role }}"
  register: new_function
```

如果你有其他想用来交付无服务应用的工具，这也是可以的。开源的[无服务框架](https://serverless.com/)有自己的 Ansible 模块，它也可以工作：



```
- serverless:
    service_path: '{{ project_dir }}'
    stage: dev
  register: sls
- name: Serverless uses CloudFormation under the hood, so you can easily pull info back into Ansible
  cloudformation_facts:
    stack_name: "{{ sls.service_name }}"
  register: sls_facts
```

这不是你需要的全部，因为无服务项目也必须存在，你将在那里大量的定义你的函数和事件源。对于此例，我们将制作一个响应 HTTP 请求的函数。无服务框架使用 YAML 作为其配置语言（和 Ansible 一样），所以这应该看起来很熟悉。



```
# serverless.yml
service: fakeservice

provider:
  name: aws
  runtime: python3.6

functions:
  main:
    handler: test_function.handler
    events:
      - http:
          path: /
          method: get
```

在 [AnsibleFest](https://www.ansible.com/ansiblefest?intcmp=701f2000000h4RcAAI) 中，我将介绍这个例子和其他深入的部署策略，以最大限度地利用你已经拥有的 playbook 和基础设施，还有新的无服务实践。无论你是否能到，我希望这些例子可以让你开始使用 Ansible，无论你是否有任何服务要管理。


*AnsibleFest 是一个单日会议，汇集了数百名 Ansible 用户、开发人员和行业合作伙伴。加入我们吧，这里有产品更新、鼓舞人心的交谈、技术深度潜水，动手演示和整天的网络。*


（题图： opensource.com）




---


via: <https://opensource.com/article/17/8/ansible-serverless-applications>


作者：[Ryan Scott Brown](https://opensource.com/users/ryansb) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
[Ansible](https://www.ansible.com/) is designed as the simplest deployment tool that actually works. What that means is that it's not a full programming language. You write YAML templates that define tasks and list whatever tasks you need to automate your job.

Most people think of Ansible as a souped-up version of "SSH in a 'for' loop," and that's true for simple use cases. But really Ansible is about *tasks*, not about SSH. For a lot of use cases, we connect via SSH but also support things like Windows Remote Management (WinRM) for Windows machines, different protocols for network devices, and the HTTPS APIs that are the lingua franca of cloud services.


In a cloud, Ansible can operate on two separate layers: the control plane and the on-instance resources. The control plane consists of everything *not* running on the OS. This includes setting up networks, spawning instances, provisioning higher-level services like Amazon's S3 or DynamoDB, and everything else you need to keep your cloud infrastructure secure and serving customers.

On-instance work is what you already know Ansible for: starting and stopping services, templating config files, installing packages, and everything else OS-related that you can do over SSH.

Now, what about [serverless](https://en.wikipedia.org/wiki/Serverless_computing)? Depending who you ask, serverless is either the ultimate extension of the continued rush to the public cloud or a wildly new paradigm where everything is an API call, and it's never been done before.

Ansible takes the first view. Before "serverless" was a term of art, users had to manage and provision EC2 instances, virtual private cloud (VPC) networks, and everything else. Serverless is another step in the direction of managed services and plays nice with Ansible's agentless architecture.

Before we go into a [Lambda](https://aws.amazon.com/lambda/) example, let's look at a simpler task for provisioning a CloudFormation stack:

```
``````
- name: Build network
cloudformation:
stack_name: prod-vpc
state: present
template: base_vpc.yml
```


Writing a task like this takes just a couple minutes, but it brings the last semi-manual step involved in building your infrastructure—clicking "Create Stack"—into a playbook with everything else. Now your VPC is just another task you can call when building up a new region.

Since cloud providers are the real source of truth when it comes to what's really happening in your account, Ansible has a number of ways to pull that back and use the IDs, names, and other parameters to filter and query running instances or networks. Take for example the **cloudformation_facts** module that we can use to get the subnet IDs, network ranges, and other data back out of the template we just created.

```
``````
- name: Pull all new resources back in as a variable
cloudformation_facts:
stack_name: prod-vpc
register: network_stack
```


For serverless applications, you'll definitely need a complement of Lambda functions in addition to any other DynamoDB tables, S3 buckets, and whatever else. Fortunately, by using the **lambda** modules, Lambda functions can be created in the same way as the stack from the last tasks:

```
``````
- lambda:
name: sendReportMail
zip_file: "{{ deployment_package }}"
runtime: python3.6
handler: report.send
memory_size: 1024
role: "{{ iam_exec_role }}"
register: new_function
```


If you have another tool that you prefer for shipping the serverless parts of your application, that works as well. The open source [Serverless Framework](https://serverless.com/) has its own Ansible module that will work just as well:

```
``````
- serverless:
service_path: '{{ project_dir }}'
stage: dev
register: sls
- name: Serverless uses CloudFormation under the hood, so you can easily pull info back into Ansible
cloudformation_facts:
stack_name: "{{ sls.service_name }}"
register: sls_facts
```


That's not quite everything you need, since the serverless project also must exist, and that's where you'll do the heavy lifting of defining your functions and event sources. For this example, we'll make a single function that responds to HTTP requests. The Serverless Framework uses YAML as its config language (as does Ansible), so this should look familiar.

```
``````
# serverless.yml
service: fakeservice
provider:
name: aws
runtime: python3.6
functions:
main:
handler: test_function.handler
events:
- http:
path: /
method: get
```


At [AnsibleFest](https://www.ansible.com/ansiblefest?intcmp=701f2000000h4RcAAI), I'll be covering this example and other in-depth deployment strategies to take the best advantage of the Ansible playbooks and infrastructure you already have, along with new serverless practices. Whether you're able to be there or not, I hope these examples can get you started using Ansible—whether or not you have any servers to manage.

*AnsibleFest is a **day-long** conference bringing together hundreds of Ansible users, developers, and industry partners. Join us for product updates, inspirational talks, tech deep dives, hands-on demos and a day of networking. Get your tickets to AnsibleFest in San Francisco on September 7. Save 25% on registration with the discount code OPENSOURCE.*

## Comments are closed.