Hi I’m Shiun

EventBridge 簡介 EventBridge Scheduler 是 AWS 在 2022/11 推出的新服務，相較於傳統事件驅動的 EventBridge，新推出的 Scheduler 是時間驅動的一個服務，你可以很輕易的在上面設置一些排程任務去調用 AWS 的其他服務，截至 2024/04/06，官方文件是顯示可以調用 AWS 超過 270 種服務，就我目前使用下來的心得，真的是相當易用！ 常見的使用場景: 自動調整服務容量: 如 Amazon ECS 任務的數量或今天要介紹的 Aurora Serverless V2 ACU (今天要示範的) 自動化維護任務: 定時啟動或停止 EC2 Instance，以節省成本或進行系統維護。 SasS 訂閱即將到期通知: 蠻多 SaaS 系統可能會需要在用戶快到期時發送信件通知客戶續訂 架構說明 關於本文，我會預設讀者們對於 AWS 有基本的操作能力和認識，對於一些較瑣碎的動作會省略不講解 本文要教學的是排程每天固定時間，會透過 EventBridge Scheduler 調用 Lambda Function 然後將 Aurora Serverless V2 的 ACU 降低。 關於這個動作，我們其實要拆解成兩個部分: 用 Lambda 去調整 Aurora Serverless v2 ACU 用 EventBridge 去 Trigger Lambda 下圖是從 AWS 官方 Blog 下載下來的架構圖，純示意圖大概讓各位認識 EventBridge 和 Lambda 的配合 整體的步驟大概會是...

前言 很多人在初學 Docker 時，通常都會知道 CMD 和 ENTRYPOINT 基本上可以互換，但又覺得很疑惑既然兩個指令能互換為什麼要提供兩個指令給我們用? 但其實這兩者是有一些差異的，今天這篇文章就是來帶你了解 Dockerfile 中的 CMD 和 ENTRYPOINT CMD vs ENTRYPOINT 我這邊準備了兩個 Dockerfile，分別使用了 CMD 和 ENTRYPOINT FROM ubuntu:22.04 CMD [ "echo", "Hello from CMD" ] FROM ubuntu:22.04 ENTRYPOINT [ "echo", "Hello from ENTRYPOINT" ] 接著 build 了兩個 docker image，分別取名為 docker-cmd, docker-entrypoint $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE docker-entrypoint latest fa8ea026cc54 12 days ago 77.9MB docker-cmd latest bd73abaca1f4 12 days ago 77.9MB CMD 會被覆寫、ENTRYPOINT 則不會 理應來說我用 docker-cmd 這個 image 啟動一個容器，會打印出 Hello from CMD，執行結果確實也是如此:...

我踩到了什麼坑 本文的背景延續自我之前的文章《一個專案需要多個 Dockerfile - 淺談建構上下文 (build context)》 因為我們目前經手的專案會需要針對不同環境或是測試 Build 不同的 Image，為了讓目錄架構更具組織性且容易理解，我們根據不同的環境把各個環境的 Dockerfile, docker-compose.yaml, .sh 等等放在各個環境的目錄下，現在的目錄架構大概像這樣 ↓： E2Eproject/ ├── testenvironment1/ │ └── Dockerfile ├── testenvironment2/ │ ├── docker-compose.yaml │ └── Dockerfile ├── start-headless-tests.sh └── requirements.txt 由於我正在本地 Debug 這個專案，需要在本地運行 Docker-compose，我便很自然的執行 docker-compose -f ./cicd/headless/docker-compose.yaml up，結果 Docker 容器運行起來時，遇了一個錯誤：/bin/bash: /usr/src/app/cicd/headless/start-headless-tests.sh: No such file or directory。 這個錯誤讓我想也想不透哪邊出錯，我一開始都是針對 Dockerfile 去做動作，但完全沒有用 這邊就附上當時錯誤發生時的 Dockerfile 和 docker-compose.yaml，大家可以試著猜猜看是哪個環節導致錯誤！ E2Eproject/cicd/headless/Dockerfile ↓ # Dockerfile # Use the official Python base image from the DockerHub....

