国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Cloud Foundry中DEA組件內(nèi)應(yīng)用的啟動(dòng)與資源監(jiān)控

codercao / 2958人閱讀

摘要：監(jiān)控應(yīng)用資源完成對(duì)所在節(jié)點(diǎn)應(yīng)用的監(jiān)控主要通過周期性監(jiān)控來完成的，代碼如下其中默認(rèn)的監(jiān)控間隔為。以上便是對(duì)于的中的應(yīng)用啟動(dòng)與應(yīng)用資源監(jiān)控。

????? Cloud Foundry中所有的應(yīng)用都運(yùn)行在一個(gè)稱為DEA的組件中，DEA的全稱是Droplet Execution Agent。

??????DEA的主要功能可以分為兩個(gè)部分：運(yùn)行所有的應(yīng)用，監(jiān)控所有的應(yīng)用。本文主要講解Cloud Foundry v1版本中DEA如何啟動(dòng)一個(gè)應(yīng)用，以及DEA如何監(jiān)控應(yīng)用的資源使用。雖然DEA兩個(gè)功能的實(shí)現(xiàn)遠(yuǎn)不止這么多，但是筆者認(rèn)為啟動(dòng)應(yīng)用和監(jiān)控應(yīng)用資源是 DEA的精髓所在，很多其他的內(nèi)容都是在這兩個(gè)點(diǎn)上進(jìn)行封裝或者強(qiáng)化。

DEA啟動(dòng)應(yīng)用

??????在一般情況下，啟動(dòng)一個(gè)應(yīng)用，首先需要三樣?xùn)|西：環(huán)境，源碼，應(yīng)用入口。

??????關(guān)于環(huán)境，Cloud Foundry在DEA節(jié)點(diǎn)處，已經(jīng)部署完多套不同框架應(yīng)用運(yùn)行所需要的環(huán)境。關(guān)于源碼，Cloud Foundry中有一個(gè)droplet的概念，它是一個(gè)可運(yùn)行的源碼包，比用戶上傳的源碼還要多一些Cloud Foundry自定義添加的內(nèi)容，比如說對(duì)于Spring應(yīng)用，Cloud Foundry會(huì)將Tomcat將應(yīng)用源碼打包在一起，并且添加Tomcat中應(yīng)用的啟動(dòng)，終止腳本等。關(guān)于程序入口，剛才已經(jīng)涉及到，打包過程中，啟動(dòng) 腳本已經(jīng)被加入droplet之中。因此，DEA只需要簡(jiǎn)單的通過環(huán)境來執(zhí)行啟動(dòng)腳本，就可以成功啟動(dòng)應(yīng)用。在研究了源碼之后，也會(huì)發(fā)現(xiàn)DEA中最主要的 文件名為agent.rb，在啟動(dòng)這方面，也就是充當(dāng)一個(gè)代理的角色，通過Linux底層的腳本命令來完成對(duì)應(yīng)用的操作。

?????了解Cloud Foundry中消息機(jī)制的開發(fā)者，一定會(huì)熟悉NATS的訂閱/發(fā)布機(jī)制，而DEA也正是通過這種機(jī)制實(shí)現(xiàn)接收“啟動(dòng)應(yīng)用”的請(qǐng)求。訂閱代碼如下：

???? [ruby] view plaincopy

  1. NATS.subscribe("dea.#{uuid}.start")?{?|msg|?process_dea_start(msg)?}??

????? 可見DEA組件訂閱“dea.#{uuid}.start”主題的消息后，只要NATS接受到相同主題消息的發(fā)布，就會(huì)將消息轉(zhuǎn)發(fā)給DEA，也就是上行代 碼的msg，DEA接受到msg后，通過函數(shù)process_dea_start來處理。以下我們?cè)敿?xì)介紹process_dea_start方法實(shí)現(xiàn)。

??????? 在process_dea_start方法中，首先通過JSON類來解析message消息，從中獲取眾多的屬性值，然后將這些屬性值賦值給方法內(nèi)的變 量。由于在下文的資源監(jiān)控部分，會(huì)涉及到應(yīng)用使用的內(nèi)存，文件數(shù)，硬盤等，故在這里以這幾個(gè)屬性為例，介紹解析message。

