一次puppet部署自动化的尝试

背景:

大约有20台的生产和测试主机(Centos5.3),有6个大模块,以前都是用手动安装的,费时费力,有时也会手动操作出错。

目标

希望用puppet来实现部署的自动化

下面以其中的一个模块的自动化部署尝试来讲解如何实现用puppet的部署自动化。

前提

在一台测试机上安装puppet master,一台装puppet agent.具体的安装和配置过程就不再讲述了,网上的资料一堆堆的。

现在着重讲述如何配置puppet的类。

  • 创建一个模块,叫ppe
    /etc/puppet/modules/ppe/{manifests,templates,files}
  • 编辑ppe的类文件:/etc/puppet/modules/ppe/manifests/ini.pp

内容如下:

  1. 检查war包放在/nishome/ppeuser001/installation/frontend/的目录下面
      file { ‘frontend.war‘:
      path => ‘/nishome/ppeuser001/installation/frontend/frontend.war‘,
      ensure => present,
      }
  2. 备份现在的部署包

    exec { ‘ppefe_install_bp‘:
         path       => ‘/bin‘,
         command      => ‘cp -R /nishome/ppeuser001/frontend.war /tmp/frontend_backup‘,
         require    => File[‘frontend.war‘],
         notify     => Exec[‘ppefe_install_cp‘],
        }

  3. 将包拷贝到安装目录(出于演示的目的,安装目录采用了/tmp)

    exec { ‘ppefe_install_cp‘:
         path       => ‘/bin‘,
         command    => ‘cp /nishome/ppeuser001/installation/frontend/frontend.war /tmp‘,
         require    => Exec[‘ppefe_install_bp‘],
        }

  4. 执行安装脚本test.sh,加了provider这个参数,否则运行SHELL脚本会失败。

    exec { ‘ppefe_install‘:
         path       => ‘/nishome/ppeuser001/‘,
         command    => ‘test.sh‘,
         provider   => ‘shell‘,
         require    => Exec[‘ppefe_install_cp‘],
         notify     => Exec[‘ppefe_install_conf‘],
        }

  5. 恢复配置文件(因为安装包里面不提供环境的配置文件,所以需要手动恢复)。

exec { ‘ppefe_install_conf‘:
     path       => ‘/bin‘,
     command    => ‘cp /nishome/ppeuser001/installation/frontend/properties /tmp ‘,
     require    => Exec[‘ppefe_install‘],
     notify     => Exec[‘ppefe_install_post‘],
    }

6. 修改文件目录的属性(因为puppet默认都是以root的用户来执行,所以所有涉及到的文件的owner和group都是root,所以在部署后需要修改属性)。最后的notify提示语法错误,不知何故。注释掉后可以运行。

exec { ‘ppefe_install_post‘:
     path       => ‘/bin‘,
     command    => ‘chown -R ppeuser001:ppeuser001 /tmp/frontend.war ‘,
     require    => Exec[‘ppefe_install_conf‘],
#     notify   { "Deployment is complete" },
    }

  • 将模块添加到节点配置文件:

node ‘alihzppe002.ha.cekasp.cn‘ {
    include ppe
}
$pwd
/etc/puppet/manifests/nodes

  • 将测试节点载入到site.pp

    vim /etc/puppet/manifests/site.pp
    import "nodes/alihzppe002.ha.cekasp.cn"

  • 在puppet agent端执行:sudo puppet agent --test --server alihzppe001.ha.cekasp.cn --debug

执行的输出:

