早安，這是「第 55 屆全國技能競賽英雄榜暨第3屆亞洲技能競賽及第 48 屆國際技能競賽國手選拔賽青年組雲端運算職類」系列文章的第五篇，這次來分享科目五的題目和解題過程。轉眼間就寫到最後一篇了，等九月的二階國手選拔結束後再來繼續寫幾篇吧。

科目五: 一堆監控

這題都圍繞在 CloudWatch 的各項功能上，從 Metrics、Logs、Application Signals (APM) 到 Network Monitoring，可以說是把 CloudWatch 的功能都用上了。

題目提供了一個 CloudFront + S3 + API Gateway + Lambda 的架構，並要求使用者去監控這個架構的各項指標。

這題必須要先解第一大題才會開啟剩下的題目，因為整題都圍繞在 CloudWatch，且我沒有照順序做也沒做完，所以只列出大致的方向：

• Lambda Code 改 metric unit
• Metric filter 擷取特定 log 並轉換為 metric
• Synthetics Canaries 監控 API 的可用性
• 建立 Dashboard 來顯示各項指標
• Metric anomaly detection 異常偵測
• Internet monitors 監控各國連線狀態
• RUM 監控實際使用者行為
• 從 JSON 匯入 Dashboard
• Dashboard 新增 RSS reader
• WAF 封鎖 VPN 流量
• 從 WAF logs 提取欄位
• Logs Insights 查詢並產生指定報表

Lambda Code 改 metric unit

題目提到某 API 端點產生的 metrics unit 為 Percentage，需要將其改為 Count。

到 CloudFront 可以得知 /api 的 origin 是 API Gateway，進入 API Gateway 後找到對應的 endpoint 即可找到目標 Lambda。進入 Lambda 後可以很明顯地看到 unit 設為 Percentage，將其改為 Count 並 Deploy 即可。

python
def lambda_handler(event, context):
    # ...
    metric_data = {
        'MetricName': 'APIRequests',
        'Unit': 'Percentage',  # 改為 Count
        'Value': 1,
        # ...
    }
    # ...

Metric filter 擷取特定 log 並轉換為 metric

題目要求將 /api/donate 的 payload 提取 amount 出來，並轉換為 metric。

透過剛剛的方式找到目標 Lambda，進入後可以看到程式碼內並沒有用到 metric，且我們也沒有修改程式碼的權限，但程式碼內有 logging 且內容為我們要的 amount。因此我們可以透過 CloudWatch Logs 的 Metric filter 來擷取這些訊息。

python
def lambda_handler(event, context):
    # ...
    payload = event['body']
    logger.info({
      'event': 'donate',
      'amount': payload['amount'],
    })
    # ...

在 CloudWatch Logs 找到對應的 Lambda log group，Actions -> Create metric filter，然後輸入以下 pattern：

json
{ $.event = "donate" && $.amount = * }

接著在下一步中設定 namespace 為題目指定的 UnicornFarm，metric name 為 Donations，metric value 為 $.amount，unit 為 Count 即可。

Synthetics Canaries 監控 API 的可用性

這題要透過 Synthetics Canaries 來監控 API 的可用性。功能跟 uptime robot 類似，就是定期發 request 去戳一下看正不正常。

這題因為題目講得不清不楚，我直接跑去設 UAM 想說怎麼沒得分，花了 20 分鐘把 CloudWatch 都摸過才知道原來是要用它…

在 CloudWatch Synthetics 中建立一個新的 Canary，Blueprints 選擇 API Canary，然後新增 HTTP request:

yaml
- Method: POST
- Application or endpoint URL: https://xxx.cloudfront.net/api/donate
- Headers:
  - Content-Type: application/json
- Request data:
  { "amount": 0 }

需要留意題目提到的 API 為走 CloudFront 的，所以不能勾選 “I’m using an Amazon API Gateway API”。

接下來設定 Schedule 為每分鐘執行一次，然後 Deploy 即可。

賽後跟其他選手討論發現蠻多人設定完也沒有得分被卡著不能繼續，好像一定要用 API canary 的 blueprints 才會過。

建立 Dashboard 來顯示各項指標

題目要求建立一個 Dashboard 來顯示各項指標。

在 CloudWatch 中建立一個新的 Dashboard，然後把剛剛建立的 metric 和 canary 加入到 Dashboard 中即可。

Metric anomaly detection 異常偵測

題目要求對 Donations metric 建立異常偵測。當每分鐘的數值過小時發出 SNS 通知。

SNS 已經幫你建好了，只需要在 CloudWatch 中對 Donations metric 建立 alarm，threshold type 設為 Anomaly detection，然後選擇 Lower than the band，並設定 SNS topic 為題目提供的 UnicornFarmSNS 即可。

Internet monitors 監控各國連線狀態

題目要求建立 Internet monitors 來監控各國連線狀態。

在 CloudWatch 中建立一個新的 Internet monitor，在 Resources to monitor 中選擇自己的 CloudFront distribution 並建立即可。

RUM 監控實際使用者行為

題目要求使用 RUM 來監控實際使用者行為，功能與 Google Analytics、Cloudflare Web Analytics 類似。

在 CloudWatch 中建立一個新的 RUM app monitor，指定 Application domain list 為自己的 CloudFront domain，題目暗示到”所有需要使用到的驗證都已幫你設定好”，所以在 Authorization 需要選擇環境中唯一的 Identity Pool，其餘參數保持預設即可。

建立完成後會提供一段 JavaScript 程式碼，正常步驟應該自己更新 S3 上的 HTML，但只要提交建立的 RUM name 題目會自己幫你更新，真是貼心。

從 JSON 匯入 Dashboard

題目提供了一個 JSON 檔案，要求從中匯入 Dashboard。

需要留意的是 JSON 檔裡面有很多 [placeholder-your-xxx] 的部分，需要根據前幾題的設定來替換成自己的值，若直接上傳會跳第 n 個 widget 找不到資源的錯誤。改好之後在 CloudWatch 中建立一個新的 Dashboard，然後選擇 Import dashboard，將 JSON 檔案上傳即可。

Dashboard 新增 RSS reader

題目要求在 Dashboard 中新增一個 RSS reader，顯示指定的 RSS feed。