???? [ruby] view plaincopy

  1. ??????message_json?=?JSON.parse(message)??
  2. ??????mem?????=?DEFAULT_APP_MEM??
  3. ??????num_fds?=?DEFAULT_APP_NUM_FDS??
  4. ??????disk????=?DEFAULT_APP_DISK??
  5. ??
  6. ??????if?limits?=?message_json["limits"]??
  7. ????????mem?=?limits["mem"]?if?limits["mem"]??
  8. ????????num_fds?=?limits["fds"]?if?limits["fds"]??
  9. ????????disk?=?limits["disk"]?if?limits["disk"]??
  10. ??????end??


???????解析message后，在message_json中取出鍵為limits的值，如果存在的話，那就以limits的值來初始化變量mem,num_fds,disk，如果不存在的話，那就是使用DEA默認(rèn)的值來給這些變量賦值。

???????通過一系列資源檢測(cè)之后，DEA開始為需要啟動(dòng)的應(yīng)用創(chuàng)建合適的實(shí)例，這些實(shí)例最終需要保存在DEA所維護(hù)的內(nèi)存塊中。同時(shí)，DEA還需要為應(yīng)用創(chuàng)建合適的文件目錄來運(yùn)行該應(yīng)用。

??????在DEA所在節(jié)點(diǎn)的文件系統(tǒng)中創(chuàng)建文件目錄的代碼如下：

?????[plain] view plaincopy

  1. instance_dir?=?File.join(@apps_dir,?"#{name}-#{instance_index}-#{instance_id}")??


???????? 通過process_dea_start方法內(nèi)的變量，創(chuàng)建在內(nèi)從中的內(nèi)存實(shí)例，簡(jiǎn)化代碼如下：

???? [ruby] view plaincopy

  1. instance?=?{??
  2. ??:droplet_id?=>?droplet_id,??
  3. ??:instance_id?=>?instance_id,??
  4. ??……??
  5. ??:mem_quota?=>?mem?*?(1024*1024),??
  6. ??:disk_quota?=>?disk??*?(1024*1024),??
  7. ??:fds_quota?=>?num_fds,??
  8. ??:state?=>?:STARTING,??
  9. ??……??
  10. ??:cc_partition?=>?cc_partition??
  11. }??


??????隨后，將以上創(chuàng)建的實(shí)例，存入DEA維護(hù)的Hash類型內(nèi)存@droplets中，代碼如下：

???? [ruby] view plaincopy

  1. instances?=?@droplets[droplet_id]?||?{}??
  2. instances[instance_id]?=?instance??
  3. @droplets[droplet_id]?=?instances??

???????然后，在process_dea_start方法中，緊接著定義了一個(gè)lambda函數(shù)start_operation。

??????在start_operation方法中，DEA首先做了以下的操作：

  • 為應(yīng)用程序分配一個(gè)普通端口，供應(yīng)用最終的用戶進(jìn)行訪問
  • 若需要配置debug端口，DEA為應(yīng)用分配debug端口
  • 若需要配置console端口，DEA為應(yīng)用分配console端口

???????做完端口分配之后，DEA開始作必要的環(huán)境設(shè)置操作。

???????按次序的話，首先創(chuàng)建一個(gè)manifest變量，存儲(chǔ)droplet.yaml文件中的狀態(tài)值，通過該狀態(tài)值，來檢測(cè)應(yīng)用程序是否準(zhǔn)備就緒等先決準(zhǔn)備工作。

???????接著，創(chuàng)建變量prepare_script，，從源代碼的某路徑中將內(nèi)容拷貝入prepare_script，以供執(zhí)行啟動(dòng)操作命令的時(shí)候使用。

???????接著，通過DEA運(yùn)行平臺(tái)的系統(tǒng)類型，選擇不同的shell命令。

