AWS EC2 总结和实验

Elastic Computing Cloud

其实本质就是个虚拟机。
虚拟机的资源划分就和咱们普通的服务器没啥区别。计算，存储，内存。因此AWS在提供EC2服务的时候也是这么划分的。固然由于业务的需求，如今细分了很多。
英语名称为instance type：

一个compute optimized 的instance type的参数

当咱们在launch一个EC2 intance的时候，须要选择一个AMI(AWS Machine Image)。我我的理解这个相似虚拟机硬盘的一个指针，（固然同时包含了实例须要的操做系统，应用程序及其相关的模板）。由于虚拟机的硬盘，内存等其实都是以文件的形式存在的。因此只要provision了一堆资源，当用户发起一个EC2，只要把预先弄好的指针指到相应的EBS 卷就能够了。

4种类型的AMI

1. Published by AMI 免费的
2. AMI Marketplace （这个是第三方发布的，例如微软会发布一个打完补丁的Windows 2016）
3. Generated from Existing Instance 顾名思义
4. Uploaded Virtual Services （能够用VMWare 的ova，vmdk文件生产虚拟机，由于咱们知道AWS是基于KVM开发的）

AWS默认以及建议使用密钥对（Key Pair）的形式访问EC2实例，AWS将保存public key，用户负责保存私private key。

安全组（Security Group）检测数据包的端口、协议、源IP地址，相似一个stateful Firewall的做用。记住Security Group只有allow，没有deny

弹性IP（Elastic IP address）：
An elastic IP address is an address unique on the Internet that you reserve independently and associate with an Amazon EC2 instance. 其实能够把它简单的理解为公网地址。这个Elastic IP有个备份功能，即这台虚拟机挂了，接上来的虚拟机能继续使用这个elastic ip，从而实现冗余。
Because it can be transferred to a replacement instance in the event of an instance failure, it is a public address that can be shared externally without coupling clients to a particular instance.

在开启EC2 instance的时候，有几个feature在实际运维中也能够有所帮助。

1. Bootstraping：实际上就是在开机的时候刷一段脚本，能够是Linux bash，也能够是Windows Powershell
2. VM import/export 不只能够从AMI导入。也能够将现有的EC2导出，而后放入on-prem的环境里
3. Instance meta data： http://169.254.169.254/latest/meta-data/ 会以json格式返回大量的关于此EC2 instance的attributes

EC2的计费类型
On-Demand Instances 用多少付多少
Reserved Instances
和AWS签一年或者三年的合同，能够得到折扣。同时买断这些运算资源
Spot Instances 竞价实例，较为便宜，但同时用户获得的资源也不稳定
Scheduled Reserved Instances
Dedicated Instances
Dedicated Hosts
重点是前三种

开始进入console 建立一个EC2

第一个EC2， 选择AWS 的Linux，里面预装了AWS CLI，Ruby，Python
step 1 Choose AMI
step 2 选择instance type
step 3 配置参数

这里说一下placement group
When you launch a new EC2 instance, the EC2 service attempts to place the instance in such a way that all of your instances are spread out across underlying hardware to minimize correlated failures.
cluster：同一个AZ，通常使用在延时低的环境里面。

同时，若是开启了CloudWatch对这台EC2进行监控会有额外费用产生。

租户啥的不用管。通常都用最便宜的。

step 4 Add storage 其实就是建立一个EBS volume
step 5 Add Tags

Step 6 Security Group

AWS居然还能自动检测我家的ip地址……

当review 完launch以后，生成一对秘钥对。
记得这个秘钥对须要用putty的generator从新load一下 变成ppk形式才能使用。而后Amazon Linux不是root user……是ec2-user...
成功进入

查看metadata的方法 curl http://169.254.169.254/latest/meta-data/

建立完EC2以后，也要捎带开一下这个dashboard

我的以为比较重要的是Tag。Tag能够在业务层面打上表示，在day2 的运维中，不少其余的AWS服务也能调用。典型例子就是IAM。

在建立EC2的时候，须要挂载一个卷。一般卷咱们会使用EBS。注意EBS，实际上是区别于S3的一种存储服务，也是能够存数据的，只不过单价较贵，咱们一般只会用来给EC2的实例使用。
比较有趣的是，EBS是能够脱离EC2实例存在的，即你terminate一个EC2的时候，你是能够选择是否保留这个EBS卷的。这个EBS卷，只在本AZ里面生效。这里我搬运一句study 贵的上的原话：Each Amazon EBS volume is automatically replicated within its Availability Zone to protect you from component failure。

EBS备份的方式是作snapshot，这个snapshot能够保存在S3上面，而且是incremental的。
若是要将EBS卷复制到不一样的AZ，那就是将这个快照复制到另一个AZ，而后根据这个snapshot生成一个卷。