在新增 widget 的 Other content types > Custom widget 中可以選擇內建的 RSS reader，會透過 CloudFormation 替你建立 Lambda。但由於往年題目都要求不能使用 CloudFormation，雖然今年沒說(?而且昨天有用到 SAM 但我猶豫了，所以這題沒有做。我相信應該是用這方法做沒錯?

WAF 封鎖 VPN 流量

題目要求透過 WAF 封鎖 VPN 流量。

在 WAF 中建立一個新的 Web ACL，然後新增一個規則，選擇 AWS Managed rule groups，其中有封鎖 VPN 的規則可以使用，勾選後套用到 CloudFront distribution 即可。

沒錢不敢在自已帳號開 WAF，有寫錯歡迎告知。

從 WAF logs 提取欄位

題目要求從 WAF logs 中提取每個請求的 host 與 uri，並另存為新的欄位。

在 Web ACL 內的 logging and metrics 中啟用 logging，將 log 儲存到指定的 log group。然後到 Log Insights 中，選擇剛剛的 log group，使用以下查詢語句來提取欄位：

sql
fields @timestamp, @message
| parse @message ""host": "*"" as host_url
| parse @message ""uri": "*"" as host_uri

即可在結果中看到 host_url 與 host_uri 兩個欄位，將 Query 儲存並提交即可。

Logs Insights 查詢並產生指定報表

題目要求使用 Logs Insights 查詢並產生各 API endpoint 的請求數量報表。

這步驟的前提是須要到 API Gateway 的 stage 中啟用 CloudWatch Logs，將請求日誌記錄到 CloudWatch Logs 中。

在 Log Insights 中選擇對應的 log group，使用以下查詢語句來統計各 endpoint 的請求數量：

sql
fields @timestamp, @message
| parse @message ""uri": "*"" as @path
| stats count() as @request_count by @path
| sort @request_count desc

這樣就可以得到各 API endpoint 的請求數量，一樣將 Query 儲存並提交即可。

科目心得

這次題目的難度沒記錯是從 300 ~ 400，看記分板發現有做到第二大題的人大概只有 5 位，可見大家都被 Canary 卡住。我到最後還有約 10% 的題目沒做完，東西真的太多了，只有不到三小時一個人怎麼做的完啊。但我又學到了很多東西，像是我更懂 metric 跟 Log Insights 語法了!

競賽結語

為期五天(扣掉開幕閉幕只有三天)的競賽，說長不長、說短不短，卻是一段充實無比的旅程。

兩年前我第一次參加技能競賽(53屆)，當時的我接觸雲端還不到一年，雖然還是雲端小白但靠著多年來的實作經驗以及對資訊科技的熱愛，第一次參賽就拿到中區第四與全國第三，頒獎時自己也是嚇了一跳，雖然晉級二階國手選拔，但能力還是敵不過其他選手，與法國里昂的國際賽無緣。

兩年後，這次的我(55屆)在比完賽後才發現自己又變強了，總共五個科目都拿到第一，雖說大概有 70% 我沒接觸過的服務，但我還是靠著對資訊領域的知識來推測邏輯並快速釐清方向，也在幾個科目中拿到首殺(第一個得分，但不會因此加分)。

這次的競賽看到有些人在質疑我的成績，畢竟五個科目都第一難免會被針對。但我想說的是，雲端運算不單只是比誰會用雲端平台，而是比誰能在有限的時間內快速理解題目、找到符合真實世界的解決方案並實作出來。

雲端競賽考的是企業會遇到的真實問題，而不是課本上的標準答案。在這科技日新月異、AI 技術週週更新的時代，只有不斷學習、快速適應新技術的人才能在競爭中存活，不被世界蛋雕。

這一路走來常常都是自己一個人在學習與摸索(母胎單身😭)。高中暑假的某一天，突然腦袋撞到、異想天開地用手機學寫 Python 聊天機器人(對，就是這麼白癡)，從此踏上了我不斷自學、撞牆、把牆撞破又遇到下一道牆的獨自升級之路。

感謝這幾天陪我討論跟吃晚餐的夥伴們，以及前幾個月一起參加訓練營的朋友們，讓我們一起加油，繼續在資訊科技的道路上前進。

早安，這是「第 55 屆全國技能競賽英雄榜暨第3屆亞洲技能競賽及第 48 屆國際技能競賽國手選拔賽青年組雲端運算職類」系列文章的第四篇，這次來分享科目四的題目和解題過程。

科目四: 大雜燴

共有六大題，內容非常的廣，從 ECS 到 IoT，資料分析到資料串流，應有盡有。題目大致如下:

• 給一 ECR，把它用 ECS 跑起來
• 把 AWS 的 IoT services 都用過一遍
• EMR studio 分析 S3 資料
• Kinesis Data Stream 串來串去
• CodePipeline 增加 CodeDeploy 部署
• SageMaker AI 模型訓練 (感謝 @garyellow 補充)

這場比完細節大概就快忘光了，歡迎其他選手留言補充，我會再補上 🙇。

ECR + ECS

這題給了一個放在 ECR 的 image，然後要把它用 ECS 跑起來。

花了點時間在看它跑在哪個 port 上，我是直接跑起來看 log 後才知道 port 是 8080，賽後交流才得知原始程式碼有放在 CodeCommit 上。

要做的事就只有建一個 ECS cluster，定義 task，然後跑起來即可。

IoT Services

這題用到了 IoT Core、IoT Greengrass、IoT Analytics、IoT SiteWise、IoT Events、IoT Device Management，對於沒用過的人(我)來說超級複雜，幸好之前碰過 Arduino 跟 ESP32，對於 IoT 的概念還算熟悉，難不倒我。

沒有很想開 IoT services 的服務來做實驗加上忘得差不多，這邊就不寫的太詳細了。

IoT Core MQTT client

這題很多步驟都圍繞著 IoT Core 的 MQTT client，必須使用它來收發訊息。

透過 AWS IoT Core 的 console 來開啟 MQTT client，然後訂閱一個 topic，接著就可以透過 publish 來發送訊息。

基本上都是題目叫你幹嘛就幹嘛。

IoT SiteWise 修正

這題提供的 SiteWise 有個設備的 data stream 的資料來源沒設定好，需要參考其他設備的設定來補上。

後續設定完成後要把四個設備的資料(溫度)在 dashboard 上放在同一圖表上做呈現。進編輯然後把四個設備的資料都拖進去即可。

IoT Greengrass deploy component

根據提供的 json 檔，建立一個 Greengrass component，然後 deploy 到 Greengrass core device。

首先先建立 component，設定完成後直接到 core devices 把它 deploy 上去即可。

IoT Device Management 更換憑證

這題要把 IoT Device 的憑證 deactivate，然後再 activate 一個新的憑證。

題目提供了一個 Certificate Signing Request(CSR)，在 IoT Device Management 內建立憑證的某處可以選擇透過 CSR 來建立憑證，建立完然後 activate 即可。

EMR Studio 分析 S3 資料

這題給了一個 S3 bucket，裡面有一堆我看不懂的資料，然後要用 EMR Studio 來分析。目標為找出資料內的 inner、mana 與 outer 的關聯性，看了半小時還是看不懂這三個東西是什麼鬼，幸好直接跑程式就可以拿到答案。

題目提供了一個 EMR studio 可以直接跑 spark job，也提供了對應的 Python 程式碼。透過 EMR studio 建立 spark job，指定參數為 --inner xxx --outer yyy，然後跑起來即可。

這題做太慢會被扣分，後續還會要求接 S3 event 來自動化，但不知道是我做太慢還是怎樣，有好多檔案跑完沒得到分數。

Kinesis Data Stream 串來串去

這題要求建立一個 Kinesis Data Stream，提供名稱後會開始打資料到這個 stream。

收到 stream 後會要求將它丟到 Apache Flink 做分析，notebook 也有提供，就丟上去直接跑即可。

後面好像還有 Data Firehose 做 transform，但內容忘了，只記得被 Gameday 上的獨角獸說我做太慢。

CodePipeline 增加 CodeDeploy 部署

這題要求在 CodePipeline 上增加一個 CodeDeploy 的部署步驟。

前天就碰過 CodePipeline 了，沒什麼難度，建一個 CodeDeploy 設定部署到 auto scaling group，然後到 CodePipeline 增加一個 stage，把 CodeDeploy 加進去即可。

SageMaker AI 模型訓練

這題我因為點開 JupyterLab 後沒看到 code 以為是 bug 就先跳去做其他題了，所以沒印象。

感謝 @garyellow 的補充，這邊引用他的流言:

1. 打開預先建立好的 JupyterLab (在 Amazon SageMaker AI 中)
2. 將專案從 Gitea clone 到 JupyterLab 中
3. 依說明修改專案中 jupyter notebook 檔案裡的 3 個地方
4. 改完執行全部程式碼，然後等模型練好
5. 把練好的模型部署到 Endpoint (用 Amazon SageMaker Studio)
6. 回答有幾顆星星 (應該是用部署的模型去得出，這邊我沒弄出來)

科目心得

這題的難度比前面幾題高很多，沒記錯難度都是 300，因為涉及的服務非常多，對於沒碰過相關服務與領域的人來說有點難度。

在碰 IoT services 的過程感覺 AWS 這方面其實做的蠻好的，只是我沒錢沒機會用到而已。

早安，這是「第 55 屆全國技能競賽英雄榜暨第3屆亞洲技能競賽及第 48 屆國際技能競賽國手選拔賽青年組雲端運算職類」系列文章的第三篇，這次來分享科目三的題目和解題過程。

科目三: Unicorn Farm

共有兩大題，考驗的是懂 serverless 與 no-code 的概念與實作能力，題目如下:

• 無程式碼搬遷
  • 給一既有 Lambda + DynamoDB 架構，透過 Step Functions 來取代 Lambda
• Serverless Application Model 部屬
  • 給一 Python 程式碼，透過 Serverless Application Model(SAM) 來部署

無程式碼搬遷

這題給了兩個 Lambda 與兩個 DynamoDB table，要求透過 Step Functions 來取代 Lambda 的功能。

看懂既有架構

先看下方負責 feed unicorns 的 Lambda 程式碼，我們可以得知它會吃到一個 event，裡面包含了多個 unicorn 的 ID 以及 feed_amount，然後去 DynamoDB 更新每個 unicorn 對應的數值與 last_feed。

json
{
  "Unicorns": [
    {
      "id": "unicorn-1",
      "amount": 10
    },
    {
      "id": "unicorn-2",
      "amount": 20
    }
  ],
  "TotalFeedAmount": 30,
  "TableName": "unicorn_status",
  "FeedTableName": "feed_amount"
}

上方的 Lambda 只會檢查 feed amount 是否小於 50，若是的話則補到 300。

設計 Step Functions

對於第一次接觸 Step Functions 的我來說，第一眼看到時一臉懵逼，我要怎麼把 event 讀出來? Array 要怎麼分別處理?

幸好雲端運算職類可以看官方文檔，需要用到 Parallel 與 Map 兩個狀態，邏輯如下圖所示:

Step Functions Code: step-func-1.json

對於 Map state，我們需要設定 Provide items 為 {% $states.input.Unicorns %}，這樣才會將每個元素傳入其中。

兩個更新 DynamoDB 的 PutItem 則需修改 Arguments，需要留意 DynamoDB 對於 Number 欄位的 API 呼叫需要傳遞字串，而不是數字。

json
{
  "TableName": "unicorn_status",
  "Key": {
    "id": {
      "S": "{% $states.input.id %}"
    }
  },
  "UpdateExpression": "SET hunger = hunger + :feedRef",
  "ExpressionAttributeValues": {
    ":feedRef": {
      "N": "{% $string($states.input.amount) %}"
    }
  }
}

對於上方的 Lambda，我們則須先從 DynamoDB 讀取剩餘的 feed_amount，檢查是否足夠，然後再更新。

Step Functions Code: step-func-2.json

要留意的是 GetItem 後需要將結果存在 Output，每個 state 的 $states.input 都是根據上一個 state 的輸出而來的。此處的 $states.result等同於 DynamoDB API response 的格式。

json
{
  "dbAmount": "{% $number($states.result.Item.feed_amount.N) %}"
}

接下來透過 Choice state 與判斷式 {% $states.input.dbAmount < 50 %} 來決定是否執行後方 UpdateItem 來更新 feed_amount。

最後，透過 EventBridge 建立一個 cron job 來定時觸發 Step Functions，這樣這題就完成了。

Serverless Application Model 部屬

這題提供了一個 Cloud9 雲端 IDE 環境，以及一個 Python 程式碼，要求透過 Serverless Application Model(SAM) 來部署。

題目共有多個階段，第一步先叫你設計一個能跑的 template 出來，再來要求把 Lambda 拔掉但要維持功能…

看懂要求

文檔中隱喻提到會用到 API Gateway、Lambda 與 DynamoDB，這些都是 Serverless 架構中常見的組件，也是 SAM 這骨董唯數不多支援的服務。

看的出來這題設計時還沒有 Lambda Function URL，所以才會需要 API Gateway。

設計 SAM template

SAM template 需要包含以下幾個部分:

• AWS::Serverless::Api => API Gateway (RESTful)
• AWS::Serverless::Function => Lambda Function
• AWS::Serverless::SimpleTable => DynamoDB Table

基本這題上要做的事只有寫 yaml 檔，然後透過 sam deploy 部署上去。

考 Cloud Formation 我還願意學，考這 SAM 搞得我有點沒心態，下方範例就靠 Copilot 幫我想了 ❤️

yaml
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  UnicornApi: # API Gateway
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
  UnicornFunction: # Lambda Function
    Type: AWS::Serverless::Function
    Properties:
      Handler: lambda_function.lambda_handler
      Runtime: python3.11
      CodeUri: unicorn_function/
      Events:
        Request: # API Gateway Event
          Type: Api
          Properties:
            Path: /
            Method: POST
            RestApiId: !Ref UnicornApi
  UnicornTable: # DynamoDB Table
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: id
        Type: String

能跑的 template 大概就是這樣，接著把 Python 程式碼放到 unicorn_function/ 資料夾下，然後透過 sam deploy 就搞定了。

第二步要求把 Lambda Function 拔掉但又要維持功能，原本以為也是用 Step Functions 來取代，但搞好之後一直不給我分數 😡😡😡。

花錢買 hint 才知道要到 API Gateway 設定 Integration type 為 AWS service ，並透過 Integration Request 與 Integration Response 去修改請求與回應…這是省 Lambda 費用的方法沒錯，但沒必要這麼噁心吧。

圖很醜懶得畫好看，我盡力了。總之就是 request body 會被轉換成 DynamoDB UpdateItem 的格式，呼叫到 service 後再把 API response 轉換成正常的格式。

看了半小時搞懂了原理但想不到 yaml 怎麼寫，文檔翻了三遍還是找不到哪裡可以設 integration type，最後有想到應該是要直接導入 OpenAPI schema 但剩下時間不多就放棄了。

科目心得

之前就有想學 Step Functions 的念頭，但一直沒有機會深入了解。謝謝這次題目(除了第二題最後一步，我不喜歡你)讓我有機會被迫學習。這應該也是近幾年雲端運算職類第一次碰到 Infrastructure as Code 的題目，做起來其實還蠻有趣的，希望未來的我可以順便去學一下 Terraform。

早安，這是「第 55 屆全國技能競賽英雄榜暨第3屆亞洲技能競賽及第 48 屆國際技能競賽國手選拔賽青年組雲端運算職類」系列文章的第二篇，這次來分享科目二的題目和解題過程。

科目二: Secure Legends

AWS experience: AWS GameDay - Secure legends

共有四大題，考驗的是有沒有看懂既有架構與資源，並且能夠在不影響服務的情況下，修正架構中的安全性問題。

Gameday題目的命名都很ㄎㄧㄤ，後續命名都以我自己記得的名稱為主:

• CodePipeline 修正
• Auto Scaling Instance 隔離與替換版本
• Macie PII detection
• 超 級 資 安 大 雜 燴

CodePipeline 修正

這題給了一個 CodePipeline，結構如下:

中間 Build stage 中的三個 CodeBuild 都是爛的，這題目標就是把它修好。

在 config.zip 裡面有三個 CodeBuild 的 buildspec.yml 檔案，要做的事基本上只有看 error message 然後改它而已。

Code Lint

這步有點忘記，反正就是看 build log 然後看文件提供的 Github 把指令加上一個參數就好。

Git-secrets check

這步會用 git-secrets 檢查 Git commit 中是否有敏感資訊，題目中某個地方有一組 ID 會被當作敏感資訊檢查到，所以要把它加到白名單。

Grype CVE check

這步會用 Grype 檢查程式碼與 dependecies 是否有 CVE 漏洞，題目中的 flask 會因為版本過舊而報錯，需要把 requirements.txt 中的 flask 版本升級。

都改好之後重新打包 config.zip 並上傳到 S3，然後待 CodePipeline 順利執行完畢即可。

Auto Scaling Instance 隔離與替換版本

這題會給你一個 Auto Scaling Group，裡面有兩台被駭的 EC2 instance，目標是把這兩台 instance 隔離、修補漏洞並替換成新的。

找出為什麼被駭

該題沒有給程式碼，連進網頁後會看到亂碼(被駭入加密)，只能直接 SSH 進機器去看 log。

透過 user data 我們可以得知網站程式碼來自 S3，拉取後放在 /website/，裡面有個 flask server 跟他的 log 檔。在程式碼中我們可以看到有一個 endpoint /backdoor，可以透過它來執行任意指令，在 log 檔中也看到駭客透過 openssl 執行了 aes-256-cbc 加密指令。

修補漏洞

User data 中是從 S3 拉取程式碼，該 S3 bucket 我們沒權限動，因此只能複製一份到自己的 bucket 中並修改。

修補 /backdoor 有三種作法:

• 程式碼中直接刪除 /backdoor endpoint (我的作法)
• 用 WAF 規則封鎖 /backdoor
• ALB 的 listener 規則封鎖 /backdoor (其他選手告知的騷操作)

隔離

一開始看到題目說 “isolate” 以為是把它 public IP 拔掉讓它不能被存取或是建 AMI 然後 stop instance，結果買 hint 後才知道是建一個空的 Security Group 並把它套用到這兩台 instance 上…

因為兩台機器在 Auto Scaling Group 裡面，套空的 Security Group 會導致 Health Check 失敗而被自動替換，所以需要先把它移出 Target Group。

替換

隔離後就可以直接在 Auto Scaling Group 中指定新的 Launch Template 讓它自動開新 instance 即可。

Macie PII detection

這題給一個 S3 bucket，你看不到內容，需要透過 Macie 來掃描是否有 PII 資訊。

在 Macie 中建立一個新的 PII 掃描任務，指定剛剛的 S3 bucket，並選擇掃描除了 Financial information 以外的 PII 資訊(題目要求)。

掃描完成後會有一個報告，裡面會列出所有 PII 資訊的檔案與位置。

還有一題是必須自訂 data identifier 來偵測某個特定的 ID 格式，regex 如下:

[pk]_\d{3}[A-Z]{3}e\d{8}

也是一樣建完 data identifier 後再建立一個新的 PII 掃描任務即可。

超 級 資 安 大 雜 燴

這題超雜，會用到 CloudTrail、AWS Config 跟 Lambda。

是誰改了 S3 設定

這題要求你找出哪個 IP 改了 S3 bucket 的 encryption 設定。在 CloudTrail 中搜尋對應的 S3 bucket 事件，並查看 source IP 即可。

是誰改了 EC2 名稱

這題要求你找出誰用 access key 改了某個 EC2 instance 的名稱，並把它的 access key deactivate。解法同上，搜尋 CloudTrail 中對應的 EC2 instance 事件，找出是誰改的並去 IAM 把他的 access key deactivate。

Continuously key & password rotation

這題要求持續輪替 IAM 使用者的 access key 與 password，並停用 unused password，間隔時間為 90 天。

在 AWS Config 中建立一個新的 rule，選擇兩個 managed rule 並設定 90 天即可。

改 lambda 網頁密碼

這題給了一個 lambda function URL，要求你改網頁中的管理員密碼。在 Lambda function 的程式碼中找到明文的密碼變數，把它改成其他的即可。

科目心得

好懶得寫，總之就是題目說啥就幹啥，沒有什麼特別的。

沒記錯的話最後領先快一大題的分數守住了第一名🥵。

早安，我是今年參與「第 55 屆全國技能競賽英雄榜暨第3屆亞洲技能競賽及第 48 屆國際技能競賽國手選拔賽青年組雲端運算職類」並入圍二階國手選拔的選手，寫這篇文章是為了分享我在比賽過程中的一些心得和經驗。

在開始分享之前，先客套的感謝一下主辦單位、裁判及工作人員們的辛勤付出，讓這次比賽能夠順利進行。雖然比賽過程中浪費了點時間在處理設備問題，但整體還是很順利的。

簡單介紹一下我自己：

• 逢甲大學資訊工程學系畢業
• 國立中央大學資訊工程學系碩士
• 第 53 屆全國技能競賽雲端運算職類 第三名、入圍二階國手選拔¹
• 第 54 屆中區技能競賽網頁技術職類 第二名、全國賽請假跑去學海築夢爽²
• 第 55 屆全國技能競賽雲端運算職類 一階國手選拔第一名、入圍二階國手選拔³
• 自籌 2025 中區雲端運算訓練營 講師兼出題仔

第一次接觸到雲端運算職類是在第 53 屆，當時的我接觸雲端還不到一年，但不知不覺就拿到了個全國賽第三名還進入二階國手選拔，可惜當時的我實戰經驗不夠，與法國里昂的國際賽無緣。今年的比賽帶著更充足的準備和實戰經驗，在全國賽的五個科目中全部拿下第一，希望 9 月的二階國手選拔也能如此順利。

比賽流程

扣掉第一天報到跟最後一天的頒獎，比賽共有五個科目，各科目約為 3 小時且內容獨立。

比賽內容不公開，但這次題目都是用 AWS Workshop，賽後 Google 一下關鍵字能找到蠻多有的沒的資源。這篇文會分享一下科目一的題目和我的解題過程。因為科目內的題目內容高度糾纏，比完賽出來就快記不起來了，有錯誤歡迎指正。

競賽過程中會有 Scoreboard 顯示目前的分數和排名，分數則是根據解題進度來計算，但有些靠北的題目送錯答案或是做太慢會被扣分，這點要特別注意不要一口氣把題目全開。

參考資料： 【全國賽】114年第55屆全國技能競賽-賽前公告試題資料

科目一: Unicorn.Rentals

這題目考驗的是怎麼動態調整 Compute 資源，能應付忽大忽小的 HTTP 流量，同時保持可用性、回應時間與成本最佳化。

題目只有一個送出欄位讓你提交 endpoint URL，後臺會自動發請求到你的 endpoint，並根據每個 request 的回應時間來計算分數。同時每分鐘會根據使用的資源來做扣分，只要流量得分小於成本扣分，分數就會被扣爛。

該題目提供了一個既有的 AWS 環境，內容大致如下:

• 1x VPC
  • 有點忘記 resource map 長怎樣，但記得沒有 S3-gateway
• 1x 有 Elastic IP 的 EC2 instance
  • 完全獨立，endpoint 預設指在這台
• 1x Application Load Balancer (ALB)
  • 1x target group
  • 2x EC2 instances，都有 public IP

EC2 裡面跑的是 Python HTTP server，題目文件中也有提供 user data 來協助設定環境，大概長這樣:

bash
#!/bin/bash
wget https://s3.amazonaws.com/xxx/web-binary.py -O /website/web-binary.py
chmod +700 /website/web-binary.py
python3 /website/web-binary.py
shutdown -h now

沒記錯的話整場的流量大概長這樣:

CloudFront 快取

這題的重點在於使用 CloudFront 快取來降低計算資源的使用率，同時降低回應時間。

在題目文件中我們可以看到請求會長的像這樣：

GET /calc?input=xxxxx

我們可以推測一個 input 只會對應到一個結果，所以可以利用 CloudFront 的 Cache policy 來做快取。

透過在 CloudFront 建立一個 Cache policy，設定 Default TTL 不要太低(預設一天即可)、指定 Cache key settings 中的 Query strings 為 All，並於對應的 behavior 中使用該 policy 即可。

比賽結束前幾分鐘看到 CloudFront 的 Hit Rate 大概為 10.5%，對於回應時間和成本的優化都有很大的幫助。

Auto Scaling

題目提到流量會隨時間變化，開一台大機器接請求肯定是不划算的，因此需要使用 Auto Scaling 來動態調整 EC2 instance 的數量，應對變化的流量需求。當然這題也可以用 ECS 或 EKS 來做，但礙於時間有限加上懶得寫 Dockerfile，所以就直接用 EC2 來做了。

在做 auto scaling 之前，我們可以看到 user data 裡面只有對外抓取 S3 上的程式碼，所以我們可以不給他 public IP 跟 NAT gateway，直接透過 VPC endpoints 來存取 S3 gateway，省下 IP 跟 NAT 的費用。

新建一個 VPC，資源如下:

接下來建立一個 Launch Template，指定 AMI、user data、disable public IP 等。從 S3 抓程式碼是用 wget，可以得知不需要 IAM role。

接著建立一個 Auto Scaling Group，指定 VPC 為剛剛建立的 VPC，subnets 選擇建立的兩個 private subnets，並指定 Launch Template。最省錢的作法會是用 t3.nano 的 spot instance，但我忘記而是用 t2.nano on-demand，賽後跟其他選手討論後才得知每台可以少被扣 4 分。

最後建立一個 Application Load Balancer，並將 ALB 的 subnets 改為 public subnets (預設會自動選跟 EC2 的一樣，但 ALB 需要 internet gateway，只有 public subnets 才有)、target group 指向 Auto Scaling Group，這樣就完成了。

對於 Auto Scaling Policy 的設定，單看 EC2 的 CPU 使用率並沒有太大變化，因此我使用 Request Count per Target 來做 scaling policy，設定為每分鐘約 15 個請求。

除此之外還有幾點可以優化的地方:

• Target group 的 algorithm 可以改成 least outstanding requests，讓流量優先分配到請求較少的 instance 上。
• 降低 Auto Scaling 設定的 health check grace period，讓 instance 在啟動後就能更快開始接收請求。
• 降低 Load Balancer 的 connection draining 時間，更快釋放要縮減的 instance。

建完後記得回到 CloudFront 建立新的 origin，並把對應的 behavior 指向新的 origin。

更新版本

題目在後期會有一個叫你更新 server-binary.py 版本的步驟，因為我們已經建好 launch template 了，直接建立新版本並在 Auto Scaling Group 中做 instance refresh 即可(慢到靠北，追求速度的話直接 terminate 再開其實也行)。

猴子

在競賽過程中會遇到「猴子」來亂條你的設定，這時候就需要透過監控來快速反應，把它亂改的設定改回來。賽後跟其他選手討論總結出來被改到的地方只有 Auto scaling group 的 desired capacity，透過監控 scaling activity 便可快速發現並修正。但我還是花了點時間搞了 CloudWatch Dashboard 來監控整體流量、回應時間以及 CloudFront 狀態(不知道為什麼有時候會突然跑出幾個 504)。

科目心得

第一步先看懂文件並清點預設環境內有哪些資源跟它的邏輯蠻重要的，像我一開始就發現它建好了個可以用的 ALB，連上去測也是正常的，套完 CloudFront 就直接上線開始賺分，整場沒被扣分過。

雖然更新版本的過程中被其他選手分數反超，但我把 auto scaling 的 scale-in/out 設定得很極致，最後半小時流量上上下下依舊穩定輸出，直接把分數拉回來，最後領先 2000 分守住了第一名。

這幾天會再寫其他科目的心得，一個科目一篇，慢慢寫到 Part 5。有興趣的話可以關注一下或是請我喝杯咖啡或吃一頓好料 🥰。

前言

要架一個 mail server 並不容易，除了要隨時跑著一台伺服器外，家用或 VPS 的 IP 也不夠純淨，通常會被 Google 跟 Microsoft 當成垃圾信。

此文會介紹怎麼使用 Cloudflare 來收信並轉寄到 Gmail，並從 Gmail 透過 SendGrid 來寄信，而且可以用無限多個 email address。

Cloudflare 收信

Cloudflare 免費方案提供了無限用量的 Email Routing 服務，可以將收到的 email 轉寄到指定的信箱，而且支援 Catch-all。

在 Dashboard 啟用 Email Routing 後，Cloudflare 會自動替你設定三個 MX record 跟一個 SPF record，可以在 Settings Tab 看到。為了後續 SendGrid 的設定，我們必須先將它 Unlock，不然 Cloudflare 不會讓我們動這四個 record。

開啟 Email Routing 後，先在 Destination addresses 新增自己的 Gmail 並驗證，接下來就可以去 Routing Rules 新增路由規則。

要接收所有 email 可以直接使用 Catch-all，也可以針對不同的 email address 設定不同的轉寄規則。

SendGrid 寄信

SendGrid 是一個可以用 API、SMTP Relay 來寄信的服務，免費方案每天可以寄 100 封，驗證 domain 後可以使用任意 email address 來寄信。

要註冊 SendGrid 帳號需要一點技巧，如果從官網註冊的話有 99% 會被擋掉(至少我不是那 1%，送了三次都被擋==)，個人用戶開 ticket 也只會等三天然後被拒絕，這時我們可以用 Google Cloud Platform 裡面的 Marketplace 來訂閱 SendGrid Free Plan，理論上只要開一張 ticket 證明一下你是誰就可以了，內容大致如下：

To have your account reviewed, please reply back to this email with the following:
1. User Identification
Your first and last name to help us confirm your identity.
Any of your personal social media profiles such as LinkedIn, Facebook, Twitter, or your online portfolio such as GitHub or Upwork, showing your full name.
An email address which matches your website domain or a screenshot of a receipt that verifies domain ownership.
2. Intended Use Case
A complete description of the services/products your organization provides to better understand the nature of your business.
3. Email Type
Will you be sending Transactional or Marketing emails?
How will your recipient's email addresses be collected (opt-in)? Please provide a link to an accessible website for your organization or a screenshot of the registration flow. If the website is not publicly available yet, a mock-up of the sign-up page will suffice.

成功註冊後，先在 Settings > Sender Authentication 驗證自己的 domain，依照指示設定三個 CNAME record (emXXX.、s1._domainkey、s1._domainkey) 跟一個 TXT record (_dmarc)。

設定完成後建議 Single Sender Verification 也一同設定，我不太確定會不會影響被當垃圾信的機率。

設定完後就可以在 Settings > API Keys 新增一個 API Key，權限可以只給 Mail Send。

Gmail 設定

拿到 SendGrid 的 API Key 後，就可以在 Gmail 設定 SMTP Relay 了，這樣就可以用 SendGrid 來寄信了。

點開右上角齒輪 > 查看所有設定 > 帳戶和匯入 > 選擇寄件地址 > 添加另一個電子郵件地址，名稱任取，電子郵件地址為你的 domain，照下列設定 SMTP 伺服器並儲存：

• SMTP 伺服器：smtp.sendgrid.net
• 連接埠：587
• 使用者名稱：apikey
• 密碼：你的 SendGrid API Key
• 採用 TLS 的加密連線 (建議使用)

接下來在寄信時就可以選這個 email address 來寄信了 🎉

SPF、DKIM、DMARC

為了避免被當成垃圾信，我們還需要確認 SPF、DKIM 跟 DMARC 有正確設定。

SPF

Sender Policy Framework 用來確認寄件者是否有權利使用這個 domain 來寄信。在這案例中會有兩個寄件者，分別是用來寄信的 SendGrid，還有 Cloudflare 轉寄給你。DNS record 會長這樣：

其中 include 代表允許這些 domain 下的 IP 來寄信，~all 代表把不符合規則的信標記為垃圾信。

DKIM

DomainKeys Identified Mail 用來簽署寄出的 email。在 SendGrid 設定時便已設定好兩個 domain key，DNS record 長這樣：

DMARC

Domain-based Message Authentication Reporting and Conformance 用來告訴收信者這個 domain 的寄信規則。

Cloudflare 提供了 DMARC Management，啟用後會設定一個 TXT record，DNS record 長這樣：

其中 p 代表不符合規則的信要怎麼處理，none 代表不處理，quarantine 代表標記為垃圾信，reject 會直接拒收。 rua 代表收件者該把狀況通報給誰，這裡是通報給 Cloudflare 自動分配的 email，不用動它。

結語

筆者用這個方法大概一年多了，收信、寄信都沒問題，但就是有時會被 Gmail 當成垃圾信，通常是因為 domain 的信譽不夠好，可以透過 Gmail Postmaster Tools 來看收信狀況還有被當垃圾信的原因。

另外 SendGrid 還有提供自訂 domain 的連結追蹤(Link Branding)、開信追蹤(Pixel tracking，domain 信譽不好會被當垃圾圖片QQ)等功能，可以摸索看看。

去年比雲端運算職類拿到全國第三後被 BAN 掉，不能再比相同職類，剛好這次年紀壓線可以報名網頁技術，自己也寫網頁一段時間了，就報名來玩看看，也有幸拿到了中區第二，可以再去全國賽玩ㄌ。

這篇文章主要是記錄一下競賽中遇到的問題及心得。

參考資料： 【分區賽】113年第54屆分區技能競賽-賽前公告試題資料

競賽環境

如競賽公告的”場地設備準備表”所述，競賽環境提供了下列幾項軟體，粗體是我有用到的：

• Windows 10

• Chrome、Firefox Developer Edition、內建的 Edge

  • 挑習慣的用就好，反正也只會開網頁 + DevTools
  • 其實我都用 Chrome，但它預設瀏覽器是 Edge 我懶得改

• XAMPP 8.2.0

  • 監評要求檔案放置於桌面 webXX 資料夾，可以改 httpd.conf 的 DocumentRoot 直接把它指過去

• jQuery、jQuery UI

  • jQuery UI 只用到了 button 跟 dialog

• 三大框架(Angular、React、Vue)

  • 分區賽的題目用 Vanilla JS 就夠了

• Prototype

  • 這是不是很久以前的東西了

• Adobe 全家統(Dreamweaver、Photoshop、Illustrator)、CorelDRAW

  • 我都不會用

• Visual Studio Code、Sublime Text、PHPStorm

  • VS Code 沒裝套件，只有 HTML、CSS、JS 的語法提示
  • PHPStorm 內建 PHP 文檔可以看，還可以開 live reload，大推 👍👍👍
  • 環境提供 PHPStorm 2021.3 及 2023.3，但後者因為沒網路起用不了，只能用 2021.3

• Notepad++、PS Pad、EditPlus、UltraEdit

  • 這幾個都用不到

競賽過程

Day 1

中午 12:30 開放報到，人都到齊後帶隊去競賽場地，抽崗位編號然後入座，給大家 15 分鐘測試環境(測硬體、安裝軟體)，電腦不會還原，隔天競賽時直接繼續用。

Day 2

早上 8:00 前報到，講解題目及注意事項大概 30 分鐘，然後就開始 4 小時的競賽。

題目會事先公告在競賽公告上的”競賽試題及說明”，當天會有紙本試題，題目會稍微修改，增加一些有的沒的 feature。

競賽結束後會叫大家把檔案複製到 USB，並把網頁打開，然後就可以離場用餐了，監評會趁這段時間先評主觀分數。

大概 13:30 開始照崗位編號叫進去 demo 評客觀分數，每個人大概 10 分鐘，評完就可以閃人了。

題目解析

這次題目是”快樂旅遊網”，主要有訪客留言、網頁管理、訪客訂餐、訪客訂房這四個功能。

訪客留言

如題目所敘，輸入資料並送出後會顯示在留言列表，可以輸入留言序號(把它當作密碼)來編輯或刪除留言。

輸入欄位有要求像要驗證格式，可以直接用 input type 或 pattern 來做。

html
<!-- Email 只少要有一個 `@` 跟 `.` -->
<input type="email" />
<!-- 電話號碼只能輸入數字及 `-` -->
<input pattern="[0-9-]+" />
<!-- 留言序號只能 3 位數小寫英文及數字 -->
<input pattern="[a-z0-9]{3}" />

輸入的資料用 mysqli 丟進資料庫，我把編輯跟刪除都寫在同一個頁面，透過網址參數 ?action=edit 來判斷要幹嘛，還有 session 來判斷是不是管理員，藉此少寫幾個頁面。

網頁管理

要先做一個登入頁面，登入後可以編輯、刪除留言，還有更改訂房資料。

登入頁面要做一個圖片驗證碼，還要可以重新產生。

我原本想說用小畫家畫個 5 張圖片然後隨機輪替，但好懶得 P 圖，最後選擇直接放一個 <p>1234</p> 然後設定 user-select: none 還有把它搞得很難看到，這樣監評也給過 XD。

現場題目還多了一個第二階段驗證碼，要產隨機的 9 宮格數字，並用拖曳的方式把它照順序排好，但這題才占 1 分，寫起來不划算果斷跳過。

登入驗證反正題目要求就那樣，直接寫死就好 🥰，然後用 $_SESSION 存一個 boolean 來判斷是否登入。

php
<?php
session_start();
if ($_POST['username'] === 'admin' && $_POST['password'] === '1234') {
  $_SESSION['login'] = true;
  header('Location: index.php');
  exit;
}
?>

編輯留言我直接使用上一段所寫的功能，加了些權限判斷讓管理員登入後可以編輯、回應還有刪除。

訂房管理… 沒時間做 PASS。

訪客訂餐

沒有任何”訂餐”的要素

給 16 張熱炒圖片，設計 RWD 頁面，題目要求寬版(>= 1024px)時一列 4 張，中版(>= 800px)時一列 2 張，窄版(< 800px)時一列 1 張。

這部分直接使用 grid layout 搭配 media query 來做即可。

css
@media (min-width: 1024px) {
  .img-container {
    grid-template-columns: repeat(4, 1fr);
  }
}
/* ...etc */
.img-container {
  display: grid;
  grid-template-columns: repeat(1, 1fr);
}

點擊圖片後開啟一個 dialog，有 < O > 三個按鈕，分別是減少透明度、重設透明度、增加透明度。

這部分直接使用 jQuery UI 的 dialog，透明度丟到全域變數，然後按鈕點擊時改變變數即可。

js
window.OPACITY = 1;
const updateOpacity = val => {
  const img = document.querySelector("#dialog img");
  window.OPACITY = val;
  img.style.opacity = window.OPACITY;
};
$("#dialog").dialog({
  buttons: [
    {
      text: "<",
      click: () => updateOpacity(window.OPACITY - 0.1),
    },
    {
      text: "O",
      click: () => updateOpacity(1),
    },
    {
      text: ">",
      click: () => updateOpacity(window.OPACITY + 0.1),
    },
  ],
});

訪客訂房

寫到這邊剩下 5 分鐘，乖乖吃零食等結束。

原本還以為只有我寫不完，但看來這很正常 XD。

結語

報名時還在想我都沒寫過半行 PHP 會不會爛掉，幸好競賽前一天的臨時抱佛腳有派上用場，加上分區賽題目根本就是在考驗手刻 CSS，除了寫不完之外都很順利。

希望 7 月的全國賽競賽順利，趁這段時間給自己一點動力去碰 PHP。

前言

反向代理是網頁開發環境上常見到的工具，在開發過程如果需要讓其他人存取區網內的伺服器，除了進一層又一層的 router 開防火牆權限讓外面連進來之外，最簡單的方法就是直接從 local 端建立一條連線到外部，讓其他人可以透過這條連線存取 local 端的資源。

常見的應用場合像是 Line Bot 或第三方金流 API，我們需要接收它們所發送的 Webhook，而且必須是 https。

還有可以用來繞過 Secure Context，在做網頁開發時通常為了方便都會直接走 http protocol，在 http://localhost 存取不會有問題，但當要用區網內其它裝置連去測試時，就容易被 Secure Context 搞到，拿個 MediaDevices 都不行 😥。

使用反向代理還有一個好處，就是可以避免伺服器的 IP 洩漏，對方只會看到代理伺服器的 IP，且大多數反向代理都至少會幫你做一點點 🤏 的防護，比較不容易被打爛。

Cloudflare Tunnel

Cloudflare Tunnel 是 Cloudflare 提供的一個免費服務，可以讓你在 local 端建立一條連線到 Cloudflare 的伺服器，讓外部的人可以透過 Cloudflare 的伺服器存取 local 端的資源。

(圖片來源: Cloudflare Blog)

與 Ngrok 相比，Cloudflare 擁有自己的全球骨幹，連線品質相對穩定，而且免費方案的功能很完整，但需要擁有自己的 domain 才能把它用到極致。

實際使用

要用這酷酷的東西，首先要去 Cloudflare GitHub 下載 cloudflared，之後直接對它下指令就可以了。

在沒有登入的情況下，Cloudflare 會給你一個隨機的 <some-random-words>.trycloudflare.com 網域，以下以建立一個反向代理到 http://localhost:3000 為例:

bash
$ cloudflared tunnel --url http://localhost:3000
2024-03-01T00:00:00Z INF Thank you for trying Cloudflare Tunnel. Doing so, without a Cloudflare account, is a quick way to experiment and try it out. However, be aware that these account-less Tunnels have no uptime guarantee. If you intend to use Tunnels in production you should use a pre-created named tunnel by following: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps
2024-03-01T00:00:00Z INF Requesting new quick Tunnel on trycloudflare.com...
2024-03-01T00:00:00Z INF +--------------------------------------------------------------------------------------------+
2024-03-01T00:00:00Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2024-03-01T00:00:00Z INF |  https://pad-supplier-bailey-representative.trycloudflare.com                              |
2024-03-01T00:00:00Z INF +--------------------------------------------------------------------------------------------+
...

大概2秒後就會看到 Your quick Tunnel has been created! ，然後就可以用下方的網址去存取你的網站了，非常快速。

自訂網域

以下步驟需要: 自己的網域、Cloudflare 帳號及大人的卡片(免費方案需填寫付款方式)

如果你有自己的網域，且 Name Server 為 Cloudflare，那就可以搭配 Cloudflare 的 Zero Trust 服務，將你的主機加入到 Zero Trust Network 中，這樣就可在控制台直接管理 Tunnel 及設定路由。

首先，登入 Cloudflare Dashboard 並點選 Zero Trust，照畫面指示開通免費方案。

建立 Tunnel

點選 Networks => Tunnels => Create a tunnel 來建立新 Tunnel。

Connector 選擇 Cloudflared，輸入 Tunnel name，最後複製下方 cloudflared 的指令，並用系統管理員執行。執行後會在主機上建立一個常駐 service，負責與 cloudflare 連線。

成功後會在 Connectors 看到你的主機，之後便可以直接透過網頁來管理這台主機上的路由。

每個 Tunnel 都可以同時設定多個路由，也就是多個 domain 可以指到 local 端不同的 port。舉例來說：

alpha.example.com => http://localhost:3000
beta.example.com  => https://192.168.1.1:443
ssh.example.com   => ssh://localhost:22

除了常見的 http、https 協定外，ssh、rdp、tcp 等都是可以使用，但需要在存取端安裝 cloudflared，詳細可參考 Cloudflare Docs。若連線到的是 ssh 或 vnc，下方存取控管章節有提到瀏覽器直接渲染的功能。

首先選擇要設定的 Tunnel，進入 Public Hostname => Add a public hostname 來設定 domain 及路由。

Additional application settings 內還有許多細節可以做設定，儲存後即可開啟網站測試連線。要設定多個 domain 就重複上述步驟繼續新增 Public hostname。

存取控管

Cloudflare Access 可用於管理網頁存取權限，透過指定使用者的 email address，並藉由 Google、Github 等常見的 OAuth 管道，或是內建的 One-Time Pin 來進行驗證。

設定 Login methods

首先選擇 Settings => Authentication => Login methods => Add new ，點選要使用的驗證方式，並照各平台的指示設定。

建立 Application

設定完成後，我們需要將要做存取控管的 domain 加入到 Access 中，選擇 Access => Applications => Add application ，我們的 Tunnel 屬於 Self-hosted application ，選擇這個選項後填入 Application name(會顯示於登入頁面上) 及 domain，其他設定保持預設即可，並進入下一步。

接下來我們需要設定 Access Policy，預設是 Allow(白名單) 模式，只有符合 Policy 的人可以存取，以下舉例只允許 user1@example.com 及 user2@example.com 存取，且存取國家必須是 Taiwan。

除了上述所用的條件外，還可以透過 IP range、是否於 Github Organization 中，甚至呼叫外部 API(External Evaluation) 來進行驗證，詳細可參考 Cloudflare Docs。

BTW，若要一次設定多個 email address，可在 My Team => Lists 建立 User Emails List，之後在 Policy 中選擇這個 List 即可。

設定完後，下一步還有 CORS、Cookie 的詳細設定，這邊就不贅述，但 Additional settings 中有一個很強大的功能叫 Browser rendering，若這個 tunnel 的目標服務是 ssh 或是 vnc，開啟此功能後就可以直接在瀏覽器渲染 SSH Terminal 或是 VNC 畫面。

結語

在 Cloudflare Tunnel 推出前，原本自已的伺服器是走種花固定 IP 出去，並掛一層 Cloudflare proxy 來架 web server，但這樣畢竟還是有個公開 IP 在網路上晃，難免還是會被機器人掃到，很怕哪天被打爛。現在直接在機器上跑一個 cloudflared，全部連線都走 tunnel 出去，連固定 IP 都不需要，超級快樂。

Cloudflare Tunnel 跟 Access 只是其中的一部分，還有許多騷操作可以玩，像是拿它來擋廣告、在多裝置建立虛擬私有網路等，後續會在寫幾篇文章來分享。

轉眼間就快大四畢業了，感覺是時候開始寫點 blog 紀錄一下自己這幾年到底在幹嘛，還有練習一下寫作能力。

希望我能夠一個月至少寫一篇 🥲

To be continued…