ansible

写在前面的话，笔者目的是为了尝试用Kolla来方便快捷的部署OpenStack，为以后多节点部署打下基础。 Kola 简介： kolla 项目起源于TripleO项目，聚焦于使用Docker容器部署OpenStack服务。该项目由Cisco于2014年9月提出，是OpenStack 社区Big Tent开发模式下的孵化项目。 Kolla 项目是一个支持Openstack服务以容器的方式部署，借助ansible部署工具可以简单的扩展到多个节点。同时，又借助于使用 heat 来编排 Kolla 集群。 环境介绍： 10.0.100.201 kolla-all-in-one Centos7.2 系统 10.0.100.207 docker-registry Centos7.2 系统 由于我目的很明确，所以这里就不强调网络了，没有特殊要求，能上网就行。 另外就是 安装kolla，必须自己build 镜像， 由于网络的原因，经常会导致在build 镜像的时候失败。这次我们直接采用kolla官方提供的镜像文件，这样就不需要自己build镜像的环节 ，也就是说我们搭建本地的docker registry。 环境准备： 安装epel源 yum install epel-release -y 安装所需的依赖包 yum install python-devel libffi-devel gcc

k3s介绍 K3S是一个轻量级的K8S集群，它是Rancher Lab开发的一个新的产品, 目的是在资源有限的设备上面跑K8S。它的最大特点就是小，二进制包只有40MB，只需要512MB的内存就能跑起来。K3S目的是在一些资源受限的设备上面把Kubernetes跑起来，主要的应用场景包括Edge，IoT，CI和ARM等等，至于为什么叫K3S呢，官方就一句话: k3s - 5 less than k8s 官方访问地址： https://k3s.io/ 安装方式 k3s的相关衍生安装工具很多在，比如k3d(类似kind), k3s-ansible, k3sup和官方k3s-install.sh等，每个工具都有其特殊用途 k3d k3d 是一个dind模式安装k3s，创建快速，演示： k3d create --image registry.cn-hangzhou.aliyuncs.com/k8ops/k3s:v1.17.3-k3s1 --publish 80:80 --server-arg --no-deploy --server-arg traefik --name istio-test k3d stop --name istio-test k3d start --name istio-test export KUBECONFIG=$(k3d get-kubeconfig --name

目录 安装前的准备 最低系统要求 1. master最低要求 2. node最低要求 3. 磁盘要求 实验环境说明 预配置 1. 配置yum源 2. 安装基础环境依赖包 3. 安装docker 安装openshift 1. 安装openshift-ansible 2. 关闭selinux检查 3. 修改openshift-ansible代码中使用的yum源为国内源 4. 配置inventory 5. 执行部署 6. 卸载 7. 访问 注意事项及常见故障 注意事项 其他安装说明 常见错误 附录 安装前的准备 最低系统要求 1. master最低要求 最小4 vCPU 最小16 GB RAM /var/最小40 GB硬盘空间 /usr/local/bin/最小1 GB硬盘空间 临时目录最小1 GB硬盘空间 2. node最低要求 1 vCPU 最小8 GB RAM /var/最小15 GB硬盘空间 /usr/local/bin/最小1 GB硬盘空间 临时目录最小1 GB硬盘空间 3. 磁盘要求 /var/lib/etcd Less than 20 GB /var/lib/docker 50GB /var/lib/containers 50GB 这是openshift官方给出的最小要求，也是openshift-ansible检测环境时的最小要求，实际上，我们的实验环境满足不了最小要求

软件包下载 maven软件包下载 gradle软件包下载 ant软件包下载 node软件包下载 配置环境 #解压 tar zxf apache-maven-xxxx.tar.gz -C /usr/ local tar zxf gradle-xxxx.tar.gz -C /usr/ local tar zxf node-xxxxx.tar.gz -C /usr/ local tar zxf apache-ant-xxxx.tar.gz -C /usr/ local #添加环境变量 vim /etc/profile export MAVEN_HOME=/usr/ local /apache-maven-3.6.0 export ANT_HOME=/usr/ local /apache-ant-1.10.5 export GRADLE_HOME=/usr/ local /gradle-5.3 export NODE_HOME=/usr/ local /node-v10.15.3-linux-x64 export JAVA_HOME=/usr/ local /jdk1.8.0_201 export PATH= $PATH : $MAVEN_HOME /bin: $ANT_HOME /bin: $GRADLE_HOME /bin: $NODE_HOME /bin export PATH=

离线安装集群 参考 https://github.com/easzlab/kubeasz/blob/master/docs/setup/offline_install.md 离线文件准备 在一台能够访问互联网的服务器上执行： 下载工具脚本easzup，举例使用kubeasz版本2.2 export release=2.2.1 curl -C- -fLO --retry 3 https://github.com/easzlab/kubeasz/releases/download/${release}/easzup chmod +x ./easzup 使用工具脚本下载 默认下载最新推荐k8s/docker等版本，使用命令 ./easzup 查看工具脚本的帮助信息 # 举例使用 k8s 版本 v1.18.2，docker 19.03.5 ./easzup -D -d 19.03.5 -k v1.18.2 # 下载离线系统软件包 ./easzup -P 执行成功后，所有文件均已整理好放入目录/etc/ansible ，只要把该目录整体复制到任何离线的机器上，即可开始安装集群，离线文件包括： /etc/ansible 包含 kubeasz 版本为 ${release} 的发布代码 /etc/ansible/bin 包含 k8s/etcd/docker/cni 等二进制文件 /etc

