puppet

服务器安全问题，一直是大多数站长很关心却完全不知道该如何解决的。要不就是完全不设防的状态存着侥幸心理在“裸奔”，要不就是花钱让别人帮忙维护，还要确保找的人足够可靠。其实系统本身带有大量的安全工具和安全机制，只要合理的设置并利用他们，就可以防御大部分基础的攻击。比如selinux、snort和honeynet。 统一集中化管理工具 大多数互联网公司来说，服务器的数量相对较大，很多单机的工具就不太合适。这时候可以使用统一集中化的管理工具，有效的简化多台服务器的系统管理工作。Windows下可以用域，linux下可以用ldap，或者像Puppet、Func之类的工具。类似于木马一样，每一台服务器都装一个agent。 最小权限访问控制策略 比如网络访问控制，Windows可以使用IPSec、linux可以使用IPTABLES。针对游戏服务器，那么除了游戏端口，什么都不要让普通用户访问。而web应用就只开放80/443。文件权限控制，不要什么都777，对应在WIndows平台下，不要什么都是Everyone完全控制。 补丁与反病毒 这是大家都比较信赖的方案，但补丁防不住0day漏洞，杀毒软件也可以用免杀绕过（虽然在HIPS的围剿中正越来越难）。补丁和反病毒软件是一个基础必备却并不能依赖的方案。Windows下可以用WSUS进行补丁的部署，Linux下需要通过统一集中化管理工具来推送。

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

简介 puppet是一种Linux、Unix、windows平台的集中配置管理系统，使用自有的puppet描述语言，可管理配置文件、用户、cron任务、软件包、系统服务等。puppet把这些系统实体称之为资源，puppet的设计目标是简化对这些资源的管理以及妥善处理资源间的依赖关系。 puppet采用C/S星状的结构，所有的客户端和一个或几个服务器交互。每个客户端周期的（默认半个小时）向服务器发送请求，获得其最新的配置信息，保证和该配置信息同步。每个puppet客户端每半小时(可以设置)连接一次服务器端, 下载最新的配置文件,并且严格按照配置文件来配置客户端. 配置完成以后,puppet客户端可以反馈给服务器端一个消息. 如果出错,也会给服务器端反馈一个消息。 工作流程 puppet客户端首先会连接到puppet服务器端,并且通过facter工具把客户端的基本配置信息发送给服务器端. 服务器端通过分析客户端的主机名,通过node 定义,找到该主机的配置代码,然后编译配置代码,把编译好的配置代码发回客户端,客户端执行代码完成配置.并且把代码执行情况反馈给puppet服务器端. 常用资源 常见的资源有notify（调试与输出）,file（配置文件）,package（软件安装）,service（服务管理）,exec（执行命令）,cron（定时脚本）,user(用户),group(用户组)

fpm工具安装 CentOS 6.x下安装 #centos6 由于自带yum源中的ruby版本太低，需要如下安装： yum -y install rpm-build yum update nss gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB curl -sSL https://get.rvm.io | bash -s stable source /etc/profile.d/rvm.sh rvm install 1.9.3 gem install fpm rvm use 1.9.3 --default #选择ruby版本 CentOS 7.x下安装 #安装ruby： yum -y install ruby rubygems ruby-devel rpm-build gem install fpm FPM常用参数 -f :强制覆盖[覆盖同名rpm包] -n :指定的rpm包名 -p :指定的rpm包文件放置位置 -v :指定的rpm包版本 -d :指定依赖的软件 ( [-d 'name'] or [-d 'name > version'] 例子: -d 'libstdc+

配置主机名 [root @server ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.220.138 server 192.168.220.139 client [root @client ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.220.138 server 192.168.220.139 client [root @server ~]# rpm -ivh http://yum.puppetlabs.com/el/7/products/x86_64/puppetlabs-release-7-12.noarch.rpm [root @client ~]# rpm -ivh http

提到DevOps这个词，我相信很多人一定不会陌生。 DevOps的历史 在开发人员关注之前，我们传统的IT部门在组织中有两个独立的团队-开发团队和运营团队。 开发团队负责软件开发，开发并确保代码完美运行。经过数小时的努力和大量的反复试验，团队发布了必须由运营团队执行的代码，该团队负责代码的发布和操作。 运营团队将检查应用程序及其性能，并报告所有错误（如果存在）。 尽管听起来很简单和计划周详，但两个主要团队在执行时总是会发生冲突。 例如，让我们说，开发团队使用i7处理器，8GB RAM，操作系统（如Ubuntu）和php 5.6脚本语言开发了代码，而运营团队则使用i5处理器，16GB RAM，与Centos的操作系统运行了相同的代码。和php 7.0编程语言。 当运营团队运行相同的代码时，它将无法正常工作。 原因可能是系统环境不同或缺少任何软件库。 即使该问题可能存在于他们自己的系统中，操作团队仍将此代码标记为错误代码。这导致了开发人员和运营团队之间的来回交流。 为了弥合这种差距，Development（'Dev'）团队和Operations（'Ops'）团队合作开发了DevOps。 例如，为了解决上述问题，开发团队将其代码封装在一个轻量级软件环境的容器中。 该软件环境中封装了所有必需的软件，这些代码或应用程序将需要按预期运行。 开发人员完成工作后

Automation 自动化 需要安装Puppet class nginx { package {"nginx": ensure => 'installed',} #确认Nginx已安装 service {"nginx": ensure => 'true', hasrestart => 'true', #确认开机自启 restart => '/etc/init.d/nginx reload', #重启Nginx } file { "nginx.conf": path => '/etc/nginx/nginx.conf', require => Package['nginx'], notify => Service['nginx'], content => template('nginx/templates/nginx.conf.erb'), user=>'root', group=>'root', mode='0644'; } } Chef 安装Chef package 'nginx' do action :install end service 'nginx' do supports :status => true, :restart => true, :reload => true action [ :start, :enable ] end template 'nginx

Ansible 初试 实验介绍 随着云技术的日渐成熟以及服务器数量的增多，对于运维的日常管理也就逐渐繁杂，因此越来越多的运维管理就趋向于自动化的方式。所以从本周开始将带着大家认识和学习几个常用的自动化运维的工具。 本节主要讲解的是 Ansible 工具，虽然 Chef、Puppet、SaltStack and Fabric 等等这些都是比较流行的自动化运维管理工具，但是相较于 Ansible 来说要复杂得多，不过每个工具也是各有各的好处，这里我们就先来学习这个比较简单的一款自动化运维工具—— Ansible 。 知识点 Ansible 的简介 Ansible 的安装 Ansible 的配置 ad-hoc 临时命令 Ansible 简介 Ansible 是一款基于 Python 开发，能够实现了批量系统配置、程序部署、运行命令等功能的自动化运维工具。Ansible 主要是基于模块进行工作的，本身没有批量部署的能力，真正实现部署功能的是运行的模块。 结构框架 和 Chef、Puppet 刚好相反，Ansible 使用的是无代理体系结构，这种体系结构可以通过防止节点轮询控制机器来减少网络开销。Ansible 提供的结果框架如下所示： 图片来源： https://geekflare.com/ansible-basics/ Ansible ：运行在中央计算机上； Connection