转载,原文 敖小剑  https://skyao.io/talk/202004-mecha-mesh-through-to-the-end/

摘要

Servicemesh落地实践三年,效果一直并不理想,到了该反思的时候了。Mecha作为面向服务的分布式能力抽象层,是Servicemesh模式的自然进化版本,预计也将是云原生化和Mesh化的必然趋势,让我们将Mesh进行到底。

Mecha介绍

什么是Macha?

Mecha一词,相信爱好动漫的同学应该都不陌生。是的,就是大家熟悉的那个Mecha(机甲):

Mecha这个词之所以出现在这里,主要是因为 Bilgin Ibryam 的这个博客文章 “Multi-Runtime Microservices Architecture”,提出了微服务架构的一个新的设想:Multiple Runtime。

备注:这篇博客文章强烈推荐阅读,我甚至建议在阅读本文之前先阅读这篇文章,因为我今天的内容,可以视为对这个文章的深度解读和思考。为了方便,这里提供一份中文翻译版本 多运行时微服务架构

在这篇博客中,Bilgin Ibryam 首先分析并总结了分布式应用的四大需求:

  • 生命周期(Lifecycle)
  • 网络(Networking)
  • 状态(State)
  • 捆绑(Binding)

由于每种需求存在的问题和局限性,导致传统解决方案如企业服务总线(ESB)及其变体(例如面向消息的中间件,更轻量级的集成框架等)不再适用。随着微服务架构的发展,以及容器和Kubernetes的普及和广泛使用,云原生思想开始影响这些需求的实现方式。未来的架构趋势是通过将所有传统的中间件功能移至其他运行时来全面发展,最后的目标是在服务中只需编写业务逻辑。

备注:详情请见原文,为了节约篇幅,这里只做简单概述,不完全引用原文内容。

下图是传统中间件平台和云原生平台的对比,传统中间件以各种SDK的方式提供能力,而云原生平台则通过各种外围Runtime(典型如大家熟悉的Servicemesh/Istio):

因此作者引入了Multiple Runtime的概念:

作者提出:很可能在将来,我们最终将使用多个运行时来实现分布式系统。多个运行时,不是因为有多个微服务,而是因为每个微服务都将由多个运行时组成,最有可能是两个运行时-自定义业务逻辑运行时和分布式原语运行时。

对多运行时微服务架构和Mecha的说明:

您还记得电影《阿凡达》和科学家们制作的用于去野外探索潘多拉的 Amplified Mobility Platform (AMP)“机车服”吗?这个多运行时架构类似于这些 Mecha-套装,为类人驾驶员赋予超能力。在电影中,您要穿上套装才能获得力量并获得破坏性武器。在这个软件架构中,您将拥有构成应用核心的业务逻辑(称为微逻辑/micrologic)和提供强大的开箱即用的分布式原语的sidecar mecha组件。Micrologic与mecha功能相结合,形成多运行时微服务,该服务将进程外功能用于其分布式系统需求。最棒的是,Avatar 2即将面世,以帮助推广这种架构。我们最终可以在所有软件会议上用令人赞叹的机甲图片代替老式的边车摩托车;-)。接下来,让我们看看该软件架构的详细信息。

这是一个类似于客户端-服务器体系结构的双组件模型,其中每个组件都是独立的运行时。它与纯客户端-服务器架构的不同之处在于,这两个组件都位于同一主机上,彼此之间有可靠的网络连接。这两个组件的重要性相当,它们可以在任一方向上发起操作并充当客户端或服务器。其中的一个组件称为Micrologic,拥有非常少的业务逻辑,把几乎所有分布式系统问题都剥离出去了。另一个伴随的组件是Mecha,提供了我们在本文中一直讨论的所有分布式系统功能(生命周期除外,它是平台功能)。

作者在这里正式提出了Mecha的理念:

思路大体是:Smart Runtime, Dumb Pipes

我对Mecha的理解是:业务逻辑在编码开始阶段应该是“裸奔”的,专注于业务逻辑的实现,而尽量不涉及到底层实现逻辑;而在运行时,则应该装备“机甲”,全副武装,大杀四方。熟悉的味道是吧?标准而地道的云原生思想。

Mecha的本质

作者在原文中探讨了Mecha运行时的特性:

  1. Mecha是通用的,高度可配置的,可重用的组件,提供分布式原语作为现成的能力。
  2. Mecha 可以与单个Micrologic组件一起部署(Sidecar模式),也可以部署为多个共享(注:我称之为Node模式)。
  3. Mecha不对Micrologic运行时做任何假设。它与使用开放协议和格式(例如HTTP/gRPC,JSON,Protobuf,CloudEvents)的多语言微服务甚至单体一起使用。
  4. Mecha以简单的文本格式(例如YAML,JSON)声明式地配置,指示要启用的功能以及如何将其绑定到Micrologic端点。
  5. 与其依靠多个代理来实现不同的目的(例如网络代理,缓存代理,绑定代理),不如使用一个Mecha提供所有这些能力。

下面是我对上述特性的个人理解:

  1. Mecha提供的是能力,以分布式原语体现的各种能力,而不局限于单纯的网络代理。
  2. Mecha的部署模型,不局限于Sidecar模式,Node模式在某些场景下(如Edge/IoT,Serverless FaaS)可能会是更好的方式。至少,Mecha下有机会按需选择,而不是绑死在Sidecar模式上
  3. Mecha和Micrologic之间的交互是开放而有API标准的,Mecha和Micrologic之间的“协议”体现在API上,而不是TCP通讯协议。这提供了一个契机:一个统一Micrologic和Mecha之间通讯方式的契机。
  4. Mecha可以以声明式的方式进行配置和控制,这非常符合云原生的理念,同样也使得API更关注于能力本身,而不是能力如何配置。
  5. 应用需要的能力如此之多(参见上面的图:分布式应用的四大需求),如果每个能力都对应一个代理(不管是Node还是Sidecar),数量会非常夸张,带来的运维压力会很可怕。因此,如Mecha这个名字暗示的,运行时应该是整套的形式提供能力,而不是分散。

如果用一句话来总结,那么我认为Mecha的本质应该是:

“面向应用的分布式能力抽象层”

如Servicemesh的本质是服务间通讯的抽象层一样,Mecha的本质是应用需要的各种分布式能力和原语,包括但不限于服务间通讯。