ansible 对于自动化运维非常方便。在这里就记录一点自己觉得好用的地方。 1 ansible 的inventory 文件分组，组变量 /etc/ansible/hosts # 分组 [single] 172.28.64.104 172.28.64.105 172.28.64.133 172.28.64.137 # 组变量 [single:vars] ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=borui2020 2 inventory 文件子分组 [single] 172.28.64.104 172.28.64.105 172.28.64.133 172.28.64.137 [single:vars] ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=borui2020 [ceph] 172.18.0.131 172.18.0.132 172.18.0.133 # 主组包含下面两个子组 [test:children] ceph single 3 inventory 文件 组参数yml文件 由于组比较多，每个组的参数也比较多，如果都放在/etc/ansible/hosts 文件中 就不好管理。对组的参数可以分开放在不同yml文件中管理

pipe(command, [envVars]) 对于每个分区，都执行一个perl或者shell脚本，返回输出的RDD 1 2 3 4 5 6 7 8 9 10 11 scala> val rdd = sc.makeRDD(List( "wangguo", "yangxiu", "xiaozhou", "kangkang"),3) rdd: org.apache.spark.rdd.RDD[String] = ParallelCollectionRDD[9] at makeRDD at <console>:24 scala> rdd.pipe( "/opt/test/spark/pipe.sh").collect res4: Array[String] = Array(wangcen, wangguohehe, wangcen, yangxiuhehe, wangcen, xiaozhouhehe, kangkanghehe) scala> val rdd = sc.makeRDD(List( "wangguo", "yangxiu", "xiaozhou", "kangkang"),4) rdd: org.apache.spark.rdd.RDD[String] = ParallelCollectionRDD[11] at makeRDD at <console>:24

我先说几个最让你兴奋和开心的点吧： 在 TiDB 里，你完全不用担心磁盘容量的问题。 在 TiDB 里，原生支持 Online DDL，你完全不用担心第三方改表工具改表出现各种 Bug 的问题，相信用开源工具改过上 T 级别表的同学都遇到过或多或少的各类 error。 在 TiDB 里，加列、主键扩容字段都是秒级的，比如我刚刚就刚对一张 19 亿的表加完了字段，1 秒完事，这在 MySQL 里要 8.0 才可以，而且还要求列在最后才行。 在 TiDB 里，你会发现 count(*) 惊人的快，一张近 20 亿的表 coun(*) 大概在 1 分钟完事儿，当然，这取决于你的 KV 数量和磁盘性能。 在 TiDB 里，从 MySQL 迁移将变得简单，图形化一键迁移，爽不爽？ 在 TiDB 里，绝大多数情况你会发现比单机 MySQL 有更好的性能，当然也不排除一些例外，例如 enum 这样奇葩的字段类型。 在 TiDB 里......您且往下看，我慢慢和您说。 使用背景 60 云平台对 360 集团各大业务线均有提供服务支持，涉及的数据库支持方案有：MySQL、Redis、MongoDB、ES、GP、PiKA。 其中 MySQL 至今已有过万的实例，目前，对于一些写入量大的业务，已经出现瓶颈。 例如磁盘空间，虽然我们可以通过分库分表的方式，拆分出来，但这对业务和 DBA

“攻城狮”之痛 痛一：最“可爱”的产品经理，这些人一天到晚提需求，而且毫无愧意改来改去。 每一个需求背后都是一大串的代码，每一次需求的变更，意味着相对应的每一个环节都要变更，而这些，都是“攻城狮”一个一个代码敲上去的。所谓杀掉一个“攻城狮”，不用枪、刀、剑、斧，多提需求以及需求变更就够，大概就是这样子的吧。 产品经理们，摸过你们长在左心房的良心吗？而且，说好的下午茶、大餐呢？ 痛二：最“要命”的老板，这些人老是有这周想到下周就要的系统。 996已经司空见惯，跟谁学更是提倡“996变为007”，鼓励员工尽量住在公司，所谓“不畏加班不念下班”，虽然不确定真假，但这个应该是每一个老板的内心想法。项目工作量需要30人/天，老板要求10人/天，这就是现实！ 老板们，你有考虑过我们“攻城狮”所剩无几的头发兄弟的感受吗？你有想过我们“攻城狮”也想有时间去大学城找女朋友吗？ 痛三：最费头发的事儿——修Bug，这些“兄弟”最讨人烦，但无奈它天天光顾。 在公司/机构里，老师绝对是最受宠的那类人，天天都有人围着。 我们这些“攻城狮”则天天围着Bug，当真是一个Bug一时爽，一打Bug头发光。如果是自己写的代码倒还好，最坑的是公司/机构里有N多不知道哪儿来的“系统”，甚至还没有说明文档。 痛四：最憋屈的事儿——修复“罢工”系统，这些家伙不来则已，一来惊天动地。 每年招生高峰期，大大小小的活动肯定是少不了

背景 在用ansible撰写一个etcd恢复的playbook时，有一个操作是获取etcd启动时的"initial-cluster"启动参数，该参数在etcd集群不同节点不一致，需要取出etcd节点启动参数中最长的作为etcdctl snapshot restore的参数。 [root@tke-init ansible]# cat etcd.hosts [etcd] 10.0.32.79 10.0.32.41 10.0.32.97 [snapshot] 10.0.32.79 recoverySnapFile=/alauda/etcd_bak/snap-202005250843.db [root@tke-init ansible]# cat c.yaml --- - name: etcd snapshot recovery gather_facts: false hosts: all tasks: - name: get the initial-cluster info shell: |+ cat /etc/kubernetes/manifests/etcd.yaml |grep "initial-cluster="|sed 's/.*initial-cluster=//' register: initialCluster - debug: msg: "{