在部署、使用開源雲平台cloudfoundry（版本為v1）的過程中，遇到了一些問題，通過分析cloudfoundry的實現機制和bosh的結構，在google的幫助下，最終將問題解決，同時對linux也有了進一步的了解。
現在將一些問題和解決方案總結出來，與大家一起分享。
一、vcenter故障排除
問題：
新虛擬機器ip與已有虛擬機器ip（如nfs server的ip）衝突後，造成已有虛擬機器、bosh、cloudfoundry不能正常工作。
解決方案：
1， 使用esxi主機上的「restart management agent」；可以恢復虛擬機器狀態
2， 重啟vcenter服務
3， 使用「主機—>配置儲存介面卡、儲存器」上的「全部重新掃瞄」功能重新整理儲存。（可選）
4， 重啟micro bosh虛擬機器（micro bosh的模板虛擬機器雖然未啟動，但需要在第一步的操作使他恢復正常狀態，否則即使重啟了micro bosh虛擬機器，也無法訪問。）。
通過以下一組命令確認micro bosh已恢復正常。
$ bosh target
$ bosh login
$ bosh deployments
$ bosh releases
$ bosh vms
如果以上命令能正常執行並返回預期的資訊，則micro bosh恢復正常。
5， 在micro bosh恢復正常後，執行「bosh cck」檢查多節點的bosh的執行狀態。根據「bosh cck」的提示操作，先選擇「reboot vm」進行恢復。如果無法恢復，則選擇「bosh cck」命令提示中的「recreate vm 。。。」進行恢復。
6， 在多節點的bosh恢復正常後，執行「bosh cck」檢查多節點的cloudfoundry的執行狀態。根據「bosh cck」的提示操作，先選擇「reboot vm」進行恢復。如果無法恢復，則選擇「bosh cck」命令提示中的「recreate vm 。。。」進行恢復。
cloudfoundry恢復後，各節點中的原有資料和設定會隨著節點的重建而恢復。
二、主機增加
往vcenter中增加乙個新的vsphere主機後，需要在vcenter中為新的vsphere主機增加nfs 儲存（nfs datastore）、網路（cf network、services network），使得bosh部署cloudfoundry時能夠識別出網路中新增加的vsphere主機。
三、powerdns節點
第一次部署多節點bosh時，如果powerdns在job列表中最後乙個時，最後乙個執行該dns job，則dns這個節點上的資料庫會沒有表。因為powerdns節點上的表有director job來建立。因此最好將powerdns這個節點放在director之前。或者多節點bosh部署完後，再重新部署一下director這個job。
四、修改『最大開啟檔案數』
1、 修改dea節點上的agent.rb
agent.rb: /var/vcap/packages/dea/lib/dea/agent.rb
搜尋 『fds』,在def process_dea_start方法中修改num_fds值為9000.
2、 使用root許可權修改以下檔案內容
/etc/security/limits.conf，增加以下內容，
* soft nproc 10240
* hard nproc 10240
vcap soft nofile 9000
vcap hard nofile 65000
root soft nofile 9000
root soft nofile 65000
* soft nofile 10240 # 控制程序的開啟最大檔案數
* hard nofile 10240 # 控制程序的開啟最大檔案數
/etc/pam.d/common-session，增加以下內容，
session required pam_limits.so
/etc/profile，增加以下內容，（該操作可選）
ulimit -hsn 10240
需要重啟電腦，否則更改不會立即生效。
檢查：
ulimit -a 這個是列出當前系統的所有內容限制
ulimit -n 這個是列出當前系統能夠開啟最大的檔案控制代碼數。
重啟電腦之後，就可以使用root方式進行修改/etc/profile中的ulimit -hsn 後的數字，再執行source /etc/profile，就可以馬上看到效果了。（該操作可選）
檢視程序的limits
1、 ps -ea
檢視程序資訊。
2、 cat /proc/程序id號/limits
檢視指定程序下的操作限制內容。
五、修改cloud controller的nginx上傳檔案大小限制
當上傳大檔案到cloudfoundry時，檔案大小超過256m，此時cloudfounry會返回413 的http 響應**（上傳檔案大小超過nginx最大值）。
為了能夠上傳大檔案，修改兩個節點上的nginx.conf檔案。
1、cloud controller節點上的nginx的「client_max_body_size 556m;」引數值。
檔案：/var/vcap/data/jobs/cloud_controller/56.8-dev/config/nginx.conf，在http上下文中修改client_max_body_size。
2、router節點上的nginx的「client_max_body_size 556m;」引數值。
檔案：/var/vcap/data/jobs/router/18.5-dev/config/nginx.conf，在http上下文中修改client_max_body_size。
六、修改dea節點的系統時間
如果在執行『bosh deploy』命令時，出現各種錯誤提示，可以使用重啟micro bosh節點上的虛擬機器，或者在vcenter中選擇micro bosh、多節點bosh所在的vsphere主機 並選擇右鍵選單中的『重新引導』功能進行重啟，使用這兩種方法可以修復錯誤提示。
八、修改cloudfoundry使用者的記憶體分配量
問題：hbase_master節點處於『failing』狀態。
檢視該節點上的日誌檔案 /var/vcap/sys/log/hbase_master/hbase_master_start.stdout.log，發現錯誤資訊。
解決辦法：修改hbase_master節點上配置檔案中的hbase.rootdir。
被修改的檔案位置：
/var/vcap/data/jobs/hbase_master/1.1-dev/config/hbase/hbase-site.xml
hbase.rootdir
hdfs:
說明：192.168.2.98是hbase_master節點上的主機ip位址 。
十、修改cloudcontroller中stage操作時間
檢視tempest\cf-release\jobs\cloud_controller\templates\cloud_controller.yml.erb，可以看到staging下的 max_staging_runtime引數控制cloud controller的stage時間，這個時間可以在cloudfoundry的部署檔案中進行配置；或者修改cloud controller節點上的/var/vcap/data/jobs/cloud_controller/56.8-dev/config/cloud_controller.yml檔案中的該引數值。
首先嘗試使用CloudFoundry
所有這些意味著您無法使用現有應用程式，無法將其上載到gae並期望它像在本地伺服器上執行一樣執行。實際上，將應用程式遷移到gae是乙個冗長的過程，具體取決於您使用的內容與允許使用的內容之間的差距。最糟糕的是，一旦遷移，您將無法再在標準伺服器上執行 或僅在提供的gae沙箱中執行 或者既要配置gae又要花...
如何在CloudFoundry上強制使用https
cloud foundry平台一般都提供http https兩種協議，但是某些時候我們只想使用https，這時候我們就可以通過cf提供的x forwarded proto來處理 以flask為例，在應用中加上如下語句即可 return redirect request.url.replace htt...
Android MediaMuxer使用遇到的問題
1.illegalstateexception問題 mediamuxer的使用必須嚴格遵循如下順序 addtrack start writesampledata stop release 如果有順序衝突或者多次呼叫start stop release，會導致illegalstateexception...