introducing cloud native programming pulumi

pull/240/head
rootsongjc 2018-06-24 21:32:18 +08:00
parent 1ab78daf53
commit 428d889ce5
3 changed files with 178 additions and 1 deletions

View File

@ -10,7 +10,9 @@
- [Play with Kubernetes](cloud-native/play-with-kubernetes.md) - [Play with Kubernetes](cloud-native/play-with-kubernetes.md)
- [Kubernetes与云原生应用概览](cloud-native/kubernetes-and-cloud-native-app-overview.md) - [Kubernetes与云原生应用概览](cloud-native/kubernetes-and-cloud-native-app-overview.md)
- [云原生应用之路——从Kubernetes到Cloud Native](cloud-native/from-kubernetes-to-cloud-native.md) - [云原生应用之路——从Kubernetes到Cloud Native](cloud-native/from-kubernetes-to-cloud-native.md)
- [云原生编程语言Ballerina](cloud-native/cloud-native-programming-language-ballerina.md) - [云原生编程语言](cloud-native/cloud-native-programming-languages.md)
- [云原生编程语言Ballerina](cloud-native/cloud-native-programming-language-ballerina.md)
- [云原生编程语言Pulumi](cloud-native/cloud-native-programming-language-pulumi.md)
- [云原生的未来](cloud-native/the-future-of-cloud-native.md) - [云原生的未来](cloud-native/the-future-of-cloud-native.md)
### 概念与原理 ### 概念与原理

View File