从这个角度上说,Mecha覆盖的范围是Servicemesh的超集:毕竟Servicemesh只覆盖到应用的部分需求(服务间通讯,还只限于同步/一对一/request-response模式),还有更多的分布式能力和原语有待覆盖。

换一句话说,Mecha的目标应该是:“将Mesh进行到底!”

Mecha的优势和未来

作者指出:Mecha的好处是业务逻辑和越来越多的分布式系统问题之间的松耦合。

下图是业务逻辑和分布式系统问题在不同架构中的耦合:

其实思路和Servicemesh是一脉相承的,只是覆盖的分布式能力更广泛一些。

有一个问题:Mecha会不会成为微服务架构的演进的下一个形态?我个人的答案:是,随着云原生的推进,分布式能力(以传统中间件为典型代表)下沉是大势所趋,Mesh化的范围必然会继续扩大,也就离Mecha的形态越来越近了。这也就是本文标题的立意所在,Mecha会是微服务乃至云原生的下一站。

微软Dapr

在介绍完 Mecha/Multiple Runtime 的理念之后,我们来看看目前微软新推出来的Dapr项目 —— 这应该是业界第一个Multiple Runtime的开源实践项目。

项目地址:https://github.com/dapr/dapr。

Dapr介绍

Dapr 是 Distributed Application Runtime (分布式应用运行时)的缩写,官方介绍说Dapr是“一种可移植的,事件驱动的运行时,用于构建跨云和边缘的分布式应用”。

Dapr的详细介绍是:

Dapr是一种可移植的,serverless的,事件驱动的运行时,它使开发人员可以轻松构建弹性,无状态和有状态微服务,这些服务运行在云和边缘上,并包含多种语言和开发框架。

Dapr 整理了构建微服务应用为开放,独立的构建块的最佳实践,使您能够使用自己选择的语言和框架来构建可移植的应用程序。 每个构建块都是独立的,您可以在应用中使用其中的一个或多个。

Dapr的功能和定位,下面这一张图就可以概括了:

  • 最底下基础设施是各种云平台(主流公有云都支持)或者边缘环境
  • 其上是dapr提供的分布式能力,dapr称之为“building block”。
  • 这些building block的能力,以统一的API(支持HTTP和gRPC)对外提供服务
  • 应用可以用各种语言编写,然后通过dapr提供的API使用这些能力,dapr也提供客户端类库来简化对API的调用,实现了多语言的支持。

Dapr提供的具体分布式能力(building block)如下图所示:

每个building block提供的具体能力请参加 Dapr 的官方文档:https://github.com/dapr/docs/tree/master/concepts。

Dapr的API例子

我们来看一下应用调用Darp API的例子,体验一下使用Dapr的方式。

以 Service Invocation / 服务调用为例:

部署和调用方式与 Servicemesh/Istio 极为相似,但是,差别在于:Dapr是以提供API的方式提供API背后的能力,而不是提供提供协议代理的方式。

上图中1,是ServiceA发起请求来调用一个远程服务。其HTTP request 如下所示:

POST/GET/PUT/DELETE http://localhost:<daprPort>/v1.0/invoke/<appId>/method/<method-name>

其中:

  • 参数 daprPort 是Dapr Runtime启动的监听端口,用来接受应用的 outbound 请求
  • 参数 appId 是远程应用在darp中的关联id,每个注册到dapr的应用都有一个唯一的appId
  • 参数 method-name 是要调用的远程应用的方法名或者URL

负载可以存放在HTTP body中随请求发送,如 json。

注意,虽然都是提供相同的功能,这里体现了Dapr(或者说背后的Mecha)和Servicemesh在方式上的差异:暴露API还是代理通讯协议。

我们看一个更明显的例子,dapr提供的 “publish/subscriptions” 能力,让应用可以方便的发布消息,或者订阅主题并接收消息。下图是应用发布消息,请求直接发给dapr即可:

例子中,参数 topic 指定了消息要发往的主题(例子中是 deathStarStatus)。后续dapr会完成将消息入queue,然后推送到订阅了该topic的应用。接收消息的方式也类似,不过这次是darp主动发起:

  1. dapr首先会请求应用,咨询应用需要订阅那些主题(topic),如例子中应用返回的的TopicA / TopicB
  2. dapr实现主题订阅,在接收到消息之后,再把消息发送给应用,通过URL参数的不同来区分不同的主题

注意在这个调用期间,无论是收发消息,应用完全不用理会底层pub/sub的实现机制(比如是kafka,还是rocketmq,还是其他公有云提供的消息机制),也完全不用引入该实现机制的客户端SDK,只是简单的使用darp定义的API即可,从而实现了和底层的解耦,以及“厂商不绑定”。

为了进一步简化调用的过程(毕竟发一个最简单的HTTP GET请求也要应用实现HTTP协议的调用/连接池管理等),dapr提供了各个语言的SDK,如 java / go / python / dotnet / js / cpp / rust 。另外同时提供HTTP客户端和gRPC客户端。

我们以 Java 为例,java的 client API 接口定义如下:

public interface DaprClient {  
   Mono<Void> publishEvent(String topic, Object event);
   Mono<Void> invokeService(Verb verb, String appId, String method, Object request);
    ......
}

具体可见:

https://github.com/dapr/java-sdk/blob/master/sdk/src/main/java/io/dapr/client/DaprClient.java

分析和总结

前面介绍了Multiple Runtime / Mecha 的架构思想,以及参考实现之一的微软Dapr项目。

由于 Multiple Runtime / Mecha 这个思想非常的新,刚刚提出不久,而微软 Dapr 项目也是一个新出来的项目,不管是理论思想还是实践都处于非常早期的状态,也还没有形成完善的方法论。

特别申明:以下内容更多是我个人当下的理解和感悟,仅代表个人意见,肯定有很多不成熟甚至谬误的地方,欢迎指正和探讨。

