kuanhung c

繼入手第一隻 Murker 38C 傳統式刮鬍刀後，現在每天都很期待刮鬍子。還收集了很多刀片 Astra / Derby Extra / Derby Premium，然後又手滑買了第二隻，也是幾乎都會推薦給新手使用的 DE89 ，比較常聽到的名字可能是 Muhle R89 根據我看到的說法是，Muhle 和 Edwin Jagger 共同開發這個刀頭，所以只有兩家各自出的手柄握把不一樣，刀頭都是相同的。那為什麼選 Edwin Jagger 呢？因為 Amazon CA 只有賣 Edwin Jagger ... Orz... Edwin Jagger 的刀頭設計和 38C 一樣雖然也是 close combat 但他的刀片露出就比 Murker 38C 多一些。刮起來也是很順暢，但是第3刮的 Against The Grain 就噴血了..lol...不知道是刀片太利了還是 DE89 攻擊性比較強.... 但也有可能是我技術太差... 所以又換回 38C 刮刮看，確認 Murker 38C 真的比較溫和，但似乎不像 DE89 可以刮得很乾淨。現在都會乖乖用 pre shave cream 這樣子容錯率比較高... 有了兩隻比較以後，已經可以分辨出，刀頭設計，二件式，三件式，握把長短，握把重量等等的差異。像 38C 就屬於長握把約 10cm，重量約 100g 。 DE89 就是一般的短握把，約 8cm，重量也較輕。但這兩款的確都很適合新手，所謂的噴血也只是有小血珠冒出，不是割痕，用鬚後水塗完就沒感覺了。 現在慢慢體會到傳統濕式刮鬍的魅力有一部分是刮鬍刀本身設計很漂亮，刀片有很多選擇，不會卡鬍渣，刮鬍手感很棒。另一部份就是塗 pre shave cream，從刮鬍皂用刮鬍刷打出刮鬍泡塗在臉上，並沒有想像中的麻煩，現在反而有點期待這整個過程。 這是還沒用過傳統刮鬍刀前我完全沒想到的! 繼續收集研究刮鬍刀和刀片，還有各種不同的刮鬍皂/膏…刮鬍子現在變的很有趣 :)

如果在 CloudFormation 裡面直接使用  "AWS::Lambda::Version" 加上  ProvisionedConcurrencyConfig 接著 update stack 更新 ConcurrentExecutions 就會出現 update error 因為 version 不能夠 update 但是如果把 ProvisionedConcurrency 放在  "AWS::Lambda::Alias" 裡面，update stack 卻又可以了... lol... 不過一個 provisioned concurrent lambda 一個月要額外多 $5 USD 的費用還不包含 lambda execution 的費用，一個 1 vCPU + 512MB 的 fargate container 也不過大概是 $31 USD .... Update: 再仔細看了一下，update stack 失敗的原因有兩個一個是因為 Application Load Balancer Target Group 指向的 lambda 無法 stabilized 所以 update 失敗導致 rollback。其中一個原因是因為 ALB 沒有權限 invoke lambda function。LambdaPermission resource 還沒執行時，就先執行了 ALB TargetGroup 設定，所以在 TargetGroup resource 加了 DependsOn LambdaPermission 後，就少了 一個錯誤，但剩下的 ALB 無法 stabilized 的錯誤目前還是無解.... 只能把 stack 刪掉重新 deploy，接下來的 update 好像就都沒事。只是說在刪除 stack 的時候，會出現等待 lambda ENI 刪除的 waiting... 要等 8 ~ 20 min? 據說是後來 aggregate ENI 給 VPC 內的 lambda 後導致的 side effect.... CloudFormation 印象中也是越來越聰明，當 Resource A 有 !Ref Resource B 的時候，就會自動做 DependsOn 調整執行順序，但是像今天這個...