Debug: /Stage[main]/Ppe/Exec[ppefe_install_cp]/require: requires Exec[ppefe_install_bp]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_post]/require: requires Exec[ppefe_install_conf]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_bp]/require: requires File[frontend.war]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_bp]/notify: subscribes to Exec[ppefe_install_cp]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_conf]/require: requires Exec[ppefe_install]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_conf]/notify: subscribes to Exec[ppefe_install_post]
Debug: /Stage[main]/Ppe/Exec[ppefe_install]/require: requires Exec[ppefe_install_cp]
Debug: /Stage[main]/Ppe/Exec[ppefe_install]/notify: subscribes to Exec[ppefe_install_conf]
Info: Applying configuration version ‘1404266209‘
Debug: Exec[ppefe_install_bp](provider=posix): Executing ‘cp -R /nishome/ppeuser001/frontend.war /tmp/frontend_backup‘
Debug: Executing ‘cp -R /nishome/ppeuser001/frontend.war /tmp/frontend_backup‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_bp]/returns: executed successfully
Info: /Stage[main]/Ppe/Exec[ppefe_install_bp]: Scheduling refresh of Exec[ppefe_install_cp]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_bp]: The container Class[Ppe] will propagate my refresh event
Debug: Exec[ppefe_install_cp](provider=posix): Executing ‘cp /nishome/ppeuser001/installation/frontend/frontend.war /tmp‘
Debug: Executing ‘cp /nishome/ppeuser001/installation/frontend/frontend.war /tmp‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_cp]/returns: executed successfully
Debug: /Stage[main]/Ppe/Exec[ppefe_install_cp]: The container Class[Ppe] will propagate my refresh event
Debug: Exec[ppefe_install_cp](provider=posix): Executing ‘cp /nishome/ppeuser001/installation/frontend/frontend.war /tmp‘
Debug: Executing ‘cp /nishome/ppeuser001/installation/frontend/frontend.war /tmp‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_cp]: Triggered ‘refresh‘ from 1 events
Debug: /Stage[main]/Ppe/Exec[ppefe_install_cp]: The container Class[Ppe] will propagate my refresh event
Debug: Exec[ppefe_install](provider=shell): Executing ‘/bin/sh-ctest.sh‘
Debug: Executing ‘/bin/sh -c test.sh‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install]/returns: executed successfully
Debug: /Stage[main]/Ppe/Exec[ppefe_install]: The container Class[Ppe] will propagate my refresh event
Info: /Stage[main]/Ppe/Exec[ppefe_install]: Scheduling refresh of Exec[ppefe_install_conf]
Debug: Exec[ppefe_install_conf](provider=posix): Executing ‘cp /nishome/ppeuser001/installation/frontend/properties /tmp ‘
Debug: Executing ‘cp /nishome/ppeuser001/installation/frontend/properties /tmp ‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_conf]/returns: executed successfully
Info: /Stage[main]/Ppe/Exec[ppefe_install_conf]: Scheduling refresh of Exec[ppefe_install_post]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_conf]: The container Class[Ppe] will propagate my refresh event
Debug: Exec[ppefe_install_conf](provider=posix): Executing ‘cp /nishome/ppeuser001/installation/frontend/properties /tmp ‘
Debug: Executing ‘cp /nishome/ppeuser001/installation/frontend/properties /tmp ‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_conf]: Triggered ‘refresh‘ from 1 events
Info: /Stage[main]/Ppe/Exec[ppefe_install_conf]: Scheduling refresh of Exec[ppefe_install_post]
Debug: /Stage[main]/Ppe/Exec[ppefe_install_conf]: The container Class[Ppe] will propagate my refresh event
Debug: Exec[ppefe_install_post](provider=posix): Executing ‘chown -R ppeuser001:ppeuser001 /tmp/frontend.war ‘
Debug: Executing ‘chown -R ppeuser001:ppeuser001 /tmp/frontend.war ‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_post]/returns: executed successfully
Debug: /Stage[main]/Ppe/Exec[ppefe_install_post]: The container Class[Ppe] will propagate my refresh event
Debug: Exec[ppefe_install_post](provider=posix): Executing ‘chown -R ppeuser001:ppeuser001 /tmp/frontend.war ‘
Debug: Executing ‘chown -R ppeuser001:ppeuser001 /tmp/frontend.war ‘
Notice: /Stage[main]/Ppe/Exec[ppefe_install_post]: Triggered ‘refresh‘ from 2 events
Debug: /Stage[main]/Ppe/Exec[ppefe_install_post]: The container Class[Ppe] will propagate my refresh event
Debug: Class[Ppe]: The container Stage[main] will propagate my refresh event
Debug: Finishing transaction 70208250166440
Debug: Storing state
Debug: Stored state in 0.02 seconds
Notice: Finished catalog run in 2.96 seconds

从结果来看是成功的,所以用puppet来实现应用的部署自动化是可行的,但是问题是用puppet来管理20台机子的部署效率到底有没有得到提升,值不值得用这个工具来实现?

而且puppet本身是一个系统管理员的工具,用到应用层面,好象就不是一把“利剑”了,比如上述的六个部署步骤,改用shell脚本来直接运行,效率肯定更高,是吧?

仅个人观点。

对于puppet exec命令的讲解,推荐:http://blog.chinaunix.net/uid-20639775-id-3317595.html

一次puppet部署自动化的尝试,布布扣,bubuko.com

时间: 2024-11-25 04:58:28

一次puppet部署自动化的尝试的相关文章

puppet部署与应用