???????接著，對(duì)當(dāng)前應(yīng)用目錄進(jìn)行一些權(quán)限設(shè)置，比如：使用chown命令，對(duì)應(yīng)用的用戶進(jìn)行修改；使用chgrp命令，對(duì)用戶組進(jìn)行修改；使用chmod命令，對(duì)應(yīng)用的讀寫權(quán)限進(jìn)行修改。

?????? 接著，通過setup_instance_env方法實(shí)現(xiàn)，對(duì)應(yīng)用環(huán)境變量的設(shè)置。實(shí)現(xiàn)過程中，該方法將所有的環(huán)境變量都加入一個(gè)數(shù)組，最后將數(shù)組內(nèi)所有的內(nèi)容export到應(yīng)用的環(huán)境變量中。

??????緊接著，一個(gè)很重要的部分是，DEA定義了一個(gè)proc代碼塊，來實(shí)現(xiàn)對(duì)DEA中要啟動(dòng)應(yīng)用程序啟動(dòng)時(shí)的資源限制，需要注意的是，這僅僅是代碼塊的定義，并不是在process_dea_start方法中，在這個(gè)代碼塊所在的位置被調(diào)用，代碼如下：

????? [ruby] view plaincopy

  1. exec_operation?=?proc?do?|process|??
  2. ??process.send_data("cd?#{instance_dir} ")??
  3. ??if?@secure?||?@enforce_ulimit??
  4. ????process.send_data("renice?0?$$ ")??
  5. ????process.send_data("ulimit?-m?#{mem_kbytes}?2>?/dev/null ")??#?ulimit?-m?takes?kb,?soft?enforce??
  6. ????process.send_data("ulimit?-v?3000000?2>?/dev/null ")?#?virtual?memory?at?3G,?this?will?be?enforced??
  7. ????process.send_data("ulimit?-n?#{num_fds}?2>?/dev/null ")??
  8. ????process.send_data("ulimit?-u?512?2>?/dev/null ")?#?processes/threads??
  9. ????process.send_data("ulimit?-f?#{disk_limit}?2>?/dev/null ")?#?File?size?to?complete?disk?usage??
  10. ????process.send_data("umask?077 ")??
  11. ??end??
  12. ??app_env.each?{?|env|?process.send_data("export?#{env} ")?}??
  13. ??if?instance[:port]??
  14. ????process.send_data("./startup?-p?#{instance[:port]} ")??
  15. ??else??
  16. ????process.send_data("./startup ")??
  17. ??end??
  18. ??process.send_data("exit ")??
  19. end??


??????該執(zhí)行塊，首先進(jìn)入應(yīng)用相應(yīng)的目錄下，重新設(shè)置完程序運(yùn)行的優(yōu)先級(jí)之后，對(duì)該進(jìn)程啟動(dòng)時(shí)所需要的一些資源進(jìn)行設(shè)置，設(shè)置過程中使用的是Linux操作系統(tǒng) 中的ulimit命令，該命令可以做到：限制shell啟動(dòng)進(jìn)程是所占用的資源數(shù)量，具體的資源類型，有：物理內(nèi)存，虛擬內(nèi)存，所需打開的文件數(shù)，需要?jiǎng)?chuàng) 建的線程數(shù)，磁盤容量等。需要注意的是，這樣的限制是臨時(shí)性的限制，一旦shell會(huì)話結(jié)束之后，這樣的限制也就失效了。這樣也比較可以理解，否則DEA 中應(yīng)用對(duì)于資源的隔離和控制也就不難實(shí)現(xiàn)了。資源的限制做完之后，隨即實(shí)現(xiàn)的是env環(huán)境變量的導(dǎo)入，使用export命令。倒數(shù)第二實(shí)現(xiàn)的是，執(zhí)行啟動(dòng) 腳本，從而真正的實(shí)現(xiàn)應(yīng)用的啟動(dòng)。最后，需要將該shell會(huì)話關(guān)閉，使用exit命令。

??????執(zhí)行代碼塊如下，退出代碼塊如下：

