ansible

kube-proxy组件是要是为集群内pod应用提供endpoint服务，当我们为一个pod定义了svc时，kube-proxy会自动生成pod与svc的映射关系，并代理到集群内部或宿主机上。 1 安装准备 特别说明：这里所有的操作都是在devops这台机器上通过ansible工具执行；kube-proxy 需要使用kubeconfig认证文件安全访问kube-apiserver：它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。 1.1 环境变量定义 #################### Variable parameter setting ###################### KUBE_NAME=kube-proxy K8S_INSTALL_PATH=/data/apps/k8s/kubernetes K8S_BIN_PATH=${K8S_INSTALL_PATH}/sbin K8S_LOG_DIR=${K8S_INSTALL_PATH}/logs K8S_CONF_PATH=/etc/k8s/kubernetes KUBE_CONFIG_PATH=/etc/k8s/kubeconfig CA_DIR=/etc/k8s/ssl SOFTWARE=/root/software

本系列文档将介绍使用二进制文件部署最新 kubernetes v1.14.2 集群所有步骤，而不是使用 kubeadm 等自动化方式来部署集群。主要适合于有一定 kubernetes 基础，想通过一步步部署的方式来学习和了解系统相关配置、运行原理的同学。也同样适用于测试或生产自建kubernetes集群等应用场景。 一 环境准备 1.1 版本信息 ： OS 系统： Centos 7.6 kubernetes版本：v1.14.2 Etcd数据库：v3.3.13 Network插件：Flanneld 0.11.0 Docker 版本： 18.09.6-CE K8s插件：CoreDns，Heapster，Influxdb，Grafana，Dashboard，elk，Metrics-server Docker仓库：Harbor 1.2 架构概览： 其中： 负载均衡： 采用keepalived主主模式结合haproxy tcp四层代理为kube apiserver提供高可用架构，内网使用内网VIP地址作为集群内所有组件访问地址；外网采用外网vip地址访问，主要为Internet 客户端访问 master集群： 使用keepalived+haproxy部署apiserver集群高可用；其他组件kube-controller-manager，kube-sheduler利用etcd选举机制

在kubernetes组件中，master节点组件主要包括：kube-apiserver，kube-controller-manager，kube-scheduler等三个组件，每个组件功能职责分工不同，这里我们将三个组件部署在同一机器上，分别部署了三台机器。 1 安装准备 1.1 环境变量定义 #################### Variable parameter setting ###################### KUBE_NAME=kube-apiserver K8S_INSTALL_PATH=/data/apps/k8s/kubernetes K8S_BIN_PATH=${K8S_INSTALL_PATH}/sbin K8S_LOG_DIR=${K8S_INSTALL_PATH}/logs K8S_CONF_PATH=/etc/k8s/kubernetes CA_DIR=/etc/k8s/ssl SOFTWARE=/root/software VERSION=v1.14.2 PACKAGE="kubernetes-server-${VERSION}-linux-amd64.tar.gz" DOWNLOAD_URL=“”https://github.com/devops-apps/download/raw/master/kubernetes/$

Ansible基础介绍 我们在做系统运维时，很多时候需要SSH登陆到各个服务器进行各种系统和包的安装启动及状态检查等操作。这些过程很繁琐，而且操作的过程，结果及脚本代码很零散不好管理，容易造成一些不必要的问题。Ansible正好是满足了这个需求，把重复而繁琐的运维操作通过简洁易懂的YAML代码来描述和执行。 Ansible的特点 简洁易懂，功能丰富，扩展方便 只需在主控端安装，无需在被控端安装Agent, 大大简化了部署复杂性 默认使用SSH，不需要额外的安全框架 YAML描述性语言，把部署过程体现为代码，从而可以把部署过程纳入代码的版本管理 Ansible架构介绍 -- 图片来源： https://geekflare.com/ansible-basics/ 上图演示了如何通过Ansible对共有云或私有云的一堆机器进行运维操作。 模块介绍： 核心：最中间的是Ansible自动化执行引擎，接受用户输入，调度各个模块完成操作 Inventory: 所有被控端的host的IP地址清单，可以按需进行分组归类 Playbooks: 配置中心，定义操作的流程（play）, 每一个play可以定义一系列顺序执行的task, 每个task定义具体执行的action module: action通过module封装，module通过SSH推送到被控端执行，执行后自动删除 plugin:

Ansible： Configuration、Command and Control 是什么 ？ SSH-based configuration management, deployment, and task execution system 运维工具的分类： agent：基于专用的agent程序完成管理功能，puppet, func, zabbix, ... 需要有代理程序的工具 降低了系统级账号和密码泄露的风险 agentless：基于ssh或telnet服务完成管理，ansible, fabric, ... 无需代理程序的工具 架构： Ansible Core Modules： Core Modules Customed Modules自定义模块 Host Iventory 主机清单，定义要管理的主机 Files CMDB PlayBooks剧本，定义哪个主机扮演什么角色 Hosts roles时我们定义好的调用模块完成的任务功能 Connection Plugins：连接插件 特性： 模块化：调用特定的模块，完成特定的任务； 基于Python语言研发，由Paramiko, PyYAML和Jinja2三个核心库实现； 部署简单：agentless； 支持自定义模块，使用任意编程语言； 强大的playbook机制； 幂等性； Eg： 主机67 Yum install

