作者介绍：田晓亮，8年软件行业经验，曾就职于三星，2012年进入云计算领域，对PaaS，DevOps，APM有深入的研究和实践经验，方案支撑近千台VM中的应用部署监控。 2016年加入华为担任架构师，负责微服务的Go语言开发框架及Service Mesh设计和落地，Go语言微服务框架已被华为5G核心网络采用，Service Mesh服务也已在华为云商用上线。 微服务架构是个难题，但解法有多个微服务是一个很大的概念，从团队组织到最佳实践似乎都有实施微服务的一些指导。我们这里只提构建微服务的架构模式，也就是关乎到你用什么样的方式来构建你以微服务架构来组织的应用系统。近些年随着微服务的火热，越来越多的团队开始进行实践，将微服务纷纷落地，也许你是从0开始，一步步地完成了单体应用向微服务的改造，让我们来看看，你解决了多少问题。 13830图1 微服务架构需要解决的问题 微服务将原本内存中函数的调用转换为网络中的调用后，就牵扯到这些问题，而任何一个分支展开，都会涉及一系列的问题。业务开发者也许真的有精力去学习架构相关的复杂问题，然而对于公司来说，真正有价值的是业务本身，让业务开发者解决这些问题需要花费浪费大量的时间精力，导致业务上线受到影响。那我们来看看是否有便捷的方式来解决业务开发者的痛点。Chassis模式 一句话来概括：一种语言开发框架来作为微服务开发的底座，封装掉复杂性，帮助你解决跨网络带来的问题，让用户聚焦在上层业务逻辑的开发。通常情况下会实现以下功能： [*]日志、Metrics、分布式追踪数据上报 [*]健康检查 [*]对接统一的配置中心实现动态配置 [*]对接注册中心 [*]实现负载均衡、熔断降级、容错、限流等保证高可靠运行的功能 现在我们来看看业界有哪些可用的Chassis框架 [*]Spring Cloud [*]ServiceComb [*]Dubbo [*]Go-Micro [*]Go-Kit 先不细去纠结微服务的严格定义，也先暂且搁置诸如“某些老旧框架是否是真的微服务框架”这类争议，从实现方式来看，上述服务化框架都是将分布式系统开发的复杂性进行了一定程度的封装然后提供了简便的开发接口供使用者调用。但是，用这种方式构建微服务还有一些问题： [*]多语言SDK支持：微服务提倡不同组件使用最适合它的语言开发，但是这需要每种语言都有开发框架，不断实现相同的功能。上面可以看到只有go语言和Java语言出现了微服务开发框架，其他语言呢？ [*]不论代码侵入程度，都需要开发者思考如何与SDK结合，并从代码层面做出改变，对于大部分开发者来说都是一个高曲线的学习过程。 [*]绑定了特定技术栈，一旦想抽身就需要一定程度上的代码改造。 [*]老旧单体应用由于无人维护，耦合程度高等问题无法进行改造，在进行微服务拆分的过程中重用遗留代码变得无比困难。而且微服务的拆分难以分步进行，需要一个相对较长的周期将系统整体拆分后才能上线。 我们知道技术演进来自于在实践中不断地将功能抽象，解耦，封装，服务化。 [*]云计算技术出现前是数据中心虚拟化，不断地实践使技术发展形成理论和新的实践。IaaS是一种封装，如今开发者与大部分技术团队不需要再学习虚拟化等技术以及如何维护数据中心。 [*]没有TCP/IP的时代，开发人员需要自己考虑网络间数据包的传输，以及网络传输代码与业务代码完全耦合的问题，如今，开发者已经不需要关心，操作系统和开发语言已经封装好网络传输过程。 是否也可以把语言框架提供的能力抽象，成为服务？ 在引入后面内容前，我先介绍下SideCar模式SideCar模式 [*]在近些年受到Kubernetes对容器调度方式的启示而日渐受到关注的一种功能部署模式，也是一种微服务的设计模式。 [*]主要利用了一个Pod中的容器可以共享存储与网络的能力，或者说在一个Host中，这个模式也同样适用。 [*]一般分为应用容器和工具容器，工具容器可以重用。 一个典型的场景如下: 13831图2 SideCar典型场景 应用容器与日志同步工具在同一个Pod下，共享存储卷，应用程序生成的日志文件会由日志同步工具收集并发送到类似kafka，elasticsearch这样服务中。在这样的架构下我们获得了什么呢？ [*]以容器作为基础打包单元，那么就可以分给不同的团队进行开发测试 [*]Sidecar容器可重用，可以与不同的容器结合 [*]以容器作为错误边界，使服务能够独立开发和测试，比如应用服务在没有日志保存功能的情况下也可以独立运行 [*]独立回滚与更新（但需要考虑复杂的版本组合，建议使用语义版本管理对版本进行控制） 在这个模式的基础之下，我们引入了Service mesh。Service Mesh 新瓶中的那一杯老酒什么是Service Mesh Service mesh最早是由Linkerd给出的定义，我们来看看英文版:[indent]A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.[/indent]大致的意思如下： [*]一种基础设施层服务，服务间的通信通过service mesh进行 [*]可靠地传输复杂拓扑中服务的请求，将它们变成现代的云原生服务 [*]一种网络代理的实现，通常与业务服务部署在一起，业务服务不感知 [*]一种网络模型，在TCP/IP之上的抽象层，TCP/IP负责将字节码可靠地在网络节点间传递，Service mesh则复杂将服务间的协议请求可靠地在服务间进行传输。它们不关心传输的内容 [*]TCP/IP仅仅负责传输，但Service mesh可对运行时进行控制，使服务变得可监控，可管理。 为什么使用Service Mesh [*]无需考虑每种语言都要解决的问题 [*]对业务代码0侵入，开发者无需关心分布式架构带来的复杂性以及引入的技术问题 [*]对于不适合改造的老旧单体应用，提供了一种接入分布式环境的方式 [*]微服务化的进程通常不是一蹴而就的，很多应用选择了演进的方式，就是将单体应用一部分一部分地进行拆分。而在这个过程中，使用Service Mesh就可以很好地保证未拆分的应用与已经拆分出来的微服务之间的互通和统一治理 [*]开发出的应用既是云原生的又具有云独立性，不将业务代码与任何框架，平台或者服务绑定 依然没有银弹，我们来看看Service mesh解决不了的问题 [*]无分布式事务方案 [*]Service Mesh组件代理请求转发，会在一定程度上降低系统通信性能 [*]没有Event Driven的框架 [*]侵入式框架以源码和业务代码结合，有较强定制和扩展能力，Service mesh相对不易定制扩展 [*]在运行时，依赖单独的Service Mesh代理，多了一个故障点。整个系统的运行和运维也强依赖于Service Mesh组件的能力 Service Mesh的实践历程和设计思路Service Mesh在华为公司内部的发展历程 第一代： 基于NGINX的微服务代理该平台是华为公司内部使用的微服务开发部署运行平台，开发于2013年，用于公司内部某电信业务。在这个业务系统中有大概400多个左右的微服务，实例数量根据局点大小不一样，一个典型的部署为800多个左右实例的规模。整体架构如下：13832图3基于NGINX的微服务代理的平台整体架构 其中的Internal Router组件用来给开发者解决分布式架构中的可靠传输问题： [*]使用高性能nginx及其相应的lua扩展作为Internal Router，将Http服务接入 [*]使用RouteAgent负责注册/注销实例，更新IR的实例信息 [*]使用zookeeper作为注册中心 [*]以Per-Host的方式部署在微服务所运行的环境中 用这种方式构建的微服务环境已经在超过200个局点的生产环境下得到使用，整体运行情况良好。但是随着时间的推移，当业务对敏捷的要求越来越大，而且容器的使用也越来越广泛，这种方式带来了一些问题： [*]使用lua脚本扩展注册发现，负载均衡，熔断，降级，容错，限流，但lua的扩展性有一定的局限 [*]用RouteAgent负责服务的注册以及每个NGINX上服务实例路由的刷新，RA需清楚地感知本节点上的微服务都有哪些，但是使用Kubernetes做容器调度后微服务和实例的分布信息在K8S里面集中记录 [*]容器的IP更多，变化更频繁，使用RouteAgent刷新NGINX路由的方式会导致NGINX服务受到影响，频繁的路由刷新导致业务运行收到影响 [*]当IR服务失败后，整个Host中的服务都会丢失，无法与外界建立联系 为了解决这些问题，出现了第二代的解决方案： HSA Sidecar13833图4 HSA Sidecar设计 HSA是华为内部的一套微服务开发框架，它提供了注册中心，配置中心，java开发框架，以及SideCar等组件 [*]基于Java 微服务框架开发,非侵入式通信方式，支持RPC与Http，提供SOAP协议转换，但会导致性能下降 [*]与微服务部署在一个Pod中即Sidecar模式 [*]作为代理服务，使微服务自动获得注册发现，负载均衡，熔断，降级，容错限流等功能 [*]占用资源很高，一个应用实例一个Sidecar实例的部署方式，会占用过高资源 虽然第一代的问题解决了，但是第二代的Sidecar在性能和资源占用上有很大的问题，在少量的技术项目中试用后，因为资源占用过高的问题无法在大规模环境中推广使用。CSE Mesher介绍 Service Mesh 模式的一种实现。基于自研的Go语言微服务框架（该框架即将开源）开发，使用ServiceComb注册中心（已经开源）与CSE配置中心，以Sidecar的方式部署在微服务所运行的环境中，也可以PerHost模式运行。在用户数据面使用，提供VM部署、公有云部署、容器部署，占用资源小（闲置10多M，并发运行时30多M）。基本能力 注册发现注册中心为插件化模块，目前对接了ServiceComb、Service Center，未来还会有更多的系统对接进来 13834图5 可插件化的注册中心 路由规则管理根据预定义的路由规则对请求进行引流 [*]支持权重引流：比如将5%的流量引到购物车的1.0版本，20%引到2.0版本 [*]可根据服务请求特征进行引流：比如消费者的请求中Header带有的用户名为Json，那么可以引流到某个服务的特定版本中 [*]利用读写锁，路由可在运行时更新，并且不丢失请求 协议转换与不同框架的对接与统一治理使用标准OpenAPI契约，可以实现Dubbo RPC协议与Http协议的互转，用于透明地接入遗留的Dubbo应用并对遗留应用进行统一的服务治理使用负载均衡与重试策略 [*]负载均衡器会调用注册中心插件进行实例查询 [*]在查询中的实例里表中，使用Filter进行过滤 [*]将过滤后的实例传入Strategy中进行实例选择 [*]默认提供RoundRobin Random，会话粘滞策略 [*]具备容错能力且加入Backoff算法，增强网络稳定性 使用熔断降级熔断使用的断路器对一个执行过程进行包装，断路器负责监控维护每个执行过程的状态、结果、错误、超时。当达到一定阀值时就会熔断，并触发降级。以这样的机制来保护服务提供者，不会出现级联的雪崩式错误。使用限流提供了消费者端与提供者端限流用户可以通过配置来限制每秒只允许多少个请求被发出或者接受对接监控Metrics：提供了主动上报到CSE Dashborad的方式。也可与华为公有云APM，Prometeus对接 分布式追踪：对接Zipkin架构设计 整体架构13835图6 CSE Mesher整体架构 Mesher背靠CSE组件，使用微服务引擎中的服务中心与配置中心等服务作为控制面，Mesher与业务代码部署在一起运行在数据面数据面13836图7 CSE Mesher数据面 即Service mesh组件本身，对所有请求进行处理，它有以下功能 [*]发现服务 [*]执行路由策略 [*]负载均衡 [*]拦截所有请求并处理，转发 [*]认证鉴权 [*]生成监控数据 控制面13837图8 CSE Mesher控制面 为管理人员提供统一的管理入口，为所有运行的mesher提供配置下发但不会介入服务请求 [*]注册中心：服务上下线感知 [*]下发配置：使用Web Console对运行时更改，负载均衡，熔断容错，限流等策略 [*]对接监控服务与监控页面 [*]调度引擎：这里并非是微服务引擎提供的组件，是可选组件，这个组件负责拉起服务，维护实例数，在资源池中调度分配实例，这里推荐使用ServiceStage负责实例的生命周期管理 运行场景 不同的部署方式与业务服务部署在一起有3种运行模式1.仅消费者使用Mesher，提供者为使用ServiceComb开发框架的服务或者裸服务，下图为例:ServiceC为裸服务,它既不用mesher也不用SDK，那么起码它需要自己注册到服务中心中，供其它服务发现，否则无法进行访问。13838图9 仅消费者使用Mesher 2.消费者与提供者均使用Mesher13839图10 消费者与提供者均使用Mesher 以这种方式运行的服务可以使用透明TLS传输，并且拥有了服务端限流3.提供者使用Mesher，消费者A使用ServiceComb SDK进行开发可直接发现服务B，但是消费者C作为裸服务需要自己发现服务B 13840图11 仅提供者使用Mesher 运行时请求处理消费者端请求 13841图12 消费端发送请求流程 上图为例：SockShop服务将mesher作为代理并使用地址http://order/list访问订单服务 [*]Destination Resolver 目标微服务名解析，支持插件定制，可根据请求特征决定微服务名是什么 [*]Source Resolver 将IP地址解析为微服务实体信息 [*]路由决策 根据Source和Destination 信息决定最终要访问哪个微服务 [*]处理链 处理链为可随时**或减少的模块，在这里Mesher实现了限流，熔断，降级，负载均衡等功能 [*]传输层 最终请求通过传输层发送到目标微服务实例 提供者端接收请求 13842图13 提供者端接收请求流程 上图为收到远程请求后的处理过程 [*]服务端接到请求，将IP地址解析为微服务信息 [*]进入处理链，这一步并没有负载均衡而是直接使用local selection 进行处理 性能对比 13843图14 Mesher1.0、Istio 0.1.6 (Envoy)、Linkerd1.1.3性能对比 在性能对比后，我聊下自己的看法 [*]Linkerd 作为java实现的service mesh，受到资源占用的拖累，考虑到数据中心成本，不适合作为SideCar和应用部署在一起，相信它的主要场景在于Kubernetes Ingress和Daemonset，并且由于只有数据面，需要和别的生态系统对接获得控制面能力，否则，业务团队又要考虑自己开发控制面。 [*]目前Istio已知问题是每次请求都要调用一次Mixer API来传送metric数据，相信未来版本能够解决，但不能满足我们内部的产品节奏。 [*]作为对比，Mesher通过Channel与Go协程机制主动上报metric数据，以此获得更高的性能，机制如下：模块将数据传送到channel中，协程收到信号并主动上报，在这样的机制下开启监控，性能只有百分之2左右的下降。 13844图15 Metric数据上报机制 一些思考以及未来华为为什么开发了自己的Service Mesh [*]Istio的性能问题没有解决，Envoy每次访问请求Mixer API导致性能下降 [*]Istio强绑定Kubernetes平台（1.7.4+），虽然有着良好的架构，对接不同平台不是问题但需要时间，Mesher贯彻不将开发者绑定到任何框架和平台的理念 [*]从成本角度讲Linkerd并不适合做SideCar部署，JVM资源占用较多 [*]过去在ServiceComb中的积累：Service center，Config center，Go SDK，Governance UX已经提供了大量技术积累，可用于做Mesher的控制面。 [*]既然非侵入式与侵入式都不是银弹，侵入式（ServiceComb Java）与Mesher提供的非侵入式框架的无缝结合，混编就变得有价值了，开发者可以因地制宜，选择适合自己的方案。 Service Mesh是个大舞台 现在已经出现了越来越多的Service mesh实现： [*]数据面：Linkerd，Nginx，Envoy [*]控制面：Istio Linkerd 是在2016年出现的，Envoy在6个月后出现，不过Envoy已经在2015年就商用了。这两个项目也是最有名的Service Mesh。Istio在2017年5月出现，它提供了控制面，并使用Envoy作为数据面的Service Mesh。目前已经开始有些Service Mesh提供者宣布与Istio进行集成，比如Linkerd和Nginx。这意味着控制面与数据面是解耦的，任何的控制面都可以和数据面Service Mesh进行集成。CSE Mesher也会考虑与Istio进行集成，成为除了Envoy之外的另一种数据面选择。实际上在开源项目之外，很多公司内部也早已用类似的方案进行自己系统的构建，各自有各自的特点用来解决自己的实际问题。Istio成为CNCF里面一个被认为是“Kubernetes之后的第二个爆款”是有理由的，它提供了一种从平台的角度解决应用架构的思路，进一步简化了应用的开发。我们也相信在这个大舞台上会有更多的方案出现，而这些方案的出现也会让微服务和Cloud Native应用的构建方式有更多地选择。我们团队也已经基于多年的实践经验将当前的内部Service Mesh方案包含在华为云的“微服务引擎”中，开放给外部用户使用。希望可以作为一种参考，可以给正在选择实施微服务架构方案的读者一些帮助。