防伪码:忽如一夜春风来,千树万树梨花开. 第十二章 puppet部署与应用 前言:作为一名运维工程师,就需要寻找一款能够降低工作量的工具.那么今天就给大家介绍一批工具,这批工具是"可编程"的,只需要为这批工具写上几行代码,它便会自动完成所有的工作,这批工具就是运维自动化puppet(为什么说是一批工具,因为软件不止一个).Puppet可以针对多台服务器进行统一的操作,例如:软件分发,统一执行脚本,在服务器上写好脚本分发给客户机,客户机就会自动执行,减少了人力及误操作风险.Puppet与

Puppet实现自动化运维

Puppet实现自动化运维 一.案例分析 1.案例概述: 随着服务器数量的增多,系统管理员任务量也逐渐增加,这时就需要简洁的.强大的框架来完成系统管理任务为实现这一目的,我们将引入一批工具,这批工具是"可编程"的,系统管理员只需要为这批工具写上几行"代码",它便会自动完成所有的工作,这批工具就是运维自动化puppet 在一些大型互联网企业中,运维自动化管理着几百甚至上千台服务器,它可以针对多台服务器进行统一操作,例如部署统一软件.进行统一上线维护等,而且能够快速完成

【中级篇】puppet部署与应用

Puppet部署与应用 1.          实验需求: 1)     2台服务器部署puppet服务 2)   1台服务器做puppetmaster和NTP Server 3)   实现主动拉取,服务器推送同步. 2.          实验环境: 主机 操作系统 IP地址 主要软件 Puppetmaster NTP Server CentOS6.5 X86_64 192.168.10.30 Facter-1.7.1.tar.gz Puppet-2.7.21.tar.gz Puppetcli

Puppet 部署tomcat

 Puppet 部署tomcat Tomcat运行需要java环境,所以需要同时安装tomcat和java, 相对应的puppet也需要编写两个模块 tomcat 和java(puppet一般以模块的形式来部署软件) 一.java模块 1.1创建模块目录结构    [[email protected] ~]# mkdir –vp /etc/puppet/modules/java7/{files,templates,manifests} files目录存放需要分发给客户端的文件 templates

Maven实现Web应用集成测试自动化 -- 部署自动化(WebTest Maven Plugin)

上篇:Maven实现Web应用集成测试自动化 -- 测试自动化(WebTest Maven Plugin) 之前介绍了如何在maven中使用webtest插件实现web的集成测试,这里有个遗留问题,就是在执行maven的intergation测试时候web应用已经部署在容器中处于in service的状态,那么web应用的部署是否可以自动化呢?在我们公司的系统中,由于使用了weblogic的cluster,自己写了脚步来实现部署,花费了不少人力物力,其实java web应用早就有福音了,是一款自

使用puppet实现自动化运维

使用puppet实现自动化运维 服务概述: 1.什么是puppet puppet是一个为实现数据中心自动化管理而设计的配置管理软件.是一种Linux.Unix平台的集中配置管理系统,使用ruby语言,可管理配置文件.用户.cron任务.软件包.系统服务等.puppet把这些系统实体称之为资源,puppet的设计目标是简化对这些资源的管理以及妥善处理资源间的依赖关系. 2.Puppet的工作模式 Puppet是一个C/S架构的配置管理工具,在中央服务器上安装puppet-server软件包(被称作

Puppet部署:安装puppet server、client

Puppet部署:安装puppet server.client puppet与其他手工操作工具有一个最大的区别就是 puppet的配置具有稳定性,因此你可以多次执行puppet,一旦你更新了你的配置文件,puppet就会根据配置文件来更改你的机器配置,通常每30分钟检查一次. AD:2014WOT全球软件技术峰会北京站 课程视频发布 puppet与其他手工操作工具有一个最大的区别就是 puppet的配置具有稳定性,因此你可以多次执行puppet, 一旦你更新了你的配置文件,puppet就会根据配

puppet 部署 horizon server 所需的参数和部署逻辑

所需要的参数: $secret_key, $bind_address = '127.0.0.1', $cache_server_ip = '127.0.0.1', $cache_server_port = '11211', $swift = false, $quantum = false, $package_ensure = present, $horizon_app_links = false, $keystone_host = '127.0.0.1', $keystone_port = 50

关于自动化部署平台的尝试

前言 参加过两次公司生产环境的版本更新,最近一次让我萌生了开发一个自动化部署平台的念头.虽然网上也有不少的自动化部署软件,但还是想自己动手写一个.一来是为了让平台更适应当前的实际情况,也利于以后自己对平台通用性的扩展:二来是为了锻炼自己,给自己的空闲时间找点事情做,不至于虚度时光. 以下是整理出的初稿,想到的点比较简单,后面会持续完善. 如果本文有幸被您看到,望能指点一二. 不管是积极的还是消极的,请留下您的看法. 背景 程序开发好之后免不了部署.刚开始还好,手动打包.上传.部署,也不需要多长时