VMWare Harbor 在 Kubernetes 上的部署

VMWare 家的 Harbor 是我目前能免费得到的最好的私库管理工具了,除了解决了基础的镜像存储、权限控制这些基础能力之外,还具备 对 DevOps 非常有帮助的镜像同步功能

原本这一产品只提供了基于 Docker Composer 的部署方法,后由社区为其新增了 Kubernetes 的部署支持。本文大部分基于官方文档而来。

部署过程大概分这样几个步骤:

  1. 环境准备
  2. 配置
  3. 运行

环境准备

  • 首先是需要有一个正常运行的 Kubernetes 环境,需要提供对持久卷和 Config Map 的支持,没记错的话应该是 1.2。

  • 下文需要执行的脚本需要 Python 2.6 的支持。

镜像获取和上传

https://github.com/vmware/harbor/releases可以找到离线版本的二进制文件包。

利用 Gitlab 为 Sonarqube 提供单点登录服务

Gitlab 很贴心的提供了一个 Oauth 2 功能,可以作为 CI/CD 工具链的认证中心来使用。

Sonarqube 的官方插件只有一个 Github 的支持插件,因此这一功能需要借助第三方插件来完成。

项目地址

https://gitlab.talanlabs.com/gabriel-allaigre/sonar-auth-gitlab-plugin

下载地址

http://nexus.talanlabs.com/content/groups/public_release/com/synaptix/sonar-auth-gitlab-plugin/1.0.0/sonar-auth-gitlab-plugin-1.0.0.jar

Linkerd + Namerd,实现 Kubernetes 集群的灰度发布

主要内容源于 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ,砍掉了 Jenkins 等附加部分,更换了更加易于理解的示例应用,以保证主干突出。

Kubernetes 所提供的 rolling-update 功能提供了一种渐进式的更新过程,然而其滚动过程并不容易控制,对于灰度发布的需要来说,仍稍显不足,这里介绍一种利用 Linkerd 方案进行流量切换的思路。

官网介绍:linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications。

本文从实际操作入手,上线两个版本的简单应用,利用这一组合完成流量的切换和测试过程。

Grafana 和 Elasticsearch

容器化和微服务,让世界花枝招展,又支离破碎。一个典型的运行在容器云之上的微服务架构的应用,通常是由多种服务和基础设施的支撑而来的。这对运维工作提出一个很大的挑战 —— 一个应用后端的众多系统,究竟是怎样的工作状况?

事实上,所有构成这一应用的微服务以及支撑这一应用的所有基础设施,都会有各自的日志、指标数据,以及构建在上游的监控、日志系统。各处分散的数据和系统,会给支持团队造成极大的负担,也最终成为开发运维工作的拦路虎。

之前的经验中,可以把自家应用的各种业务、技术指标通过 Zabbix 或者 influxDB 进行存储,经由 Grafana 的插件系统进行整合展示,目前流行的容器云支撑系统 Kubernetes,也能够通过 influxDB 在 Grafana 上展示 Heapster 搜集到的数据。指标的事情解决了,下面自然就是日志了。

Grafana 也提供了针对 Elasticsearch 的数据源插件。下面用 Kubernetes 中正在运行的日志收集实例来展示 Grafana 对 ES 的支持。

Kubernetes 支持 OpenAPI

Open API 让 API 提供者可以定义自己的操作和模型,并让开发者可以自动化的生成喜欢语言的客户端,用以和 API 服务器通信。Kubernetes 已经支持 Swagger 1.2(OpenAPI 规范的前身)有一段时间了,但是这一标准不够完整和有效,凭借这一支持,非常难生成工具或客户端。

在 Kubernetes 1.4,我们对目前的模型和操作进行了升级,引入了 Open API 规范(在没被捐献给 Open API 之前被称作 Swagger 2.0)支持的 Alpha 版本。从 Kubernetes 1.5 开始,OpenAPI 规范的支持已经完备,能够直接从 Kubernetes 源码生成规范,对于模型和方法的任何变更,都会保障文档和规范的完全同步。

Kubernetes 的 Windows Server 支持

响应群众呼声,Kubernetes 1.5 包含了对 Windows Servern 的支持。80% 的企业应用运行于 Linux + Java 或 .Net + Windows 平台上。Kubernetes 正在 Preview 阶段的这一功能,是贴近企业需求的一次努力。

Kubernetes Windows Server 2016 以及 Windows 容器支持包含了下列功能的预览版本:

容器化的多平台应用

使用操作系统原生语言,例如 Go 和 .NET 核心开发的应用,在以前是不可能再 Linux 和 Windows 之间进行编排的。现在 Kubernetes 有了 windows Server 2016 支持,这些应用就能够同时部署在 Windows 和 Linux 之下了,开发者可以自行选择操作系统运行时。这一功能,消费者已经等了 20 年了。

StatefulSet: Kubernetes 中对有状态应用的运行和伸缩

我们认为,对于大量的有状态容器化负载,我们已经具备了一定的支持能力。我们并不是宣称这一功能已经完全完成,但是我们相信他已经处于一个可用状态,并且我们会在推动其正式发布的过程中保持其兼容性。

Kubernetes 中的容器运行时接口

文中多次出现了个单词 shim,胡翻成代理了,虽然垫片还是比鲁棒啥的好听。。

归根结底,Kubernetes Node 的最底层就是启动和停止容器的组件了,这一部分我们称之为容器运行时( Container Runtim ),这其中最知名的也就是 Docker 了,这一领域正在快速成长,他并不孤独。为了让 Kubernetes 更具扩展性,我们投入了不少精力,在 Kubernetes 中加入了容器运行时插件 API,我们称之为 “CRI”。

Robotframework + selenium2library 实现 Headless 模式的 Web 功能测试

今天来点小技巧凑个数。 感谢健哥提供的 Hello world 样本。

之前因为做一些 CI/CD 的尝试,做了个要你命三千一样的 Jenkins 镜像(docker pull dustise/jenkins),其中包含了 Maven、Sornar Scanner、Robot Framework 以及 Git/Subversion、Kubectl 等一系列的相关工具。

一旦用起来,测试的兄弟发现了个大问题,基于 selenium2library 的页面功能测试无法完成了,回头一想,镜像里面压根没有浏览器,怎么可能执行浏览器测试呢。

安装

首先就要安装浏览器了,我这里选择了 FireFox。

apt-get install -y firefox

为了让 selenium2library 能够同 FireFox 互动,还需要 geckodriver 的支持,这个软件提供了 WebDriver 协议所需的 HTTP API,能够和 FireFox 这样的 Gecko 浏览器进行通信。

监控随想,业务和迭代

其实我不知道我在说啥

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

< Microservices > By Matin fowler

如 Matin 大爷所言,微服务的两个重要特征:面向业务和自动化。随着微服务架构的普及和深入,每一个线上业务都是由为数众多的独立运行的微服务协作完成的。加之容器、云计算等技术的引进使用,自动化工具链也加入战团,这一切情况的叠加,使得一个具体业务的整个生命周期所涉及的 IT 资产数量不断膨胀,并且微服务化带来的快速变更,原有的按照网域、按照应用类型等监控 Screen 的定义方式越来越难跟上业务需求,运维监控这一分支的技术工作成为背锅侠的风险越来越大。

目前见过的几个的监控方式,有几个共同点:

页面