黑咖啡的創業音符

  Q1:為什麼要控制體重？ 根據衛福部統計：70%慢性病(糖尿病、痛風、心臟病、高血壓...)是由肥胖引起的，而失眠、過敏、腰酸背痛、不孕、月經不順、荷爾蒙失調...等文明病也經常發生在肥胖者身上，這是因為脂肪過多，毒素蓄積所致，如同廚房油煙堆積、藏污納垢就會滋生蚊蠅、病菌一樣。 因此，控重是淨化體內毒素、改善慢性病、維持健康的基本要素。 Q2:為何會胡亂發胖？ 1.肥胖體質與先天遺傳基因有關，又受後天環境、營養 及生活習慣所影響。 2.基礎代謝率降低，脂肪容易堆積。 3.內分泌失調，干擾胰島素，使糖分轉化為脂肪儲存體內。 4.腸胃機能改變，味覺靈敏度↓，更加偏好高熱量、高糖分、 高鹽分的食物。 5.雌激素分泌減少，脂肪代謝緩慢，體內脂肪重新分佈， 造成中廣型肥胖。 Q3: 進行控重時，正餐應該怎麼吃？ 控重期間除了每天要吃足4包健又麗取代兩餐之外，還有一餐正餐也要吃得營養均衡，千萬別為了想瘦得更快而吃得過少，反而容易導致基礎代謝下降喔。 正餐可以先喝些清湯，多吃點青菜，半碗飯（低GI五穀飯），然後女性3～4份蛋白質、男性則4～5份。 一份蛋白質（每份含蛋白質7克、脂肪5克，熱量75大卡) ＝1兩瘦肉（豬、牛、羊、雞） ＝1兩鱼肉＝1個雞蛋＝半塊豆腐 ＝4塊五香豆干＝1根素雞＝1杯無糖豆漿 Q4:進行控重時，嘴饞可以吃什麼？ 1.可補充茶葉蛋、高纖餅乾、大蕃茄等熱量較低 的食物。 2.若有充足的時間下，可製作一些，如燙青菜、 青菜蛋花湯、涼拌小黃瓜、西洋芹、海帶絲、 蒟蒻絲；香菇白菜，加秀得甜的愛玉、仙草、 果凍等低熱量的食物來增加飽足感。 Q5:進行控重時，能吃澱粉主食嗎？ 澱粉為三大營養素之一，當不吃澱粉時，身體會先利用肝臟中肝醣作為熱量來源，當肝醣消耗殆盡時就會轉為利用肌肉組織做為能量來源，因此往往減掉的不是脂肪而是蛋白質和水分，所以只要恢復正常飲食，很容易復胖。有鑑於此，控重的過程中還是要適量的攝取低GI值的澱粉類主食。 Q6:進行控重時，可以吃水果嗎？ 當然可以。控重期間每日可食用2份水果。如：2顆柳丁、2顆奇異果、2顆小蘋果或1顆葡萄柚；然而香蕉、榴槤、酪梨、荔枝、龍眼、鳳梨等熱量較高請避免食用。 Q7:進行控重時，能喝酒精飲料嗎？ 盡量避免。酒精的熱量很高，僅次於脂肪，平均每1公克的酒精便含有7大卡的熱量。 如果工作上一定要飲酒，就盡量選擇酒...

  免費多雲架構畫布 CloudSkew 簡介 CloudSkew一個 免費線上畫布編輯器 ，可幫助你我 繪製雲端架構圖 。 CloudSkew完成的畫布圖片可以 儲存到雲端上或是自己下載保存 ，重點還不只有我自己常用的Azure，包含AWS，Google Cloud，Kubernetes，阿里雲，Oracle Cloud OCI等圖標都有。 CloudSkew的基礎架構建立在多個Azure服務之上，就像樂高積木堆疊拼湊成你所需的樣貌，連結中還有更詳細的組件說明。 發佈CloudSkew原文 CloudSkew Login 牛刀小試 小弟剛剛稍微登入試用一下，如果已經有 LinkIn帳戶 ，直接Oauth授權驗證登入即可， 旁邊真的有非常多的圖示，直接點擊就到中間畫布上了，直接拖拉即可，如果要打字點圖示兩下就可以了。 、 作為一個自己的架構圖後最重要就是要能輸出，同樣有三種格式供選擇， 下載到自己電腦後就可以自行運作到您的簡報上，精美好看又看起來高大上(假掰但看起來開心) 預設是Azure，但剛剛有提到舉例的不少雲平台還包含K8s，原來要自行手動調整，以OCI為例 調整後就可以看到你要的雲平台圖示可以在你原來畫布或新畫布來做增添應用。 搞個多雲架構時這真的是非常好用的工具，值得大推。 自己留做日記，也分享給大家，需要就自行試試嘍！