在docker中可以使用docker save命令将镜像保存为本地文件，有如下两种方式：1. docker save imageid，例如： 11574 2. docker save imagename:tag，例如： 11575 如果要使用docker save命令保存下来的文件在SWR前端界面上传的话，需要使用方法2来保存文件。 如果使用方法1保存的文件在前端上传的话，前端会提示镜像格式不合法。 原因：使用方式1保存的镜像中manifest.json文件中的Repotag字段为NULL，这样在前端上传后，SWR后端无法解析 出该镜像到底属于哪个仓库，导致上传失败。方法2保存的镜像中manifest.json文件中的Repotag字段则会保存仓库地址和tag信息， 这样在前端上传就不会出现问题。

容器作为一种轻量级的虚拟技术，使应用程序认为他们自己有一个专门为他们服务的完整的操作系统，其帮助开发人员实现了更简单的封装、快速的程序部署、减少程序的环境依赖并支持横向的可扩展性。然而这种通用包装服务模式，其将每个容器视为“服务单位”，大大降低了程序的透明度和可审计性， 那么我们如何在不损失容器带来的优点情况下保证容器及其内运行程序的安全性？Aqua Security做为专门为容器技术设计的安全性产品，给予企业容器虚拟环境从开发到生产整个周期的安全性，减少IT安全部门与开发部门的协调沟通成本，并对容器内部的应用程序活动具有高可见性，允许组织检测和防范可疑活动和实时攻击。其同时还通过以下几点来提高企业内部容器虚拟环境的安全性：l 定期同步Registry内的images并进行安全扫描，可根据预先设置的规则，比如CVE总体威胁级别、CVE评分等，自动禁用威胁image。l 所有的威胁扫描条目都与云端同步，保证实效性。l 可自定义image镜像执行的白名单和黑名单，也允许用户自定义Base OS image （操作系统模板镜像）。l 可与Jenkins等常用CI/CD程序整合，在自动打包image时即进行威胁扫描。l 可查看Host主机上所有运行及停止状态容器的详细信息，包括威胁漏洞、环境变量、挂载卷、已安装包、容器配置等。l 对Host及容器内部都有详细的活动日志记录。l 可针对容器运行状态设置自定义的安全规则，如只读文件、运行容器的OS用户、执行命令、挂载盘、特权参数、环境变量参数等，保证容器运行时的合规性、安全性。l 可自主学习相关容器运行时的操作，根据学习到的结果自动生成安全规则赋予容器。l 可针对Host主机的操作系统用户定义不同角色，实现用户docker相关命令的颗粒化权限管理。l 可针对容器与容器、容器与Host、Host与其他节点之间设置网络防火墙策略，实现Docker容器虚拟环境的网络监管。l 可将内部数据导入到Splunk、ArcSight等其他日志收集程序进行分析、联动l 集中化管理容器运行时的敏感信息（Secret），并以环境变量的方式注入容器。注入后密码信息只能通过容器内部获取，无法通过外部Inspect等命令得到。同时Aqua Security也支持和CyberArk、Azure Key Vault、Amazon Key Management Store等的整合，将这些敏感信息储存在这些第三方程序内并调用。 http://www.aqua-sec.com.cn 如果有需要请直接联系我们, [email]ChinaSupport@edvancesecurity.com[/email], 电话：400-099-2608。

