Hi，本周第一天没什么事，所以就先分享一下我研究自动化代码部署与回滚软件的经验。这个软件有什么用途？主要是解决自动进行代码的部署，避免手动部署时出现错误，节省时间，同时在出现问题的时候，能回滚到之前的版本（或者你指定的版本），我在gitlab里找到了这样的软件，名为capistrano。下面就先给大家介绍一下。
文章结构
一、介绍
二、要求的环境
三、安装
四、命令行测试
五、代码部署（结合git）
六、代码部署（结合svn）
七、代码回滚
八、总结
九、namespace
一、介绍
Capistrano是一种在多台服务器上运行脚本的开源工具，它主要用于部署web应用。它自动完成多台服务器上新版本的同步更新，包括数据库的改变。Capistrano最初由JamisBuck用Ruby开发，并用RubyGems部署渠道部署。现在Capistrano不仅限于应用RubyonRails的web应用框架，而且可以用于部署用其他框架的web应用程序，比如用PHP开发的。Capistran最初是用来应用于bash指令行。现在RubyonRails框架的用于也可以使用它的新特性，例如，对当前web应用部署改变使其更新版本，或者使其回滚到之前的旧版本。
二、要求的环境
1、Ruby一定要1.9.x；
2、server端与client端一定要进行ssh信任或者client端统一一个相同的密码；
三、安装
gem install capistrano
四、命令行测试
root@ubuntu:/tmp# cat capfile task :du, :hosts => "ubuntu.hadoop.com" do run "df -h" end
在ubuntu.hadoop.com（本机）机器上运行dfh命令查看磁盘空间
root@ubuntu:/tmp# cap du * 2013-06-25 13:34:48 executing `du' * executing "df -h" servers: ["ubuntu.hadoop.com"] executing command ** [out :: ubuntu.hadoop.com] Filesystem Size Used Avail Use% Mounted on ** [out :: ubuntu.hadoop.com] /dev/mapper/ubuntu-root 39G 3.3G 33G 10% / ** [out :: ubuntu.hadoop.com] udev 489M 4.0K 489M 1% /dev ** [out :: ubuntu.hadoop.com] tmpfs 199M 336K 199M 1% /run ** [out :: ubuntu.hadoop.com] none 5.0M 0 5.0M 0% /run/lock ** [out :: ubuntu.hadoop.com] none 498M 0 498M 0% /run/shm ** [out :: ubuntu.hadoop.com] /dev/sda1 228M 51M 166M 24% /boot command finished in 981ms
可以看到类似使用python的fabric，但capistrano比fabric多了一个代码回滚功能。
需要注意的是如果你的client机器的ssh端口不是默认22的话，你还想操作的话，需要添加
ssh_options[:port]=50020#sshport
如果不添加的话，就会出现connectionfailedfor:ip(Errno::ECONNREFUSED:Connectionrefused-connect(2))
如果你在使用iptables的机器上使用capistrano，只需要开启ssh端口就可以正常的使用capistrano。
五、代码部署（结合git）
测试环境
主机名 ip 状态 ruby ubuntu.hadoop.com 192.168.56.102 server 1.9.3 server.hadoo.com 192.168.56.101 client 1.9.3
1、进入tmp目录，然后创建capi目录
cd /tmp mkdir capi cd capi
2、capistrano部署我的应用
capify .
这将产生两个文件，一个是capfile，这个是Capistrano需要的主要文件，就像make自动产生makefile，rake自动产生Rakefile一样，Capistrano默认寻找并加载capfile文件，默认产生的rapfile非常小，它所做的事就是加载"config/deploy.rb"；第二个文件是"config/deploy.rb"，这个文件包含你的应用程序部署所需的设置。Ralis的所有设置文档都放在config目录下，通常，你不需要管capfile文件，只需要把精力放在config/deploy.rb的设置和优化上。如果你的Capistrano用于非Rails环境，你可能只有一个capfile文件，而没有config/deploy.rb这个文件。
3、修改config/deploy.rb文件
set :application, "test" set :scm, :git set :repository, "ssh://git@192.168.1.250/data/gitrepo/jsonLib.git" set :deploy_to, "/tmp/result" set :normalize_asset_timestamps, false # set :scm, :git # You can set :scm explicitly or Capistrano will make an intelligent guess based on known version control directory names # Or: `accurev`, `bzr`, `cvs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none` role :web, "192.168.56.101" # Your HTTP server, Apache/etc role :app, "192.168.56.101" # This may be the same as your `Web` server role :db, "192.168.56.101", :primary => true # This is where Rails migrations will run #role :db, "your slave db-server here"
我的修改内容如上
主要是从192.168.1.250里获取git库，然后应用部署到192.168.56.102机器的/tmp/result目录。
set :application, "test"
是告诉Capistrano我们的应用程序被"调用"了
set :scm, :git
默认启动svn，而不是git，如果使用的话，需要set:scm,:git开启。
set :repository, "ssh://git@192.168.1.250/data/gitrepo/jsonLib.git"
然后我们需要告诉Capistrano我们的源代码在哪里，这个地址你的本地主机和服务器都可以到达。
set :deploy_to, "/tmp/result"
我们需要告诉Capistran我们的应用放在服务器的哪里，如果不加的话，默认为"/u/apps/#{application}"。
set :normalize_asset_timestamps, false
如果不添加这句话，在deploy:update的时候会出现
*** [err :: 192.168.56.101] find: `/tmp/result_svn/releases/20130625071724/public/images' *** [err :: 192.168.56.101] : No such file or directory *** [err :: 192.168.56.101] find: `/tmp/result_svn/releases/20130625071724/public/stylesheets': No such file or directory *** [err :: 192.168.56.101] find: `/tmp/result_svn/releases/20130625071724/public/javascripts': No such file or directory
原因是
-
理解DHCP的雏形BOOTP（Bootstrap Protocol）
-
DHCP的为什么要替代BOOTP；它们的区别在哪里？
- 理解DHCP的工作原理与每个过程的数据帧取证
-
Offer消息到底是以单播的方式进行发送，还是以广播的方式进行发送
-
关于DHCP服务器分配IP地址时的冲突检测
动态主机配置协议（Dynamic Host Configuration Protocol, DHCP）被设计用于动态的为网络中的主机分配IP地址及其它相关的TCP/IP属性，它属于客户/服务模式的应用程序，使用UDP协议号67（服务端）和68（客户端）工作。它代替了网络管理员手工为网络中的计算机配置IP地址及其它TCP/IP属性的工作，如果网络中的计算机数量较大，使用人工静态配置IP地址容易造成配置错误，比如：把一个IP地址配置到两台不同的计算机，当配置量过大时，这种失误是很有可能的，造成过大的管理成本开销，所以，在中大型网络中通常都使用DHCP为计算机自动配置IP地址及其它相关的TCP/IP属性，本小节将以描述DHCP的工作原理与演示DHCP在思科路由器上的配置为重点。
理解DHCP的雏形BOOTP（Bootstrap Protocol）:
DHCP的前生是BOOTP（Bootstrap Protocol），要理解DHCP，不得不说明一下这个BOOTP（Bootstrap Protocol），它比DHCP出现得更早，与DHCP提供类似的服务，用于网络早期的无盘工作站，这个无盘工作站在现今的网络应用中基本上已经退出应用市场了，如果还能看到它影子，那就是超市和商场所用的收银机。BOOTP的功能就是为这些无盘终端自动的分配IP地址、子网掩码、默认网关、DNS地址。
DHCP的为什么要替代BOOTP；它们的区别在哪里？
由于DHCP的出现，BOOTP逐渐被DHCP所替代，因为DHCP有更完善、更安全的工作机制、能够提供更灵活的IP地址分配方式、能够为客户机自动配置更多的TCP/IP参数，如果更具体的讲就是：BOOTP在分配IP地址时，IP地址和请求主机的MAC必须被预置到BOOTP服务器上，如果BOOTP客户端发来的IP地址请求消息中，请求主机的源MAC地址在BOOTP服务器上有记录，并对应了一个IP，那么，BOOTP服务器将对应的IP发放给BOOTP的客户端，如果没有对应记录的存在，请求会话将失败，这是BOOTP缺泛灵活性的一种典型代表；另外DHCP支持发放IP地址的"租约"机制，但是BOOTP不支持，关于"租约"机制，后面会有详细的描述；BOOTP只能最多分配4个网络参数，分别是IP地址、子网掩码、默认网关、DNS地址，DHCP可以提供更多的TCP/IP属性的自动配置。
理解DHCP的工作原理与每个过程的数据帧取证：
现在来理解DHCP的工作原理并取证每个工作过程的数据帧，如下图 9.12所示为DHCP的工作过程，这四个过程，基本上是现今网络领域公认的四大过程，但事实上，DHCP的工作原理在这四个公认的过程中还有一些小插曲，关于这一点，取证了如下图9.13所示的DHCP完整工作过程的数据帧，所以现在拟订一个清晰的学习思路：
理解DHCP四个工作步骤，并分析每个工作步骤的数据帧。
理解为什么在这四个工作步骤中会携带两个ARP请求消息，并分析这两个ARP请求消息。
第一步：DHCP客户端向本地子网发送一个DHCP的Discover消息，该消息是以广播的形式被发送到网络上，源MAC地址是发送源主机的MAC地址，源IP地址是0.0.0.0，因为此时的客户机还没有被DHCP动态的配置IP地址，目标MAC地址是广播MAC（FFFF.FFFF.FFFF），目标IP地址是广播IP（255.255.255.255）,为什么该消息会是广播，因为客户端现在根本就不知道网络上谁是DHCP服务器，关于DHCP客户端发送的DHCP Discover消息的数据帧如下图 9.14所示。
图9.14 DHCP的在Discover数据帧
在执行DHCP第二步Offer消息前的小插曲：当收到客户端发来的Discover消息的DHCP服务器会立即查寻自己可对外提供IP地址的地址池，提供一个可以分配给DHCP客端的机会IP，比如192.168.2.5；注意：此时并不是立即将这个地址分配出去，这只是一个可供分配的机会IP，DHCP服务器会以自己的MAC作为源MAC，自己的IP作为源目标，向网络中发送一个目标IP地址为192.168.2.5（事实上，就是那个机会IP）的ARP请求，目的在于：确认这个它（DHCP服务器）认为可以分配给某个客户端的IP地址，是否正在被别的主机使用，如果网络上有主机正在使用这个IP地址，可能是管理员人工输入的，该主机就会对这个ARP请求应答，这说明，192.168.2.5这个地址正在被使用，反之，没有应答，就表示DHCP可以将这个地址分配给某个DHCP的客户端，关于DHCP用于检测机会IP是否被其它主机使用的数据帧如下图9.15所示。
第二步：DHCP服务器必须完在上述的小插曲后，方可确定机会IP地址可以提供给DHCP的客户端，这也是为什么在DHCP工作的四个步骤中会出现一个ARP消息的原因。此时DHCP向网络中发送一个Offer消息，为客户端提供IP地址。
首先说明：DHCP服务器发送的Offer消息，即可以是单播形式，也可以是广播形式，这要分情况而定，如果将Offer消息单纯的定义为广播或是单播发送都是不严密的定义，事实上DHCP的Offer消息是广播还是单播，这取决于DHCP客户的具体情况，它可以从如下图图 9.16所示DHCP报文中的两个关键字段来做出定义，客户端IP地址（CIAddr）和标志（Flags）中的Broadcast flag来决定：
n如果Broadcast flag被转置位为1，则表示客户机不允许DHCP服务器的Offer消息以单播的方式回应，所以必须使用广播回应，在如下图 9.16所示的数据帧中Broadcastflag被转置位为0，所以DHCP服务器可以选择以单播的方式发送Offer消息。
n如果客户端IP地址（CIAddr）有一个明确的IP地址，这个已经存在的IP地址，可能是上次引导计算机时DHCP服务器提供的IP地址。那么，此时DHCP服务器的Offer消息将以单播的方式回应。
n如果Broadcast flag和客户端IP地址（CIAddr）都是0；此时，DHCP服务器既可以使用广播进行Offer消息发送，也可以使用上一步小插曲中的ARP记录进行单播发送，因为在小插曲中的机会地址检测说明网络上没有主机使用这个地址，所以，此时DHCP服务可以假定192.168.2.5这个IP地址可供请求主机使用，所以，可以使用单播的形式回送Offer消息给DHCP客户机，但事实上，请求主机此时还没有真正的获得这个IP。
第三步：当DHCP的客户机收到服务器发来的Offer消息后，它会以广播的形式发出一个DHCP的Request消息，正式向DHCP服务器申请IP地址，注意该消息并不是只发给提供机会IP的DHCP服务器，而是以广播的形式发送给网络中的所有DHCP服务器，因为一个网络上有可能存在多台DHCP服务器，现在DHCP客户端正是使用这个DHCP的Request广播向整个网络可能存在的所有DHCP服务器讲："我现在准备申请192.168.2.1这台DHCP服务器所提供的192.168.2.5这个IP地址如下图 9.17所示，其它DHCP服务器，你们的好意心领了！"相当于是委婉的拒绝其它
没有评论:
发表评论