苦口婆心的警惕自己 會PO這樣的圖文想必是已經是初老以上的年紀邁進，但普世價值裡，慢慢有越來越多的健康警訊個案一直在下修，從60...50....40...甚至30更低．．． 從簡單的數據上看，呼應了下圖各器官的使用期限是有生命周期的，假使不是有效的利用自己的器官而讓年限下修個多少百分比的折損，就不能想像為何健康亮紅燈會落入在青壯年時期了． 大家包含我自己都相對外顯體態的訓練更大於內在身體看不到的各個器官狀態，但外顯狀態舉凡精神，氣色，身形，活動行為，思考等等都是需要仰賴這些器官能幫你好好在他們的各自岡位上運作不罷工，我們才能凸顯一個好的外在行為． 所以我們自己真的要好好的活著！活著有尊嚴也降低給家人不必要的負擔，照顧自己也就間接照顧別人． 下圖是參考網站圖文擷取引用之．

  Day 27. Google GKE 叢集參數深入實踐 GKE叢集重要參數設置 上篇在GKE採用簡單的佈署示範讓我們對服務上手性更為容易，但實際上有更多很值得拿來進階應用生產環境使用的功能來做說明，我也把原來已經簡易佈署的K8s Cluster移除，本篇就來針對一些有意義的功能來圖文探索。 叢集基本資訊 位置地區性可以作為 多可用區域的實體層級服務保護 ，建議生產環境一定要選擇此。 版本上篇是選擇一個穩定版本類型由系統指派，但如果自身開發上有特別版本環境的需求，其實也有 下拉選單指定的版本 可以選擇。 節點集區 節點版本通常會與叢集一致性，自行選擇適合自身的部署環境為主。 節點數量 預設是會在底層跑3台GCE伺服器，測試環境可以選擇更低的數量節省成本，當然生產環境可能會更多，自行判斷。 生產環境建議啟用 自動擴展 ，且Pod所支撐的Node上下限可以 依據預估的負載量判定 設置。 部署的節點位置也會呼應 是否有設置可用性區域 來做執行的地區選擇。 如果底層更新升級後所指定的 Node數量允許的上限值 及如果 異常Node可接受數量 。 節點數 預設是Google提供一個系統認為優化過的容器作業系統，而如果自己也可以選擇所熟悉的OS，如：Ubuntu等... 伺服器等級的選用也是可以自訂的，包含以下幾種類型： 一般用途 運算(CPU)最佳化 記憶體(Memory)最佳化 涵蓋上述的自訂規格(不過CPU Core要>=2，RAM最小可以1G)已滿足客製化的生產環境或是測試節省成本之用。 開機的磁碟可以是標準的 HDD 或是較高IOPS的 SSD 磁碟 預設是100GB空間大小，可以自訂，不過一旦決定就無法在縮小空間。 安全性選項，是否需要開機時的管理加密。 先佔節點可在24hr區間內先行佔用Node資源但租用成本較低，一但設置就無法再調整，預設是沒有啟用。 一個節點 最多可以執行110個Pod ，也可以根據負載等應用考量 指定Pod最多的上限 值。 網路標記就跟 原GCE上綁定的防火牆規則做法相同 ，如果沒有設置是無法直接對外提供服務的。 安全性 預設都是用系統的預設服務帳戶來做存取，如果有想要帳戶存取的安全性切分，則可以透過自訂的服務帳戶來作調整。 防護的部分會啟用系統的完整監視。 安全啟動可以視需求讓容器環境更為安全。 gVisor本身是Googl...

  Day 26. K8s 小白初始安裝實踐 K8s初始安裝實踐 運作執行流程 Kubernetes(K8s)最終就是要透過Pod來實踐一個個容器上的應用，那我們該如何建立第一個Pod呢？ K8s架構圖中有個簡易的叢集，而叢集中會有 一個到多個不等Master互為備援 ，但測試方便性就只有一個。 當用戶想部署一個新的Pod到K8s叢集時，首先要通過 kubectl 命令列來輸入要建立Pod應該要有的指令。 而指令會 經過身份認證 後把需求傳遞到Master中的API Server。 API會在把指令狀態更新 備份到etcd 儲存空間內。 接著Controller控制器會從API Server接收到需要 建立一個新Pod的資訊並檢查可用的資源狀態 ，如沒有問題就會建立一個新Pod。 最後Scheduler排程器在定期輪詢API Server時會確認控制器是否建立新Pod，假設有新建Pod，Scheduler就會實際 負責Pod指派到最適的Node節點上 安居樂業。 雖然上述運作繁瑣，但實際操作過程，我們就只需要輸入我們想要的需求指令，K8s就會自動在一系列的黑盒子中幫我們完成一整個流程動作。完全不需要我們煩惱，只能說開發這套的谷歌團隊真的是佛心。 K8s前置作業小觀念 方法一 如果想要實際手工在本機電腦體驗操作需要以下套件分別下載： Minikube VirtualBox or VMware Fusion kubectl Minikube 谷歌發佈的一套輕量級容器工具，讓用戶輕鬆體驗K8s Cluster。Minikube會需要上本機建立一台VM並運行單一節點的K8s叢集服務。 minikube download VirtualBox or VMware Fusion 因為 Minikube 會透過VM來跑K8s，故需先安裝虛擬化平台管理工具。 VirtualBox Download VMware Fusion Download Kubectl 是K8s的Command Line命令列工具，之後都會 透過Kubectl來操作K8s Cluster 。 方法二 同樣是谷歌大神，但是小弟直接懶惰使用Google Cloud上的K8s叢集服務簡稱GKE來做搭建，如果需要申請免費試用可以參考小弟 GCP第一次申請就上手 官方優點參考如下： 按一下即可建立叢集，快速開始...

  線上資源紀錄日記 OCI 在成本計算上不像其他雲端的計算服務可以很容易的理解，第一次碰就踢鐵板，原來魔鬼藏在細節裡，但真的覺得是有必要這樣提高門檻，也許，這樣在這生態鏈的人可能才有被依賴的價值>< PS：補充一個眼睛一亮的好處， 每月10TB對外頻寬資料量下載免費 。 IaaS計算成本的規格細則對照 >>   Compute Shapes Standard Shapes Dense I/O Shapes GPU Shapes HPC Shapes 列舉Standard Shapes系列： BM.Standard1 :   X5-based   standard compute. Processor: Intel Xeon E5-2699 v3. Base frequency 2.3 GHz, max turbo frequency 3.6 GHz.X5-based shapes availability is limited to monthly universal credit customers existing on or before November 9, 2018, in the US West (Phoenix), US East (Ashburn), and Germany Central (Frankfurt) regions. BM.Standard.B1 :   X6-based   standard compute. Processor: Intel Xeon E5-2699 v4. Base frequency 2.2 GHz, max turbo frequency 3.6 GHz. BM.Standard2 :   X7-based   standard compute. Processor: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz. BM.Standard.E2 :   E2-based   standard compute. Processor:   AMD EPYC   ...

  Day 25. Container Orchestration 編程了解K8s與架構初探 Container Orchestration編程初探 從下圖中從下而上來看你可以理解成在一個大的平台 可以想像是雲端或是虛擬化平台 平台上分別有三台各自獨立的宿主機 上面有各自的作業系統 跑了運作容器的執行環境(Container Runtime) 容器化應用程式服務 Container Runtime 也簡稱CRI，可以指這整個容器程序運作的抽象底層，又或是理解為內部環境中程式語言在整個執行過程的生命週期的實踐。其中Container Runtime初始的用途就是要能夠運行容器。 透過上述各自宿主機上執行自己的容器化應用程式，但隨著AP服務需求日益增大，無論是在大規模的佈署管理正式生產環境或是爆量的存取需求而反映出需要更多大量計算資源而導致無法快速因應市場環境需求。 這時就有了叢集與編程腳本的概念，透過Container Orchestration把三台機器抽象成一整個共享池的容器資源，而原來各自宿主機就如同是一個個的容器節點，而APP的佈署實踐再也不需要知道需要配置到哪的指定機器上，直接由Orchestration來決定該如何佈建以及該放置到哪個節點資源的調度即可。 就如同前篇中 Docker Swarm   原生的叢集編排腳本技術來實踐。 Container Orchestration也把裡面的服務分別拆解出以下重要核心： Resource Management：管理底層的資源包含像是擴充與縮容運算資源節點，而節點資源內容就像是常見的CPU，Memory等... Scheduling：當被上層指派一個任務像是一個容器服務時，而容器到底應該要放在哪個節點機器上來運作。 Service Management：主要是提供把容器應用服務透過連接埠映射讓外部用戶能順利存取訪問之用。 上述說了這些露露長就是希望讓自己能夠瞭解這樣的產品技術背後的驅力是想要解決甚麼樣的問題，另外這樣的核心服務並不僅僅專屬於在某一家的產品技術上，而一個通識服務基礎，無論哪種容器編程都一定是內涵這樣的觀念在裡面，已經就是標準化技術編程，以下是列出市場熟知的三大自動編程解決方案： Docker Swarm Mesos Kubernetes(K8s) 經過這幾年的容器發展， Kubern...