先简单描述一下环境，Jenkins部署在私有云，从git拉取代码并编译后会调用脚本将jar包部署到阿里云的应用服务器。 阿里云应用服务器无公网IP，通过跳板机登录。就产生了连续调用脚本，穿透跳板机部署到阿里云内网的需求。 服务器信息： 主机名称 IP git server 10.150.27.51 jenkins server 10.150.27.52 jump server 1.1.1.1/192.168.2.20 app server1 192.168.2.21 app server1 192.168.2.22 拓扑图如下： 1.部署脚本01-backend-earphone-8888.sh (Jenkins server) 主要实现功能： 将跳板机1.1.1.1上面临时目录/data/deploy/pccode/earphone内容情况 拷贝Jenkins编译生成的jar包文件（earphone-1.08888.jar）至跳板机/data/deploy/pccode/earphone目录 调用跳板机脚本进行部署/data/deploy/script/earphone.sh [root@bobo365 prod]# more backend-earphone-8888.sh #!/bin/bash . /etc/init.d/functions node="1.1.1.1"

前言 大家做运维普遍经历这样的过程： 首先我们会把操作做一个标准化，这个阶段是运维质量的提升的阶段。 在标准化实施完以后，由于数目的增加，或者是一些运维场景的增多，我们会逐步的进行一些工具化和自动化，这个阶段我们的运维的效率得到提升。 但是众多的工具以及自动化脚本，会让我们的管理过程中比较困难，随着人员的变动或者是一些工具维护过程中的差错，我们的自动化运维工具的受众群体不太稳定。 这个时候我们就需要一个平台将我们的运维工具以及运维过程中的一些经验进行沉淀，借助这个平台实现我们的智能化运维，于是我们从运维人员的需求和体验出发出发进行了一个运维平台产品化的构建。 银行卡组织云运维平台的概况 我给大家介绍一下我们IT体系建设的情况，差不多十年前我们以ITIL为基础构建了流程平台，变更、事件、问题、服务等流程通过这个平台进行流转。 在五年前我们从开放平台转化为云运维平台，在这个过程中，我也建立了IaaS虚拟化资源平台，同时我们也跟业界一样构建了CMDB，用于同意管理运维数据。 但是在运转下来以后，我们发现还有很多需求需要实现，主要三个方面： 软硬件节点数目不断增加，日常运维迫切需要一个适应各种运维场景的高效自动化平台，减少重复劳动。 需求是将运维人员的经验需要在一个平台沉淀，形成一个智能化场景库，将运维服务或能力的复用，从而提高整体运维质量和运维效率。

目录 0、Ansible模块语法 1、Command模块 2、Shell模块 3、Scripts模块 4、Copy模块 5、File模块 6、Yum模块 7、Service模块 8、Cron模块 9、Group模块 10、User模块 11、Mount模块 12、Unarchive模块 13、Git模块 14、Systemd模块 0、Ansible模块语法 在ansible中是指需要快速执行一条命令，并且不需要保存的命令，对于复杂的命令则为playbook 查看模块帮助：ansible-doc -l // 统计模块数量 $ ansible-doc -l |wc -l 3387 // ansible有大量的模块 Ansible模块语法： ansible [管理主机信息或者主机组信息] -m [模块名称] -a [相关模块参数] 主机信息：远程主机IP地址；远程主机组名称；远程所有主机all -m：指定相应模块 -a：利用模块中某些参数功能 -f ：定义每次输出内容的数量 Ansible注意事项颜色信息： 绿色：对远程节点不进行相应修改，或者只是对远程节点信息进行查看 红色：操作执行命令有异常 黄色：对远程节点进行相应修改 深紫色：表示对命令执行发出警告信息（可能存在的问题，给你提示建议） 1、Command模块 command模块的作用：默认模块, 在远程主机执行命令 ；默认模块

Notify所在的Task状态为Changed时触发Handler Task， Handler与普通的Task没有任何区别。 示例 修改Apache配置后，重启Apache服务 --- - name: stup web server hosts: dev tasks:- name: copy apache index.html copy: src: index.html dest: /var/www/html/index.html notify: - restart httpd　　# 调用handler，只有在该Task状态为Change时才会触发Handler。 handlers: - name: restart httpd service: name: httpd enabled: true state: restarted 来源： https://www.cnblogs.com/vincenshen/p/12627784.html

Ansible Playbook 基本概述与使用案例 主机规划 添加用户账号 说明： 1、 运维人员使用的登录账号； 2、 所有的业务都放在 /app/ 下「yun用户的家目录」，避免业务数据乱放； 3、 该用户也被 ansible 使用，因为几乎所有的生产环境都是禁止 root 远程登录的（因此该 yun 用户也进行了 sudo 提权）。 1 # 使用一个专门的用户，避免直接使用root用户 2 # 添加用户、指定家目录并指定用户密码 3 # sudo提权 4 # 让其它普通用户可以进入该目录查看信息 5 useradd -u 1050 -d /app yun && echo '123456' | /usr/bin/passwd --stdin yun 6 echo "yun ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers 7 chmod 755 /app/ Ansible 配置清单Inventory 之后文章都是如下主机配置清单 1 [yun@ansi-manager ansible_info]$ pwd 2 /app/ansible_info 3 [yun@ansi-manager ansible_info]$ cat hosts_key 4 # 方式1、主机 + 端口 + 密钥 5 [manageservers] 6 172.16.1