閱讀本文約花費: 1 (分鐘)Ubuntu/CentOS Docker使用阿里云镜像加速器 查找服务的路径：阿里云后台 >> 搜索【窗口镜像服务】>> 镜像中心 >> 镜像加速器 1. 安装／升级Docker客户端 推荐安装1.10.0以上版本的Docker客户端，参考文档 docker-ce 2. 配置镜像加速器 针对Docker客户端版本大于 1.10.0 的用户 您可以通过修改daemon配置文件/etc/docker/daemon.json来使用加速器 Tags: Docker, Shell, Ubuntu, 阿里云
閱讀本文約花費: 18 (分鐘)Docker Engine是一种开源容器化技术，用于构建和容器化您的应用程序。Docker Engine通过以下方式充当客户端-服务器应用程序： 具有长时间运行的守护进程的服务器dockerd。 API，用于指定程序可以用来与Docker守护程序进行对话和指示的接口。 命令行界面（CLI）客户端docker。 CLI使用Docker API通过脚本或直接CLI命令控制或与Docker守护程序进行交互。许多其他Docker应用程序都使用基础API和CLI。守护程序创建和管理Docker对象，例如映像，容器，网络和卷。 docker常用命令 中文版 $ docker –help Usage: docker [OPTIONS] COMMAND A self-sufficient runtime for containers一个可以独立运行的容器 Options:–config string 客户端配置文件的位置 (默认 “/home/mrdede/.docker”)-c, –context string 用于连接守护进程的上下文的名称 (使用“DOCKER上下文使用”覆盖DOCKER主机env变量和默认上下文设置)-D, –debug 启用调试模式-H, –host lis…
閱讀本文約花費: 5 (分鐘)Clair 是 CoreOS 最近发布的一款开源容器漏洞扫描工具。该工具可以交叉检查Docker 镜像的操作系统以及上面安装的任何包是否与任何已知不安全的包版本相匹配。漏洞是从特定操作系统的通用漏洞披露（ CVE ）数据库获取。该工具当前支持的操作系统包括 Red Hat 、 Ubuntu 和 Debian 。 通过从镜像文件系统中抽取静态信息以及维护一个组成镜像的不同层之间的差异列表，可以大大减少分析时间，而且不需要实际运行可能存在漏洞的容器。如果镜像所依赖的一个靠下的层存在漏洞，那么该镜像就会被识别为有漏洞，而且，通过使用图存储，可以避免重新分析镜像。 CoreOS使用Clair 分析用户上传到 Quay.io （一个类似 DockerHub 的容器注册中心）的 Docker 镜像。现已发现， Quay 上的大多数镜像都存在漏洞，甚至是像 Heartbleed（80%）或 Ghost（67%）这样的著名漏洞。2015 年初，一份有关 DockerHub 的报告推断，至少有30% 的官方镜像和多达40% 的用户上传镜像包含高级漏洞。期间，在 DockerCon 2015 欧洲大会上，…
閱讀本文約花費: 10 (分鐘)网上有很多关于如何将应用 Docker 化的教程，为什么我还要再写一个呢？ 我见过的大部分教程都是限定在某种特定技术（例如 Java 或者 Python），可能无法满足读者的需求。同时，这些教程也没有说清楚关于 Dev 和 Ops 团队之间建立明确约定所涉及到的所有相关方面（这正是容器化的精髓所在）。 我根据最近的经验总结了以下一些步骤。它是一份细节清单，包含了其他指南中忽略的内容。 声明：这不是一份新手指南。我建议读者先掌握一些如何设置和使用 docker 的基础知识，并且创建和运行一些容器之后，再来阅读。 让我们开始吧。 一、选择基础镜像 每种对应技术几乎都有自己的基础镜像，例如： https://hub.docker.com/_/java/ https://hub.docker.com/_/python/ https://hub.docker.com/_/nginx/ 如果不能直接使用这些镜像，我们就需要从基础操作系统镜像开始安装所有的依赖。 外面有很多教程使用的都是 Ubuntu（例如 ubuntu:16.04）作为基础镜像，这不能算有问题，但是我建议优先考虑 Alpine 镜像： https://hub.docker.com/_/alpine/ 它是一个非常小的基础镜像（大约只有 5MB）。 注意：在基于 Alpine 的镜像中无法使用“a…
閱讀本文約花費: 4 (分鐘)近日，由极客邦科技、InfoQ主办的首个年度榜单“2020中国技术力量年度榜单评选”结果揭晓，UCloud优刻得 Serverless容器实例Cube成功入选“2020年度十大云原生创新技术方案”。 顶尖专家阵容 优质项目交锋 UCloud云原生实力获得认可 此次极客邦科技、InfoQ主办的“2020中国技术力量年度榜单评选”，历经数月打磨，共有300+参评项目，100+入围项目，10000+开发者公开票选，20+顶尖专家评审，10+主编团打分。“2020 年度十大云原生创新技术方案”作为评选出的四大榜单之一，聚焦IT圈最炙手可热的“云原生”领域及优质技术方案，从研发实力、技术创新性、落地案例、市场潜力几方面综合评估，最终筛选出UCloud优刻得、华为云、腾讯云等10家入选方案。 轻量级Cube 秒级启动、最短1天完成部署 伴随云计算2.0时代的到来，越来越多企业开始拥抱云原生，容器作为云原生最基础的技术，在短时间也实现了快速普及，据权威机构的调查数据显示，2019年已有43.9%的用户采用了容器技术，另外有40.8%的用户计划采用容器技术。 UCloud作为云计算领域的核心玩家，持续关注云原生发展和用户需要，进行了多项技术、产品研发。在Kubernetes作为容器编排的事实标准在企业服务中被大量采用后，UCloud也于2018年推出了基于Kubern…
閱讀本文約花費: 6 (分鐘)开源社区治理，正在逐渐的成熟，Linux、CNCF、OpenStack、Apache基金会等俨然成为软件业的中流砥柱，本土是不是应该潜心学习这些先进的管理/治理方式？精英制还是完全民主化？是不是应该以实际行动和理性思考来作出正确的判断？ Mon Feb 5, 2018 | 1900 Words | 大约需要阅读 4 分钟 | | 引子 在2017年，关于容器的管理和调度平台，战火的硝烟渐渐的平息，Kubernetes 以压倒性的优势占据了这个细分领域的霸主，如下图来自 thenewstack 的调查： 如果仅仅从纯技术的角度而言，Kubernetes 和其它平台是半斤八两，处于伯仲之间，那么在社区的运营和赢得人们信任的方面，Kubernetes绝对是No.1，没有哪家能够相提并论。即使是Docker本身拥有无数拥泵的情况下，是容器的默认事实标准，也无法抵挡透明、开放、协作的Kubernetes社区的魅力。开源之道在Kubernetes 之所以成功的背后神秘力量 进行过专门的表述。 在上个月的中旬，Software Engineering Daily 的Jeff 撰写了一篇非常棒的文章：Kubernetes 的“下沉”，意指Kubernetes已经像Linux在单机操作系统的地位一样，成为分布式系统平台的默认选择。成为了分布式系统事实…
閱讀本文約花費: 16 (分鐘)一，环境准备 * K8S版本为15.1 * Docker版本最高支持18.06.1 二，Docker环境构建及替换 1，清除原Docker环境，原版本为最新版 yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \docker-engine rm -rf /etc/systemd/system/docker.service.d rm -rf /var/lib/docker rm -rf /var/run/docker 2，如果清除后依旧包冲突错误 file /usr/share/man/man1/docker-manifest-annotate.1.gz from install of docker-ce-18.06.1.ce-3.el7.x86_64 conflicts with file from package docker-ce-cli-1:18.09.6-3.el7.x86_64 通过yum命令手动移除冲突包 yum erase docker-common-2:1…
閱讀本文約花費: 20 (分鐘)近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄，服务治理难搞！ 一、微服务的“痛点” 微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。 微服务治理是头疼的事，也是微服务架构中的痛点。治理这个词有多元含义，很难下达一个精确定义，这里可以像小学二年级学生那样列出治理的诸多近义词：管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言，治理体现在以下诸多方面： 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说，微服务其实是一个“大系统”，要想将这个大系统全部落地，绝非易事，尤其是之前尚没有一种特别优雅的技术方案。多数方案（…
閱讀本文約花費: 9 (分鐘)1. 什么是云原生 1.1 CNCF组织 在讲云原生之前，我们先了解一下CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软。思科等巨头。 目前CNCF所托管的应用已达14个，下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。 1.2 云原生 CNCF给出了云原生应用的三大特征： 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。 动态管理：通过集中式的编排调度系统来动态的管理和调度。 面向微服务：明确服务间的依赖，互相解耦。 云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。 这边引用网上关于云原生所需要的能力和特征总结，如下图。 云原生所需要的能力和特征 1.3 The Twelve Factors 12-Factors经常被直译为12要素，也被称为12原则，12原则由公有云PaaS的先驱Heroku于2012年提出，目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下： 基准代码 显式声明依赖关…
閱讀本文約花費: 19 (分鐘)这一两周与几个朋友聊天，有年轻的90后，也有大叔级的70后，这些人在我看来都是很有能力的人，但是一些喜好过于强烈，让我不经意地回顾了我工作20年来身边的人，有发展得好的，也有发展的不好的，有些人是很可惜的，因为限制他们的不是其它人，也不是环境，而是自己，所以，很想写下这篇文章。（注：这篇文章可能会是一篇说教的文章，所以，可能会让你看着犯困，所以，我会尽量地短一些，而且尽可能多讲故事，少道理，这里的故事，全是真实发生的） 几个故事 2019年年初，我面试了一个很年轻的小伙子（93/94年出生），这个小伙子特别有灵性，也很聪明，计算机专业出身，也很喜欢技术，基础和学习能力也很好。在我这20年来认识的人中，如果他能呆在北京、上海、深圳这样的城市，我保证不出三年，他会成为他们同龄人中非常出色的技术人员，如果有个好的舞台有一个好的团队带他，他的未来会非常成功。然而，这个小伙子有两大喜好：1）只愿（或是说被迫）呆在一个毫无IT的环境的三/四线城市，2）对技术有非常大的偏好，只喜欢Go语言，非常不喜欢其它的语言，比如：Java（离开Java的世界，基本上离开了做架构的世界（相关解释见文末））。 他的这两个喜好，足以让一个未来会很优秀的人毁掉，因为，这个时代没有限制他，他的能力也没有限制他，但是他的意识完完全全地限制了他。 他把自己最宝贵的青春放在了很烂的项目上，就…
閱讀本文約花費: 16 (分鐘)上一篇文章我们着重讲解了 Docker，其实遗留了一个大问题。Docker 虽好用，但面对强大的集群，成千上万的容器，突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了，先来了解一下 K8s 的基本概念，后面再介绍实践，由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开： Docker 的管理痛点 什么是 K8s？ 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现，是存在困难的编排、管理和调度问题。 于是，我们迫切需要一套管理系统，对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生！Kubernetes，名词源于希腊语，意为「舵手」或「飞行员」。 image Google 在 2014 年开源了 Kubernetes 项目，建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上，结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写，用 8 替代了 「ubernete」，下文我们将使用简称。 什么是 K8s ？ image K8s 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 …
閱讀本文約花費: 8 (分鐘)一、Istio的来源 随着微服务架构的普及，越来越多的应用已经拆分成了微服务的架构。而微服务架构落地的一个难点，就是如何让服务和服务之间进行稳定的通信。 部署微服务之后，如何做服务的负载均衡、容错性、服务监控、日志追踪以及熔断等功能都需要考虑周全。 还好，现在已经有很多开源工具帮你做这样的事情。例如： Netflix的Eureka实现服务注册，它的优势在于实现跨数据中心的服务注册； Ribbon – 客户端的负载均衡； Hystrix – 微服务的熔断器； Zipkin – 分布式的追踪组件； Prometheus – 监控组件； Grafana – 数据可视化的工具； 于是，在写完我的微服务之后，我引入了更多的组件，带来了极大的部署复杂度，每个组件都需要高可用、负载均衡、熔断、日志收集等等。 为了让业务团队返璞归真，将所有精力集中在业务代码而不是配合微服务组件写大量非功能性需求的代码，Istio应运而生。 Istio是谷歌、IBM、Lyft等公司贡献的开源Service Mesh组件。它实现的目标就是让业务开发不再关注微服务之间如何调用、管理、监控等非功能性需求，而是让Istio来处理这些问题。Istio和Kubernetes有天然的支持。 Istio能轻松解决蓝绿发布和金丝雀发布的问题。 金丝雀发布有什么用？它的最大实际意义，是让运维不用在夜里加班…
閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用，了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题，再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战，就是即能够快速高效地针对需求、环境的变化做出改变，也能够持续提供稳定、高可用的服务。而软件架构，就是软件系统的骨骼与框架。 所谓架构，见仁见智，很难有一个明确或标准的定义；但架构并非镜花水月或阳春白雪，有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件，都需要设计和架构。抽象而言，架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作，结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值，即是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图，它描述的对象是直接构成系统的抽象组件；各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际…
閱讀本文約花費: 48 (分鐘)SOA与服务治理 SOA（面向服务的体系结构）概念由来已久，在10多年前便开始进入到我们广大软件开发者的视线中。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、Web Service技术之后的自然延伸。 服务治理，也称为SOA治理，是指用来管理SOA的采用和实现的过程。以下是在2006年时IBM对于服务治理要点的总结： l 服务定义（服务的范围、接口和边界） l 服务部署生命周期（各个生命周期阶段） l 服务版本治理（包括兼容性） l 服务迁移（启用和退役） l 服务注册中心（依赖关系） l 服务消息模型（规范数据模型） l 服务监视（进行问题确定） l 服务所有权（企业组织） l 服务测试（重复测试） l 服务安全（包括可接受的保护范围） 限于当时的技术发展水平，广大软件设计与开发人员对于SOA和服务治理的技术认知还主要停留在Web Service和ESB总线等技术和规范上，并没有真正在软件开发中得以充分落地。 Dubbo开源 直到2011年10月27日，阿里巴巴开源了自己的SOA服务化治理方案的核心框架Dubbo，服务治理和SOA的设计理念开始逐渐在国内软件行业中落地，并被广泛应用。 Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经…
閱讀本文約花費: 14 (分鐘)当 ElasticSearch 的业务量足够大，比如每天都会产生数百 GB 数据的时候，你就会自然而然的需要一个性能更强的 ElasticSearch 集群。特别是当你使用的场景是一些典型的大量数据进入的场景，比如网站日志、用户行为记录、大型电商网站的站内搜索时，一个强劲的 ElasticSearch 是必不可少的组件。在这样的场景下，如何找到一组合适的 ElasticSearch 集群？如何评估 ElasticSearch 集群的性能，就成为了一个十分重要的因素。 用什么 ElasticSearch 进行压力测试？ 对于 ElasticSearch 性能测试和压力测试方面，其实有很多不同的方案，比如： Rally：Rally 是 Elastic 官方针对于 ElasticSearch 的宏观测试工具。 ESPerf：一个基于 Golang 编写的 ElasticSerch 性能测试工具 Elasticsearch Stress Test：由著名的 ElasticSearch 服务提供商 Logzio 开发的性能测试工具 除了这些定制化的工具意外以外，ElasticSearch 也可以借由其 Restful API 来使用Load Runner、JMeter等老牌工具进行测试，这些工具零零散散，各有各的用法和用途，不过，对于广大开发者而言，还是官方出…
閱讀本文約花費: 21 (分鐘)前言 用过 MQ 的同学，可能会遇到过消息堆积的问题。而肥壕最近也踩上了这个坑，但是发现结果竟然是这么一个意料之外的原因而导致的。 正文 那一晚月黑风高，肥壕正准备踏上回家的路，突然收到告警短信轰炸！“MQ 消息堆积告警 [TOPIC: XXX] ” 肥壕心里“万只草泥马崩腾~” 第一反应是：“怎么肥事？刚下班就来搞事情？？？” 于是乎赶回公司赶紧打开电脑，登上 RocketMQ 后台查看（公司自己搭建的开源版RocketMQ） 握草 (ｷ｀ﾟДﾟ´)!!! 竟然堆积了3亿多条消息了？？？ 要知道出现消息堆积无在乎这个问题： 生产者的生产速度 >> 消费者的处理速度 1. 生产者的生产速度骤增，比如生产者的流量突然骤增 2. 消费速度变慢，比如消费者实例 IO 阻塞严重或者宕机 擦了一下头上的冷汗😓…赶紧登上消费者服务器瞧瞧。 应用运行正常！服务器磁盘IO 正常！网络正常！ 再去上去生产者的服务器，咦…流量也很正常！ 什么？？？佛了😨 …生产者和消费者的应用都很正常，但是为什么消息会堆积怎么多呢？看着这堆积的数量越堆越多（要是这是我头发的数量那该多好啊），越发着急。 虽然说 RocketMQ 版能支持 10 亿级别的消息堆积，不会因为消息堆积导致性能明显下降，…