???? [ruby] view plaincopy

  1. exit_operation?=?proc?do?|_,?status|??
  2. ??@logger.info("#{name}?completed?running?with?status?=?#{status}.")??
  3. ??@logger.info("#{name}?uptime?was?#{Time.now?-?instance[:start]}.")??
  4. ??stop_droplet(instance)??
  5. end??


???????該部分代碼較為簡(jiǎn)單，只是調(diào)用了stop_droplet方法。

???????接著會(huì)有一個(gè)非常重要的模塊，負(fù)責(zé)實(shí)現(xiàn)應(yīng)用的真正啟動(dòng)：

???? [plain] view plaincopy

  1. Bundler.with_clean_env?{?EM.system("#{@dea_ruby}?--?#{prepare_script}?true?#{sh_command}",?exec_operation,?exit_operation)?}??


??????? 該代碼的含義是：使用一個(gè)全新環(huán)境變量的env進(jìn)行操作括號(hào)內(nèi)的內(nèi)容，EM.system中的內(nèi)容即為最終執(zhí)行的ruby啟動(dòng)腳本。

??????? 接著會(huì)有一些檢測(cè)應(yīng)用準(zhǔn)備情況或者pid信息的操作，為一些必要的輔助操作。

??????? 最后，DEA定義了一個(gè)纖程Fiber，纖程中首先通過stage_app_dir來實(shí)現(xiàn)droplet中所有的內(nèi)容的準(zhǔn)備工作。一旦成功，則馬上調(diào)用代碼塊start_operation。

??????? 最后的最后，使用f.resume方法實(shí)現(xiàn)，纖程的喚醒。

DEA監(jiān)控應(yīng)用資源

??????? DEA完成對(duì)所在節(jié)點(diǎn)應(yīng)用的監(jiān)控主要通過周期性監(jiān)控來完成的，代碼如下：

???? [ruby] view plaincopy

  1. EM.add_timer(MONITOR_INTERVAL)?{?monitor_apps?}??

??????? 其中默認(rèn)的監(jiān)控間隔為2s。所有的實(shí)現(xiàn)在方法中monitor_apps中實(shí)現(xiàn)，簡(jiǎn)化代碼如下：

???? [ruby] view plaincopy

  1. ????def?monitor_apps(startup_check?=?false)??
  2. ??????……??
  3. ??????process_statuses?=?`ps?axo?pid=,ppid=,pcpu=,rss=,user=`.split(" ")??
  4. ??????……??
  5. ??????process_statuses.each?do?|process_status|??
  6. ????????parts?=?process_status.lstrip.split(/s+/)??
  7. ????????pid?=?parts[PID_INDEX].to_i??
  8. ????????pid_info[pid]?=?parts??
  9. ????????(user_info[parts[USER_INDEX]]?||=?[])?<
  10. ??????end??
  11. ??????……??
  12. ??????if?startup_check??
  13. ????????du_all_out?=?`cd?#{@apps_dir};?du?-sk?*?2>?/dev/null`??
  14. ????????monitor_apps_helper(startup_check,?start,?du_start,?du_all_out,?pid_info,?user_info)??
  15. ??????else??
  16. ????????du_proc?=?proc?do?|p|??
  17. ??????????p.send_data("cd?#{@apps_dir} ")??
  18. ??????????p.send_data("du?-sk?*?2>?/dev/null ")??
  19. ??????????p.send_data("exit ")??
  20. ????????end??
  21. ????????cont_proc?=?proc?do?|output,?status|??
  22. ??????????monitor_apps_helper(startup_check,?start,?du_start,?output,?pid_info,?user_info)??
  23. ????????end??
  24. ????????EM.system("/bin/sh",?du_proc,?cont_proc)??
  25. ??????end??
  26. ????end??

??????? 其中，首先看一下代碼：process_statuses = `ps axo pid=,ppid=,pcpu=,rss=,user=`.split(" ")，其實(shí)現(xiàn)的是：通過操作系統(tǒng)層，將所有進(jìn)程運(yùn)行的信息，存入 process_status數(shù)組中，然后將這個(gè)數(shù)組中按pid信息分類，存入Hash類型pid_info中，同時(shí)又通過user信息分類，存入 Hash類型user_info中，以備后續(xù)資源監(jiān)控使用。