報名流程 履歷及申請動機 本篇文章主要以「技術支援」這個角度來探討履歷準備的方向，當然！這當中肯定有很多方向也是其他職能也可以拿來參考用的。即便您第一志願不是「技術支援」職能，我仍然建議你繼續讀完！ 先來了解 Technical Support (技術支援)這個角色會做哪些事 技術工作坊上台演講並教學雲端技術 提供組內雲端技術的諮詢和建議 撰寫工作坊所需的技術教學文件及應用 履歷準備方向 了解技術支援這個角色會做哪些事，盡可能地在撰寫履歷時，使內容可以讓面試官覺得你很適合這個角色 教學技術的經驗 上台演講的經驗 技術專案的經驗 有使用到 AWS 尤佳 內容可以和 Amazon 領導力準則掛勾 展現你在技術上的所專精的專業領域，例如： AI Data Analysis DevOps … 展現你的 Leadership 和 Ownership 量化你的成果 雲端技術證照 履歷常見錯誤 ❌ 履歷的大頭照可放可不放，但仍建議不要放，部分職位、傳統台商或特別要求則例外，原因如下： 避免因種族、膚色、人種… 產生任何 Bias 篇幅過長，超過兩頁 技術方面寫的過多過雜、許多不必要的雜訊，例如： 您有提到您會 Flask, Django，那就不必列出你會 Python 把有碰過的技術都寫上去，例如： 僅用過 Java 印出過 “Hello World” 就在「技能」區塊寫 Java 把專精的技術寫上去就好，怎樣算是專精呢？只要您對於這個技術有信心給面試官隨便問 5 個 Why 你都有信心可以回答就寫上來 未量化你的各經歷的成果，例如： 你曾舉辦過技術工作坊，但你僅僅寫了你任期內舉辦了工作坊 更好的寫法是，你可以告訴我們你舉辦了幾人的 XXX 技術工作坊，觀眾對於您的講評評價高達 4.8/5 分 把自己描述成跨領域通才了，你應要把自己描述成一個專精 XX 技術領域的跨領域人才，例如： 因履歷投遞的職能是「技術支援」，你應該要讓自己成為一個「專精 XX 技術領域的雲端人才，同時附帶了活動規劃的跨領域優勢」 而非把自己寫的什麼都很會，讓人摸不清你到底是來投技術職能還是來投活動規畫職能，又或者讓人覺得你是一個通才 把其他人的貢獻寫在自己的履歷，例如： 你參與了某專案你僅負責後端開發，前端開發部分並非你做的，然而你卻在專案中的經歷寫到你使用了前端的 XXX 技術做了 XXX 功能 申請動機準備方向 申請動機這一塊就有比較多自由發揮的空間 以下就給出兩點簡單的小建議：...

最近在寫 E2E 測試遇到一個問題，因 E2E 專案中，除了專案本身的 Docker Image 需要 Build 之外，還有多個測試環境的 Image 也要 Build，這造成了我在這個專案上需要創建多個 Dockerfile 發生了什麼問題? 我一開始的錯誤處理方式 菜鳥時期的我，以為 Dockerfile 就是一定得命名為"Dockerfile"，這導致了我沒辦法在專案根目錄下創建三個 Dockerfile，因為會導致命名衝突 那我想出了什麼處理方式？相當簡單，很菜的我，一開始便自然地根據不同環境在專案下創建了不同的目錄，然後在目錄底下存放各自的 Dockerfile 就很類似這種感覺： E2Eproject/ ├── testenvironment1/ │ └── Dockerfile ├── testenvironment2/ │ └── Dockerfile ├── requirements.txt └── Dockerfile 接著便接著發生下一個問題 — 錯誤的建構上下文 以其中一個測試環境內的 Dockerfile 為範例，當時我的寫法如下，請特別注意 COPY ../../ /usr/src/app/ 這行 # Use the official Python base image from the DockerHub. FROM python:3.12 # Set the working directory within the container. WORKDIR /usr/src/app # Set the PYTHONPATH environment variable....