Tools on 涯余的博客

Git 与 GitOps

hang.yan@hotmail.com (涯余) — Thu, 12 Sep 2019 13:02:41 +0000

伴随着 GitOps 的盛行， Git 本身的影响力也在逐渐增大。从最开始只是为了管理 linux kernel, 到支撑起了 Github 这个最大的软件社区，Git 本身的应用范畴早已超出了 vcs 本身，我们还用它来存储配置文件，文档，制作电子书，维护 blog (由 Github 等平台展示)等等。在 GitOps 的范畴内，它更是成为了 the single source of truth。

但 Git 最初的设计目标只是针对于 linux source code，大量的小文件，而伴随着 git 应用范围的增多，明个明显的问题便显现出来

大文件的管理：大文件通常都是难以 diff 的二进制文件，跟 git 本身的设计理念完全背道而驰
大仓库的管理: 像 Google 的 Single Repo 以及微软的 windows 等巨型仓库，在使用 git 时都都会遇到非常多的性能问题。

对于前者来讲，目前的主流的解决方案都是 LFS, 主流的托管平台都支持。但在 GitOps 的大前提下，这个问题仍然算是未解决，因为在企业场景下又多了一个 Git 大文件管理的 dashboard，而 GitOps 得了理念是为了减少 dashboard, 将所有的一切都统一起来。一个可能的选项是用Cloud Native Artifact Registries的理念，用distribution 作为 LFS Server。

大仓库的管理微软的贡献比较显著些。像 Windows 这样的巨型项目，他们必须提前做很多改善才能把 Windows的代码放到一个仓库里。最终的实现原理跟 Google 类似: 与普通的 Git 仓库不同，他们使用一个 virtual filesystem 来作为底层存储，当用户使用 git 时，只有那些被访问的文件才会被实时从 Server pull 下来。这种方式带来的一个附带好处是也解决了大文件的管理问题。

在 Kubernetes 中安装 Gitlab

hang.yan@hotmail.com (涯余) — Wed, 08 May 2019 13:36:33 +0000

现在很少写这种安装类的博客了。之前在公司部署了一个 Gitlab 作为日常使用，因为步骤比较繁琐。在此把零零散散的资料汇聚一下，记录一个比较完整的安装过程

环境

Kubernetes 1.13.1 三个高可用节点
每个节点上一个空余磁盘

步骤

安装 Rook

Rook 提供了基于 Ceph 的分布式存储，我们利用每个节点上的空余磁盘来支撑 Kubernetes 里的 PV/StorageClass 等

Helm 安装

首先，初始化磁盘

mkfs.ext4 /dev/vdb
mount /dev/vdb /var/lib/rook
mkdir /var/lib/rook
# TODO: add to /etc/fstab

然后通过 Helm 安装 Rook

helm repo add rook-stable https://charts.rook.io/stable
helm install --namespace rook-ceph-system rook-stable/rook-ceph

部署完成后可以看到rook-ceph-system Namespace 下运行的 Resource:

创建 CephCluster

#################################################################################
# This example first defines some necessary namespace and RBAC security objects.
# The actual Ceph Cluster CRD example can be found at the bottom of this example.
#################################################################################
apiVersion: v1
kind: Namespace
metadata:
 name: rook-ceph
---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: rook-ceph-osd
 namespace: rook-ceph
---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: rook-ceph-mgr
 namespace: rook-ceph
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-osd
 namespace: rook-ceph
rules:
- apiGroups: [""]
 resources: ["configmaps"]
 verbs: [ "get", "list", "watch", "create", "update", "delete" ]
---
# Aspects of ceph-mgr that require access to the system namespace
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr-system
 namespace: rook-ceph
rules:
- apiGroups:
 - ""
 resources:
 - configmaps
 verbs:
 - get
 - list
 - watch
---
# Aspects of ceph-mgr that operate within the cluster's namespace
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr
 namespace: rook-ceph
rules:
- apiGroups:
 - ""
 resources:
 - pods
 - services
 verbs:
 - get
 - list
 - watch
- apiGroups:
 - batch
 resources:
 - jobs
 verbs:
 - get
 - list
 - watch
 - create
 - update
 - delete
- apiGroups:
 - ceph.rook.io
 resources:
 - "*"
 verbs:
 - "*"
---
# Allow the operator to create resources in this cluster's namespace
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-cluster-mgmt
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: rook-ceph-cluster-mgmt
subjects:
- kind: ServiceAccount
 name: rook-ceph-system
 namespace: rook-ceph-system
---
# Allow the osd pods in this namespace to work with configmaps
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-osd
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: Role
 name: rook-ceph-osd
subjects:
- kind: ServiceAccount
 name: rook-ceph-osd
 namespace: rook-ceph
---
# Allow the ceph mgr to access the cluster-specific resources necessary for the mgr modules
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: Role
 name: rook-ceph-mgr
subjects:
- kind: ServiceAccount
 name: rook-ceph-mgr
 namespace: rook-ceph