@ -0,0 +1,154 @@
# 云原生编程语言Pulumi
2018年6月18日 Joe Duffy在[他的博客](http://joeduffyblog.com/2018/06/18/hello-pulumi/)中宣布开源了云原生编程语言[Pulumi](https://pulumi.io)。这是继[Ballerina](https://ballerina.io)之后我看到的另一款云原生编程语言他们之间有一些共同的特点例如都是为了支持多种云环境基于不可变基础设施和基础设施即代码的理念构建使云原生应用的集成更加方便但也有一些不同Ballerina是直接创建了一个基于JVM的语言而Pulumi是为不同编程语言构建了SDK。
下文部分来自Joe Duffy的博客[Hello, Pulumi](http://joeduffyblog.com/2018/06/18/hello-pulumi/)
![云原生编程语言Pulumi](https://ws1.sinaimg.cn/large/00704eQkgy1fsm4v0a6qwj30xc0m8t9d.jpg)
TL;DR 有了Pulumi38页的手动操作说明将变成了38行代码。25000行YAML配置变成了使用真实编程语言的500行语句。
Pulumi的整个运行时、CLI、支持的库都可以在GitHub上免费下载。我们的团队正急切的等待您的反馈。与此同时我需要告诉您一些关于Pulumi的事情为什么我们会创造它。
## Pulumi是什么
Pulumi是一个支持多语言和混合云开发平台。它可以让您使用真实语言和真实代码创建云计算的各个方面从基础设施到应用程序本身。只需编写程序并运行它们Pulumi就能帮你完成出其余部分。
Pulumi的中心是一个云对象模型与运行时相结合以了解如何以任何语言编写程序理解执行它们所需的云资源然后以强大的方式规划和管理您的云资源。这种云运行时和对象模型本质上是与语言、云中立的这就是为什么我们能够支持如此多的语言和云平台。更多支持正在路上。
Pulumi采用了基础设施即代码以及不可变基础设施的概念并可让您从您最喜欢的语言而不是YAML或DSL中获得自动化和可重复性优势。在部署它们之前您可以对变更进行区分并且我们会对谁更改了什么以及何时更改进行完善的审计追踪。核心模型因此是陈述性的。
使用真正的语言可以带来巨大的好处:
- **熟悉**不需要学习新的定制DSL或基于YAML的模板语言
- **抽象**:正如我们喜爱的编程语言那样,我们可以用更小的东西来构建更大的东西
- **共享和重用**:利用现有的语言包管理器共享和重用这些抽象,无论是与社区、团队内部共享
- **表现力**:充分利用您的编程语言,包括异步、循环和条件
- **工具**通过使用真正的语言我们可以即时访问IDE、重构、测试、静态分析和编排等等
- **生产力**:将以上所有好处加在一起,一起将变得更快,我们也会变得更快乐
当提供原始云资源时,这些好处当然最重要,但是我们在团队中发现,您只能使用抽象。这包括在函数中包装事物以消除样板并创建引入更高级别概念的自定义类,通常将它们打包并重复使用。
例如此代码在AWS中创建一个DynamoDB数据库
```python
import * as aws from "@pulumi/aws";
let music = new aws.dynamodb.Table("music", {
attributes: [
{ name: "Album", type: "S" },
{ name: "Artist", type: "S" },
],
hashKey: "Album",
rangeKey: "Artist",
});
```
此代码创建一个基于容器的任务和无服务器功能,由一个存储桶触发:
```python
import * as cloud from "@pulumi/cloud";
let bucket = new cloud.Bucket("bucket");
let task = new cloud.Task("ffmpegThumbTask", {
build: "./path_to_dockerfile/",
});
bucket.onPut("onNewVideo", bucketArgs => {
let file = bucketArgs.key;
return task.run({
environment: {
"S3_BUCKET": bucket.id.get(),
"INPUT_VIDEO": file,
"TIME_OFFSET": file.substring(file.indexOf('_')+1, file.indexOf('.')).replace('-',':'),
"OUTPUT_FILE": file.substring(0, file.indexOf('_')) + '.jpg',
},
});
});
```
更好的是,这些代码可以根据您的需求部署到任何公共或私有云中。
最后这个例子创建了一个Redis缓存。我们怎么知道我们不需要。缓存组件是一个抽象它封装了我们可以安全忽略的不重要的细节
```python
import {Cache} from "./cache";
let cache = new Cache("url-cache");
```
在使用Pulumi之后你不会再以同样的方式考虑基础设施。你的大脑将不再是一个独立于应用程序的独特“事物”而是开始将分布式云系统看作是你的程序架构的核心部分而不是事后的想法。
由于抽象,我们已经能够提供一些强大的库。该库是提炼和执行最佳实践的绝佳方式。当然,对于我们自己的库来说没有什么特别的,因为它们只是功能、类和代码,我们期待着看到你为自己、你的团队或者社区建立的那些库。
我们最复杂的库——Pulumi云框架——提供了一些令人兴奋的正在进行的工作的早期预览展示如何创建跨越云提供商自己对诸如容器、无服务器功能和存储桶等核心概念的抽象。以同样的方式您可以用Node.js、Python、Java、.NET等语言编写功能强大的应用程序利用进程、线程和文件系统无论是在macOS、Linux还是Windows上这种方法都可以让您创建针对任何云提供商的现代混合云应用程序。像Kubernetes和其他CNCF产品组合这样的技术正在帮助推动这一不可避免的结果因为它们在整个云基板上实现了对基本计算抽象的民主化和共识。
Pulumi不是PaaS尽管它提供类似PaaS的生产力您的程序总是直接针对您选择的云运行并且始终可以访问该基础云的全部功能。即使您选择使用更高级别的组件它也会向下兼容并且您可以随时直接使用原始资源。它就像任何复杂的现代软件有时整个事情必须用C++编写以便访问底层平台的全部功能但对于大多数常见情况70%到100可以是平台独立代码而只有不到30%的专业化才能真正需要直接与操作系统交互。
接下来我还将发布十几篇博客文章来介绍Pulumi所有方面的更多细节。然而为了保持这篇文章尽量简短我将首先介绍下Pulumi的一些我最喜欢的方面。
## 我最喜欢的东西
这很难选择但这里有一些关于Pulumi我最喜欢的东西
**开源**。我坚信所有开发人员工具都应该是开源的。当然Pulumi也是一家公司但是有充足的机会通过增加便利性以建立商业模式。可以认为是Git与GitHub的关系我们从以前的工作中受益匪浅其中包括Docker、Terraform、Kubernetes、TypeScript以及其他许多明确提及的工作。我们期待成为生态系统的一部分。因为我们在开放源代码方面下了很大功夫所以我很高兴看到社区给我们带来什么特别是在更高级别的软件包领域。
**多语言**。就像使用Java和.NET一样Pulumi运行时的架构可以支持多种语言并以目标语言的所有方面风格、语法、软件包等的惯用方式来实现。因为我们是开源的任何人都可以贡献自己的力量。
**混合云**。我们的云对象模型是一个强大的基础可以支持任何云提供商。这提供了一个统一的编程模型工具和控制平面用于在任何地方管理云软件。如果仅仅是为了让一个简单的基于容器的应用程序在生产中运行起来没有必要学习三种不同的YAML方言和五种不同的CLI。
**云对象模型**。这个底层云对象模型为您的云计算构建方式提供了丰富的视图。所得到的对象使用程序中的依赖关系组成一个DAG系统可以分析和理解这些依赖关系以提供洞察力这是我们打算随着时间的推移解锁复杂的静态分析和可视化的功能。
**可重复使用的组件**。由于拥有真正的语言我们可以构建更高层次的抽象。我最喜欢的例子之一是帮助我们的客户定期从部署中排除1000行YAML这是我们的AWS基础架构软件包。它采用AWS最佳实践来设置虚拟私有云并提供专用子网和多可用区域支持并将其转变为几行代码以配置整个网络
```python
import * as awsinfra from "@pulumi/aws-infra";
let network = new awsinfra.Network(`${prefix}-net`, {
numberOfAvailabilityZones: 3, // Create subnets in many AZs
usePrivateSubnets: true, // Run inside private per-AZ subnets
});
```
迄今为止我最喜欢的成功案例是将客户的25,000行AWS CloudFormation YAML文件其中使用无服务器、容器、基础设施和三个自定义部署管道使用500行TypeScript和一个Pulumi的持续部署架构来替换。这不仅仅使得公司所有工程师都可以理解的代码变得少得多这样他们可以将过去需要花费数周时间才能完成的事情现在用一个下午就可以搞定而且现在可以在任何云或原生的Kubernetes上运行而不仅是在AWS。管理团队的CloudFormation堆栈而不是一个工作量过饱和的工程师整个团队可以更加高效。
**统一的容器构建/发布管道**。尝试将容器投入生产时有个问题让我早就感到很沮丧就是同步我的应用程序、容器和基础架构管理因为每个容器都倾向于使用不同的工具。我们的云框架演示了一个集成的工作流程在这个工作流程中只需简单地运行Pulumi构建、diff、推送和拉取新的容器镜像所有这些都经过精心安排以消除停机时间。
**Lambda无服务器功能 **。 AWS的取了个好名字Lambda。在Pulumi中我现在可以用我最喜欢的语言使用lambda表达式来编写我的无服务器函数而不需要一行YAML
```python
import * as aws from "@pulumi/aws";
import * as serverless from "@pulumi/aws-serverless";
let topic = new aws.sns.Topic("topic");
serverless.cloudwatch.onEvent("hourly", "rate(60 minutes)", event => {
const sns = new (await import "aws-sdk").SNS();
return sns.publish({
Message: JSON.stringify({ event: event }),
TopicArn: topic.id.get(),
}).promise();
});
```
此功能允许您捕获对变量的引用:常量、配置设置或加密,甚至可以引用其他资源,以便与它们进行通信。当你第一次这样做的时候,我保证你会有一个“哇塞”的时刻,将无服务器连接到你写过的每一个事件驱动的代码片段。
**使用API的资源**。因为我可以捕获对其他云资源的引用所以我可以在其上创建API以使它们更易于在我的运行时代码中使用。这使得“演员般的”编程模型无需处理配置和服务发现。
**堆栈**。 Pulumi的核心是“堆栈”的概念。堆栈是您的云计算的独立实例其资源和配置与所有其他堆栈不同。您可能有一堆用于生产、暂存和测试的堆栈或者可能是每个单一租户的环境。Pulumi的CLI使得启动和卸载大量堆栈变得轻而易举。这会打开以前可能没有尝试过的工作流例如每个开发人员都拥有自己的堆栈将新堆叠起来并拆除以测试每个Pull请求甚至将服务的层拆分成多个链接在一起的堆栈。
我将在未来的博客文章介绍如何做。现在Pulumi已经公开期望在接下来的几天和几周内听到更多的消息。我希望这能让您更好地了解整体平台其方法和独特优势。
## 下一步是什么?
我们希望通过Pulumi开发人员和DevOps团队都将体验到云的复兴。构建强大的云软件将更加愉快、更高效、更具协作性。现代云计算软件将从代码孤岛转变为等量的配置胶水成为优雅的分布式系统。
这是一个难题。我绝不会说我们已经解决了它。我确实相信Pulumi是我亲身见过并希望最接近我心目中的云开发平台。在这个激动人心的时刻投注于语言将使我们所有人“站在巨人的肩膀上”这让我感到乐观语言总是一个安全的赌注。
今天很可能是我职业生涯中最激动人心的一天。我想感谢我们的团队和所有帮助过我们的人,放纵我们的疯狂想法并相信我们。
现在访问[https://pulumi.io](https://pulumi.io/),或者直接运行:
```bash
$ curl -fsSL https://get.pulumi.com | sh
```
我迫不及待想看看你将使用Pulumi构建的所有令人难以置信的东西。
## 参考
- [Pulumi](https://pulumi.io)
- [Hello, Pulumi!](http://joeduffyblog.com/2018/06/18/hello-pulumi/)

View File

@ -0,0 +1,21 @@
# 云原生编程语言
> 以下内容来自Joe Duffy的博客[Hello, Pulumi!](joeduffyblog.com/2018/06/18/hello-pulumi/)。他说这些是为了说明为什么要创造Pulumi在此我引用它说明为什么会有云原生编程语言。
对于每一个serverless函数来说我都要写几十行的JSON或者YAML配置。要链接到一个API端点我还要学习晦涩的概念执行一系列复制-粘贴的低级工作。如果我想在本机上运行一个小的集群的话那么Docker还是很棒的但是如果要在生产上使用的话那么就要手动管理etcd集群配置网络和iptables路由表还有一系列与我的应用程序本身不相干的事情。不过Kubernetes的出现至少让我可以配置一次下次就可以跨云平台重用但这还是会分散开发人员的精力。
我认为我还算一个经验丰富的工程师已经在软件行业从业20年了但是当我想要将自己的代码部署到云中的时候我感觉自己就像是个傻子。真是太令人悲哀了如果我掌握了这些能力那么是世界就会出触手可及。我总是在淌这浑水处理云的复杂性而我真正想做的是花时间来创造业务价值。
关于编程的许多方面都经历了类似的转变过程:
- 在80年代初我们使用汇编语言对微处理器进行了编程。最终编译器技术进步了我们可以同时处理多种常见的架构。像FORTRAN和C这样的Low-level的编程语言开始兴起。
- 在90年代初期我们直接针对低级别操作系统原语进行编程无论是POSIX系统调用还是Win32 API并进行手动内存和资源管理。最终语言运行时技术和处理器速度提升到了可以使用更高级别语言的状态如Java。除了动态语言之外这种趋势已经加速如JavaScript统治了Web。
- 在21世纪初期我们的编程模型中的共享内存并发性最好是原始的[我花了很多时间在这个问题上](http://joeduffyblog.com/2016/11/30/15-years-of-concurrency/)。现在我们简单地假设OS具有高级线程共享、调度和异步IO功能以及编程到更高级别的API例如任务和承诺。
我相信云软件也在进行类似的转变。从构建单一应用程序到构建真正的云优先分布式系统,我们正处在一场巨变中。然而,当海啸发生之前,人们几乎不知道它正在发生。
从上面的角度来看使用“配置”情况是有道理的。在虚拟机的早期我们利用现有的应用程序并将它们扔在栅栏上以便有人添加一点INI或XML粘合剂让它们在虚拟机内部运行以实现更灵活的管理。随着我们将这些相同的虚拟机“提升并转移到云中”这种配置方法一直伴随着我们。这将我们带到了大致正确的边界。
使用这种相同类型的配置表示基于容器的微服务、serverless和细粒度托管服务之间的关系导致了异常的复杂性。将应用程序转变为分布式系统应该是事后的想法。事实证明云覆盖了您的架构和设计。表达架构和设计的最好的方式是使用代码使用真正的编程语言编写抽象重用和优秀的工具。
早些时候Eric和我采访了几十个客户。我们发现开发人员和DevOps工程师都普遍感到幻灭。我们发现了极端的专业化即使在同一个团队中工程师也不会使用同一种语言。最近几周我已经听到了这个消息我期待有一天会出现NoYAML运动。