EBS根据需求通常分为三类，magenetic，general purpose SSD， provisioned-IOPS-SSD。加个么，确定最后那个最贵啦。
总结一下：

1. 备份的快照将会保存在亚马逊S3 (Simple Storage System)上
2. EBS快照属于ncremental backup，即只会在更新过的数据上作备份
3. 你能够在EC2实例运行的状态下进行EBS的快照操做，但会给EC2的系统带来必定延迟（CPU，内存利用率会变高）
4. 最佳实践是将EC2实例中止，而后将EBS从EC2上卸载下来，进行快照操做
5. 你能够基于EBS Snapshot去建立一个新的EBS volume
6. 加密的EBS volume创造的snapshot， 也是自动加密的

EC2/AMI/EBS/Snapshot的关系

若是想要将EC2从一个区域迁移到另一个区域。惟一的方法就是以下：

1. 从EC2中建立一个AMI
2. 将此AMI复制到另外一个region中，注意，虽然AMI 内容同样，可是AMI的ID是不一样的
3. 经过这个AMI建立一个EC2实例
4. 将此EC2挂载的EBS卷，备份成snapshot
5. 将snapshot迁移到另一个区域（其实这是S3的操做），转换成一个EBS卷
6. 将这个volume挂载到咱们以前建立的EC2上

同一个AZ就不用那么麻烦了，直接建立一个你想要的用的EBS挂上去就行。

ELB/ALB/ASG
AWS的load balancer在功能性上较为简单，只是简单的TCP，SSL。实际上就是F5的LTM的基础功能。不过在通常的生产环境中也够用了。load balancer自己也是managed service，因此不须要对太多的具体参数进行调优，也不须要考虑redundancy，打补丁等，由于原本就是分布式架构

study guide上把load balancingf和auto scaling 单独放在一章，配置界面里面能够看到实际上集成在EC2 dashboard的。

一边配置这个load balancer一边讲概念

Step 1： 基础配置
Internet LB vs Internal LB
Internet 好理解，通常来讲end user都是经过用户名访问某些资源（一般是web server，因此这里我选择了ALB，listener 开启https 443）
Internal LB 一般是放在web server访问application server之间。我放一段学习指南的原话：
An Internet-facing load balancer might receive and balance external traffic to the presentation or web tier whose Amazon EC2 instances then send its requests to a load balancer sitting in front of the application tier.

注意在基础配置里面，会让你选择AZ，能够看出AWS的load balancer就是分布式架构。

Step 2: 安全配置

这里的证书，其实就是一个根证书，用来validate用户访问的。取决于你是用internal 仍是internet LB。

Step 3 Configuring Routing

选择target group，实际上就是F5里面的Pool，定义了一个业务/服务。

Step 4 Registering Targets
往Pool 里面添加pool member。通常这时候Auto Scaling Group就派上用场了。
附上茶馆的一张图：

Auto Scaling：自动地增长/减小EC2实例的数量，从而让你的应用程序一直能保持可用的状态。

Auto Scaling Plans：(一看名字就一目了然，没啥好说的）

1. Manual Scaling
2. Sceduled Scaling
3. Dynamic Scaling

Auto Scling 的组件

1. Launch Configuration
   其实就是一台EC2 通常须要的参数 （这个截图就不放了，基本和建立一台EC2 没设呢么区别，就是少了些步骤）
   AMI， keypair，Instance type， Security Group，IAM Role（这些能够复用的参数）
2. Auto Scaling Group
   Name, Launch Configuration, AZ, Desired Capacity, Maximum Capacity, Load Balancer
3. Scaling policy
   指的是在何种状况下咱们须要添加或者删减EC2 的实例。Auto Scaling Group还能够根据CloudWatch的警报在调整。
   

放一张三个组件的关系。

这里补充一点IAM的操做。当我要在EC2上使用AWS CLI的时候，如今是不让的。

须要建立一个基于SDK的user

建立完以后会有个key 生成，记得须要保存。

经过AWS configure进行配置就能够用AWS CLI啦。因此以此类推，这个

能够看出基本上仍是以一个json的形式。我的感受这个对于devops意义不大，我我的仍是更喜欢rest api

当我更改了这个policy以后，能够看见S3的操做就不能操做了。

不过这种方式毕竟有泄露key的风险，因此最保险的方法仍然是使用role。因为AWS的架构其实就是将各类服务串联在一块，因此颇有必要熟练使用role。首先建立一个role，适用服务EC2，选择的策略S3fullAccess

而后在EC2上attach
![](https://s4.51cto.com/images/blog/202006/30/9ef2aade3df417f90515b667338a72d7.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk