Cloud Foundry使用dev_setup部署多节点之排错分析

最新推荐文章于 2023-01-05 23:12:27 发布

明何

最新推荐文章于 2023-01-05 23:12:27 发布

阅读量8.6k

点赞数

分类专栏： CloudFoundry

本文链接：https://blog.csdn.net/minghe_uestc/article/details/8072799

版权

CloudFoundry 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

多节点部署，说白了就和单节点一样，区别就是把一个东西拆开来放到不同节点上去安装而已。

（1）怎么部署多节点，可以先参看这个帖子：http://blog.csdn.net/cherry_sun/article/details/7711913

里面介绍了一个大体流程，对后面的的工作有很多好处。

（2）如果在安装过程中出现问题，可以参考这个博客，虽然问题可能不一样，但是思路基本是一样的：

http://blog.csdn.net/wearenoth/article/details/8035968

（3）安装完成后我又遇到一些比较诡异的问题，这些问题里面有一些我晓得大概为什么，但是更多都不明白是怎么回事，下面是我找到的一些答案：

注：我这个是按照官方给的教程弄的，https://github.com/cloudfoundry/oss-docs/tree/master/vcap/single_and_multi_node_deployments_with_dev_setup

本来部署就不是我工作的重点，但是不弄一次，很多东西又弄不明白，所以只能弄一次了。

注2：由于当时没有写笔记写的乱七八糟，所以看下文的时候会出现很多地方信息不太一致，但是方法还是基本差不多的。

问题0：到底有没有成功

问题描述：我在安装mysql的节点的时候，遇到下面这种情况，首先出现了我们最喜欢看到的Success的信息，但是在开启的时候出现了问题。所以问题就出来了，我到底是装成功了，还是没有装成功？

Deployment Info
***************
* Status: Success
* Config files: /home/vm/cloudfoundry/.deployments/mysql1/config
* Deployment name: mysql1
* Note:
  * If you want to run ruby/vmc please source the profile /home/vm/.cloudfoundry_deployment_profile
  * If you want to run cloudfoundry components by hand please source the profile /home/vm/.cloudfoundry_deployment_local
