[AWS] Cloudformation Study

AWS內部函數參考
以下皆採用YAML的格式

Ref

cloudformation 自己的函數, 用來回傳指定的”Parameters”或”Resources”的值
縮寫
    !Ref 自定義邏輯名稱
更多詳細資料
ex:
Parameters:
  KeyName:
    Description: The EC2 Key Pair to allow SSH access to the instance
    Type: 'AWS::EC2::KeyPair::KeyName'
Resources:
  Ec2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      SecurityGroups:
        - !Ref InstanceSecurityGroup
        - MyExistingSecurityGroup
      KeyName: !Ref KeyName
      ImageId: ami-7a11e213
  InstanceSecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: Enable SSH access via port 22
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: 0.0.0.0/0
像上面這個例子, Ec2Instance > Properties > SecurityGroups 底下有個
!Ref InstanceSecurityGroup
!Ref 就是去搜尋在Resources/Parameters中的邏輯名稱為 InstanceSecurityGroup 的
上面的例子就會找到在Resources中的InstanceSecurityGroup
InstanceSecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: Enable SSH access via port 22
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: 0.0.0.0/0

Fn::FindInMap

回傳與Mappings中對應到的值
用法
!FindInMap [ MapName, TopLevelKey, SecondLevelKey ]
  • MapName
    • Mappings 部分中所宣告的邏輯名稱，包含Key和Value
  • TopLevelKey
    • 最上層的Key名稱。Value為一個Key/Value Pair列表
  • SecondLevelKey
    • 第二層Key的名稱，為分配给 TopLevelKey 的列表中的其中一個key
ex:
Mappings: 
  RegionMap: 
    us-east-1: 
      32: "ami-6411e20d"
      64: "ami-7a11e213"
    us-west-1: 
      32: "ami-c9c7978c"
      64: "ami-cfc7978a"
    eu-west-1: 
      32: "ami-37c2f643"
      64: "ami-31c2f645"
    ap-southeast-1: 
      32: "ami-66f28c34"
      64: "ami-60f28c32"
    ap-northeast-1: 
      32: "ami-9c03a89d"
      64: "ami-a003a8a1"
Resources: 
  myEC2Instance: 
    Type: "AWS::EC2::Instance"
    Properties: 
      ImageId: !FindInMap [ RegionMap, !Ref "AWS::Region", 32 ]
      InstanceType: m1.small
RegionMap 為 MapName
AWS::Region比較特別, 是會回傳你的Region
假如我在新加坡, 那AWS::Region會是ap-southeast-1
32就是 ap-southeast-1 底下那個32
更多關於Fn::FindInMap

Fn::GetAtt

回傳 YAML/JSON 中 Resources 的 Property 值
用法
!GetAtt logicalNameOfResource.attributeName
  • logicalNameOfResource
    • 定義在Resources中的邏輯名稱
  • attributeName
    • 資源特定的屬性名稱
ex:
AWSTemplateFormatVersion: 2010-09-09
Resources:
  myELB:
    Type: 'AWS::ElasticLoadBalancing::LoadBalancer'
    Properties:
      AvailabilityZones:
        - eu-west-1a
      Listeners:
        - LoadBalancerPort: '80'
          InstancePort: '80'
          Protocol: HTTP
  myELBIngressGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: ELB ingress group
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '80'
          ToPort: '80'
          SourceSecurityGroupOwnerId: !GetAtt myELB.SourceSecurityGroup.OwnerAlias
          SourceSecurityGroupName: !GetAtt myELB.SourceSecurityGroup.GroupName
更多可以取回的資料

留言

張貼留言

這個網誌中的熱門文章

[MySQL] schema 與資料類型優化

圖片
選擇優化的資料類型 原則: 越小越好 因為會佔用最小的磁碟、記憶體與CPU快取。 越簡單越好 操作整數比操作字串代價低，因為字串排序規則 ex: 儲存ip應該用 unsigned int - 4 bytes, 用 varchar 會用到 15 bytes 儲存時間應該用 mysql 內建的時間類型 DATETIME, TIMESTAMP可以儲存相同資料：時間日期，精確到秒 TIMESTAMP 只用 DATETIME 一半的儲存空間，根據時區自動變化 TIMESTAMP 允許的時間範圍比 DATETIME 小很多 避免 NULL 在 innodb 上有單獨的 bit 儲存 null 值，但在 myisam，但還是盡量避免 整數類型 tinyint - 8 bits smallint - 16 bits mediumint - 24 bits int - 32 bits bigint - 64 bits 如果是有正負數的，會因為 1 bits 會用來記錄正負，故範圍為 -2^(n-1) ~ 2^(n-1) unsigned 的範圍則是 -2^n ~ 2^n MySQL 可以為整數指定寬度，例如 INT(11)，其實沒什麼意義，11只是表示與 MySQL 相關工具(client 端的 cli) 用來顯示的長度，對於儲存與計算來說，INT(1)與INT(20)是一樣的。 實數類型 decimal(M,N) - M: 最大位數, N: 小數點後有幾位 ex: decimal(18, 9) => 9位數字.9位數字，總共使用 9 個 bytes float => 4 bytes double => 8 bytes decimal的計算雖然比較精確，但需要額外，但需要額外的空間與計算開銷，資料量較大時，可以用 bigint 代替 decimal，假設需要精準到萬分之一，則可以將數字*1百萬，將結果存在 bigint 內，可以同時避免福點數計算不精準與 decimal 計算代價太高。 字串類型 VARCHAR row_format=fix，這樣就都會固定長度，沒意義 varchar會需要額外1~2 bytes記錄長度, 假設用 latin1 charset, varchar(10) => 11 bytes, varchar(1000) => 1002...
閱讀完整內容

[翻譯] 介紹現代網路負載平衡與代理伺服器

圖片
原文(Source): https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236 什麼是網路負載平衡 (network load balancing) 與 代理伺服器的代理行為 (proxying)? 維基百科是這樣定義負載平衡的 > 負載平衡藉由工作量分配到多台運算資源, 例如: 主機, 主機叢集, 網路連結, CPU,  硬碟等. > 負載平衡盡量最佳化資源的使用, 最大化每個最大化每個資源的吞吐量(生產能力), 最小化反應時間, 避免單一資源工作量過重 > 使用多個資源來當負載平衡來提升可靠與高可用而不是單一個資源 > 負載平衡總是使用獨立的軟體或硬體, 例如獨立的 multilayer switch, 或是 DNS主機的程式 上面的定義用於各資訊領域的各方面, 不單單只有網路而已. 作業系統使用負載平衡在實體處理器去分配運算任務, 容器編排服務像是K8S使用負載平衡在不同的主機叢集中去分配任務, 而網路負載平衡器則是將網路上進來的任務分配給可用的後端主機們. 剩下的文章主要都是講解關於網路負載平衡. 圖1 圖1展示了從應用層來看網路負載平衡. 許多的用戶端(Client)透過只需要向 load balancer 請求, load balancer就會將這些request, 也就是上述提到的任務分配給可用的後端服務. Load balancer位於Client 與後端之間執行幾個重要的任務: 服務發現 (Service discovery) 後端的服務在系統的哪裡, 他們的IP(位置)是什麼? (也就是load balancer該如何與後端主機溝通) 服務的狀態檢查 (Health checking) 現在的服務是否是可接受請求的 負載平衡 (Load Balancing) 該用什麼樣的演算法去平均將request分配給可用的服務 在分散式系統使用負載平衡主要有幾個好處: 主機抽象 (Naming abstraction): 每個client 不需要知道每個後端服務在哪, 只需要利用預先定義好的機制向負載平衡器...
閱讀完整內容