黑咖啡的創業音符

  Day 30. 容器小白學習歷程及部落客試金 時間過得好快！轉眼從猶豫是否要再報名自我挑戰，到確定發文的第一天還在擔心文庫內的彈藥存量不多。 一轉眼經歷了兩次中秋與雙十連假，埋首撰寫本次的容器技術文真的需要滿大的意志力與犧牲休閒時光，不過回首過去時間心境上在即將完成的這一刻起是異常的滿足。每一次痛苦的過程，辛苦的挑戰並堅持總是讓人有莫名的開心感。 容器技術真的為了要呈現一篇篇的技術文，要實際輸出才又更深刻的覺得想要學的精通真的需要一股腦的埋頭鑽進容器的世界把自己完全融入，這才能內化成自己的，隨手捻來就是容器經。 自己還是會持續在容器的領域上面精進，這次的手札日記還是讓自己打了一點基礎，也更清楚瞭解這架構的運作全貌，也謝謝一路有在關注或是覺得哪個篇章文章有幫助到自己的IT朋友們，都非常感謝。 以下是從Day1～Day29的技術總集，讓需要的朋友更方便查找 容器故事緣起 Day 1. Docker / K8s 前世今生與所需基礎知識 Day 2. Docker / K8s 求職市場分析 Day 3. Docker / K8s 我們不一樣 Day 4. Docker 與 K8s 具體化口碑優勢，不知道也要背起來 Docker實作預習 Day 5. Docker 燒腦專有名詞與應用場景 Day 6. Docker 架構流程說明 Day 7. Docker 所需收納口袋指令 Docker由淺入深實作 Day 8. Docker Engine on Ubuntu 18.04 安裝示範 Day 9. 好奇心殺死貓，一探究竟Docker info Day 10. Docker Images 深入探討 Day11. 利用 Dockerfile 簡單撰寫自己的映像 Day12. Dockerfile 語法深入探討 Day13. Docker Container 操作日常 Day14. Docker Registry on GCR 實測 Day15. Docker Volume 入門示範 Day16. 簡單備份還原與遷移 Docker 容器 Day17. Docker 外部網路存取實記 Day18. Docker Container 服務互連串接 Day19. Docker 進階網路深入探討(一) Day20. Docker 進階網路深入探討(二) Day21. Docker...

  Day 29. YAML 描述檔探討 科普YAML 實際上自己也常把YAML與JSON拿來做比較，我這邊非常簡易的分辨一下： YAML本身視為JSON的超集 ，故YAML本身就支援JSON的格式。 實務場景應用上JSON與YAML本身並不是很雷同。 JSON大多用於資料傳輸通訊 YAML大多用於組態設定 所以透過以上區分其實並沒有互相取代的意味，更 凸顯的雙方的共生 行列。 科普YAML維基百科 官網強調YAML並非標註語言，而是一種適用於所有語言，人性化的資料序列標準。講人話 YAML就是一種描述設定的文字檔 格式，讓生為萬物之靈的我們可以清楚了解文字內容所要表達的意思。 科普超集： 如果一個集合S2中的每一個元素都在集合S1中，且集合S1中可能包含S2中没有的元素，則集合S1就是S2的一個超集，反之，S2是S1的子集，而S1是S2的超集。 若S1中一定有S2中没有的元素，则S1是S2的真超集，反之S2是S1的真子集。 [科普JSON、XML、TOML、CSON、YAML差異化]( https://kknews.cc/code/a3ex5av.html   https://kknews.cc/zh-tw/code/a3ex5av.html) docker-compose.yml Docker Compose可讓我們用一個指定採用的描述檔 docker-compose.yml來管理多容 ，預設範本文件是docker-compose.yml，其描述檔就是 採用YAML格式 來做撰寫。 而描述檔中的服務會需要透過 image指令來指定映像 或 透過build搭配Dockerfile来做自動佈建 。 一旦透過build佈建，在Dockerfile中所設置的選項如：CMD，EXPOSE，VOLUME等．． 都是會被自動獲取而無需在docker-compose.yml中重複设置。 我們可以先比較一個個分開的前後端部署的狀態 單身前 使用Dockerfile建立新映像或是到指定的倉庫來抓取後建立所需要的容器，以下為例分別有前後端各一組容器，透過docker run指令來運行，但會需輸入很多次可能是重複性或非重複性的指令才能讓一個完整的應用服務啟動。 前端 docker run --rm -p 8000:8000 --name webapp1.fronte...

  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與...

  Day23. Docker Swarm 新手上路 Docker Swarm新手入門 前面說了一堆Docker知識，一路走到了這，快要進入的一個與K8s批敵的重頭戲Docker Swarm，不過我們首先要了解Docker Swarm的意義？ 我們有注意到，前面的所有示範的容器其實都只有跑在一台宿主機上面，那萬一主機掛了呢？ OK，我想你我大概也猜到了，沒錯，Docker Swarm 簡單說就是可以在多個宿主機上來管理容器的一種管理工具。 透過Docker Swarm，用戶可以非常容易的部署應用程式到任何一台宿主機上面，此外，假始其中一台宿主機離開人世了，也會立刻找一台最佳的宿主機上來啟動新的容器。 了解完定義後也要知道能實際帶給我們什麼樣的好處 Scaling自動擴展 Scaling本身概念簡單，也是雲端能帶來的其中一項價值所需，當回應需求服務數量或 連線流量過大時，能透過自動擴展機制一次啟動多個相應的服務同時處理需求回應與因應流量，直到流量或需求恢復正常，就可以透過縮容來減少服務數量，以節省主機成本。 Load Balacning負載平衡 當流量進到Docker Swarm的服務中，會透過像輪詢( Round Robin )的機制去把進來的流量做分流，也就是輪流把流量送到各服務去，舉例第一個進來給A容器，第二個進來給B容器，第三個進來再給A，以此類推... Service Discovery服務探索 在Docker swarm中每個服務都可以定義自己服務獨有的DNS，而接下來就可以讓其他容器透過自訂的DNS來使用服務。 啟動Docker Swarm前需要了解的兩個重要角色 Manager管理叢集 目的就是負責來管理叢集的宿主機，並調用安排每個需要的服務容器應該要被放在哪一台來做啟動，當服務停止時也要負責啟動服務容器使之正常來做服務的提供。 Worker Nodes工作節點 Node翻譯成節點，簡單說就是代表一台台的宿主機，而執行Service的地方就是在任意的Node節點上。 示範Docker Swarm部署 示範主機是在Google Cloud上的兩台Ubuntu docker1 version 19.03.6 IP：10.100.1.2 docker2 version 19.03.6 IP：10.100.1.3 前置作業 測試雙方的標的主機網路要能互...