Mecha和Dapr的启示

  1. Mesh 模式应该推向更大的领域

    随着云原生的深入,应用需要的分布式能力应该全面下沉,而不仅仅局限于Servicemesh提供的服务间通讯能力;应用形态会朝纯业务逻辑这个目标更进一步,应用更加的云原生化。

    这是大势所趋,也是Mecha架构出现和发展的原动力。

  2. Mecha强调是“提供能力”,而不是通讯代理

    Mecha的使用方式和Servicemesh有非常大的差异:Mecha强调的是提供分布式能力给应用使用,这些能力最终以封装完善的API的方式呈现。API体现的是应用对能力的“需求”和“意愿”,不涉及到如何实现,实现是Mecha的职责,采用什么样的实现也是由Mecha来控制。

    在Servicemesh下,不存在这个需求:Servicemesh提供的是服务间通讯能力,这个能力是由sidecar来提供,没有其他的更底层的实现,不存在隔离和替换的可能。受服务通讯协议和报文schema的限制,Servicemesh只能做请求的“转发”,能力聚焦在“如何转发”上,没有其他需要隔离和替代的能力。

    当Mecha把能力扩展到Servicemesh之外时,很多能力是由外部系统提供:比如 pub-sub 能力可以由不同的Message Queue实现;状态管理能力可以连接不同的Key-Value实现。此时能力的隔离性和可替代性就成为关键需求:解耦应用和能力实现,容许Mecha替换底层实现(进而实现供应商不锁定等)。

  3. 不强求“零侵入”

    在Servicemesh中,“零侵入”是一个非常强调的特性,为此不惜引入 iptables 等流量劫持方案。“零侵入”在某些特殊场景下会发挥巨大的优势,如旧有应用不做改造的前提下接入servicemesh。好处自然不言而喻,但零侵入也有自身的限制:客户端必须能发出符合服务器端要求的网络通讯请求,这个过程外部无法插手。

    对于服务间通讯,这个不是大问题。但是对于其他能力,由于有和实现解耦的需求,再通过客户端自行发起原生协议的请求就不合适了。因此,Mecha中更倾向于采用低侵入的轻量级SDK方案,同样也可以实现跨语言和跨平台,只是需要付出实现各种语言SDK的代价。由于这个SDK足够轻量,因此代价还不算很高。

    而这些少量的工作量,少量的侵入,可以换取轻量级SDK能提供的各种便利和配合(简单理解:开后门),可以实现能力的抽象和API的封装。权衡利弊,Mecha下更倾向于轻量级SDK方案。

  4. 不限定 Sidecar 部署

    Sidecar部署模式,存在资源占用、维护成本增加等缺点,在某些情况下可能并不合适:

    • 边缘网络,IoT场景:资源非常有限,不适合启动太多Sidecar
    • FaaS场景:应用自身足够轻量,甚至比Sidecar还要轻量
    • Serverless场景:Scale to Zero时,对冷启动速度有严格要求,Sidecar的启动和初始化可能拖累应用启动速度

    Mecha下,部署模式不限定于 Sidecar ,在合适时容许选择 Node 模式,甚至 Node 模式和 Sidecar 模式混合使用。

  5. API和配置是关键

    API是分布式能力的抽象,需要要对(开发上层业务应用的)客户友好,简单好用,稳定不变。这些API 也需要标准化,被社区广泛接受和采纳,才能实现厂商不锁定和自由迁移,提升客户价值。

    另外,API还需要配合配置使用,在把能力抽象为API时,是不提供能力的细节控制的。这些控制将在运行时由Mecha根据配置实现,可以理解为:“API + 配置 = 完整的能力”。

    API和配置的制订以及标准化,预计将会是Mecha成败的关键。

Mecha的精髓

Program to an interface, not an implementation.

Design Patterns: Elements of Reusable Object-Oriented Software (GOF, 1994)

Mecha的精髓,要从上面这句名言开始:

  1. 在Mecha下,为了实现解耦可替换, Runtime 隔离了底层实现,因此演变为:”Program to an Runtime, not an implementation.“”
  2. 考虑到 Runtime 不管是部署为Sidecar模式,还是部署为 Node 模式,都是Localhost,因此有: “Program to an Localhost, not an implementation.”
  3. 为了简化开发,Mecha还是会提供轻量级SDK,提供API作为能力的抽象:“Program to an API, not an implementation.”
  4. 考虑到 API 通常是以 interface 的形式提供,因此绕了一圈,Mecha最后还是回到原点:“Program to an interface, not an implementation.”

个人理解,Mecha的精髓就在于这几个关键点:隔离/抽象/解耦/可替换。如下图所示:

  • 在Mecha下,MicroLogic(也就是业务逻辑的代码实现)不容许直接使用底层实现提供的分布式能力
  • Mecha Runtime将为Micro Logic提供分布式能力,同时隔离应用和底层实现
  • 为了方便使用,提供轻量级SDK,其中的API层实现了分布式能力的抽象,应用只需面向API编程
  • 轻量级SDK和Mecah Runtime配合,完成对底层实现的解耦和可替换。

Mecha的实现原则

在Mecha的实现上,我理解的原则是这样:

  1. Runtime 是主力,要做厚
  2. 轻量级SDK 主要是给 Runtime 打配合,要做薄

具体的职责划分:

  1. 轻量级SDK:实现多语言接入,低侵入(但不追求零侵入)
  2. API 接口:由轻量级SDK中提供统一,目标社区化+标准化,给开发者提供一致的编程体验,同时提供可移植性
  3. 应用:轻量级SDK/Runtime配合,提供各种分布式能力,应用无感,只需简单使用API,不耦合底层实现

在Mecha架构中,Runtime 自然是整个架构的核心,扮演类似Servicemesh中数据平面的角色

  • 所有分布式能力使用的过程(包括访问内部生态体系和访问外部系统)都被 Runtime 接管和屏蔽实现
  • 通过CRD/控制平面实现声明式配置和管理(类似Servicemesh)
  • 部署方式上 Runtime 可以部署为Sidecar模式,或者Node模式,取决于具体需求,不强制

备注:Mecha有非常多的能力,实现上也有非常多的细节,这里先做一个High Level的概述。细节后面会有一系列文章一一覆盖,欢迎多交流讨论。

Mecha总结

大概是在3月初,当时我第一次阅读 “Multi-Runtime Microservices Architecture” 这篇文章,有一种豁然开朗的感觉,尤其是有很多之前在反复考虑和权衡但是下不了结论的问题,在这个文章中得到了清晰的解答。可谓受益匪浅。

在Servicemesh探索和实践的这三年中,遇到很多问题,有很多之前没有想到过的问题浮现。比如,以前一直觉得Servicemesh中引入Sidecar带来的最大麻烦会是性能,但实际上,从目前的实践看,Sidecar引入后带来的维护代价才是更令人头疼的事情,相比之下Sidecar引入带来的性能损失显得无伤大雅。

