前言

在实际工作中，常需要初始化系统，批量执行命令或脚本，上传文件等操作。

为便于以上操作执行和查看结果，故开发“基础运维作业平台”，现已在生产上使用.

下面把开发用的组件和平台主要功能介绍下。

主要开发用组件

1
2
3
4
5
6
7
8
9
10
11

saltstack

django

ldap

mysql

jquery

bootstrap

主要功能

选取执行目标

可从cmdb平台，saltstack分组， 自定义动态分组选取待执行目标主机。

下图是从cmdb平台选取执行目标主机.

前言

前不久未经多考虑做了一个决定,确切讲应该是对事物认知不够,而做出了决定.

认知一时半会改变不了,那有办法尽量避免这种情况吗.

反思

一直以来,做重要的决定前,会凭借直觉思索下,是否应该这么做,然后要么做了,要么没有做. 但直觉不是认知,总有错的时候.

需要有个”方法论”帮助自己做出决策.

简易方法论

后记

有些事,可能只有1%的成功概率,但这1%还有另一个名字-希望,希望是无价的,是每天开心生活的源泉.

Summary

在频繁ci/cd过程中,导致harbor中images累积了大量tags, 有的多达上千个tag,需采取措施进行清理.

批量删除harbor镜像tags脚本支持两种方式.

1) 保留最后指定数目的tags (tag格式需是数字)

2) 保留指定日期后的所有tags

问题描述

在k8s中部署gocd-server,因需要持久化数据,gocd-server相关数据目录挂载到了nfs volume,
但这导致gocd-server启动失败.错误提示如下:

1
2
3
4
5
6
7
8
9

root@master01:~/k8s-test/gocd-server# kubectl logs -f test-gocd-server-deployment-5c849557d9-5prc2 -n test
/docker-entrypoint.sh: Creating directories and symlinks to hold GoCD configuration, data, and logs
$ mkdir /go-working-dir
$ chown go:go /go-working-dir
$ ln -sv /godata/artifacts /go-working-dir/artifacts
'/go-working-dir/artifacts' -> '/godata/artifacts'
$ chown go:go /go-working-dir/artifacts
chown: /go-working-dir/artifacts: Operation not permitted
/docker-entrypoint.sh: cannot chown go:go /go-working-dir/artifacts

前言

k8s的安装方式有很多，kubeasz,kubespray,kubeadm,手动安装等等,今天尝试了kubeasz,遇到些问题,在此记录下.

上下文

• 安装k8s 1.12
• vagrant起了四台vm
• kube-proxy模式选择ipvs
• 网络选择flannel

安装过程

按照kubeasz文档中“多主多节点”方式配置安装，不在细说！, 本文档下kubeasz目录有相关配置文件。

Troubleshooting过程

coredns和dashboard的pod状态不是“running”

经查发现，这两货报错如下：

xtengine

封装tengine为docker镜像, 基于cloudposse/tengine,增加了状态监控和动态调整upstream pool,后期会加入监控和管理UI。

install & config

docker run -d -p 80:80 -p 443:443 -p 8081:8081 itwye/xtengine

在你的工作主机增加dns解析, 如在”/etc/hosts”增加如下, $docker_server请替换为你的docker宿主机IP.

1
2
3

$docker_server prod.xtengine.com
$docker_server test.xtengine.com
$docker_server manage.xtengine.com

Summary

在更新nginx upstream pool时，一般方案是更新nginx配置文件，然后reload nginx, 在nginx繁忙时会导致worker process长久处于shutdowning, 
在频繁reload ng时，可能会导致nginx挂掉. 

本文用的方案是:consul + cosnul-template + tengine dyups + python script , 当服务有变动时，触发consul-template渲染模板并持久化，同时
consul-template触发执行python脚本，python脚本先调用consul api获取对应服务信息，然后将新的服务信息调用dyups管理接口写入nginx upstream pool. 

这个方案有两个好处, 一是将nginx upstream pool持久化了  二是在服务出现变动时，不需要再reload nginx了。

简略流程如下：

Summary

以下所做操作是基于<<consul之集群搭建>>中的环境.

192.168.1.101(consul-client01)是一个consul client节点, 服务与发现操作都在其上进行.

基本概念

(1) 每个节点运行的consul进程，都是一个consul agent , 节点包括server和client节点.
(2) Consul agent 分server 和 client 两种角色.
(3) 每个集群或数据中心需要3-5个server节点, 其它需要注册与发现服务的节点就是client节点,也就是你的应用所在节点是client节点.
(4) server节点用来保存数据，处理请求. client节点不保存数据, 转发请求到server节点.

通过thrift api框架访问hdfs

可在任何客户端通过thrift框架管理hdfs上数据.

注: start_thrift_server.sh不一定要在namenode上运行,datanodes上皆运行.

以下操作均在namenode(192.168.0.112)下执行.