資源描述：
《快速使用AWS的14個經(jīng)驗分享》由會員上傳分享，免費在線閱讀，更多相關內(nèi)容在教育資源-天天文庫。
1、快速使用AWS的14個經(jīng)驗分享在今天的文章中，我整理出了大量當初曾經(jīng)錯過、而至今仍將我追悔莫及的AmazonWebServices（簡稱AWS）使用心得。在幾年來的實踐當中，我通過在AWS之上新手構建及部署各類應用程序而積累到了這些經(jīng)驗。雖然內(nèi)容有些雜亂，但相信仍然能給各位帶來一點啟示。從物理服務器向“云環(huán)境”轉移的過程不僅僅是一項技術任務，同時也意味著我們的思維方式需要作出針對性的轉變?？傮w而言，在物理環(huán)境下我們需要關注的只是每一臺獨立主機;它們各自擁有自己的靜態(tài)IP，我們能夠對其分別加以監(jiān)控。而一旦其中一臺發(fā)生故障，我們必須盡最大可能讓其快速
2、恢復運轉。大家可以以為只要將基礎設施轉移到AWS環(huán)境之下，就能直接享受到“云”技術帶來的種種收益了。遺憾的是，事情可沒那么簡單(相信我，我親身嘗試過了)。在AWS環(huán)境之下，我們必須轉變思維，而且這方面的任務往往不像技術難題那么容易被察覺。因此，受到了SehropeSarkuni最近一篇帖子的啟發(fā)，我將自己幾年來積累得出的AWS使用心得匯總于此，而且說實話、我真希望自己當初剛剛接觸AWS時能有人告訴我這些寶貴經(jīng)驗。這些心得總結自我在AWS之上部署個人及工作應用程序時的親身感受，其中一部分屬于需要高度關注的“疑難雜癥”(我自己就是直接受害者)，而另一
3、部分則是我聽其他朋友說起過、并隨后親自確認有效的解決方案。不過總體而言，為了積累這些經(jīng)驗，我確實付出了相當慘痛的代價：)應用程序開發(fā)千萬不要把應用程序狀態(tài)保存在自己的服務器上。之所以這么說，是因為一旦我們的服務器發(fā)生故障，那么應用程序狀態(tài)很可能也隨之徹底消失。有鑒于此，會話應當被存儲在一套數(shù)據(jù)庫(或者其它某些集中式存儲體系、memcached或者redis當中)而非本地文件系統(tǒng)內(nèi)。日志信息應當通過系統(tǒng)日志(或者其它類似方案)進行處理，并被發(fā)送至遠程位置加以保存。上傳內(nèi)容應當直接指向S3(舉例來說，不要將其存儲在本地文件系統(tǒng)內(nèi)，并通過其它流程隨后遷
4、移到S3)。再有，任何已經(jīng)處理過或者需要長期運行的任務都應該通過異步隊列(SQS非常適合處理此類任務)來實現(xiàn)。編輯點評:對于S3上傳內(nèi)容而言，HN用戶Krallin指出，我們可以徹底避免其與自有服務器的接觸，并利用預簽名URL保證用戶的上傳數(shù)據(jù)被直接發(fā)送至S3當中。將額外信息保存在日志當中。日志記錄通常包含有時間戳以及pid等信息。大家也可能希望將實例id、服務區(qū)域、可用區(qū)以及環(huán)境(例如分步環(huán)境或者生產(chǎn)環(huán)境等)添加進來，而這些都能在日后的調(diào)試工作中作為參考。大家可以從instancemetadataservice當中獲取到這些信息。我所采用的方法
5、是將這些信息作為引導腳本的組成部分，并將其以文件形式存儲在文件系統(tǒng)當中(例如/env/az或者/env/region等)。這樣一來，我就用不著持續(xù)查詢元數(shù)據(jù)服務來獲取這些信息了。大家應當確保這些信息能夠在實例重新啟動時得到正確更新，畢竟我們都不希望在保存AMI時發(fā)現(xiàn)其中的數(shù)據(jù)還跟上次完全一樣，這肯定屬于非正常狀況。如果我們需要與AWS進行交互，請在當前語言中使用對應SDK。千萬不要試圖自己動手。我當初就犯過這個錯誤，因為我認為自己只是單純需要向S3上傳內(nèi)容，但隨著后續(xù)服務的持續(xù)增加、我發(fā)現(xiàn)自己的決定簡直愚蠢至極。AWSSDK的編寫質(zhì)量很高，能夠自
6、動處理驗證、處理重試邏輯，而且由Amazon官方負責維護與迭代。此外，如果大家使用EC2IAM角色(大家絕對應該這么做，這一點我們后面會進一步提到)，那么該SDK將幫助我們自動獲取到正確的證書。利用工具查看應用程序日志。大家應當采用管理員工具、系統(tǒng)日志查看器或者其它方案，從而幫助自己在無需在運行中實例內(nèi)使用SSH的方式查看當前實時日志信息。如果大家擁有集中式日志記錄系統(tǒng)(我強烈建議大家使用此類系統(tǒng))，那么當然希望能在不使用SSH的情況下完成日志內(nèi)容查看任務。很明顯，將SSH引入正處于運行狀態(tài)的應用程序實例會引發(fā)諸多弊端。運營心得如果將SSH引入自
7、己的服務器，那么自動化機制恐怕將無法生效。在全部服務器上禁用SSH訪問。這聽起來確實有點瘋狂，我知道，但在大家的安全組當中、請務必確保端口22不向任何人開放。如果各位想從今天的文章中獲得什么啟示，那請千萬牢記以下一點：如果將SSH引入自己的服務器，那么自動化機制恐怕將無法生效。從防火墻級別(而非服務器本身)禁用SSH有助于整套框架實現(xiàn)思維轉變，因為這樣一來我們就能了解到哪些區(qū)域需要進行自動化改造，同時大家也能更輕松地恢復訪問來解決當前面臨的問題。在意識到再也不必將SSH引入實例之后，大家肯定會像我一樣感到渾身輕松。沒錯，這是我在實踐中了解到的最驚
8、世駭俗、但也卻具實用性的心得。編輯點評:很多人對這項心得表現(xiàn)出了高度關注(HackerNews網(wǎng)站上還出現(xiàn)了不少值得一讀的評論意見)，因
