2015年5月27日星期三

svn利用钩子脚本功能实现代码同步到web目录

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订
svn利用钩子脚本功能实现代码同步到web目录  阅读原文»

svn利用钩子脚本功能实现代码同步到web目录

一、hook简单介绍

为了方便管理员控制提交的过程 ,Subversion 提供了 hook机制。当特定的 事件发生时,相应的 hook会被调用, hook其实就相当于特定事件的处理函数。每个hook 会得到与它所处理的事件相关的参数,根据 hook的返回值, Subversion会决定是否继续当前的提交过程

要实际安装一个可用的钩子,你需要在 repos/hooks目录下安装一些与钩子同名(如 start-commit或者post-commit)的可执行程序或脚本。

二、本地机器SVN自动更新

1. export方式(备份)

在使用svn客户端时,有可能需要对某一个版本进行本地备份,比如制作成压缩包进行发布,这时候需要从svn文件夹中提取出内容,去除.svn等隐藏的svn配置文件。最笨的方法拷贝一份出来,然后显示隐藏文件,把所有 .svn文件夹都删掉。在svn菜单中,可以找到export命令,这个命令可以将当前svn目录中的内容干净地导出到指定的目录

例如你版本库的svn访问地址是http://10.30.11.12:8080/svn/project1,你想把这个版本库下的/trunk/web文件夹发布到tomcat上,发布到tomcat的文件夹地址是d:/tomcat/opt/web,svn的管理员用户名是abc,密码是12345,那么这个钩子程序应该就是:
svn export http://10.30.11.12:8080/svn/project1/trunk/web d:/tomcat/opt/web --force --username abc --password 12345 --no-auth-cache

注:
--force 是说强制覆盖d:/tomcat/opt/web这个文件夹,避免这个文件夹不为空时报错
--username abc --password 12345 是自动将用户名和密码作为参数传送进去
--no-auth-cache 是说不缓存用户名和密码,这是出于安全考虑

2.update方式

修改hooks/post-commit

export LANG=en_US.UTF-8
SVN=/usr/bin/svn

STATIC_DIR=/web/root/wwwdeng #注意权限问题$SVN update $STATIC_DIR --username deng --password 123456 --no-auth-cache

#必须加上--no-auth-cache不然会报错!!

默认使用的shell类型是sh,最好改成bash,sh是bash的子集,centos中sh其实就是软链接到bash

wKiom1VjzKaCE3pRAAFTxyIwIrs242.jpg

3.update和export比较

update会生成一个隐藏.svn文件夹,这个文件夹是我们不需要的,当然了,如果整个发布的内容很多的话,建议还是用update,而不用export,因为update只更新有变化的部分,而export将重新导出所有内容,网络消耗比update大。

三、svn实现远程机器自动更新

首先实现A机器通过ssh无密码登陆B机器, 修改A机器的post-commit文件

/usr/bin/ssh -l root 192.168.127.183 "/bin/bash /home/www/svnup.sh"

然后在B机器的/home/www/目录创建svnup.sh可执行文件

vim/home/www/svnup.sh

/usr/bin/svn update /web/root/code

版本库有提交请求的时候自动会执行post-commit脚本,post-commit脚本通过ssh让远程机器执行shell脚本自动更新svn。

附注:

@echo off并不是DOS程序中的,
而是DOS批处理中的。
当年的DOS,所有操作都用键盘命令来完成,
当你每次都要输入相同的命令时,
可以把这么多命令存为一个批处理,
从此以后,只要运行这个批处理,
就相当于打了几行、几十行命令。

DOS在运行批处理时,
会依次执行批处理中的每条命令,
并且会在显示器上显示,
如果你不想让它们显示,
可以加一个"echo off"

当然,"echo off"也是命令,
它本身也会显示,
如果连这条也不显示,
就在前面加个"@"。

说了这么多,
我觉得非常详细了,
可能你还是不懂。
没有经过DOS时代的人,
想法跟我们是有区别的。

本文出自 "一无所有-天行者" 博客,请务必保留此出处http://tianxingzhe.blog.51cto.com/3390077/1655385

每日博报 精彩不止一点

迟来的观后感――伪存储专家谈IOPS  阅读原文»


微信号VMCloud

篇前语:

看到封面,相信参加过在北京举行的年亚太区域MVP Open Day的朋友一定不陌生,当时这篇名字为"Hyper-V的数学作业"的课程震撼了在场的每个人的心,包括笔者跟当时跟我一起前往的领导也深深被贾浩老师这篇既有实例又有数据的公开课所启发并在之后的项目中一直收益。当时听完贾老师的课之后,我甚至直接联系到贾老师本人跟他探讨IOPS之余,还要了课件继续做研究(由于保密协议要求,该课件不方便公开,抱歉抱歉,不过本篇解读将会"隐晦"地分享该课件的精华之处,虽远不及贾老师现场讲解的万分之一,但权当抛砖引玉),以下是当年跟贾老师的邮件:

