我是新来的AWS,做我的研究,但没有得到一个很好的答案,所以问一个简单的问题。
什么到目前为止,我已经做了
- 我开始一个Linux AMI,安装LAMP和部署我的应用程序,这是工作的罚款
- 弹性IP是AMI的设置
- 域名也正确地指出
所以,事实上,如果你http://example-domain-name.com你就可以看到应用程序,与它进行交互...
我的问题是,我现在能完成的,是我的应用程序正确部署 ? 正如我所听到的恐怖故事,包括AWS AMI崩溃等。
能否请您在此分享经验。
我是新来的AWS,做我的研究,但没有得到一个很好的答案,所以问一个简单的问题。
什么到目前为止,我已经做了
所以,事实上,如果你http://example-domain-name.com你就可以看到应用程序,与它进行交互...
我的问题是,我现在能完成的,是我的应用程序正确部署 ? 正如我所听到的恐怖故事,包括AWS AMI崩溃等。
能否请您在此分享经验。
The best of all possible cases, per your comment on your question, is a highly available, multi-AZ, autoscaling web tier, backed either with a replicating mysql db or, if you can afford it, something like Amazon RDS. Here's an example CloudFormation template that will build more or less what I just described in about two clicks, after you fill out a couple of variables.
It's overkill... I suppose... but if you are concerned about Amazon's myriad failure modes, high availability can be had for a price. That template's default instances (including multi-AZ RDS) come to about $270 a month for 24/7 uptime. If you were really dedicated to your blog, and could guarantee you'd be writing on it for years, you could save a fair bit of money using reserved instances.
That's a lot of money, yes. But it's also less than my monthly car insurance rate in NYC. That says more about my dubious insurer or my driving record than Amazon's prices, but in some personal applications highly available designs might be worth the cost. How much is your time worth to you? How about the blog?
Call that the gold standard, because you have to have a dump truck full of gold to afford it and still eat. What do you lose when you start hemorrhaging pieces?
AZs: Shoot multi-AZ deployment and you risk an AZ outage. This doesn't happen that often but then again neither do derechos in the DC metro. Don't worry though, if you design around a single AZ, you're in some huge and perhaps unexpected company.
RDS / replicated MySQL: Lose highly available data solutions and you risk losing your data. This is such a pain to recover from you'd best design with it in mind, even if it's as simple as the occasional EBS snapshot.
Multiple webservers: Like the MySQL database, if you put your web tier on one machine, you're asking for an outage. You can design around it, if you can afford alternatives. Otherwise you'll want a simple programmatic way to construct your webserver.
Autoscaling: I don't understand why anyone designs an AWS application without using autoscaling via CloudFormation or the CLI tools, even if the minimum number and maximum number of instances is exactly one. The free tier of AWS pricing includes plenty of CloudWatch metrics to make instance monitoring easy, but of course this depends on...
Configuration management: The common thread in every AWS design is configuration management. It's the most important component of your deployment process regardless of how many machines you actually deploy. Whether you're using CloudFormation, Chef, Puppet, some other service, or a combination thereof, any time you spend on configuration management now, when the machine construction is still fresh in your mind, will be rewarded later.
Each of these components contributes to your application's stability, and all of them cost money or time. It's just a matter of what you want to spend, and when.
You can get part of the way to the gold-standard with Amazon's free tier. It includes enough hours to run a micro instance, an ELB, and a small RDS instance continuously in a single AZ. It also allows the use of 10 custom CloudWatch metrics at the time of this writing. The free tier is available only to new customers for their first year of use. Were you to combine its offerings with some basic configuration management, you could reasonably run a small blog on AWS in a way that avoids many downtime scenarios.
要明白,你的AWS EC2服务器“可能”失败在什么时候,这是“设计” ......他们收取您在廉价非冗余硬件商品房租便宜是很重要的......没有SLA .. 。
所以,真正的问题是:你有据可查(理想的脚本)过程中可以快速从头开始重建服务器和/或从EBS快照恢复?
如果这个问题的答案是:是的! 然后我会说你已经“做对” ...
如果没有,你可能要花费一点时间了解坏事,可以在AWS土地发生......(再次“设计”)。
有没有什么好办法。 至少,你需要一个负载均衡器和两个应用实例。 此外,根据您的应用程序,你需要一个容错RDS实例和/或S3。
AWS是一个简单的应用程序或博客的错误的解决办法。 您可以通过使用一个VPS或专用服务器在其他供应商获得更好的性能和耐用性的显著降低成本。 有了AWS,你付出的迅速扩展的应用程序的能力溢价。 如果你不需要这么做,这不是正确的选择。 90%使用AWS的人不明白这一点。