??????? 然后通過startup_check參數(shù)，進(jìn)行不同的磁盤檢測(cè)模塊，代碼為：

????? [ruby] view plaincopy

  1. ??????du_entries?=?du_all_out.split(" ")??
  2. ??????du_entries.each?do?|du_entry|??
  3. ????????size,?dir?=?du_entry.split(" ")??
  4. ????????size?=?size.to_i?*?1024?#?Convert?to?bytes??
  5. ????????du_hash[dir]?=?size??
  6. ??????enddu_all_out?=?`cd?#{@apps_dir};?du?-sk?*?2>?/dev/null`??

??????? 該命令實(shí)現(xiàn)進(jìn)入應(yīng)用的根目錄，執(zhí)行du命令，統(tǒng)計(jì)應(yīng)用目錄所占用的磁盤空間，隨后使用monitor_app_helper方法對(duì)方才收集到的數(shù)據(jù)進(jìn)行處理，得到最終所需要的監(jiān)控?cái)?shù)據(jù)。判斷語句的另外一部分，只是通過proc代碼的方法來實(shí)現(xiàn)相同的功能。

??????? 以下分析monitor_app_helper方法。以下是通過目錄分離磁盤占用空間的實(shí)現(xiàn)：

???? [ruby] view plaincopy

  1. du_entries?=?du_all_out.split(" ")??
  2. du_entries.each?do?|du_entry|??
  3. ??size,?dir?=?du_entry.split(" ")??
  4. ??size?=?size.to_i?*?1024?#?Convert?to?bytes??
  5. ??du_hash[dir]?=?size??
  6. end??


??????? do_all_out顯示的是@droplets中所有應(yīng)用的磁盤使用情況，通過split方法或者每個(gè)應(yīng)用的信息，然后存入Hash類型du_hash中。

??????以下是最重要的信息的匯總：

???? [ruby] view plaincopy

  1. ??????@droplets.each_value?do?|instances|??
  2. ????????instances.each_value?do?|instance|??
  3. ??????????if?instance[:pid]?&&?pid_info[instance[:pid]]??
  4. ????????????pid?=?instance[:pid]??
  5. ????????????mem?=?cpu?=?0??
  6. ????????????disk?=?du_hash[File.basename(instance[:dir])]?||?0??
  7. ????????????#?For?secure?mode,?gather?all?stats?for?secure_user?so?we?can?process?forks,?etc.??
  8. ????????????if?@secure?&&?user_info[instance[:secure_user]]??
  9. ??????????????user_info[instance[:secure_user]].each?do?|part|??
  10. ????????????????mem?+=?part[MEM_INDEX].to_f??
  11. ????????????????cpu?+=?part[CPU_INDEX].to_f??
  12. ????????????????#?disabled?for?now,?LSOF?is?too?slow?to?run?per?app/user??
  13. ????????????????#?deleted_disk?=?grab_deleted_file_usage(instance[:secure_user])??
  14. ????????????????#?disk?+=?deleted_disk??
  15. ??????????????end??
  16. ????????????else??
  17. ??????????????mem?=?pid_info[pid][MEM_INDEX].to_f??
  18. ??????????????cpu?=?pid_info[pid][CPU_INDEX].to_f??
  19. ????????????end??
  20. ????????????usage?=?@usage[pid]?||=?[]??
  21. ????????????cur_usage?=?{?:time?=>?Time.now,?:cpu?=>?cpu,?:mem?=>?mem,?:disk?=>?disk?}??
  22. ????????????usage?<
  23. ????????????usage.shift?if?usage.length?>?MAX_USAGE_SAMPLES??
  24. ????????????check_usage(instance,?cur_usage,?usage)?if?@secure??
  25. ??
  26. ????????????#@logger.debug("Droplet?Stats?are?=?#{JSON.pretty_generate(usage)}")??
  27. ????????????@mem_usage?+=?mem??
  28. ??
  29. ????????????metrics.each?do?|key,?value|??
  30. ??????????????metric?=?value[instance[key]]?||=?{:used_memory?=>?0,?:reserved_memory?=>?0,??
  31. ?????????????????????????????????????????????????:used_disk?=>?0,?:used_cpu?=>?0}??
  32. ??????????????metric[:used_memory]?+=?mem??
  33. ??????????????metric[:reserved_memory]?+=?instance[:mem_quota]?/?1024??
  34. ??????????????metric[:used_disk]?+=?disk??
  35. ??????????????metric[:used_cpu]?+=?cpu??
  36. ????????????end??
  37. ??
  38. ????????????#?Track?running?apps?for?varz?tracking??
  39. ????????????i2?=?instance.dup??
  40. ????????????i2[:usage]?=?cur_usage?#?Snapshot??
  41. ??
  42. ????????????running_apps?<
  43. ??
  44. ????????????#?Re-register?with?router?on?startup?since?these?are?orphaned?and?may?have?been?dropped.??
  45. ????????????register_instance_with_router(instance)?if?startup_check??
  46. ??????????else??
  47. ????????????……??
  48. ??????????end??
  49. ????????end??
  50. ??????end??