笔者一直忙于应付考试、项目等事没时间整理总结这篇微文,众所周知,目前的虚拟化实际上已经发展到几乎人人皆知的地步,在做虚拟化的过程中,可能很多人或多或少会遇到虚拟机卡、应用莫名访问慢(除开应用本身问题)、数据库死锁多(除开架构优化问题)等情况,而且很多情况下CPU、内存、网络都非常好,甚至占用都不到10%,这到底是为什么?

(免责声明:以下内容由StatLee扮演的StatLee编写,与StatLee本人无关!)

正文部分:

首先,请问下存储相关的参数是什么?在12年前,很多非IT人士可能会回答容量、品牌,IT人士可能会回答容量、转速、读取、写入速度。Ok,容量、转速无可厚非,读取、写入速度这个怎么来衡量呢?很多人可能会回答:"可以看拷贝、复制文件的速度嘛,每秒多少兆多少兆嘛。"没问题,您这样回答OK的,那么我怎么凭借每秒速率来设计我的的底层架构?怎么考虑并发?是平均吗?

通过每秒速率然后平均分摊来设计架构,事实上就算是这样简单的算法都很少人这样做,这样做到底可不可以?据我目前了解,大部分设计者都是基于存储容量考虑,以下我列举一个在VMCloud群里曾经有人问过的问题,姑且称呼他为小明吧(小明躺枪):

小明:"求助各位大神,我有10300G的盘可不可以放60台虚拟机T T"

大蛇:"小伙子,没问题的,每个系统盘40G来算,你3T够的!:)"

小明:"好的,谢谢大神!:D"

第一反应我看到这样的问题,我很汗颜,第二反应,看到这样的回答,我更汗颜,当然回答者说的实际上也没有错,确实,40G60台,差不多也是要2400G(约合2.4T)。

但是!这样的答案真的对吗?这位小伙子以后真的在10300G盘上跑满40台虚拟机会不会有问题呢?

回答这个问题之前,我先来回答前面所提的按照速率平均分摊设计架构究竟可不可以。可以!人家只计算容量设计都没问题,您连速率都考虑进去了肯定比只考虑容量来得慎重啊!更准确的回答,其实您可以选择比速率更加专业的方式,就是今天所要谈的――IOPS

IOPS由于最近几年存储的瓶颈越来越突出,越来越多的ITPro都明白这玩意儿的重要性,那么到底IOPS是什么鬼?如何决定存储的性能?

先上Wiki百科对IOPS的解释(传送门:http://en.wikipedia.org/wiki/IOPS):

简而言之,IOPS是指存储每秒可接受多少次主机发出的访问,主机的一次IO需要多次访问存储才可以完成的一个"指标"。以下是IOPS的计算公式:

看起来蛮复杂的,我要怎么去计算呢?实际上很多时候我们都不需要用到这个公式(如果您真的想纠结下的话,也可以试试,我尝试过,误差不会很大),接下来,咱们来聊聊实战。

实战:

IOPS的加入,仅仅是为您的规划有一个更加精细,但是再精细的估算,也是估算,再上估算之后的存储环境也会受其他的性能参数(诸如网络、内存、处理器等限制),由于本篇只讨论存储,故不考虑其他性能条件(即默认都是满足要求的),所以请不要纠结于精不精准。废话不多说,那么先上一组数据(相信大家都比较熟悉了):

  • 常见SAS盘可提供的单盘IOPS(可能有不同版本有多多少少的误差,无所谓了)

  • 常见系统的IOPS需求(可以看到最高的要求是50左右,我们按照内存比来计算,8G内存大概需要100+IOPS):

  • 常见Raid级别的IOPS比例与计算方式(可能就比较少人考虑了,并不是叠加计算),我们此篇为能够简单暴力的表达IOPS的规划,暂时不考虑应用的读写比例,就以物理的IOPS读写比例来进行计算:

  • 再来个比较夸张的IOPS例子做对比(当然SharePointExchange诸如此类都是吃IO大户,这里暂且以SQL为吃IO大户吧):

Ok,现在我们可以来回答小明的问题了,到底10300G的盘,能不能撑下60台虚拟机?鉴于小明提的问题实际上也不是特别明确,基于谨慎的原则,我们来设计两个场景:

  1. 101WRPM SAS 300G,无Raid60个虚拟机均为常规系统,且内存、CPU均为4G2 Cores

  2. 101WRPM SAS 300GRaid 1060个虚拟机80%为常规系统,内存为8G2 Cores阅读更多内容

没有评论:

发表评论