本帖最后由 码小玩 于 2017-12-29 14:22 编辑一、GitHub 发布开源指南 GitHub 在今年2月14日的发布了声明，宣布一个以开源方法论为主旨的全新站点诞生，旨在为开发者和企业提供开源的软件工程方法论。一时之间，受各路追捧。开源之道也是第一时间，以布道汉语世界为己任，有幸成为了简体中文的维护者。地址是：开源指南。 尽管从某种程度上讲，我们都是开源的受益者，但是，开源依旧需要更多的人参与进来，而开源指南无疑能够帮助人们少走弯路，正确的认识开源，在为开源做贡献的同时，收获自己想要的。对于个人也好，企业也罢，都是获利的一方。还在犹豫什么?放手去干吧! 二、Docker 公司商业化，切出项目Moby Docker 作为PaaS平台dotCloud的衍生品，以重新包装Linux的容器而风靡开发者圈，完全重新定义了软件的交付方式。自2013年第一个版本发布起，发展非常迅速。不仅吸引了众多IT大鳄的青睐，而且很快成为了Linux容器的生态事实上的标准。 但是，Docker本身的商业化道路一直都备受关注，正当很多基于Docker的创业公司和产品层出不穷，急着变现的时候，比如国内很多基于容器的云公司，如红帽的OpenShiftV3的PaaS平台，以及公有云AWS、Azure、GCE等都似乎利用容器赚了个盆满钵满，然而，很多人开始为Docker公司着急了，害怕他成为当年Sun公司的Java，大家都在赚钱，唯独最初的原创者找不到合理的模式。 有资本界的朋友是如此评价Docker的： Docker走出如此的路数一点也不意外，从微软的收购未果而言，说明后面已经有资本和运营的人在预估了，一定是比微软更高的价格来计算的。这说明有业界的高手在帮助Docker的商业化，在恰当的时间做恰当的事，是一个企业能够成功的标志性事件。 三、Google 针对开源专门设立了站点Opensource.google.com Google 似乎正在改变自己在业内的高冷形象，从 Kubernetes 的社区运营，再到今年即将参与RedHat Summit 2017，乃至这次新开源站点的建立，都在应验着开放战略，试图扳回在云计算市场的失利。再比如Spanner的服务、以及免费为开发者提供资源等具体的产品和服务。其中一定有商业因素的考量，但我们始终认为Google的信条，以及他对开源独特的理解，所以宁愿相信他的情怀：Google 开源项目部不仅仅是让Google的软件变得更好——他们更加热衷于通过开源改变世界。 四、GitHub 发布2017 开源调查 GitHub联合学术界、开源社区、以及软件界，搞了一次大规模的调查。目标一部分来自于GitHub上的仓库，超过3800个，随机询问了5500个开发者，而在其它的开源社区则是定向的500个调查。 结论值得所有人深思： 文档的呼声最高，却通常是最被忽略的那个 负面的活动虽然不频繁，但是却最容易被放大 女性的参与相对非常的少 使用和参与开源的绝大多数来自商业公司雇员 人们在选择软件时，默认会优先采用开源 五、LinuxCon正式入华，Linus承诺会每年来中国一次 Linux基金会的会议主办历经坎坷，终于顺利的完成了自己的首秀，为各位开源界的人们交出了满意的答卷。这对于本土是有着极具影响力的!其对于社会、业界的影响是非常之深远的。 在最后的关闭短暂讲话中，Jim Zemlin说到，Linux基金会承诺超过十年将落地中国、扎根中国、支持中国的开源事业发展，并和大家说“我们明年见，明年Linus仍然会来。” 六、Linux基金会发布企业开源指南 既然是企业，就需要有企业的思路，企业的精髓在于管理，在于指导。正如其副标题所言：“运营开源项目办公室 ”，毋宁说开源需要系统的逐步的进行，对于企业来讲，涉及到的部门颇多。因为它直接关系到企业的文化。 开源的重点并不在于方法论，而是在于人们的认知，如果人们的思维方式仍然停留在上个世界8、90年代微软、甲骨文崛起时期，那么开源基本上很难施行和实践。在庞大的经济环境面前，开源确实仍然没有浮出水面被大众所认知，至少本土的现实情形是如此。但是如果没有方法论，事情会是一筹莫展。 七、中国开源年会第一次全程以开源领导力为议题组织会议 7967 作为本土草根组织的会议，第一次以方法论、开源治理为话题，成功举办了以开源领导力为议题的会议，内容涉及本土顶级开源项目孵化的故事等。 这次大会总共1,108人次到场，在线视频观众总计2,284人，参加了接近60位大牛讲师的5场主题演讲，45场分会场演讲，6场动手训练营，5场嘉宾对谈/观众问答，而来自五湖四海的50位可爱的志愿者们，热情地为讲师与观众们服务。 八、CNCF的崛起 就在上一周，作为SaaS的大佬——SalesForce加入了CNCF，这家Linux基金会下属的非盈利组织，最初由Google的贡献的Kubernetes项目而生，渐渐的形成了云原生应用、微服务的生态系统。三大公有云厂商AWS、Azure、Google均号称原生支持。连传统厂商RedHat的OpenShift直接切换，直接革了CloudFoundry的命。如此成功仿佛坐上火箭般的开源项目，前几年有OpenStack。 九、微软成为GitHub企业排名榜首 在GitHub今年的宇宙大会上总结了一些内容：GitHub 2017的数据，微软，这家曾经视开源为毒瘤的公司，以实际行动证明了自己拥抱开源的决心。当然，就更不用提其在Azure云平台上发布的各种基于开源项目的产品和服务了。 十、Ubuntu 将桌面系统换回Gnome Ubuntu有着无与伦比的全球开发者和用户社区，产品涉足云平台、服务器、桌面、移动端、项目托管、部署平台等，但是几年下来，开始渐渐的有些力不从心，上个月大变动。那么从社区运营、参与、开源软件上下游等视角来分析一下，它犯了那些不应该犯的错? Unity的出现，而其它Linux桌面是推动Gnome3的，这导致了Ubuntu和整个其余的Linux产生了巨大的分歧。和Launchpad、Juju一样，Ubuntu再次将自己的打包者和开发者陷入了孤立，没有上游社区的支持来稳定供应链。这也就意味着，Canonical开发人员再次成为软件的唯一开发者和维护者，这进一步压缩了Canonical欲扩而不能的资源。 十一、Linux完全征服超算 全球公有云上运行的负载有90%是Linux操作系统，在嵌入式市场的占有率是62%，而在超算的市场占有率更是达到了99%，还有，它运行在世界上超过82%的智能手机中，也是所有公有云厂商的主要支撑服务器(90%)。 但是从技术和工程、协作、治理的角度讲，Linux 内核是人类史上的奇迹。其背后蕴含的哲学、方法都是我们值得挖掘的宝库。 十二、Linux Journal在经营23年之后，选择退出历史舞台 这是一个不怎么为人所知的围绕Linux相关技术的杂志，在前不久宣布停刊。但是我认为这是一件值得庆贺的事情，说明Linux已经是默认的信息技术的基石。 Linux成为IT从业人员的常识，GitHub的项目多达6千7百万，开源的时代已经降临。 结语 今年我听到的对于开源总结的最好的一句话作为本文的结尾，也是对开源之道未来展望。 “开源让中国与世界更加同步。” ——吴晓敏（Forrest大中华区副总裁）