总结一下我个人对 Mecha 架构的核心理解,主要是两点:

  1. Mecha是云原生化和Mesh化的必然趋势:云原生在继续发展,应用需要的分布式能力需要继续下沉,越来越多的能力会以sidecar的形式出现,这是大势所趋。但不可能出现一个应用部署十几个sidecar的局面,这会是运维地狱。因此,必然需要出现新的形态来解决Sidecar过多的问题,合并为一个或者多个Sidecar就会成为必然。
  2. Mecha是Servicemesh模式的自然进化版本:Servicemesh落地实践三年了,效果一直并不理想,到了该反思反省的时候了;而且Mecha的范围也远不止服务间通讯,新的需求下应该有新的思考和突破。Servicemesh现有的固定模式,在Mecha下可以尝试打破以探索新的方式:不必拘泥于Sidecar,试试Node模式;不必拘泥于通讯协议转发,试试Runtime提供能力解耦底层实现;不必拘泥于零侵入,试试在应用中保留一个足够轻的轻量级SDK。

正如曾有说法,说“微服务是SOA实践中正确的部分(the Good Part)”,我希望在 Mecha 的探索和实践中,能够从Servicemesh的实践中吸取成功的经验和失败的教训,希望 Mecha 也能成为Servicemesh的Good Part。希望在云原生的演进路线中,Mecha 可以继微服务和Servicemesh之后,成为云原生落地实践的下一站。

回到现实,目前 Mecha 和 Multi-Runtime 还是一个非常新的想法,Dapr 项目也才刚刚起步,Mecha 要探索的道路还很漫长,一切都还需要摸索着前进。

附录:参考资料

在文章的最后,特别鸣谢 “Multi-Runtime Microservices Architecture”一文的作者 “Bilgin Ibryam”,我非常认可这篇文章中的思想和理念,分析归纳的非常到位,提炼和升华的能力令人佩服。

作者介绍:

Red Hat的首席架构师,Apache Software Foundation 的 committer 和成员。开源的布道师,博客作者,偶尔演讲,著有书籍 Kubernetes Patterns 和 Camel Design Patterns 。

本文参考了 Bilgin Ibryam 出品的如下内容:

应用错误跟踪系统:对软件系统运行过程中产生的错误日志进行收集从而实现监控告警。

虽然软件错误❌是不可避免的,但是可以降低错误数。

提高对错误的治理能力能让错误带来的损失降到最低 ​👍🏻 。

错误日志监控在最顶层的业务层监控,有他将会帮助你打造更好的软件!

我们需要业务场景下自己发现Bug的速度快于用户报告Bug的速度,毕竟让用户报告已经晚了。

典型的这套系统的架构:错误日志(前端、后端) => 传输(HTTP)=>错误跟踪平台(收集、展示、分析、告警)。

本文不讨论哪款软件来解决这个问题,只讲Sentry这个轮子,SASS版本和私有部署版体验几乎一致

img

本文主要讲了

应用错误需要监控的场景案例

Sentry有哪些功能

Sentry如何在k8s中私有化部署

本文由 www.iamle.com 流水理鱼 原创,wx公众号搜索 流水理鱼 或 liushuiliyu

SEO 关键字

Sentry私有化部署

Sentry helm部署

Sentry kubernets部署 k8s部署

1. 需要应用错误监控的场景案例

  • 多年的老web项目需要https适配,因为老项目大量写死了http://所以文件修改数巨大,即便测试很仔细也不能保证完全没问题
  • 运营发现落地页转化异常了,有访问没表单提交,找到技术,技术发现是某个JS报错,导致表单无法提交,造成推广费用的损失
  • 上线了一个功能,由于环境差异,只在生产环境才触发,用户报告了才去查问题
  • 应用错误日志虽然通过ELK采集了,但是缺乏及时分析和告警
  • 特定的环境才产生错误,要解决问题的先去构建环境并复现错误,因为不清楚发生错误时的具体参数

2. Sentry有哪些功能

Sentry is cross-platform application monitoring, with a focus on error reporting.

Sentry跨平台应用监控,专注错误报告。

Sentry英文直译中文叫“哨兵”。

Sentry提供了一个应用程序监视平台,可以帮助您实时识别问题。

  • 提供WEB UI
  • 提供SASS版和私有部署2种方式
  • 开源,授权协议为BSL,只要你不拿他来做SASS服务卖钱,自用可以免费商用
  • 提供几乎所有主流开发语言和框架的SDK
  • 提供完整的错误详情
  • 支持自动上报错误和手动上报错误
  • 支持WEB前端、后端、APP
  • 支持多项目管理
  • 支持账号权限管理
  • 提供统一错误的聚合分析

  • 今日头条等很多大公司都在用

img

3. 在Kubernets中部署Sentry

目前网上大部分都是讲DockerCompose的部署方式

其实Helm Hub上可以找到Sentry的helm charts包(⑤),那么直接用Helm部署Sentry是最快速方便的

3.1 Sentry部署资源要求

下面给出一个部署资源情况参考,这基本也就是最低资源消耗情况了

  • Kubernets存储已经支持了动态PVC

  • Kubernets已经支持Ingress

  • 准备一个子域名 (例如, sentry.iamle.com)

  • Helm部署Sentry会部署sentry-corn、sentry-web()、sentry-worker、Redis、PostgreSQL

  • 空负载资源详细sentry-corn(220MB/0.01Core)、sentry-web(850MB/0.012Core)、sentry-worker(2048MB/0.04Core)、Redis(132+179MB/0.04+0.054Core)、PostgreSQL(506MB/0.03Core)

  • 空负载整体资源占用情况,内存:3935MB、CPU核数:0.2 Cores、存储PVC:34G

image-20200419182509260

3.2 Helm 部署 Sentry

helm为helm3

使用国内加速的charts(微软azure)

