在 Fargate 預設使用 MountPoints 去利用 ephemeral storage 作為兩個 container 之間分享資源的手段時，可能會遇到如果 container 本身是 non-root user 的話，會導致無法寫入 ephemeral storage 的問題。
這是因為 Fargate 的 ephemeral storage 預設只能夠被 root 寫入。而這個問題，目前能夠做的 workaround 如下，基本上是在 Dockerfile 中，將要作為 ephemeral storage 的目錄設定為 VOLUME，就可以保留路徑內的資料不會被 bind mount 遮蓋，而且也會有權限可以讀寫該路徑。
USER node
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
詳情可以參考 GitHub issue。
快速筆記，最近花了非常多時間在研究為什麼 ECS 底下的 EC2 作業系統從 CentOS 7 升級成 Amazon Linux 2023 後，上頭的 ECS container 出現一堆問題。
主要遇到的問題似乎是 I/O 的緣故。EBS I/O 超過部署時設定的 throughput 的話，會導致 EC2 變得很不穩定，例如無法 SSH 進入 EC2、或者 EC2 上的 ECS agent 會斷線等等。這個問題可能會衍生出 EC2 上的 ECS container 無法正常寫檔案，要寫入檔案的內容可能會一直被 cache 在 dirty page 上，導致 container 的記憶體用量超出預期。
至於為什麼 EBS I/O 的用量會超出部署的設定，這點暫時還沒有結論，不過 architect 有發現 Amazon Linux 2023 寫 system journal 寫蠻多的，相較來說，CentOS 幾乎不寫 system journal。
筆記，原來 S3 要檢查檔案是否存在，是需要有 s3:ListBucket 的權限的，如果沒有這個權限的話，當檔案不存在時 S3 會拋出的錯誤會是 403 而不是 404，代表的是 S3 想要 list bucket 但沒有足夠權限…。
花了好多天的時間在研究，然後終於稍微搞清楚想要將 AWS ECS 上的應用程式的 log 導去 Splunk 時，需要注意的地方有哪些，以及它導出時是怎麼做的。不過在紀錄之前要先提一下，這篇當中不會提到如何建置 Splunk 服務，因為在我的狀況中 Splunk 是其他公司內的團隊已經建好的。
在 CloudFormation 的 Stack 被更新的時候，CloudFormation 有可能會針對要更新的資源做三種不同的處理 [1]：
其中第一種是直接完成更新，不會導致資源的服務中斷；第二種會導致一段時間的資源服務中斷，但 Resource ID 不會改變；第三種是會建立新的資源然後替換舊的資源，所以有可能資源的服務不會中斷，但必然導致 Resource ID 改變。
當 CloudFormation 在更新資源的時候，會依據被更新的資源的類型，套用上述三種更新方法的其中一種。因此具體而言到底會採用哪個方法更新，必須看被更新的東西是什麼而定。除此之外，更新的行為是以 Stack Property 為單位的。舉例來說：
AWS::ECS::Cluster
ClusterName:
Update requires: Replacement
Tags:
Update requires: No interruption在 CloudFormation 的文件 [2] 中，可以看到 ECS Cluster 如果是 ClusterName 這個屬性變更了的話，會採取的更方式是 Replacement；但如果是 Tags 的變更的話，則會採取 Update with No Interruption。
在很久以前有寫了一篇文章 [1] 紀錄要如何用 logback 把 log 導出到 AWS CloudWatch，那時是用 logback.xml 直接設定，不過有個缺點是設定中指定在 logback.xml 裡的 Log Stream 的名字是個寫死的固定值，這在多節點的狀況可能會有問題。因為 CloudWatch 對於任一 Log Stream 同時只能允許一個執行緒存取，這會導致當應用程式會擴展成兩個以上的節點的時候，輸出 log 可能會有問題。
在 AWS 社群看到有趣的研究，在講述 AWS 的架構中如何讓 blast radius（爆炸的影響範圍）最小？或者說當服務節點出問題時，讓受到影響的客戶端影響最小。以客戶端來說，狀況的假設是客戶端發出 request，request 透過某種 Routing 送進後端的服務節點，不過因為某種原因 request 造成了服務節點崩潰。此時客戶端會繼續嘗試重發 request，然後如果 Routing 的機制沒有特別地設計的話，終究客戶端的 request 會一台一台地把所有後端服務節點全部弄掛，導致整個服務中斷。