??????? 遍歷@droplets,再遍歷@droplets中的每一個(gè)對(duì)象的instance，首先獲取實(shí)例的pid，并初始化mem，cpu，disk。隨后， 找到該instance的：secure_user，通過在user_info中找到所有instance[:secure_user]的值，然后，將其 累加進(jìn)入mem和cpu。

??????? 將獲得指定instance的資源使用情況后，需要將這些信息存入DEA維護(hù)的內(nèi)存@usage中，代碼如下：

???? [ruby] view plaincopy

  1. usage?=?@usage[pid]?||=?[]??
  2. cur_usage?=?{?:time?=>?Time.now,?:cpu?=>?cpu,?:mem?=>?mem,?:disk?=>?disk?}??
  3. usage?<


??????? 第一行需要注意操作符||=，代碼含義為若@usage[pid]不為空的話，將[ ]賦值給@usage[pid]，并最終賦值給usage。第二行代碼初始化了一個(gè)hash變量，第三行代碼表示將cur_usage加入usage數(shù) 組，而usage數(shù)組指向的是@usage[pid]的地址，所以也就相當(dāng)于在@usage[pid]中添加cur_usage。

?????? 而metrics變量則是記錄整個(gè)DEA所有運(yùn)行的應(yīng)用加起來的應(yīng)用資源，以便之后更新varz信息。

?????? 以上便是對(duì)于Cloud Foundry的DEA中的應(yīng)用啟動(dòng)與應(yīng)用資源監(jiān)控。

評(píng)價(jià)

??????? 由以上的分析可知，Cloud Foundry v1版本中的DEA在實(shí)現(xiàn)資源的監(jiān)控時(shí)，通過linux底層的ps來完成，而對(duì)于資源的控制，則并沒有做的很好，使用的方式為啟動(dòng)時(shí)限制與超額時(shí)停止的策 略。該方法顯然不是較佳的，而Cloud Foundry也推出了warden的容器，實(shí)現(xiàn)對(duì)DEA中應(yīng)用資源使用時(shí)的控制與隔離。如果筆者這腦袋能理解或者讀懂的話，期待不久給大家送上 warden的實(shí)現(xiàn)，以及cgroup的機(jī)制。


轉(zhuǎn)載清注明出處。

這篇文檔更多出于我本人的理解，肯定在一些地方存在不足和錯(cuò)誤。希望本文能夠?qū)佑|Cloud Foundry中DEA中應(yīng)用運(yùn)行與資源監(jiān)控的人有些幫助，如果你對(duì)這方面感興趣，并有更好的想法和建議，也請(qǐng)聯(lián)系我。

我的郵箱：shlallen@zju.edu.cn
新浪微博：@蓮子弗如清

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/4057.html

