devops

关于 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 在他的文章中阐述了这一观点。

从头开始:Redmine 和 Gitlab 的集成和联动

本文的操作将达成如下目的:

  1. 在 Redmine 中查看 GitLab 仓库中的变更。
  2. Redmine 中更新 Gitlab 仓库。
  3. 利用 Git Commit Log 改变 Redmine 中的 Issue 状态。

工作环境

该过程在 Kubernetes 环境中完成。

Redmine:sameersbn/redmine:3.3.1 Gitlab:官方镜像

Redmine 设置

系统仓库设置

以管理员身份登入 Redmine,进入 Administration -> Repositoriessettings?tab=repositories)。

为 Gitlab 和 Jenkins 添加 InfluxDB 支持

概述

量化和监控对现在的开发运维工作的重要性是毋庸置疑的。在大肆鼓吹 DevOps 的今天,一体化的数据采集和可视化展示就尤为重要了。

为了能在同一视图下对 Jenkins 和 Gitlab 的操作进行监控,本来写了一些数据采集的脚本,后发现这两个系统都有实现向 InfluxDB 发送指标数据的能力,虽说结构和数据的细致程度可能不及定制脚本,但懒人方案始终是更快的解决办法。

非常对不起各位的是,下面的内容主要是堆代码了。

环境准备

Docker

为方便部署,这里采用 Docker 作为执行环境,过程中需要下载一些镜像,所以这里可能要配置代理或者其他途径来获得镜像文件并导入。

这里假设宿主机 IP 为 10.211.55.5

网络

因为几个组件之间互相需要访问,因此我们首先用如下命令创建一个虚拟网络:

docker network create devops

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。

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

页面