本帖最后由 yd_14752044 于 2017-11-1 15:32 编辑Docker 是一个开源的容器引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。开发者和系统管理员在笔记本上编译测试通过的容器可以批量地在生产环境中部署，包括 VMs（虚拟机）、bare metal、OpenStack 集群、云端、数据中心和其他的基础应用平台。容器是完全使用沙箱机制，相互之间不会有任何接口。本文将介绍 Docker 的九种用法，它们可提升你的生产力。 1. 本地依赖(Local Dependency) 你需要在本地系统快速尝试 Magento，或者为一个项目使用 MySQL？还是希望尝试大部分开源项目？那就使用 Docker 吧，它将帮你节省大量时间。Docker 能提升开发者的开发效率，让我们快速搭建开发环境。 开发环境的机器通常内存比较小，此前使用虚拟的时候，经常需要为开发环境的机器加内存，而通过 Docker 可以轻易的让几十个服务在 Docker 中跑起来。 2. 搭建环境(Build Environment) 如果你希望构建源码，但发现没有准备好合适的环境。那么使用 Docker 是一个值得考虑的方案。毕竟如果使用传统的方法一个一个地安装软件，一大堆软件安装下来确实十分费时间，使用容器技术省时省力，何乐而不为？ 它能让你将运行环境和配置放在代码中然后部署，同一个 Docker 的配置可以在不同的环境中使用，这样就降低了硬件要求和应用环境之间耦合度。这里有一个值得一看的例子： docker golang builder。 3. 微服务(Microservices) 你在使用微服务吗？微服务架构 —— 将一个整体式的应用拆分成松耦合的单个服务。 那不妨考虑一下 Docker，你可以将每个服务打包为一个 docker 镜像并使用 docker-compose 来模拟生产环境(checkout docker networks)。最开始实践的时候可能会比较费时费力，但长远地来看，最终将产生巨大的生产力。 4. 自动测试(Automated testing) 试想这样一个问题，如何编写自动化的集成测试用例，这些测试用例无需花很长时间来开始运行，使用者也可轻松管理。 这里不是指在 Docker 中运行测试用例，而是将测试用例与镜像紧密运行在一起。当你针对一个 docker 镜像编写测试用例时会有一个很大的优势。下面简单介绍一下我的测试流程：运行两个 docker 镜像(app + db)，在 MySQL 启动时加载数据，并在 app docker 上使用 API。可查看此脚本以获取快速的示例。 5. 部署过程(Deployment process) 你可以使用 docker 镜像进行自我部署。许多主流的主机提供商都支持托管 docker，如果你拥有一个具有 shell 访问权限的专用节点/vm，那么事情将变得更容易。只需要设置好 docker，并在你想要的端口上运行你的镜像即可。 6. 持续部署(Continuous Deployment) 都说 Docker 天生适合持续集成/持续部署，在部署中使用 Docker，持续部署将变得非常简单，并会在进入新的镜像后重新开始。 关于这个部分的自动化工作，现在已经有许多方案以供选择，Kubernetes 就是一个耳熟能详的名字。Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 7. 多租户环境(Multi-tenancy) Docker 有意思的一个使用场景是在多租户的应用中，它可以避免关键应用的重写。如果你将应用程序服务公开给多个租户（租户指一组用户，例如组织），使用单租户方案设计的应用程序如果用上了 sub-domain + docker 可以快速获得提供多租户的服务。 关于这个场景的一个例子是为物联网的应用开发一个快速、易用的多租户环境。这种多租户的基本代码非常复杂，很难处理，重新规划这样一个应用不但消耗时间，也浪费金钱。使用 Docker，可以为每一个租户的应用层的多个实例创建隔离的环境，这不仅简单而且成本低廉，当然这一切得益于 Docker 环境的启动速度和其高效的 diff 命令。 8. 来自一台机器的多个 APP(Multiple apps from one machine) 这与上面提到的微服务有些联系，但即使你没有使用微服务，只是提供服务，Docker 仍可以很好地管理单个机器上的所有服务。你应该使用文件夹挂载来为每个基于数据的 docker 镜像保留数据。 9. 扩容 QPS(Scaling QPS) Docker 通过创建另一个容器来帮助你轻松地进行水平扩展。如果遇到巨大的高峰流量，Docker 可以帮助你解决问题 —— 只需添加更多的机器并增加负载均衡器背后运行的容器数量。 还有文章没提到的关于 Docker 的应用场景？欢迎你和大家一起分享~