helm repo add stable http://mirror.azure.cn/kubernetes/charts
helm repo add incubator http://mirror.azure.cn/kubernetes/charts-incubator
helm repo update
helm search repo sentry
#NAME                              CHART VERSION   APP VERSION DESCRIPTION
#stable/sentry                     4.2.0           9.1.2       Sentry is a cross-platform crash reporting and ...
#已经可以在stable repo 找到 sentry
## helm安装sentry
kubectl create namespace sentry
helm install sentry stable/sentry \
-n sentry \
--set persistence.enabled=true,user.email=i@iamle.com,user.password=i@iamle.com \
--set ingress.enabled=true,ingress.hostname=sentry.iamle.com,service.type=ClusterIP \
--set email.host=smtp.yourhost.com,email.port=25 \
--set email.user=user,email.password=password,email.use_tls=false \
--wait
#参数一看就懂,更多安装参数看文末的参考⑤
#第一次安装需要耗时10分钟以上,等等等,db-init-job初始化数据库的时候花费了太多时间
#在安装完成之前,访问sentry.iamle.com会出现服务器内部错误

#出现下面的内容就表示部署好了
#NAME: sentry
#LAST DEPLOYED: Sun Apr 19 21:01:26 2020
#NAMESPACE: sentry
#STATUS: deployed
#REVISION: 1
#TEST SUITE: None
#NOTES:
#1. Get the application URL by running these commands:
#  export POD_NAME=$(kubectl get pods --namespace sentry -l "app=sentry,role=web" -o jsonpath="{.items[0].metadata.name}")
#  echo "Visit http://127.0.0.1:8080 to use your application"
#  kubectl port-forward --namespace sentry $POD_NAME 8080:9000
#
#2. Log in with
#
#  USER: i@iamle.com
#  Get login password with
#    kubectl get secret --namespace sentry sentry -o jsonpath="{.data.user-password}" | base64 --decode

#查看登陆密码,也就是user.password设置的值
#kubectl get secret --namespace default sentry -o jsonpath="{.data.user-password}" | base64 --decode

#删除sentry
#helm uninstall sentry -n sentry

ingress根据自己实际环境做一些微调,笔者的环境下ssl证书使用 cert-manager 自动管理,备注annotations就自动配置ssl

# sentry ingress示例
kubectl apply -f - <<EOF
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: sentry
  namespace: sentry
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  rules:
  - host: sentry.iamle.com
    http:
      paths:
      - path: /
        backend:
          serviceName: sentry
          servicePort: 9000
  tls:
  - hosts:
    - sentry.iamle.com
    secretName: sentry-cert
EOF

浏览器访问

https://sentry.iamle.com 使用安装时设置的账号密码登陆即可

3.3 Sentry新增一个项目

理论上是需要给每个项目都在Sentry中创建一个对应的项目

但是实际上这么干会比较麻烦,笔者建议对访问量不大,比如后台类的相同类型的新建一个项目即可

发现混在一起已经不好区分了,再去拆开也不迟

对于本身访问量巨大的“前端”项目,建议在Sentry管理后台的一对一配置

Projects 》 Add new Project 选择一个JavaScript类型

image-20200419211855759

image-20200419212037861

⚠️ 官方提供的SDK是国外的CDN,实际使用的时候需要把https://browser.sentry-cdn.com/5.5.0/bundle.min.js下载后放在自己的OSS+CDN上

SDK和初始化代码一般放入全站头部当中,当页面有js错误的时候已经会自动上报了

我们用chrome的console手动上报一个消息测试下sentry是否工作正常

Sentry.captureMessage("流水理鱼 www.iamle.com")

image-20200419212444197

image-20200419212641447

3.4 Helm安装sentry常见问题及解决

  • 解决数据库不能初始化的问题

    如果安装过程数据库不能初始化,可以手动初始化

kubectl exec -it -n sentry $(kubectl get pods  -n sentry  |grep sentry-web |awk '{print $1}') bash
sentry upgrade

  • 手动创建一个新的管理员账号
kubectl exec -it -n sentry $(kubectl get pods  -n sentry  |grep sentry-web |awk '{print $1}') bash
sentry createuser

4. 总结

本文看起来洋洋洒洒一大篇,实际上15分钟就能部署好sentry🎉

Sentry不仅仅支持WEB前端,也支持桌面、APP、后端,全平台💯

注意如果要升级sentry,先备份数据先,之前的数据会被清空 ⚠️

如果遇到Sentry的部署、使用等问题可以在博客 www.iamle.com 中找到我的wx,加群讨论📣

5. 参考

1. 导言

绝大多数业务场景都是需要知道客户端IP的
在k8s中运行的业务项目,如何获取到客户端真实IP?
本文总结了通行的2种方式
要答案的直接看方式一、方式二和总结
SEO 关键字
nginx ingress客户端真实ip
kubernets获取客户端真实ip
rke获取客户端真实ip
rancher获取客户端真实ip
本文由 www.iamle.com 流水理鱼 原创,wx公众号同名

1.1 流量链路介绍

7层转发链路 Client(客户端) > Nginx > K8s Ingress(Nginx ingress)
4层转发链路 Client(客户端) > 公有云LB > K8s Ingress(Nginx ingress)
ps: 实际业务会串联更多层级的转发。WAF、CDN、Api Gateway一般是http 7层转发,LB一般是4层tcp转发

1.2 准备whoami探针

whomai是一个go编写的调试探针工具,回显http头信息
在k8s中部署一个containous/whoami用来作为探针,配置好ingress公网和访问,这样客户端web访问可以看到基本的http头信息,方便调试

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: default
  labels:
    app: whoami
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
      - image: containous/whoami
        imagePullPolicy: Always
        name: whoami
        ports:
        - containerPort: 80
          name: 80tcp02
          protocol: TCP
      dnsPolicy: ClusterFirst
      restartPolicy: Always
EOF 

ps:ingress自行增加

客户端web访问,回显http头示例

Hostname: whoami-65b8cc4b-6vwns
IP: 127.0.0.1
IP: 10.42.2.12
RemoteAddr: 10.42.1.0:47850
GET / HTTP/1.1
Host: whoami.iamle.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-TW;q=0.6,la;q=0.5
Cookie: _ga=GA1.2.30707523.1570429261;
Dnt: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 8.8.8.8, 10.0.0.1
X-Forwarded-Host: whoami.iamle.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-Forwarded-For: 8.8.8.8
X-Original-Uri: /
X-Real-Ip: 8.8.8.8
X-Request-Id: 3852c9780589ffba4c1f9f2785691d5f
X-Scheme: https

2. 两种方式 7层http头X-Forwarded-For透传 和 4层Proxy Protocol透传

