ansible

一 资源限制 1.1 pod资源限制 pod可以包括资源请求和资源限制: 资源请求 用于调度，并控制pod不能在计算资源少于指定数量的情况下运行。调度程序试图找到一个具有足够计算资源的节点来满足pod请求。 资源限制 用于防止pod耗尽节点的所有计算资源，基于pod的节点配置Linux内核cgroups特性，以执行pod的资源限制。 尽管资源请求和资源限制是pod定义的一部分，但通常建议在dc中设置。OpenShift推荐的实践规定，不应该单独创建pod，而应该由dc创建。 1.2 应用配额 OCP可以执行跟踪和限制两种资源使用的配额: 对象的数量：Kubernetes资源的数量，如pod、service和route。 计算资源：物理或虚拟硬件资源的数量，如CPU、内存和存储容量。 通过避免master的Etcd数据库的无限制增长，对Kubernetes资源的数量设置配额有助于OpenShift master服务器的稳定性。对Kubernetes资源设置配额还可以避免耗尽其他有限的软件资源，比如服务的IP地址。 同样，对计算资源的数量施加配额可以避免耗尽OpenShift集群中单个节点的计算能力。还避免了一个应用程序使用所有集群容量，从而影响共享集群的其他应用程序。 OpenShift通过使用ResourceQuota对象或简单的quota来管理对象使用的配额及计算资源。

