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