Day24. Docker Swarm 透過 GCP Load Balancer實測 透過 GCP Load Balancer Docker Swarm上篇已把服務搭建起來並透過指令快速指定Nginx來執行多容，這次在針對簡單實用功能進行示範： 擴展縮容 負載平衡實踐 擴展縮容 Scaling本身概念簡單，也是雲端能帶來的其中一項價值所需，當回應需求服務數量或連線流量過大時，能透過擴展機制一次啟動多個相應的服務同時處理需求回應與因應流量，直到流量或需求恢復正常，就可以透過縮容來減少服務數量，以節省主機成本。 – replicas  代表目前要啟動 2 個Container來運行我的Nginx服務。 擴增 透過 docker service scale hello-a=5 就可以把容器數量從 2 新增成 5 來應付更多的流量。 縮容 只需要透過 docker service scale gyhello=2 來降低數量即可。 – name  用來定義此服務的名稱，也可在之後當成DNS給其他服務做使用。 - p 8080:80 則是把容器裡的80連接埠映射到宿主機上的8080連接埠。 docker service ps gyhello docker service scale gyhello=5 docker service ps gyhello docker service scale gyhello=2 docker service ps gyhello 負載平衡 當流量進到Docker Swarm的服務中，會透過像輪詢( Round Robin )的機制去把進來的流量做分流，也就是輪流把流量送到各服務去，舉例第一個進來給A容器，第二個進來給B容器，第三個進來再給A，以此類推... iptables -L -t nat 補充一下鳥哥教學 filter是流量進到宿主機本身來決定是否Accept or Drop or Forward的方式。 NAT流量本身跟此台宿主機並無直接關係，主要作為來源與目的IP & Port間轉至後端容器主機。 Mangle屬特殊表格，會去標記某些規格並改寫封包。 下面那條規則可以發現流量被導入到172.18.0.2:8080這邊 用 ifconfig 查看目前網路介面可以發現172.18.0.2與...