近期准备将OpenStack平台升级到Ussuri版本。考虑到现在在用的整个OpenStack环境并不复杂，仅有一个 AIO 的单节点，以往升级是在两台服务器间交替进行的，相当于重新部署OpenStack并迁移实例，相当耗时。这是因为OpenStack是无法实现产品级平滑升级的。现在服务器上还是以安装CentOS 7 为主，查看 Ussuri 的发行注记，得知 Ussuri 版本对OS环境要求有了变化，且只支持 Python 3 环境。根据以往的经验，知道 Python 3 和 Python 2 是可以共存并分别调用的，所以想尝试一下 能否在 CentOS 7 1804 上安装 Ussuri。 结论是：OpenStack Ussuri 版本不可以部署在 CentOS 7 1804 平台上，即便解决了 Python 的问题，也会因为 Python组件deltarpm无法被 Python 3 有效调用而导致安装失败。执行 kolla-ansible -i /etc/kolla/all-in-one prechecks 是会提示错误： TASK [prechecks : Checking host OS release or version] ** fatal: [OpenStack]: FAILED! => {"changed": false, "msg": "CentOS

zabbix4.4 自动发现与自动注册 企业中有上千台服务器，手动添加客户端非常耗时间，增加人力、时间成本。zabbix提供了自动发现与自动注册的功能，自动批量发现局域网中的服务器，并自动添加到zabbix监控平台， 一、安装zabbix 基于LNMP的zabbix4.4源码编译安装 二、配置自动发现模板 自动发现到设备 三、配置自动注册动作 自动发现的主机通过发现策略与动作已经添加到列表中，但是目前还无法正常监控，故需要安装agent 四、安装客户端agent 实际场景中自动发现主机非常多，可以通过ansible批量安装，由于只有2台测试机，只用简单脚本批量安装 1.编写自动安装脚本 agent安装步骤可以参考 基于LNMP的zabbix4.4源码编译安装-步骤五 2.zabbix server批量拷贝至客户端 3.批量执行脚本 for ip in {129..135};do ssh -l root 192.168.197.$ip "sh auto_install_zabbix_agent.sh";done 4.自动注册验证 可以看到，客户端已经都加入监控，自动发现与注册就完成了 来源： oschina 链接： https://my.oschina.net/u/4416282/blog/4458159

了解如何通过这些 Ansible 模块实现几乎任何事情。 在我成长的时候，我爷爷在他的花园里有一个棚子。他经常会花几个小时在那里制作和修复东西。这是在我们有互联网之前的事情，所以我花了很多时间看他在那个棚子里创造东西。虽然棚子里有很多工具，从钻头到车床到电器配件，还有很多东西我至今都无法辨认，但他使用的只是他手头的一小部分。然而，他能做到的事情似乎永远没有极限。 我之所以告诉你这个故事，是因为我觉得我的职业生涯是在一个隐喻的棚子里度过的。计算机也是如此多的工具，都在一个狭小（虚拟？）的空间里。而工具棚中又有工具棚 —— 我最喜欢的是 Ansible。最近的 2.9 版本有 3,681 个模块! **3,681 个啊！**当我在 2013 年夏天第一次开始使用 Ansible 时，1.2.1 版本只有 113 个模块，然而，正如 我当时写的 ，我仍然可以实现任何我想象到的东西。 模块是 Ansible 的支柱，是让重任轻装上阵的齿轮。它们被设计为做好一项工作，从而实现了 Unix 哲学 。我们就是这样来把这么多的模块捆绑在一起，作为乐团的指挥，Ansible 现在有很多乐器可以听从它的指挥。 回顾一下我多年来的 Ansible 剧本和角色的 Git 仓库，我发现我只用了 35 个模块。这个小的子集被用来构建大型基础设施。不过，我想知道如果用一个更小的子集可以实现什么？当我回顾这 35

本文为苏宁网络架构师陈刚的原创文章。 01准备测试机 在16G的笔记本没跑起来，就干脆拼凑了一台游戏工作室级别的机器：双路E5-2860v3 CPU，24核48线程，128G DDR4 ECC内存，NVME盘 512G。在上面开5个VM，假装是物理服务器。 · 192.16.35.110 deployer · 192.16.35.111 tf控制器 · 192.16.35.112 openstack服务器，同时也是计算节点 · 192.16.35.113 k8s master · 192.16.35.114 k8s的Node k01，同时也是ops的计算节点 直接使用vagrant拉镜像会很慢，就先下载下来： https://cloud.centos.org/centos/7/vagrant/x86_64/images/ 下载对应的VirtualBox.box文件。 然后使用命令, 命名为vagrant的box： vagrant box add centos/7 CentOS-7-x86_64-Vagrant-2004_01.VirtualBox.box cat << EEOOFF > vagrantfile ###start #-*- mode: ruby -*- #vi: set ft=ruby : Vagrant.require_version ">=2.0.3" #All

配置代码： - git : repo : 'https://foosball.example.org/path/to/repo.git' dest : /srv/checkout version : release - 0.22 参考： https://docs.ansible.com/ansible/latest/modules/git_module.html#parameter-version 来源： oschina 链接： https://my.oschina.net/u/4326389/blog/4404924

网络环境： 一台3550EMI 交换机 ，划分三个vlan，vlan2 为 服务器 所在网络，命名为server，IP地址段 　　为192.168.2.0，子网掩码：255.255.255.0，网关：192.168.2.1，域 服务器 为windows 2000 advance server，同时兼作DNS 服务器 ，IP地址为192.168.2.10，vlan3为客户机1所在网络，IP地址段为192.168.3.0，子网掩码：255.255.255.0，网关：192.168.3.1命名为work01，vlan4为客户机2所在网络，命名为work02，IP地址段为 192.168.4.0，子网掩码：255.255.255.0，网关：192.168.4.1，3550作DHCP 服务器 ，端口1-8划到 VLAN 2，端口9-16划分到 VLAN 3，端口17-24划分到 VLAN 4. 　　 DHCP 服务器 实现功能： dl.bitsCN.com网管软件下载 　　各 VLAN 保留2-10的IP地址不分配置，例如：192.168.2.0的网段，保留192.168.2.2至192.168.2.10的IP地址段不分配。 bitsCN全力打造网管学习平台 　　 安全要求： bbs.bitsCN.com国内最早的网管论坛 　　 VLAN 3和 VLAN 4 不允许互相访问，但都可以访问

一 资源限制 1.1 pod资源限制 pod可以包括资源请求和资源限制: 资源请求 用于调度，并控制pod不能在计算资源少于指定数量的情况下运行。调度程序试图找到一个具有足够计算资源的节点来满足pod请求。 资源限制 用于防止pod耗尽节点的所有计算资源，基于pod的节点配置Linux内核cgroups特性，以执行pod的资源限制。 尽管资源请求和资源限制是pod定义的一部分，但通常建议在dc中设置。OpenShift推荐的实践规定，不应该单独创建pod，而应该由dc创建。 1.2 应用配额 OCP可以执行跟踪和限制两种资源使用的配额: 对象的数量：Kubernetes资源的数量，如pod、service和route。 计算资源：物理或虚拟硬件资源的数量，如CPU、内存和存储容量。 通过避免master的Etcd数据库的无限制增长，对Kubernetes资源的数量设置配额有助于OpenShift master服务器的稳定性。对Kubernetes资源设置配额还可以避免耗尽其他有限的软件资源，比如服务的IP地址。 同样，对计算资源的数量施加配额可以避免耗尽OpenShift集群中单个节点的计算能力。还避免了一个应用程序使用所有集群容量，从而影响共享集群的其他应用程序。 OpenShift通过使用ResourceQuota对象或简单的quota来管理对象使用的配额及计算资源。