相關(guān)文章

  • 深入Cloud Foundry（下）

    續(xù)與回顧 本文第一部分介紹了CloudFoundry的整體架構(gòu)，并在最后花了一點(diǎn)篇幅簡(jiǎn)介CloudFoundry的代碼組織情況，以便于讀者自己去研究源代碼。筆者認(rèn)為開源項(xiàng)目較大的好處在于：當(dāng)你讀懂源代碼、理解總體架構(gòu)后，能夠成竹在胸，并吸收為己用（有點(diǎn)類似武俠小說中的北冥神功）。為己用就是本篇要說的內(nèi)容：我們使用CloudFoundry搭建自己的私有PaaS平臺(tái)。 在介紹CloudFoundry之...

    qylost 評(píng)論0 收藏0

  • 深入 Cloud Foundry（上）

    引子 今年4月份，VMware突然發(fā)布了業(yè)內(nèi)第一個(gè)開源的PaaS——CloudFoundry。幾個(gè)關(guān)鍵字：開源、PaaS、VMware，如果你對(duì)云計(jì)算感興趣，就沖著它的ApacheV2協(xié)議，如果不去GitHub拿它的代碼好好研讀一下，真有點(diǎn)對(duì)不起自己。筆者當(dāng)時(shí)就是以這樣的心態(tài)去研究它的代碼，并把它部署在我們labs里面。發(fā)布至今的這幾個(gè)月里，筆者一直關(guān)注它的演進(jìn)，并從它的架構(gòu)設(shè)計(jì)中獲益良多，...

    XiNGRZ 評(píng)論0 收藏0

  • 基于Cloud Foundry的PaaS開發(fā)與部署

    摘要：基于的實(shí)踐一綜述參見還可參見基于的實(shí)踐之集群部署單結(jié)點(diǎn)的部署由于提供的安裝腳本，使用簡(jiǎn)單不再陳述，大家參照一下官網(wǎng)即可，在此主要談?wù)劧嘟Y(jié)點(diǎn)集群部署的要點(diǎn)。關(guān)于，大家可參考和。 使用Cloud foundry(以下簡(jiǎn)稱CF)接近一年時(shí)間，一直缺少時(shí)間寫些東西與大家探討。最近，打算寫一下。目前使用經(jīng)歷主要包括：　　1. 搭建CF運(yùn)行環(huán)境并維護(hù);　　2. 部分代碼修改和新功能擴(kuò)充的工作;　　3. ...

    chinafgj 評(píng)論0 收藏0

  • PaaS未來世界

    摘要：未來世界此屏幕截圖是一個(gè)非常好的例子，它包含了通過或者命令行開始所需要的所有內(nèi)容。未來世界架構(gòu)元素核心系統(tǒng)架構(gòu)系統(tǒng)的核心和的附加功能都圍繞著控制器。而健康管理器的作用是識(shí)別任何可能產(chǎn)生的問題，并通過告知控制器或者其他機(jī)制來解決這些問題。 PaaS的未來會(huì)是什么樣的呢?NoOps和DevOps又如何融入其中呢?PaaS將會(huì)讓開發(fā)者生活的更加輕松。 實(shí)際上，PaaS是一些事物的混合體，它關(guān)注更快...

    Lavender 評(píng)論0 收藏0

  • IBM Bluemix開啟云開發(fā)時(shí)代

    摘要：運(yùn)行時(shí)環(huán)境，又叫構(gòu)建包上提供的一系列運(yùn)行時(shí)環(huán)境包括圖中顯示的七種命名構(gòu)建包，外加已批準(zhǔn)用于的其他任何構(gòu)建包。開發(fā)運(yùn)營(yíng)服務(wù)上的八種開發(fā)運(yùn)營(yíng)服務(wù)包括來自的五種服務(wù)和來自第三方的三種服務(wù)。 去年夏天我測(cè)評(píng)了Cloud Foundry PaaS（平臺(tái)即服務(wù)），當(dāng)時(shí)著眼于Pivotal和ActiveState這兩種解決開源方案。這回測(cè)試時(shí)，我將關(guān)注IBM Bluemix，這是在SoftLayer上托管...

    cocopeak 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<