ansible

　　Linux是操作系统之一，也是现在大多数企业都比较喜欢使用的系统，可以从事的岗位有很多，为就业者提供广阔的发展空间。那么Linux相关岗位有哪些?具体工作内容是什么? 　　1、Linux运维工程师 　　一般从企业入门到中级Linux运维工程师的工作大致有：挑选IDC机房及带宽、购买物理服务器或云服务、购买及使用CDN服务、搭建部署程序开发及用户的访问系统环境、对数据进行备份及恢复、处理网站运行中的各种故障、对网站的故障进行监控、解决网站运行的潜在安全问题、开发自动化脚本程序提高工作效率、规划网站架构、程序发布流程和规范，制定运维工作制度和规范、配合开发人员部署及调试产品研发需要的测试环境、代码发布等工作需求，公司如果较小可能还会兼职网管、网络工程师、数据库管理员、安全工程师、技术支持等职责。 　　2、Linux运维架构师 　　1)自动化代码上线(SVN/GIT+Jenkins+MVN)解决方案;2)云计算部署架构及Docker微服务架构方案;3)服务自动化扩容方案(KVM/OpenStack/Docker+Ansible+Zabbix);4)10万并发的网站架构、秒杀系统的架构及解决发你个案;5)多IDC机房互联方案、全网数据备份解决方案、账号统一认证方案;6)数据库、存储及各重要服务节点的集群和高可用方案;7)各网络服务的极端优化方案、服务解耦/拆分;8)运维流程、制度

最近介绍了很多ansible的使用案例，这次就回归正轨，介绍如何使用zabbix监控CDN带宽，做到在带宽出现异常的时候及时知晓，访问带宽异常造成的经济损失。 这里以蓝汛CDN为例，监控的方法是通过CDN给与的api接口。备注：目前蓝汛api接口只能查看单独频道的带宽，无法查看所有频道的，并且频道id还需要你自己或者客服帮你查下，十分不方便。 1、api接口信息为： (一) 接口地址： https://api.chinacache.com/reportdata/monitor/query?type=monitor&withtime =true&layerdetail=true&username=xxx&pass=xxx&billingid=123&starttime=2 01009190000&endtime=201009192359 说明： 1. 目前提供两种协议的接口：一种是HTTP，另一种是HTTPS，可根据需要自 行决定使用任何其中一种 2. 用户可以通过post 或get 方式访问协议的接口 (二) 参数说明： type=monitor【必选参数】：查询类型 withtime=true【可选参数】：用来表明查询结果中是否显示详细时间戳 layerdetail=true【可选参数】：用来表明查询结果中是否显示分层数据 username【必选参数】：用户名，客户在portal

1. ansible playbook介绍 playbook是ansible用于配置，部署，和管理被控节点的剧本。 通过playbook的详细描述，执行其中的一系列tasks，可以让远端主机达到预期的状态。playbook就像Ansible控制器给被控节点列出的的一系列to-do-list，而被控节点必须要完成。也可以这么理解，playbook 字面意思，即剧本，现实中由演员按照剧本表演，在Ansible中，这次由计算机进行表演，由计算机安装，部署应用，提供对外服务，以及组织计算机处理各种各样的事情。 2. playbook的框架 3. playbook的架构图 官方给出的架构图如下: production # 正式环境的inventory文件 staging #测试环境用的inventory文件 group_vars/ # 机器组的变量文件 group1 group2 host_vars/ #执行机器成员的变量 hostname1 hostname2 ================================================ site.yml # 主要的playbook剧本 webservers.yml # webserver类型服务所用的剧本 dbservers.yml # 数据库类型的服务所用的剧本 roles/ webservers/