* Command to run cloudfoundry: /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap_dev -n mysql1 start
vm@vm:~/cloudfoundry/vcap/dev_setup$ ./bin/vcap_dev start
Targeting deployment "mysql1" with cloudfoundry home "/home/vm/cloudfoundry"
Using cloudfoundry config from /home/vm/cloudfoundry/.deployments/mysql1/config
Executing /home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/bin/ruby /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap start mysql_node -c /home/vm/cloudfoundry/.deployments/mysql1/config -v /home/vm/cloudfoundry -l /home/vm/cloudfoundry/.deployments/mysql1/log
/home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': no such file to load -- nats/client (LoadError)
	from /home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
	from /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap:13:in `<main>'
vm@vm:~/cloudfoundry/vcap/dev_setup$

这个问题困扰了我很久，在网上也找到类似的问题，然后底下也给出了很多解决办法，我下面给出我找到的绝对比较有可能的几个回答，它们最后指向的矛头都是rvm的问题，而最终的问题都是和ruby版本相关。那答案真的是不是它呢？我们先看看我找到的答案是怎么说的吧：

网上的答案1：

Did you log out of the installation shell and create a new shell? This is needed I believe with the newer version of rvm..

https://github.com/cloudfoundry/vcap/blob/master/README.md

NOTE: The automated setup does not auto-start the system. Once you are done with the setup, exit your current shell, restart a new shell and continue the following steps

网上的答案2：

Correct Michael. The pull request in flight: https://github.com/cloudfoundry/vcap/pull/67

Does a few things:

 

#1 - it installs RVM correctly given some recent changes in the RVM installer. Major issue has to do with the new rvm blindly writing to .bash_profile which on a raw ubunto vm ends up disableing .bashrc. In addition, there was a bug in the original single-line automated installer that had the test for interactive shells backwards which disabled other parts of .bashrc, and finally there was a problem with the expansion of the $rvm_home variable... Net result is that RVM wasn't always working correctly after install

#2 - the automated setup process started vcap for you, but did it in a shell that was properly prepped for rvm. Once the install exits, you are left in the original shell, but that shell did not have rmv installed correctly and as a result is unable to run bin/vcap stop. Simplest solution is to restart the shell. I usually run this process by ssh into the vm so after the install, I just drop the ssh and reconnect in a new shell. this sets up rvm correctly and then cd cloudfoundry/vcap will prep your environment. the pull request no longer starts vcap for you so it feels more natural to run setup, log off and log back in. alternatively you could just source .bash_profile to get your rvm set correctly

#3 - The rake 0.9.0 change causes major issues. Its not a trivial thing to just gem uninstall it due to the fact that it's installed using rvm .default and .global gemsets. The pull request dances around this by removing rake from those global gemsets and then in its place gem install's 0.8.7 into each ruby environment.

网上的答案3：

Hi Miguel,

  Please open up a new Terminal window/shell, which will source in the modified .bashrc and will

  setup rvm environment.   Then try doing a bin/vcap start.

  We need ruby1.9.2 in the environment, which is set by rvm.

  For example, when I traverse down to vcap directory, I see the following :

$ cd /cloudfoundry/vcap
Using /Users/svaiyapuri/.rvm/gems/ruby-1.9.2-p180
This is ensured by .rvmrc file in that directory, which invokes rvm to use 1.9.2, nats is installed under 1.9.2 gem tree

$ cat .rvmrc
rvm use 1.9.2-p180
 

  Best Regards,

  -senthil

当然这三个方法都没办法解决我的问题了，我搜了rvm是什么，然后费劲心思装上它，结果发现不会用。然后还想办法去修改ruby的版本，但是我后来发现以前部署单节点的时候ruby版本都没出现问题，所以慢慢的我就否定这三个答案了，可谓千辛万苦，但是最后的答案又是什么？我至今才开始学ruby on rails，所以它给的提示信息我只能猜着看了。

Executing /home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/bin/ruby /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap start mysql_node -c /home/vm/cloudfoundry/.deployments/mysql1/config -v /home/vm/cloudfoundry -l /home/vm/cloudfoundry/.deployments/mysql1/log
/home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': no such file to load -- nats/client (LoadError)

首先是：我们使用的ruby是

/home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/bin/ruby

那说明肯定不是ruby版本问题了，所以上面的答案基本可以确定是错的了：然后看它的执行的是什么：

 /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap

我们可以看这个vcap是什么：

#!/usr/bin/env ruby
# Copyright (c) 2009-2011 VMware, Inc.
#
# Usage: bin/vcap_system [start|stop|restart|tail|status] [component ...]
#

require 'yaml'
require 'fileutils'
require 'optparse'

require 'rubygems'
require 'eventmachine'
require 'nats/client'

require File.expand_path(File.join("..", "lib", "vcap_components"), File.dirname(__FILE__))

ruby别的看不懂，这部分还是看的懂的，类似于C地下的包含头文件嘛，然后我想起来这篇博客：http://blog.csdn.net/cherry_sun/article/details/7711913

然后继续往下走：

mysql_node

这个就是启动mysql的意思了，然后继续往下，

 -c /home/vm/cloudfoundry/.deployments/mysql1/config -v /home/vm/cloudfoundry -l /home/vm/cloudfoundry/.deployments/mysql1/log

参数不难猜，但是如果想看的细致一些，我们可以到刚刚的vcap文件底下找答案：

$config_dir ||= ENV['CLOUD_FOUNDRY_CONFIG_PATH']
args = ARGV.dup
opts_parser = OptionParser.new do |opts|
  opts.on('--port PORT')                           { |port| $port = port.to_i }
  opts.on('--configdir CONFIGDIR', '-c CONFIGDIR') { |dir| $config_dir = File.expand_path(dir.to_s) }
  opts.on('--config CONFIGDIR')                    { |dir| $config_dir = File.expand_path(dir.to_s) }
  opts.on('--vcapdir VCAP_DIR', '-v VCAP_DIR')     { |dir| $vcap_home = File.expand_path(dir.to_s) }
  opts.on('--logdir LOG_DIR', '-l LOG_DIR')        { |dir| $log_dir = File.expand_path(dir.to_s) }
  opts.on('--no-color', '--nocolor', '--nc')       { $nocolor = true }
  opts.on('--noprompt', '-n')                      { $noprompt = true }
end

这样一看，基本就懂是什么意思了，-c是读取配置文件，这样我们就知道了mysql配置文件的位置；然后是-v是vcap的目录位置，这个我们都懂，不多说；然后是-l就是日志文件，那这样我们就知道mysql的日志文件在哪里了。虽然我们遇到的问题没有解决，但是我们从这里面已经知道了一些基本的东西，不久以后我们就会用到这些东西，这部分没看。

好了，分析到这我能知道的就是，我就是在执行vcap的时候没有找到这个“nats/client”这个库（？我不知道怎么说，在我眼里就是一个函数库）。

是不是感觉还是一头雾水，我当时就是这样的，就这样这个问题我卡了1天。

好了，我们好好回忆一下以前是不是有类似的问题，在上次单节点部署排错分析的时候我们遇到过一个问题，我们缺少一个头文件，结果编译就不成功。而ruby这种是不需要进行编译的，这两者之间有什么联系呢？我的感觉就是，说白了我没有装好nats这个库，然后现在问题就出来了，这个库应该装在什么地方？去哪里找？网上真的可以找的到么？一系列的问题让我们又陷入困境。

就在这时候，我突然灵光一闪（真的就是灵光一闪，有时候解决问题就是这样），我想起来vcap/services这个目录，我安装的东西在这个底下应该要能够找到。

解决方法：当然，老天保佑，果然是因为service这个目录下是空的导致我启动mysql失败了，因为贪图方便，我直接将整个service目录下的文件全部clone过来了。但是不管白猫黑猫，能抓老鼠就是好猫，这个问题总算解决了：

vm@vm:~/cloudfoundry/vcap/dev_setup/bin$ ./vcap_dev status
Targeting deployment "mysql1" with cloudfoundry home "/home/vm/cloudfoundry"
Using cloudfoundry config from /home/vm/cloudfoundry/.deployments/mysql1/config
Executing /home/vm/cloudfoundry/.deployments/mysql1/deploy/rubies/ruby-1.9.2-p180/bin/ruby /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap status mysql_node -c /home/vm/cloudfoundry/.deployments/mysql1/config -v /home/vm/cloudfoundry -l /home/vm/cloudfoundry/.deployments/mysql1/log
mysql_node                    :	 RUNNING

问题1：VMC无法登陆

问题描述如下：大致情况就是，我可以注册，但是在登陆过程中出现了404错误。

root@arch3:~/cloudfoundry/vcap/dev_setup/bin# vmc target api.vcap.me
Successfully targeted to [http://api.vcap.me]
root@arch3:~/cloudfoundry/vcap/dev_setup/bin# vmc register
Email: y...@...com
Password: ***
Verify Password: ***
Creating New User: OK
Attempting login to [http://api.vcap.me]
Problem with login to 'http://api.vcap.me', 404: entity not found or
inaccessible, try again or register for an account.

解决方法：这个问题我找到的答案就是-将vmc重0.3.21版本降级到0.3.18版本，为什么会这样，我就不明白了。

问题2：部署的应用无法启动：

问题描述如下：这个是从网上copy下来的，当时情况是我执行vmc push hello，然后在Staging Application的时候出现了下面的这个错误。

root@ubuntu:/home/cloudfoundry# vmc start hello

Staging Application: .............Error (JSON 504):<html><head><title>504 Gatewa...

root@ubuntu:/home/cloudfoundry#  vmc update hello

Uploading Application:

    Checking for available resources:  ok

   Processing resources:  ok

   Packing application:  ok

   Uploading (706K): ok

Error (JSON 504):<html>

<head><title>504 Gatewa...

解决方法：这个东西我在网上没有找到答案，但是如果看过这篇博文的话，应该可以找到一些答案：http://samsungapps.csdn.net/text.html?arcid=2806052

然后我们返回看我们开始部署的时候是怎么写的配置文件：

---
deployment:
  name: "rest"
jobs:
  install:
    - nats_server
    - cloud_controller:
        builtin_services:
          - redis
          - mongodb
          - mysql
    - router
    - health_manager
    - ccdb
    - redis_node:
        index: "0"
    - redis_gateway
    - mysql_gateway
    - mongodb_node:
        index: "0"
    - mongodb_gateway

问题就是在于，新的CF已经将stager（打包）这个功能从原有的Cloud Controller中剥离开了。

所以我们需要做的事情就很简单了，重新装一次rest，只是这次记得将stager给添加上就可以了。

vm@vm:~/test$ vim /home/vm/cloudfoundry/vcap/dev_setup/deployments/sample/multihos
t_mysql/rest.yml 

---
deployment:
  name: "rest"
jobs:
  install:
    - nats_server
    - cloud_controller:
        builtin_services:
          - redis
          - mongodb
          - mysql
    - router
    - stager
    - health_manager
    - ccdb
    - redis_node:
        index: "0"
    - redis_gateway
    - mysql_gateway
    - mongodb_node:
        index: "0"
    - mongodb_gateway

然后再试试看

vm@vm:~/cloudfoundry/vcap/dev_setup$ vmc start hello
Staging Application 'hello': OK

问题3：dea的日志有问题

问题描述：在查看dea的log（位于$HOME/cloudfoundry/.deployment/dea/log/ 目录下）的时候发现下面的提示信息，runtime not support。

 [2012-09-20 22:04:50.898873] dea - pid=12396 tid=d39f fid=99c9  DEBUG -- DEA received discovery message: {"droplet":12,"limits":{"mem":128,"disk":2048,"fds":256},"name":"hello","runtime_info":{"version":"1.8.7","description":"Ruby 1.8.7","executable":"/root/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin/ruby","version_flag":"-e 'puts RUBY_VERSION'","additional_checks":"-e 'puts RUBY_PATCHLEVEL >= 174'","version_output":"1.8.7","environment":{"PATH":"/root/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin:$PATH","BUNDLE_GEMFILE":null},"name":"ruby18"},"runtime":"ruby18","prod":false,"sha":"012b0fc043c9e03a03bf7f3432a0fc9c54d14ba1"}
[2012-09-20 22:04:50.899769] dea - pid=12396 tid=d39f fid=99c9  DEBUG -- Ignoring request, runtime not enabled for 'ruby18'
[2012-09-20 22:04:50.899939] dea - pid=12396 tid=d39f fid=99c9  DEBUG -- Ignoring request, {"version"=>"1.8.7", "description"=>"Ruby 1.8.7", "executable"=>"/root/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin/ruby", "version_flag"=>"-e 'puts RUBY_VERSION'", "additional_checks"=>"-e 'puts RUBY_PATCHLEVEL >= 174'", "version_output"=>"1.8.7", "environment"=>{"PATH"=>"/root/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin:$PATH", "BUNDLE_GEMFILE"=>nil}, "name"=>"ruby18"} runtime not supported.

解决方法：回答之前可以先插卡看下自己的runtimes，如下。说实在的，我没弄明白这边的runtime到底是什么玩意，所以这个问题就稀里糊涂的去网上查了。

vm@vm:~/cloudfoundry/vcap/dev_setup$ vmc runtimes

+--------------+---------------+-----------+
| Name         | Description   | Version   |
+--------------+---------------+-----------+
| php          | PHP 5         | 5.3       |
| node08       | Node.js       | 0.8.2     |
| node06       | Node.js       | 0.6.8     |
| ruby19       | Ruby 1.9.2    | 1.9.2p180 |
| ruby18       | Ruby 1.8.7    | 1.8.7     |
| java         | Java 6        | 1.6       |
| erlangR14B01 | Erlang R14B01 | R14B01    |
| python2      | Python 2.6.5  | 2.6.5     |
| node         | Node.js       | 0.4.12    |
+--------------+---------------+-----------+

在Google Group里面的答案就是：问题就是这个路径名出现问题了。

Hi
   I think the problem is because dea didn't find the correct ruby executable path.
 DEBUG -- DEA received discovery message: {"droplet":12,"limits":{"mem":128,"disk":2048,"fds":256},"name":"hello","runtime_info":{"version":"1.8.7","description":"Ruby 1.8.7","executable":"/root/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin/ruby","version_flag":"-e 'puts RUBY_VERSION'","additional_checks":"-e 'puts RUBY_PATCHLEVEL >= 174'","version_output":"1.8.7","environment":{"PATH":"/root/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin:$PATH","BUNDLE_GEMFILE":null},"name":"ruby18"},"runtime":"ruby18","prod":false,"sha":"012b0fc043c9e03a03bf7f3432a0fc9c54d14ba1"}
   the correct path should be /root/cloudfoundry/.deployments/dea/deploy/rubies/ruby-1.8.7-p357/bin/.
   But how can modify this so that DEA can find the path????

要怎么解决呢？：就是去修改rest这个节点底下的runtimes.yml文件，找到里面对于这个路径名的设置的地方，然后架构rest修改成dea就可以了。

Hi guys:
     It worked.
     I find the configuration.
     /root/cloudfoundry/.deployments/rest/config/runtimes.yml
     the path of executable ruby need change to where your dea's ruby located in.

再看dea的log文件，没问题了

vm@vm:~/cloudfoundry/.deployments/dea$ tail log/dea.log 
[2012-10-15 16:25:36.540653] dea - pid=6504 tid=a226 fid=0c51   INFO -- Using ruby @ /home/vm/cloudfoundry/.deployments/dea/deploy/rubies/ruby-1.9.2-p180/bin/ruby
[2012-10-15 16:25:36.540896] dea - pid=6504 tid=a226 fid=0c51   INFO -- Using network: 192.168.1.101
[2012-10-15 16:25:36.541032] dea - pid=6504 tid=a226 fid=0c51   INFO -- Socket Limit:1024
[2012-10-15 16:25:36.541099] dea - pid=6504 tid=a226 fid=0c51   INFO -- Max Memory set to 4.0G
[2012-10-15 16:25:36.541159] dea - pid=6504 tid=a226 fid=0c51   INFO -- Utilizing 1 cpu cores
[2012-10-15 16:25:36.541212] dea - pid=6504 tid=a226 fid=0c51   INFO -- Allowing multi-tenancy
[2012-10-15 16:25:36.541273] dea - pid=6504 tid=a226 fid=0c51   INFO -- Using directory: /var/vcap.local/dea/
[2012-10-15 16:25:36.542077] dea - pid=6504 tid=a226 fid=0c51   INFO -- Initial usage of droplet fs is: 0%
[2012-10-15 16:25:36.597228] dea - pid=6504 tid=a226 fid=0c51   INFO -- File service started on port: 12345
[2012-10-15 16:25:36.636433] dea - pid=6504 tid=a226 fid=0c51  DEBUG -- Took 0.002520012 to snapshot application state.

问题4：上传的APP的health值为0%

问题描述：解决了3的问题后，我试着铺设一个自己的应用。结果出现下面的这个情况，首先App需要很久才启动起来，让后提示我去查看log文件。这是不是一种正常情况呢？

vm@vm:~$ vmc start hello
Staging Application 'hello': OK                                                 
Starting Application 'hello': ..........................
Application is taking too long to start, check your logs
Starting Application 'hello': OK

当然不是，我查看了一下我推送的应用的状态，很容易就看到这个health值为0

vm@vm:~$ vmc apps

+-------------+----+--------+---------------+----------+
| Application | #  | Health | URLS          | Services |
+-------------+----+--------+---------------+----------+
| hello       | 1  | 0%     | hello.vcap.me |          |
+-------------+----+--------+---------------+----------+

而之后我也试着使用w3m访问自己的页面，结果也失败了，这说明我们还是没有成功。好吧，接下来让我们考虑一下是什么情况。

我首先想到的是这个https://github.com/cloudfoundry/uaa。然后也试着重新弄了一个uaa的节点，但是问题还是没有解决。

然后我就上网搜，找到如下的一个回答：

Check the dea logfile on your DEA node(s). There is another problem with
the multi-node guide where the "rest" / CC node contains the path
information for the runtimes, but the DEA node has them installed at a
different place.

I filed a bug on that particular issue (not that it's the same one that
you're having, but maybe) here:
https://cloudfoundry.atlassian.net/browse/CF-140.

You can work around it by tweaking
cloudfoundry/.deployments/<name>/config/runtimes.yml on the CC node...
notice the <name> is different on your CC and DEA nodes, if you followed
the multi-node deployment guide exactly, and that's what breaks the
runtimes. You can edit the paths in that file (what I did), or try to
reinstall either the CC or DEA node to use the same "name", so that the
path happens to line up properly.

Good luck! Once it works it really is kinda nice. The multi-node guides are
just *awful* though.

意思大概就是去查看dea的log日志。晕，在问题3的时候我们才试着查看过dea的日志信息，当时试着改过一个问题，已经没问题了，现在怎么还会有问题？但是没办法我还是试着查看了一下，结果很惊讶的发现下面的信息：

[2012-10-16 12:52:28.863974] dea - pid=6504 tid=a226 fid=0c51  DEBUG -- Ignoring request, {"version"=>"1.8.7", "description"=>"Ruby 1.8.7", "executable"=>"/home/vm/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin/ruby", "version_flag"=>"-e 'puts RUBY_VERSION'", "additional_checks"=>"-e 'puts RUBY_PATCHLEVEL >= 174'", "version_output"=>"1.8.7", "environment"=>{"PATH"=>"/home/vm/cloudfoundry/.deployments/rest/deploy/rubies/ruby-1.8.7-p357/bin:/home/vm/cloudfoundry/.deployments/rest/deploy/nodes/node-0.8.2/bin:$PATH", "BUNDLE_GEMFILE"=>nil}, "name"=>"ruby18"} runtime not supported.
[2012-10-16 12:52:37.610533] dea - pid=6504 tid=a226 fid=0c51  DEBUG -- DEA received router start message: {"id":"e02da355f3b4a439cae9066fce2ec6ef","version":0.98}

解决方法：天哪，这不是和问题3中的情况一样么！！！最后解决方法也和问题3一样咯。试着修改后，再重启一下每个节点。

vm@vm:~/test$ vmc apps

+-------------+----+---------+---------------+----------+
| Application | #  | Health  | URLS          | Services |
+-------------+----+---------+---------------+----------+
| env         | 1  | RUNNING | env.vcap.me   |          |
| hello       | 1  | RUNNING | hello.vcap.me |          |
+-------------+----+---------+---------------+----------+

OK，现在已经没有问题了。

vm@vm:~$ vmc start hello
Staging Application 'hello': OK                                                 
Starting Application 'hello': ..........................
Application is taking too long to start, check your logs
Starting Application 'hello': OK

问题5：胡乱修改域名的结果

今天遇到的一个问题：我想改改我的域名，然后试着用在安装的时候修改了使用的域名，如下

~/cloudfoundry/vcap/dev_setup/bin/vcap_dev_setup -D test.uestc -c ~/cloudfoundry/vcap/dev_setup/deployments/sample/multihost_mysql/rest.yml

结果最后查看日志的时候出现下面的问题：

  mysql_gateway --> [2012-10-22 23:32:50.149187] mysql_gateway - pid=32730 tid=be94 fid=33cd  ERROR -- Failed fetching handles, status=302
  mysql_gateway --> [2012-10-22 23:32:50.691135] mysql_gateway - pid=32730 tid=be94 fid=33cd   INFO -- Fetching handles from cloud controller @ http://api.test.uestc/services/v1/offerings/mysql-5.1/handles
  mysql_gateway --> [2012-10-22 23:32:51.772054] mysql_gateway - pid=32730 tid=be94 fid=33cd  ERROR -- Failed fetching handles, status=302
  mysql_gateway --> [2012-10-22 23:32:52.765308] mysql_gateway - pid=32730 tid=be94 fid=33cd   INFO -- Fetching handles from cloud controller @ http://api.test.uestc/services/v1/offerings/mysql-5.1/handles
  mysql_gateway --> [2012-10-22 23:32:53.822947] mysql_gateway - pid=32730 tid=be94 fid=33cd  ERROR -- Failed fetching handles, status=302
  mysql_gateway --> [2012-10-22 23:32:54.827635] mysql_gateway - pid=32730 tid=be94 fid=33cd   INFO -- Fetching handles from cloud controller @ http://api.test.uestc/services/v1/offerings/mysql-5.1/handles
  mysql_gateway --> [2012-10-22 23:32:55.882179] mysql_gateway - pid=32730 tid=be94 fid=33cd  ERROR -- Failed fetching handles, status=302
  mysql_gateway --> [2012-10-22 23:32:56.875083] mysql_gateway - pid=32730 tid=be94 fid=33cd   INFO -- Fetching handles from cloud controller @ http://api.test.uestc/services/v1/offerings/mysql-5.1/handles
  mysql_gateway --> [2012-10-22 23:32:57.960161] mysql_gateway - pid=32730 tid=be94 fid=33cd  ERROR -- Failed fetching handles, status=302
  mysql_gateway --> [2012-10-22 23:32:58.953425] mysql_gateway - pid=32730 tid=be94 fid=33cd   INFO -- Fetching handles from cloud controller @ http://api.test.uestc/services/v1/offerings/mysql-5.1/handles

这个我也不知道如何开始说起，大概意思就是这两个gateway在链接到http://api.test.uestc/services/v1/offerings/mysql-5.1/handles的时候出现了问题。

根据我的想法，这个api.test.uestc应该是指向本机的。所以修改的方法就是去修改/etc/hosts这个文件。其中“192.168.1.166”是我本机的IP地址。

127.0.0.1       localhost
127.0.1.1       vm-virtual-machine
192.168.1.166   api.test.uestc

然后重启了一下，然后看看日志，问题解决。

vm@vm-virtual-machine:~/cloudfoundry$ tail -f .deployments/rest/log/mongodb_gateway.log 
[2012-10-22 23:43:03.714025] mongodb_gateway - pid=2296 tid=bd74 fid=4b65   INFO -- Successfully registered with cloud controller
[2012-10-22 23:43:23.905633] mongodb_gateway - pid=2296 tid=bd74 fid=4b65  DEBUG -- [MongoaaS-Provisioner] Received node announcement: {"available_capacity":50,"capacity_unit":1,"id":"mongodb_node_0","plan":"free","supported_versions":["1.8","2.0"]}
[2012-10-22 23:43:53.991126] mongodb_gateway - pid=2296 tid=bd74 fid=4b65  DEBUG -- [MongoaaS-Provisioner] Received node announcement: {"available_capacity":50,"capacity_unit":1,"id":"mongodb_node_0","plan":"free","supported_versions":["1.8","2.0"]}
[2012-10-22 23:44:03.721696] mongodb_gateway - pid=2296 tid=bd74 fid=4b65   INFO -- Sending info to cloud controller: http://api.test.uestc/services/v1/offerings

vm@vm-virtual-machine:~/cloudfoundry$ tail -f .deployments/rest/log/mysql_gateway.log 
[2012-10-22 23:41:47.481952] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Sending info to cloud controller: http://api.test.uestc/services/v1/offerings
[2012-10-22 23:41:47.525692] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Successfully registered with cloud controller
[2012-10-22 23:42:47.540149] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Sending info to cloud controller: http://api.test.uestc/services/v1/offerings
[2012-10-22 23:42:47.573084] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Successfully registered with cloud controller
[2012-10-22 23:43:47.581261] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Sending info to cloud controller: http://api.test.uestc/services/v1/offerings
[2012-10-22 23:43:47.609556] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Successfully registered with cloud controller
[2012-10-22 23:44:47.628153] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Sending info to cloud controller: http://api.test.uestc/services/v1/offerings
[2012-10-22 23:44:47.659385] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Successfully registered with cloud controller
[2012-10-22 23:45:47.680424] mysql_gateway - pid=1848 tid=2705 fid=6bf1   INFO -- Sending info to cloud controller: http://api.test.uestc/services/v1/offerings

注意：在此过程中我发现有个家伙遇到我类似的错误信息，但是他的原因和我的完全不一样：

http://support.cloudfoundry.com/entries/20048308-unable-to-get-started-with-cloudfoundry-single-vm-setup-unable-to-reach-api-vcap-me

总结

多节点的部署，说难挺难，说简单也算可以，心得如下：

（1）最好了解CF的基本架构，我感觉如果了解，很多东西弄起来就会有思路。也会方便很多。下面是我整理的一些东西

Cloud Foundry框架介绍（上）：http://qing.weibo.com/2294942122/88ca09aa330004r8.html
Cloud Foundry框架介绍（下）：http://qing.weibo.com/2294942122/88ca09aa33000975.html
Cloud_Controll分析：http://blog.sina.com.cn/s/blog_902f34a901014hw5.html
CloudFoundry DEA运作源码分析：http://blog.csdn.net/cherry_sun/article/details/7696482
cloud foundry之router代码解读:http://www.54chen.com/architecture/cloud-foundry-router.html
Cloud Foundry vcap_dev start过程分析:http://blog.csdn.net/cherry_sun/article/details/7730008
cloudfoundry dev setup 分析以及chef学习:http://blog.csdn.net/cherry_sun/article/details/7711913
MongoDB:http://blog.csdn.net/cherry_sun/article/details/7583215
MongoDB:http://blog.csdn.net/cherry_sun/article/details/7583761
VMC:http://www.54chen.com/architecture/cloud-foundry-vmc.html
cloud_controller:http://www.54chen.com/architecture/cloud-foundry-cloud_controller.html
cloud foundry之warden代码解读-part1:http://www.54chen.com/architecture/cloud-foundry-warden-part1.html
Cloud Foundry 深入学习三 CloudController源码分析：http://blog.sina.com.cn/s/blog_902f34a901014hw5.html
Cloud Foundry新版router源码分析：http://blog.csdn.net/cherry_sun/article/details/7780472
cloud controller 源码分析（包括Ruby on Rails项目结构分析）：http://blog.csdn.net/cherry_sun/article/details/7750394
Event Machine：http://eventmachine.rubyforge.org/

（2）学会查找资料，百度是靠不住的，我这次遇到的问题的解决方法都是在CF的社区和google的group里面找到的。

（3）学会查看日志，也就是~/cloudfoundry/.deployment/XXX/log底下的信息，有时候答案就在里面了。

小技巧

如何提高安装速度

在安装的时候我使用的dev_setup方法，中间去下载源码和数据包会耗去大量的时间，而且还常常因为源的问题失败，但是如果你有一个成功安装的vcap节点的话，可以使用原来的节点来拷贝

具体做法如下：比如我有一个已经安装好的vcap节点，用户名为ubuntu，地址为192.168.1.80，我现在的节点就叫vm，地址为192.168.1.100

克隆源码：

第一步、在$HOME目录下新建一个cloudfoundry目录

$ cd $HOME
$ mkdir cloudfoundry

第二步、将ubuntu目录下的源码克隆过来，例如我想克隆vcap的源码，可以这么做

$ cd $HOME/cloudfoundry/
$ git clone ubuntu@192.168.1.80:/home/ubuntu/cloudfoundry/vcap

此外其他的源码都可以这么来做，速度绝对提升几十倍

克隆安装包：在安装的时候，都需要下载好几个安装包，这些包都保存在/var/cache/dev_setup目录下，那我们只要将其拷贝过来，那就免去很多很多的时间了

第一步：在/var/cache目录下新建一个dev_setup目录

$ cd /var/cache/
$ sudo mkdir dev_setup

第二步、将软件包全部拷贝过来，

$ cd /var/cache/dev_setup
$ sudo scp ubuntu@192.168.1.80:/var/cache/dev_setup/* .

关于log文件:

我一直习惯使用tail命令查看log文件，可以如下使用：

$ tail -f ~/cloudfoundry/.deployments/uaa/log/uaa.log

或者

$ /home/vm/cloudfoundry/vcap/dev_setup/bin/vcap_dev tail | grep ERROR

明何

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
2
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录