五月 2017

Monitor as Code 的一点尝试

Tags: 

这篇的真实名字应该是:Grafana 也是有 API 的

在项目的 CI/CD 实践过程中,XX as code 是一个很重要的方法,利用代码的方式,对软件的构建、发布、测试等环节进行表达,一方面极大的提高了自动化程度;另一方面,将这些代码纳入版本管理范围,使其同软件代码同步更新和迭代,更好的体现了系统的整体性,提高了系统的可维护性。

前面的文章中我也多次提到了监控的内容,业务和系统的运行状况可视化是系统运行的重要支撑。甚至监控本身就应该是软件的一部分。得益于各种开源软件的支持,我们可以做一番 Monitor as Code 的尝试。

监控过程本身一般由数据的产生和展示两个部分组成,对于系统数据,例如 Kubernetes 或者主机数据,我们可以使用 Zabbix、Heapster 或者 cAdvisor 以及 Prometheus 进行获取;而业务的数据则需要借助业务应用自身的代码或者数据库来转换为指标数据,注入到 InfluxDB 等时间序列数据库中。本文中暂不介绍数据生成部分的内容。

最终我们继续选择 Grafana 进行数据的展示。这是这一篇里面唯一有用的内容了。

在 kubectl 中使用 Service Account Token

在运行基于 K8S 的 CI/CD 过程中,经常有需求在容器中对 Kubernetes 的资源进行操作,其中隐藏的安全问题,目前推荐的最佳实践也就是使用 Service Account 了。而调试账号能力的最好方法,必须是 kubectl 了。下面就讲讲如何利用 kubectl 引用 Servie Account 凭据进行 K8S 操作的方法。

这里用 default Service Account 为例

假设

目前已经能对目标集群进行操作,文中需要的权限主要就是读取命名空间中的 Secret 和 Service Account。

准备配置文件

新建一个 Yaml 文件,命名请随意,例如 kubectl.yaml。内容:

关于 Job title 中的 "DevOps" 的讨论

Tags: 

你可能看到了很多招聘 “DevOps 工程师”、“DevOps 经理” 或者 “DevOps 忍者”(胡说的)什么的,或者我最喜欢说的——“DevOps”。

另一方面,有些开发或者运维的家伙也会把 "DevOps 工程师" 这个时髦词汇加到自己的 LinkedIn 资料里面去。事实上,讨论中的很人承认干了这事(其实只要说的是你的确能做的事情就好),DevOps 之于雇主,可媲美蜂蜜之于狗熊了。

Spike Morelli 支持在 Job Title 中加入 DevOps 这个修饰,他的观点可以在博客中找到。如果对找工作有好处,何乐而不为呢?当然还是要注意这一份工作的具体需求。

Why having "DevOps in a Job Title Makes Sense

https://dzone.com/articles/why-having-devops-job-title?mz=38541-devops

而反对方,很多 DevOps 哲学的实践者会说,DevOps 是一个关于文化和自动化的词语,而非工作描述。Matthias Marschall 在他的文章中阐述了这一观点。

kubeadm 安装 Kubernetes 1.6.2

因为一些莫可名状的原因,国内网络使用 Kubeadm 颇有难度,这里大概说一下过程中的一些坑。

主体流程遵循官网指南:https://kubernetes.io/docs/getting-started-guides/kubeadm/

1/4 准备工作

这里用包管理的方式安装 kubeadm、Docker 等组件。需要注意一点点的是,如果用的非 Root 用户,要注意 sudo 的时候的环境代理设置问题。或者干脆在 apt/yum 的配置文件中写入代理服务器。

另外这里安装 Docker 之后,注意给 Docker 配置代理。或者可以直接想法子搞到下面列表中的镜像,并导入 Docker 之中:

镜像准备

下面提到的镜像基于目前的 1.6.2 版本,每次更新都会有不同。