一直以來都是用吉列三刀片/五刀片刮鬍刀 想不透有時候買整組刀架附刀片可能還比單買刀片便宜 因為覺得刀片蠻貴的，所以都拖蠻久才換一次 多刀片的設計，刀片和刀片之間也特別容易卡鬍渣 後來看到傳統式刮鬍刀，很多人都推薦 Merkur 34C 我在 Amazon 剛好看到有 Merkur 38C $69 CAD 所以就選他了 ASTRA 100 片 雙面刀片  $16 CAD 刮了幾天，目前很喜歡刀片抓住鬍鬚那種喀喀喀的聲音， 而且刀片用了三四天後還可以翻面再用，因為我鬍子長的範圍不多， 目前一片刀片大概可以用一個星期左右，還是分不太出來鈍了的感覺是什麼，可能要再多試試看 原本都是用噴罐式刮鬍泡，現在才知道原來還有刮鬍皂 用起覺得還不錯，推薦可以試試看，沒有想像中可怕， 感覺和用吉列時差不多安全，但多了刀片抓住鬍鬚的爽感 還有可以自由的換刀片!! 後來又買了 Derby Extra 和 Derby Premium Double Edge 要來試試 刀片便宜到爆阿阿阿!!

今天遇到了一個有趣的問題，是有個 build job 說他的 build node 會被隨機 terminate 掉。 大致去看了一下 Auto Scaling Group 的設定，當 idle node > 1 的時候， ASG 就會開始 scale in ，當有 build queue 不為空的時候，就 step scaling out 研究一下他的做法是在 jenkins cronjob 每分鐘去 query jenkins api 回報 build queue 和目前狀態是 idle or offline 的 build node number 去 CloudWatch metrics 然後 CloudWatch metrics 再去觸發 ASG 的 scale in or out 這時候我想到的問題是，那當 scale in 被觸發時，是哪台 instance 要被 terminate? 當初的設計很聰明，他利用了 lifecycle hook，用意是說當 build node 被選上要被 terminate 時，會進入 Terminate Wait 的狀態，直到 ASG 收到 complete-lifecycle-action 的指令時，才會真的 terminate 掉。 但這個 lifecycle hook 是有預設 timeout 時間 3600 sec !!  也就是說一但 instance 進入 Terminate Wait 即使你沒有用 cron job 去 complete-lifecycle-action 過了一小時 waiting 時間它還是會被關掉.... 原本我以為 ASG 應該會挑 CPU 閒置的機器下手吧？後來再去翻一下文件發現， default termination policy 的策略依序是盡量讓機器分散在不同 AZ >  Allocation Policy > Oldest Launch Template or Config 最後是開機時間最接近整數小時的機器。 其他可以選的 termination policy 也都不是根據 instance usage 來判定。 原本因為不想花太多時間，只是暫時先把 timeout 時間設長，讓他有機會即使不幸被選上，還是...

接手了一台 Jenkins server 他的Infrastructure as Code設計概念很棒 他用 aufs 來掛載 EBS data volume，AMI 的 rebuild 是透過 ansible 和 yaml 來設定，再透過 CloudFormation 自動 deploy 所以要更新的時候只要 commit 更新後的版本號碼進去 repo 就會有一個 fully patched AMI，然後再把 EBS volume 用 overlay fs 掛載到新的 /var/lib/jenkins 目錄 /etc/fstab 是這樣寫的: LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0 LABEL=jenkins-ebs-fs /mnt/jenkins ext4 defaults,nofail 0 2 none /var/lib/jenkins aufs br=/mnt/jenkins=rw:/var/lib/jenkins=ro,udba=reval 0 0 但長久以來一直有個問題是，每次重新開機後，/var/lib/jenkins 的目錄並沒有正確的疊上 EBS data volume 裡的資料 所以 workaround 都是 umount /var/lib/jenkins 再 mount -a 卻又好了 最近又要更新 Jenkins ，實在是很討厭每次都要手動進去把 fs 重新 mount 起來 原本以為是 jenkins service 啟動時間和 overlay fs 是不是有 in-use lock 之類，或者是 aufs.ko 載入的時候和 fstab 先後的問題 無意間看到有人說 /etc/fstab 的載入順序不保證是按照設定檔裡寫的順序的!! df -h 一看，發現第一次開機有問題的 mount /var/lib/jenkins 比 /mnt/jenkins 還前面 mount -a 正常的版本是 /mnt/jenkins 會比 /var/lib/jenkins 早 (其實以前也一直沒注意 df -h 的顯示順序) 最後只要加上  x-systemd.requires＝/mnt/jenkins  就好囉! ...