快速使用AWS的14个经验分享

快速使用AWS的14个经验分享

ID:40500512

大小:146.65 KB

页数:8页

时间:2019-08-03

快速使用AWS的14个经验分享_第1页
快速使用AWS的14个经验分享_第2页
快速使用AWS的14个经验分享_第3页
快速使用AWS的14个经验分享_第4页
快速使用AWS的14个经验分享_第5页
资源描述:

《快速使用AWS的14个经验分享》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、快速使用AWS的14个经验分享在今天的文章中,我整理出了大量当初曾经错过、而至今仍将我追悔莫及的AmazonWebServices(简称AWS)使用心得。在几年来的实践当中,我通过在AWS之上新手构建及部署各类应用程序而积累到了这些经验。虽然内容有些杂乱,但相信仍然能给各位带来一点启示。从物理服务器向“云环境”转移的过程不仅仅是一项技术任务,同时也意味着我们的思维方式需要作出针对性的转变。总体而言,在物理环境下我们需要关注的只是每一台独立主机;它们各自拥有自己的静态IP,我们能够对其分别加以监控。而一旦其中一台发生故障,我们必须尽最大可能让其快速

2、恢复运转。大家可以以为只要将基础设施转移到AWS环境之下,就能直接享受到“云”技术带来的种种收益了。遗憾的是,事情可没那么简单(相信我,我亲身尝试过了)。在AWS环境之下,我们必须转变思维,而且这方面的任务往往不像技术难题那么容易被察觉。因此,受到了SehropeSarkuni最近一篇帖子的启发,我将自己几年来积累得出的AWS使用心得汇总于此,而且说实话、我真希望自己当初刚刚接触AWS时能有人告诉我这些宝贵经验。这些心得总结自我在AWS之上部署个人及工作应用程序时的亲身感受,其中一部分属于需要高度关注的“疑难杂症”(我自己就是直接受害者),而另一

3、部分则是我听其他朋友说起过、并随后亲自确认有效的解决方案。不过总体而言,为了积累这些经验,我确实付出了相当惨痛的代价:)应用程序开发千万不要把应用程序状态保存在自己的服务器上。之所以这么说,是因为一旦我们的服务器发生故障,那么应用程序状态很可能也随之彻底消失。有鉴于此,会话应当被存储在一套数据库(或者其它某些集中式存储体系、memcached或者redis当中)而非本地文件系统内。日志信息应当通过系统日志(或者其它类似方案)进行处理,并被发送至远程位置加以保存。上传内容应当直接指向S3(举例来说,不要将其存储在本地文件系统内,并通过其它流程随后迁

4、移到S3)。再有,任何已经处理过或者需要长期运行的任务都应该通过异步队列(SQS非常适合处理此类任务)来实现。编辑点评:对于S3上传内容而言,HN用户Krallin指出,我们可以彻底避免其与自有服务器的接触,并利用预签名URL保证用户的上传数据被直接发送至S3当中。将额外信息保存在日志当中。日志记录通常包含有时间戳以及pid等信息。大家也可能希望将实例id、服务区域、可用区以及环境(例如分步环境或者生产环境等)添加进来,而这些都能在日后的调试工作中作为参考。大家可以从instancemetadataservice当中获取到这些信息。我所采用的方法

5、是将这些信息作为引导脚本的组成部分,并将其以文件形式存储在文件系统当中(例如/env/az或者/env/region等)。这样一来,我就用不着持续查询元数据服务来获取这些信息了。大家应当确保这些信息能够在实例重新启动时得到正确更新,毕竟我们都不希望在保存AMI时发现其中的数据还跟上次完全一样,这肯定属于非正常状况。如果我们需要与AWS进行交互,请在当前语言中使用对应SDK。千万不要试图自己动手。我当初就犯过这个错误,因为我认为自己只是单纯需要向S3上传内容,但随着后续服务的持续增加、我发现自己的决定简直愚蠢至极。AWSSDK的编写质量很高,能够自

6、动处理验证、处理重试逻辑,而且由Amazon官方负责维护与迭代。此外,如果大家使用EC2IAM角色(大家绝对应该这么做,这一点我们后面会进一步提到),那么该SDK将帮助我们自动获取到正确的证书。利用工具查看应用程序日志。大家应当采用管理员工具、系统日志查看器或者其它方案,从而帮助自己在无需在运行中实例内使用SSH的方式查看当前实时日志信息。如果大家拥有集中式日志记录系统(我强烈建议大家使用此类系统),那么当然希望能在不使用SSH的情况下完成日志内容查看任务。很明显,将SSH引入正处于运行状态的应用程序实例会引发诸多弊端。运营心得如果将SSH引入自

7、己的服务器,那么自动化机制恐怕将无法生效。在全部服务器上禁用SSH访问。这听起来确实有点疯狂,我知道,但在大家的安全组当中、请务必确保端口22不向任何人开放。如果各位想从今天的文章中获得什么启示,那请千万牢记以下一点:如果将SSH引入自己的服务器,那么自动化机制恐怕将无法生效。从防火墙级别(而非服务器本身)禁用SSH有助于整套框架实现思维转变,因为这样一来我们就能了解到哪些区域需要进行自动化改造,同时大家也能更轻松地恢复访问来解决当前面临的问题。在意识到再也不必将SSH引入实例之后,大家肯定会像我一样感到浑身轻松。没错,这是我在实践中了解到的最惊

8、世骇俗、但也却具实用性的心得。编辑点评:很多人对这项心得表现出了高度关注(HackerNews网站上还出现了不少值得一读的评论意见),因

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。