获得客户端真实IP有针对7层和针对4层两种方式

2.1 7层http头X-Forwarded-For透传介绍

http工作在网络第7层,http中有个X-Forwarded-For字段

大部分CDN、WAF、LB用X-Forwarded-For字段来存客户端IP,也有用X-Real-Ip字段,cloudflare、百度云加速还扩展了CF-Connecting-IP字段
标准数据为

X-Forwareded-For:Client,proxy1,proxy2,proxy3……

第一个ip是客户端ip,后面的proxy为路过一层就加一层的ip
这里的proxy可以是WAF、CDN、LB、Api Gateway等

2.2 4层Proxy Protocol透传

tcp工作在网络第4层,Proxy Protocol就是在tcp中增加一个小的报头,用来存储额外的信息

代理协议即 Proxy Protocol,是haproxy的作者Willy Tarreau于2010年开发和设计的一个Internet协议,通过为tcp添加一个很小的头信息,来方便的传递客户端信息(协议栈、源IP、目的IP、源端口、目的端口等),在网络情况复杂又需要获取客户IP时非常有用。
其本质是在三次握手结束后由代理在连接中插入了一个携带了原始连接四元组信息的数据包。

目前 proxy protocol有两个版本,v1仅支持human-readable报头格式(ASCIII码),v2需同时支持human-readable和二进制格式,即需要兼容v1格式
proxy protocol的接收端必须在接收到完整有效的 proxy protocol 头部后才能开始处理连接数据。因此对于服务器的同一个监听端口,不存在兼容带proxy protocol包的连接和不带proxy protocol包的连接。如果服务器接收到的第一个数据包不符合proxy protocol的格式,那么服务器会直接终止连接。

Proxy protocol是比较新的协议,但目前已经有很多软件支持,如haproxy、nginx、apache、squid、mysql等等,要使用proxy protocol需要两个角色sender和receiver,sender在与receiver之间建立连接后,会先发送一个带有客户信息的tcp header,因为更改了tcp协议头,需receiver也支持proxy protocol,否则不能识别tcp包头,导致无法成功建立连接。
nginx是从1.5.12起开始支持的

3. 方式一 X-Forwarded-For配置

适用于7层http转发

3.1 NGINX Ingress Controller X-Forwarded-For配置

查看NGINX Ingress Controller的ConfigMaps配置文档,可以找到以下配置项
use-forwarded-headers
如果为true,NGINX会将传入的 X-Forwarded-* 头传递给upstreams。当NGINX位于另一个正在设置这些标头的 L7 proxy / load balancer 之后时,请使用此选项。
如果为false,NGINX会忽略传入的 X-Forwarded-* 头,用它看到的请求信息填充它们。如果NGINX直接暴露在互联网上,或者它在基于 L3/packet-based load balancer 后面,并且不改变数据包中的源IP,请使用此选项。
ps: NGINX Ingress Controller直接暴露互联网也就是Edge模式不能开启为true,否则会有伪造ip的安全问题。也就是k8s有公网ip,直接让客户端访问,本配置不要设为true!

forwarded-for-header
设置标头字段以标识客户端的原始IP地址。 默认: X-Forwarded-For
ps:如果 NGINX Ingress Controller 在CDN,WAF,LB等后面,设置从头的哪个字段获取IP,默认是X-Forwarded-For
这个配置应该和use-forwarded-headers配合使用

compute-full-forwarded-for
将远程地址附加到 X-Forwarded-For 标头,而不是替换它。 启用此选项后,upstreams应用程序将根据其自己的受信任代理列表提取客户端IP

修改configmap nginx-configuration配置

kubectl -n ingress-nginx edit cm nginx-configuration

在apiVersion: v1下,kind: ConfigMap上加入

data:
  compute-full-forwarded-for: "true"
  forwarded-for-header: "X-Forwarded-For"
  use-forwarded-headers: "true"

或者直接apply附加配置

kubectl apply -f - <<EOF
apiVersion: v1
data:
  compute-full-forwarded-for: "true"
  forwarded-for-header: X-Forwarded-For
  use-forwarded-headers: "true"
kind: ConfigMap
metadata:
  labels:
    app: ingress-nginx
  name: nginx-configuration
  namespace: ingress-nginx
EOF

ps:如果nginx-configuration不在namespace ingress-nginx中就在namespace kube-system中找

3.2 Nginx作为边缘节点(Edge)配置

作为Edge需要重写remote_addr,保证了客户端IP不会被伪造
必须:X-Forwarded-For 重写为 $remote_addr
非必须扩展:X-Real-IP 重写为 $remote_addr

upstream wwek-k8s {
    server 8.8.8.8:443;
    server 8.8.8.7:443;
    server 8.8.8.6:443;
}

map $http_upgrade $connection_upgrade {
    default Upgrade;
    ''      close;
}
server {
    if ($http_x_forwarded_proto = '') {
        set $http_x_forwarded_proto  $scheme;
   }
location / {

        proxy_set_header Host              $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port  $server_port;
        #proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-For   $remote_addr;
        proxy_set_header X-Real-IP         $remote_addr;

        proxy_pass          https://wwek-k8s;
        proxy_http_version  1.1;
        proxy_set_header    Upgrade $http_upgrade;
        proxy_set_header    Connection $connection_upgrade;
        proxy_read_timeout 900s;
        proxy_buffering off;
    }
}

3.3 X-Forwarded-For是否可以伪造

客户端是否能伪造IP,取决于边缘节点(Edge)是如何处理X-Forwarded-For字段的。
客户端直接连接的首个proxy节点都叫做边缘节点(Edge),不管是网关、CDN、LB等只要这一层是直接接入客户端访问的,那么他就是一个边缘节点。

不重写-不安全的边缘节点(Edge)
边缘节点如果是透传http头中的X-Forwarded-For字段,那么这个就是不安全的,客户端可以在http中实现包含X-Forwarded-For字段值,这个值又被透传了。

#不安全
X-Forwareded-For:Client(Edge不重写,只透传),proxy1,proxy2,proxy3……

重写-安全的边缘节点(Edge)
边缘节点(Edge)如果重写remote_addr到X-Forwarded-For,那么这就是安全的。边缘节点(Edge)获取的remote_addr就是客户端的真实IP

#安全
X-Forwareded-For:Client(Edge获取的remote_addr),proxy1,proxy2,proxy3……