本帖最后由 小白 于 2017-10-26 14:18 编辑 上传镜像镜像制作完成后，您需要将镜像上传到CCE的私有镜像仓库，供创建应用时使用。为了上传镜像，需要使Docker客户端能够访问私有镜像仓库，那么您需要配置本地Docker客户端。 说明：本节只介绍在常用的Ubuntu系统（Ubuntu、Debian等）、CentOS系统（CentOS、RedHat等）、OSX、Windows 10系统上的设置方法，其余系统的设置方法请参考https://docs.docker.com/datacenter/dtr/2.0/configure/config-security/设置。 前提条件 [*]用户已注册公有云账号。 [*]安装了Docker 1.10.0或以上的版本。您可以在https://www.docker.com/下载Docker，安装指导请参见https://docs.docker.com/。 [*]Guestbook应用需要上传的frontend、redis和redisslave三个镜像已经制作完成并已传至上传镜像所在服务器。 [*]AK/SK证书已经上传到CCE上。 操作步骤 [*]连接私有镜像仓库。 说明：认证证书默认有效时间为一年，如果超时请重新下载。 [list=a] [*]单击“镜像仓库 > 上传镜像 > 下载认证文件”，下载证书文件。图1 私有镜像 证书文件“dockercfg.txt”保存在系统默认目录下。 说明：由于不同浏览器的默认文件处理方式不同，请根据系统提示，保存证书文件。 证书文件示例：{"auths":{"117.78.33.214":{"auth":"X2F1dGhfdG9rZW46YTljYWI4YmNiZWJjNGNmMDhjZjkwODI1ODQxYzBhZWItVUdGS1Y4VVlVR09KSUZRVEw0VUwtMjAxNjA2MTcxODAzNTgtZTc1ZmJiNmFlNTIwYjA3ZTA4ZjY5OThiOGEyZGFiNTJiYjgyNWI4YjRhNDQ4YzMwNjRmNDBiZGI5OWE3NDQxMA==","email":""}}}其中，“117.78.33.214”所处字段即为镜像仓库的地址，此处仅为示例，请以实际值为准。 [*]以root用户登录安装了Docker的机器，执行如下命令，进入“~/.docker”目录。 说明： [*]您也可以使用其他用户登录，但是该用户必须拥有执行Docker的权限。 [*]如果docker服务器上没有“~/.docker”目录，请执行mkdir -p ~/.docker命令创建。 [*]如果您使用Windows操作系统的机器，请进入“%USERPROFILE%/.docker”目录配置config.json。 cd ~/.docker[*]执行vi config.json命令，将dockercfg证书文件内容拷贝到“config.json”文件中。 [*]配置Docker参数，允许Docker访问私有镜像仓库。（以docker 17.05.0-ce版本为例） 说明：不同版本的Docker在不同操作系统下配置不同，关于配置Docker参数的详细信息，请参见Docker社区文档https://docs.docker.com/datacenter/dtr/2.0/configure/config-security/。 [*]Ubuntu14.04系统下：vi /etc/default/docker把 1.a中获取的镜像仓库地址加到 “DOCKER_OPTS”中的 “--insecure-registry”后面，如下加粗字体所示。# Use DOCKER_OPTS to modify the daemon startup options.DOCKER_OPTS="--insecure-registry 117.78.33.214" 执行如下命令重启docker。service docker restart [*]Ubuntu 16.04系统下：请将镜像仓库地址添加为/etc/docker/daemon.json文件中insecure-registries的参数值。{"insecure-registries": ["117.78.33.214"]} 执行如下命令重启docker。systemctl daemon-reloadservice docker restart [*]CentOS系统（CentOS、RedHat等）下（以CentOS 7为例）：执行如下命令获取Docker配置文件的路径。service docker status在Loaded开头那行后面即为Docker的配置文件，如下加粗字体所示。# service docker statusRedirecting to /bin/systemctl status docker.servicedocker.service - Docker Application Co ntainer Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled) Active: active (running) since Sat 2017-05-20 10:41:14 CST; 16min ago Docs: https://docs.docker.com编辑Docker配置文件，把1.a中获取的镜像仓库地址加到“ExecStart”开头那行“--insecure-registry”后面，如下加粗字体所示。vi /usr/lib/systemd/system/docker.service把1.a中获取的镜像仓库地址加到“ExecStart”开头那行“--insecure-registry”后面，如下加粗字体所示。[Service]Type=notifyExecStart=/usr/bin/dockerd --insecure-registry 117.78.33.214执行如下命令重启docker。systemctl daemon-reloadservice docker restart [*]OSX系统下：打开Docker GUI配置界面，在Daemon页签“Insecure registres”下添加镜像地址，如下图所示。添加完成后重启docker。 [*]Windows 10系统下：打开Docker GUI配置界面，在Daemon页签“Insecure registres”下添加镜像地址，如下图所示。添加完成后重启docker。 [*]OS Yosemite 10.10.2或更早，Windows 7及更早：使用“docker-machine ssh”或“boot2docker ss