---
# Allow the ceph mgr to access the rook system resources necessary for the mgr modules
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr-system
 namespace: rook-ceph-system
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: Role
 name: rook-ceph-mgr-system
subjects:
- kind: ServiceAccount
 name: rook-ceph-mgr
 namespace: rook-ceph
---
# Allow the ceph mgr to access cluster-wide resources necessary for the mgr modules
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: rook-ceph-mgr-cluster
 namespace: rook-ceph
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: rook-ceph-mgr-cluster
subjects:
- kind: ServiceAccount
 name: rook-ceph-mgr
 namespace: rook-ceph
---
#################################################################################
# The Ceph Cluster CRD example
#################################################################################
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
 name: rook-ceph
 namespace: rook-ceph
spec:
 cephVersion:
 # For the latest ceph images, see https://hub.docker.com/r/ceph/ceph/tags
 image: ceph/ceph:v13.2.2-20181023
 dataDirHostPath: /var/lib/rook
 mon:
 count: 3
 allowMultiplePerNode: true
 dashboard:
 enabled: true
 storage:
 useAllNodes: true
 useAllDevices: false
 config:
 databaseSizeMB: "1024"
 journalSizeMB: "1024"

这个 yaml 列表包含了如下的 Resource:

在 Gitlab 中使用 Danger

hang.yan@hotmail.com (涯余) — Tue, 07 May 2019 23:23:52 +0000

Gitlab 社区版的 CI 功能非常好用，能够很方便的地做到代码的 lint/build/test/等等。不过社区版在多人协作上(比如 Merge Request)上阉割了不少功能，比如将 MR assign 给多人等。通常来说，在代码合并这块，CI/CD 一般包括两部分: 代码本身以及 MR/PR 本身。Danger 这个工具正好可以补足 Gitlab 在后者的不足。

功能

Gitlab CI 的关注点在于提交的代码本身，而 Danger 的关注点在于 Merge Request 本身，当然也可以做到很多 Gitlab CI 能做到的事情，各种第三方插件也能极大地扩种 Danger 自身的能力。目前我觉得几个非常有用的功能是：

检查 Commit Message 的格式。这个功能是很基本的，但是很多 CI 系统本身都不支持。
检查与 jira 的关联。强制让每一个 MR 都关联一个 jira,方便项目管理
检查 MR 是否打标签。在 MR 非常多的时候用于给 MR 归类，在 Github 上的大项目上我们经常见到
检查 MR 的大小。改动太大的 MR 是不推荐的，因为 Review 起来难度太大，推荐分裂成比较小的 MR
检查是否 rebase 过了目标分支,保持一个干净的提交记录。

安装

因为 MR 本身属于 Git 系统的一个功能，所以 Danger 的一个主要能力在于与各大平台的集成性上,目前主流的 Gitlab/Github/都支持。也很容易部署。下面简要介绍与 Gitlab 的集成方法

现代化的开发人员实用工具

hang.yan@hotmail.com (涯余) — Fri, 30 Jan 2015 21:37:39 +0800

常年混迹于 linux，对命令行程序情有独钟，平时也喜欢搜集各种实用的小工具。github流行以来，越来越多的新的实用的开发工具开源出来，有的可以用来替代一些老的工具，有的则是全新的。本文整理一些实用的工具，希望大家能在实际开发中用到。

bash 各配置文件浅析

hang.yan@hotmail.com (涯余) — Fri, 23 Jan 2015 21:37:39 +0800

与 bash 相关的配置文件非常之多,用户目录下的.bashrc,.profile,.bash_profile，系统级的/etc/profile等。我们也经常会发现，在某个文件里设置好了环境变量之后，并不能总是能在使用 bash 时正确加载。下面将对这个问题进行深入剖析，以解除疑惑。

CoreOS 安装及配置

hang.yan@hotmail.com (涯余) — Thu, 22 Jan 2015 21:37:39 +0800

本文所遵照的步骤是官网的 Installing to disk 方法,即刻录 ISO 镜像 -> 启动 Coreos Live CD -> 安装到硬盘的步骤，与一般的桌面 Linux 安装非常类似。但 coreos 安装时也有一些需要注意的地方:

cloud-config.yml

这是 coreos 用来统一配置系统的地方，系统在每次启动时都会加载这个文件的配置，比如系统服务、网络设定、文件修改、用户设定等。这样做的好处是在部署集群的时候可以方便地使用相同的配置。在安装 coreos 时，需要指定好这个配置文件。实际操作时，可以提前将这个文件写好放在别的机器上，然后用 scp / wget (利用下面的 web server) 下载到 coreos 的 Live CD 即可，或者直接存在 Live CD 里更方便。
GFW

coreos 安装时需要从官网下载镜像，但网站被墙，所以实际安装的时候可能需要用代理来解决，缺点是速度慢。更方便的方法是提前下载好需要的文件并放在局域网内并搭建一个 web server，然后修改安装脚本的 server 即可。具体方法在后面详述。