4. 方式二 Proxy Protocol 配置实例

适用于4层tcp转发
公有云的负载均衡LB一般都支持Proxy Protocol

查看NGINX Ingress Controller的ConfigMaps配置文档,可以找到如何配置Proxy Protocol
use-proxy-protocol
启用或禁用roxy Protocol,以接收通过代理服务器和负载均衡器(例如HAProxy和Amazon Elastic Load Balancer(ELB))传递的客户端连接(真实IP地址)信息。

NGINX Ingress Controller 作为receiver角色 Proxy Protocol配置

kubectl -n ingress-nginx edit cm nginx-configuration

在apiVersion: v1下,kind: ConfigMap上加入

data:
  use-proxy-protocol: "true"

或者直接apply附加配置

kubectl apply -f - <<EOF
apiVersion: v1
data:
  use-proxy-protocol: "true"
kind: ConfigMap
metadata:
  labels:
    app: ingress-nginx
  name: nginx-configuration
  namespace: ingress-nginx
EOF

ps: 注意需要上一层LB支持Proxy Protocol,才能这么配置,否则会导致无法链接

5. 总结

7层http头X-Forwarded-For透传
链路proxy有透传X-Forwarded-For
访问链路上多层proxy,任意一个节点不支持Proxy Protocol

4层协议Proxy Protocol透传
上下游可控都支持Proxy Protocol协议
链路proxy中丢失了http头
https反向代理http(某些情况下由于Keep-alive导致不是每次请求都传递x-forword-for

应该用那种方式?
7层用X-Forwarded-For,4层用Proxy Protocol
如果链路的边缘节点(Edge)X-Forwarded-For字段是安全的,建议用X-Forwarded-For
如果链路proxy全路径都支持Proxy Protocol,那么建议用Proxy Protocol
如果有4层tcp业务应用,那么获取客户端IP就的用Proxy Protocol
总之搞清楚了这2种方式的原理按照场景选择

5. 参考

Istio

Istio官网
Istio中文官网
Istio开源
无需太多介绍Service Mesh明日之星,扛把子,截止2019.11还有太多问题没解决
复杂性,性能让人望而却步,能上生产的是真要技术厉害,还得内心强大,项目允许

Linkerd

Linkerd官网
Linkerd中文官网

A service mesh for Kubernetes and beyond. Main repo for Linkerd 2.x.
Linkerd is a service mesh, designed to give platform-wide observability, reliability, and security without requiring configuration or code changes.

Linkerd is a Cloud Native Computing Foundation (CNCF) project.

Maesh

Maesh官网
Maesh开源

Containous(Traefik 团队)推出了全新设计的轻量级 service mesh(服务网格)工具:Maesh,Maesh 允许对 Kubernetes 集群内流动的流量进行管理,这与入流量和出流量同样很重要。
Maesh 构建在 Traefk 之上,是一个简单但功能齐全的服务网格,支持最新的服务网格接口规范 SMI,有助于与现有的一些解决方案进行集成。此外,Maesh 默认是需要开启使用的,这意味着在你决定将它们添加到网格之前,你的现有服务不会受到影响。

比较喜欢用go语言编写的东西,毕竟CNCF中绝大多数项目都是go语言编写的,看后续走向

Consul

Consul官网
Consul开源

Secure Service Networking
Consul is a service networking solution to connect and secure services across any runtime platform and public or private cloud

consul原本是个分布式kv,可以用来做配置中心,注册中心,现在官方默认的宣传语都改成了连接和保护服务

定位服务发现(Service discovery)和 服务网格(Service Mesh)

Envoy

Envoy官网
Envoy开源
ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS
ENVOY是开放源代码边缘和服务代理,专为云应用程序而设计

envoy作为服务网格中的通用数据平面, xDS API 已经成为数据平面API接口的实施标准
就好像AWS的OSS对象存储中的S3一样,成了事实标准

SOFAMson

SOFAMson官网
SOFAMson开源

SOFAMson 是一款使用 Go 语言开发的 Service Mesh 数据平面代理,旨在为服务提供分布式、模块化、可观察和智能化的代理能力。SOFAMosn 是 SOFAStack 中的一个项目,其中 MOSN 是 Modular Observable Smart Network 的简称。SOFAMosn 可以与任何支持 xDS API 的 Service Mesh 集成,亦可以作为独立的四、七层负载均衡使用。未来 SOFAMosn 将支持更多云原生场景,并支持 Nginx 的核心转发功能。

目前蚂蚁金服有大规模落地,2019年的双十一已经做了生产实践
API接口方面也是兼容Envoy的 xDS API 标准

1. 单机运行的Docker

容器化部署是现在进行时,开源应用大多数支持容器化部署
在少量机器的场景下往往采用docker cli 和 docker-compose管理,进行“单机式管理”
机器稍多点会采用Docker Swarm群集的方式,毕竟k8s稍重
如果有更多的机器情况下一般会采用k8s的方式
在个人、创业公司、小团队的场景下我们往往在多个云、家里、vps上拥有少量虚拟机服务器,这些服务器上都运行了docker实例
虽然我们也可以用公网vpn、zerotier等方式打通各个地域的机器形成一个内网,从而构建“群集”,但实际情况是没那么多带宽,从而无法“负载均衡”,所以实际的实际还是独立使用
受限制于公网带宽很小,只能独立使用
我们也拥有一些4G移动流量接入这种EDGE边缘场景的情况,这些IoT上也运行着Docker实例
那么这些NAT内网环境下的Docker实例,公网IP环境下的Docker实例,是否能集中管理?
当然可以,用Portainer就挺方便

2. 用Portainer作为Docker实例管理平台实战步骤

2.1 主节点-Portainer server主控安装

选一个7×24小时且有公网IP的节点运行Portainer server主控

docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v /data/appdata/portainer:/data portainer/portainer

9000端口为web管理界面端口
8000端口为Agent接入端口
这2个端口公网IP防火墙都必须放行

浏览器打开web管理界面
http://Portainer server主控公网IP:9000

初次访问设置一个密码,设置密码后需要选择连接docker的方式
选第一个Local 然后点击Connect
默认进入Home菜单,点击这个Local本地docker实例进入其他管理

Portainer官方安装手册参考

2.2 配置https nginx代理(可选)

如果不配置https可跳过本节
http://你的公网IP:9000 默认没有https不安全
规划一个域名用于https访问例如https://portainer.iamle.com
用nginx作为接入反向代理到 http://portainerip:9000
下面为示例nginx portainer配置(其中包含需要的websocket proxy)

# portainer.iamle.com.conf
map $http_upgrade $connection_upgrade {
    default Upgrade;
    ''      close;
}
upstream portainer {
    server 127.0.0.1:9000;
}
server {
        listen       80;
        server_name portainer.iamle.com;
        return      301 https://$server_name$request_uri;
}
server {

                listen 443 ssl http2;
        server_name portainer.iamle.com;

                ssl_certificate         ssl/iamle.com.cer;
                ssl_certificate_key     ssl/iamle.com.key;
                #ssl_session_cache           shared:SSL:10m;
                #ssl_session_timeout         10m;
                #ssl_session_tickets         off;

                ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
                ssl_ciphers         HIGH:!aNULL:!MD5:!EXPORT56:!EXP;
                ssl_prefer_server_ciphers on;

        location / {
                    proxy_set_header Host              $host;
                    proxy_set_header X-Forwarded-Proto $scheme;
                    proxy_set_header X-Forwarded-Port  $server_port;
                    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP         $remote_addr;
                    proxy_set_header X-Request-Id $request_id;
                    proxy_set_header Upgrade           $http_upgrade;
                    proxy_set_header Connection        $connection_upgrade;
                    proxy_read_timeout 60m;
                    proxy_send_timeout 60m;
                    proxy_http_version 1.1;
                    proxy_pass http://portainer;
                    break;
        }


        error_log   /data/logs/portainer.iamle.com-error.log;
        access_log  /data/logs/portainer.iamle.com.log access;

}

2.3 主节点-配置一个在NAT内网Agent客户端

前面我们已经配置好一个具有公网IP的Portainer管理控制节点
那么现在把内网(NAT、IoT)、公有云、vps等运行的Docker实例来接入控制节点管理

一图胜千言,官方介绍图

图中这个Portainer管理了2个内网的Agent
其中一个是个Swarm群集,另外一个是个单机

Portainer server上增加一个Edge Agent
Endpoints菜单 》 Add endpoint 》 Edge Agent

Name:为自定义
Portainer server URL:默认为当前Portainer server ip (如果用nginx配置了https可以使用https不加端口号)
》 Add endpoint

增加端点后出现

部署客户端agent 有2种选择 Standalone 和 Swarm
如果已经组过Swarm那么选Swarm,默认就是Standalone
先点击 “Copy command” 复制命令,在Agent客户端去执行
Public IP: 如果有可以设置,这样在以后部署了docker容器暴露的端口可以自动生成url

2.4 被管理节点-需要被管理的Docker实例客户端机

在被管理的客户端终端上执行(内网(NAT、IOT)、公网环境都可以,只要能连接上我们的Portainer server)
本例内网1台ip为 192.168.0.8的机器

docker run -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes -v /:/host --restart always -e EDGE=1 -e EDGE_ID=6ad0f1ff-6fea-4710-97e2-513ef1066fd8 -e CAP_HOST_MANAGEMENT=1 -p 8000:80 -v portainer_agent_data:/data --name portainer_edge_agent portainer/agent:1.5.1

访问 http://192.168.0.8:8000(如果有公网ip用公网ip)
打开后会有个输入框
输入上一步获得的Join token
点击Submit 出现 Agent setup OK. You can close this page. 代表完成agent接入

回到 Portainer server管理界面等待上线

点击 iamle-lan-01 等待几秒钟

这样我们就可以管理多个docker实例了

3. 贴士

  • 如果agent运行不起来,无限重启
    需要根据docker logs portainer_edge_agent 获取到的错误信息排查, 官方github issue是个好去处
    另外发现2019年10月19日16:55:01 pull 下来的portainer/agent:latest 也运行不起来 改为 portainer/agent:1.5.1正常

  • Stacks粘贴docker-compose.yml进来后一直报version版本不对
    目前只支持version 2 改为2即可

4. 参考

Portainer Edge Agent 官方发布
Portainer内网边缘节点配置说明书PDF

副标
Dockerize your Vue Application
dockerfile Vue example
docker Vue example
Vue应用docker容器化打包

docker忽略文件

.dockerignore

node_modules

www.conf

server {
    listen 80;
    #listen [::]:80;
    listen 443 ssl http2;
    #listen [::]:443 ssl http2;

    server_name h5.iamle.com web-app-h5;

    ssl_certificate      /etc/nginx/ssl/star.iamle.com.crt;
    ssl_certificate_key  /etc/nginx/ssl/star.iamle.com.key;
    #ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;
    ssl_protocols        TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers          HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers   on;

    root /var/www/html;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api {
        proxy_pass http://${API_HOST_BASE};
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root html;
    }
}

Dockerfile

# 构建阶段 vue build stage
FROM node:10.16.0-alpine  AS build-stage-node

## 配置 apk包加速镜像为阿里
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories

## 安装 一些基础包
RUN apk update \
  && apk upgrade \
  && apk add git \
  && apk add bash \
  #&& apk add nghttp2-dev \
  && apk add ca-certificates \
  && apk add wget \
  #&& apk add curl \
  #&& apk add tcpdump \
  && apk add iputils \
  && apk add iproute2 \
  && apk add libc6-compat \
  && apk add -U tzdata \
  && rm -rf /var/cache/apk/*

# ## 设置 操作系统时区
# RUN rm -rf /etc/localtime \
#   && ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

# 设置 工作目录
ENV MY_HOME=/app
RUN mkdir -p $MY_HOME
WORKDIR $MY_HOME

## 安装 全局依赖
# RUN npm install -g express

# 安装 项目依赖
COPY package.json ./
RUN npm config set registry https://registry.npm.taobao.org \
  && npm set sass_binary_site=https://npm.taobao.org/mirrors/node-sass/ \
  && npm install

# 复制vue项目文件
COPY . .

# 构建
RUN npm run build

RUN ls -lsah /app

# 打包应用
# 生产阶段 nginx
# 使用nginx镜像运行构建物
FROM nginx:stable-alpine
COPY --from=build-stage-node /app/dist /var/www/html
RUN ls -lsha /var/www/html
COPY ./www.conf /etc/nginx/conf.d/
RUN rm /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx","-g","daemon off;"]