前言： ​ 有时需要对yaml文件中的某些敏感字段进行加密，这时就需要‘ansible-vault encrypt_string ’加密字符串，在使用过程中发现报错：Vault format unhexlify error: Odd-length string fatal，使用ansible-lint工具进行调试排查错误，本文记录了在使用过程中报错及解决的详细过程。 环境说明： 主机名 操作系统版本 ip ansible version 备注 ansible Centos 7.6.1810 172.27.34.51 2.9.9 ansible管理服务器 test85 Centos 7.6.1810 172.27.34.85 / 被管服务器 一、encrypt_string 1.原始yaml文件 --- - hosts: test85 gather_facts: false vars: test_user: "testuser" test_passwd: "test123" tasks: - name: echo user and passwd debug: msg: "user is {{ test_user }},passwd is {{ test_passwd }}" 用户名为testuser，密码为test123 2.对test_passwd字段加密 [root

Kubernetes正在不断加快在云原生环境的应用，但如何以统一、安全的方式对运行于任何地方的Kubernetes集群进行管理面临着挑战，而有效的管理工具能够大大降低管理的难度。 K9s k9s是基于终端的资源仪表板。它只有一个命令行界面。无论在Kubernetes仪表板Web UI上做什么，都可以在终端使用K9s仪表板工具进行相同的操作。k9s持续关注Kubernetes集群，并提供命令以使用集群上定义的资源。 K9s的功能包括集群的实时跟踪，使用K9s皮肤自定义视图，通过Kubernetes资源轻松遍历，向下通过选项以检查集群资源问题，提供扩展的插件来创建你自己的命令。 Rancher Rancher是开源容器管理平台，任何企业都可以轻松采用Kubernetes。可以部署和管理在谷歌云GKE，AWS EKS，Azure AKS中运行的托管Kubernetes集群，也可以仅在选择的虚拟机或裸机基础架构上部署Kubernetes。 Rancher简化了管理员的操作，主要功能包括监控集群的运行状况，设置警报和通知，启用集中式日志记录，定义和应用全局安全策略，建立身份验证并执行后台策略，管理和扩展基础架构等。 随着企业中Kubernetes的采用速度，Rancher让用户可以直接访问Kubernetes API和CLI。Rancher的新智能界面简化了应用程序管理

前言： ​ 生产上新入网的服务器都需要安装prometheus的监控客户端软件，主要步骤有：新建监控用户、拷贝客户端软件、拉起客户端进程、开机自启动。本文记录了使用ansible的role方式批量快速的安装该客户端软件。 ​ 本文使用到的主要模块：user、stat、copy、shell、script、lineinfile等。 环境说明： 主机名 操作系统版本 ip ansible version 备注 ansible Centos 7.6.1810 172.27.34.51 2.9.9 ansible管理服务器 ansible-awx Centos 7.6.1810 172.27.34.50 / 被管服务器 一、创建目录列表 [root@ansible ~]# cd /etc/ansible/roles [root@ansible roles]# ansible-galaxy init prometheus - Role prometheus was created successfully [root@ansible roles]# tree prometheus prometheus ├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├──

了解了云行业的标准，该向你的家庭实验室自动添加新设备和用户了。 Cloud-init （可以说）是一个标准，云提供商用它来为云实例提供初始化和配置数据。它最常用于新实例的首次启动，以自动完成网络设置、账户创建和 SSH 密钥安装等使新系统上线所需的任何事情，以便用户可以访问它。 在之前的一篇文章《 修改磁盘镜像来创建基于树莓派的家庭实验室 》中，我展示了如何为像树莓派这样的单板计算机定制操作系统镜像以实现类似的目标。有了 Cloud-init，就不需要向镜像中添加自定义数据。一旦在镜像中启用了它，你的虚拟机、物理服务器，甚至是小小的树莓派都可以表现得像你自己的 “家庭私有云” 中的云计算实例。新机器只需插入、打开，就可以自动成为你的 家庭实验室 的一部分。 说实话，Cloud-init 的设计并没有考虑到家庭实验室。正如我所提到的，你可以很容易地修改给定的一套系统磁盘镜像，以启用 SSH 访问并在第一次启动后对它们进行配置。Cloud-init 是为大规模的云提供商设计的，这些提供商需要容纳许多客户，维护一组小的镜像，并为这些客户提供访问实例的机制，而无需为每个客户定制一个镜像。拥有单个管理员的家庭实验室则不会面临同样的挑战。 不过，Cloud-init 在家庭实验室中也不是没有可取之处。教育是我的家庭私有云项目的目标之一，而为你的家庭实验室设置 Cloud-init

需求: 本地化部署一个mysql服务，重启自动启动 mysql 服务 重启服务自己启动 方案 方案一: 本地安装后，service 服务托管 方案二: ansible + docker 重复的事情只做一次的策略，使用ansible + docker docker run -d: 后台运行 --restart=always: 满足服务重启 docker restart docker run参考 restart 参数详解 参数 no – 容器退出时不要自动重启。这个是默认值。 on-failure[:max-retries] – 只在容器以非0状态码退出时重启。可选的，可以退出docker daemon尝试重启容器的次数。 always – 不管退出状态码是什么始终重启容器。当指定always时，docker daemon将无限次数地重启容器。容器也会在daemon启动时尝试重启，不管容器当时的状态如何。 unless-stopped – 不管退出状态码是什么始终重启容器，不过当daemon启动时，如果容器之前已经为停止状态，不要尝试启动它。 本机重启后效果: ansible-roles-task-main.yml 官方镜像 常用db之docker-compose - name: "create db_mysql dir" file: path: "{{ db_mysql_root

ansible介绍： ansible是一个基于python开发的轻量级自动化运维管理工具，可以用来批量执行命令，安装程序，支持playbook编排。它通过ssh协议来连接主机，省去了在每一台主机安装客户端的麻烦，相对比puppet和saltstack，显得更为简单和轻量。 ansible命令参数： Usage: ansible <host-pattern> [options] Options: -a MODULE_ARGS, --args=MODULE_ARGS 模块的参数 module arguments --ask-vault-pass ask for vault password -B SECONDS, --background=SECONDS 异步运行，在X秒后失效 run asynchronously, failing after X seconds (default=N/A) -C, --check don't make any changes; instead, try to predict some 测试运行后改变的内容，不会执行 of the changes that may occur -D, --diff when changing (small) files and templates, show the 在更改文件时，可以显示文件的不同

这是翻译自OpenStack官方文档的 Kolla-Ansible部分，当前适用于OpenStack Ussuri 版本。 之所以会有二次修订这个文档的想法，原因有二：一是在河南的大环境下，研究源码部署大规模OpenStack集群的内容实属屠龙之技，河南的OpenStack技术市场上绝大部分在采用单一节点的部署，最多会借助Kolla-Ansible二进制部署方式搭建一个资源利用并不充分的3节点HA。相比于在开源社区推崇的源代码部署方式，河南OpenStack技术市场上连自建内部YUM源的方式都不采用，反而采用有第三方项目构建的Kolla-Ansible二进制在线部署的方式。对于不追求自助掌握OpenStack主线技术、只是希望借助“OpenStack云计算”这个流行热词贩卖硬件的河南公司而言，采用Kolla-Ansible二进制在线部署单节点OpenStack平台，的确是一个比较经济的选择。而我目前还需要在河南停留一段时间，不想被饿死的话，最好合适违心附和一下这里的虚假宣传。二是我一直在寻求能把OpenStack组件和某个Linux发行版组合在一起的方案，最终能够成为一个定制化的OS镜像，可以像借助DVD镜像离线安装一个操作系统一样完全离线部署OpenStack平台。尽管在这方面已经有人做过探索了，但从其他人对已有方式的复用来看，效果并不尽如人意，构建失败的比例很高