本帖最后由 那个逻辑先生 于 2017-10-12 10:28 编辑本文的目的是理解容器开发在目标环境中部署的端到端流程，并列出这些操作所需的 Docker 命令。 1. 介绍整个流程包括使用代码、依赖软件和配置来开发容器映像，在开发环境中运行和测试容器，将容器映像发布到 Docker Hub，以及最后的部署和在目标环境中运行容器。 本文假设您已经在开发和目标环境中安装了 Docker 引擎。有关安装说明请参阅 6.3。 2. 开发容器映像 在构建容器映像之前，你需要创建一个 dockerfile，它包含了所需要的信息。请参考这里来编制一个 dockerfile。 2.1 构建 Docker 容器 2745 这个命令会使用当前目录下的 Dockerfile。如果 dockerfile 使用了其它文件名或者放在其它位置，可以使用 -f 参数来指定 dockerfile 的名称。“docker build” 命令会构建容器映像，这个容器映像的名称由 “-t” 参数指定。 2746 2747 2.2 Docker 映像命名规范 如果你只是在本地使用，那么你可以随意为 Docker 容器命名。它可以像上面那边简单的命名为“myApp”。但是如果你想将映像发布到 Docker Hub，就需要遵循特定的命名规范。这个规范有助于 Docker 工具将容器映像发布到正确的命名空间和仓库。 格式如下：2748现在我们按上面的规范来构建 Docker 映像：2749我们可以使用“docker tag”命令从已经存在的映像创建新的映像。“docker tag”命令会在下面说明。 2.3 列出 Docker 中所有映像 2750 2751

原文出处：开源中国PyCharm 2017.2.3 已发布，该版本包含以下改进： [*]支持 Docker Compose v3.0 和 v3.1 files (3.2 和 3.3 版本尚未支持，希望在 PyCharm 2017.3 中能实现) [*]Python 控制台用于控制 Docker 和 Docker Console（由于 Windows 的防火墙问题，现在仅在 ma** 和 Linux 上可用，有关解决方法，请参阅 PY-25341） [*]为 Docker 和 Docker Compose 生成更快的骨架 [*]各种代码的检查问题已经解决 详情请参阅发布说明：https://confluence.jetbrains.com/display/PYH/PyCharm+172.3968.34+Release+Notes官方资讯：https://blog.jetbrains.com/pycharm/2017/09/pycharm-2017-2-3-out-now/PyCharm是由JetBrains打造的一款Python IDE。PyCharm具备用于一般IDE的功能，比如， 调试、语法高亮、Project管理、代码跳转、智能提示、自动完成、单元测试、版本控制。另外，PyCharm还提供了一些很好的功能用于Django开发，同时支持Google App Engine，更酷的是，PyCharm支持IronPython