vcap代码：/root/cloudfoundry/vcap
config文件：/root/cloudfoundry/.deployments/devbox/config
log：/root/cloudfoundry/.deployments/devbox/log
安装的ruby gems（可以去那里修改gem的文件，以便于打印一些log，修改代码）：/root/cloudfoundry/.deployments/devbox/deploy/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/。还有另外一个版本的ruby，路径也类似的，不列出来了
CF自己安装的ruby bins，比如ruby、gem之类的执行文件：~/cloudfoundry/.deployments/devbox/deploy/rubies/ruby-1.9.2-p180/bin
droplet打包之后的存放处：/var/vcap/shared/droplets，这也是http方式获取的droplet。dea在启动时，如果是通过http方式获取droplet，那么就在cloud controller的这个位置。这个属性配置在cc的yml文件中，在cc的models/app_package.rb文件的package_dir方法中可以看到引用：dir = AppConfig[:directories] && AppConfig[:directories][:droplets]。当然了，外部的访问都是通过url，那么就不是这个实际路径了，一般是类似这样的url：:9022/staged_droplets/5/a6dc049a1486b007ae0587db4e911914481c2d6b
dea主目录：/var/vcap.local/dea，里面的apps目录就是所有apps的instance了，比如我有一个web项目，那么进入之后可以看到有个tomcat目录，没错，这就是一个tomcat了，每个instance使用一个独立的tomcat。然后我们可以看到有start, stop脚本，里面的内容就是简单的配置启动停止了。可以看到停止居然是直接kill -9，果然够暴力。。而/var/vcap.local/dea目录下的staged目录猜测是dea cache在本地的droplet，当条件满足时，会从这里直接拿droplet启动instance
Services目录：/var/vcap/services。不过不知到里面数据是怎么存的，只有各种.db文件，完全不知到怎么看