.NET Walker

在 .net 開發技術中，若要產生支援 Linux Container 的 Image 非常容易，你只需要底下幾個步驟即可: 上圖中的 Image Registry，可以是私有的，也可以是公用的。目前坊間公用的 Registry 典型像是 Docker Hub，若你把Image上傳到Docker Hub，人人都可以下載使用。許多軟體和框架的開發商，都已經把自己所建立的SDK, Runtime上傳至Docker Hub: 私有的Registry則適合企業存放僅供內部使用的Image。開發人員可以透過軟體自建Private Image Registry，或是採用雲端現成的服務，像是Azure 上的ACR(Azure Container Registry)。 使用Docker File建立image docker file是一份文件，透過docker file我們可以建置出docker image，你可以透過手動方式，以docker CLI來建立，若採用開發工具，在 Visual Studio 中，只需要將專案加入docker支援，即可自動建立 docker file: Visual Studio自動建立出來的 docker file，會依照 .net 版本有所不同。例如，底下是 .net 5 的 docker file: #See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging. FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build WORKDIR /src COPY [ "testdocker.csproj" , "." ] RUN dotnet restore "./testdocker.csproj" COPY . . WORKDIR "/src/....

我們知道，可以透過串聯多台虛擬機，加上traffic routing，實踐負載平衡，讓你的應用程式的可用性得以提升。 不過，在Azure當中有比手動實踐更方面的選擇，那就是 VMSS( Virtual Machine Scale Set)。Azure VMSS可幫助我們建立一套內建負載平衡的 VM組。執行個體的數目可以視需要自動或手動增加、減少，可輕易地實現 Auto Scale或Fail-over。 建立VMSS 建立一組VMSS的方式很簡單，請參考底下影片: 建立過程中，我們分別透過底下PS指令，在兩台伺服器上建立IIS服務，並建立預設網頁: Add-WindowsFeature Web-Server Set-Content -Path "C:\inetpub\wwwroot\Default.htm" -Value "Hello world from host $( $env:computername ) !" 網頁會分別顯示機器名稱，從上面的有片中，你會看到，我們試著停掉其中一台機器，另一台VM會即時接手執行，自動實現 fail-over 之效果。

Azure 中的VM(虛擬機器)，是雲端提供的典型IaaS(Infrastructure as a Service)服務模型之一。 你可以直接在Azure雲端建立一台Windows或Linux VM，並且透過portal管理該VM。使用RDP或SSH連上該VM。 建立虛擬機 建立VM所需要考量的因素大抵包含: 等級(CPU, RAM, 運算能力…etc.) 應碟大小與數量 網路與對外IP 可用性(是否支援負載平衡或容錯處理) 底下示範建立一台windows的VM: 從上面的影片你會發現，建立一台VM時，大多會同時建立多個資源，像是網路IP、虛擬硬碟…等，因此建議將其放在獨立的資源群組，以便於管理。 一般來說，建立windows VM時，我們會開啟3389 port，以便於透過RDP連入操作，但這是有潛在的資安風險的，如果你的VM有對外(網際網路)的公開IP，建議在設定完成之後，移除3389 port，以降低被網路上駭客攻擊的機會。(有需要連入再設定開啟即可) 底下展示如何透過RDP連入VM: 透過portal運行PowerShell指令 如果你需要設定VM或是安裝功能，其實也不一定需要直接透過RDP連入，針對windows VM，你可以從portal直接執行powerShell指令，例如，底下這樣的powerShell指令可以建立VM成為網站伺服器: Add-WindowsFeature Web-Server Set-Content -Path "C:\inetpub\wwwroot\Default.htm" -Value "Hello world from host $( $env:computername ) !" 你可以透過azure portal進行這個操作，完全不用連入VM: 設定防火牆 你可以透過Portal來管理防火牆，例如底下示範為VM的網站伺服器開放對外的80: 如此一來，VM就輕鬆成為Web伺服器了。

在本地端開發環境建立 Azreu Function 相較在雲端直接建立並撰寫Azure Function，更便於測試(單步執行)和維護，也可以得到預先編譯的效果。 你可以使用VS Code來建立Azure Function。但須要在開發環境上安裝好底下套件，分別是: 👉Azure Function Core Tools 3.0 download (搭配 .net 3-5) https://go.microsoft.com/fwlink/?linkid=2135274 Azure storage emulator https://docs.microsoft.com/en-us/azure/storage/common/storage-use-emulator VS Code開發套件 https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions 如果你使用 .net 5以前的版本，建議搭配 3.0版的 core tools，如果你使用 .net 6以後的版本，建議搭配 4.0版以後的core tools，相關資訊如下: https://learn.microsoft.com/zh-tw/azure/azure-functions/functions-run-local?tabs=v4%2Cwindows%2Ccsharp%2Cportal%2Cbash 你可以從命令列，看到你的版本: 當你的VS Code安裝好Azure Functions套件，可以透過VS Code直接開發，完成後直接佈署到雲端運行。 底下展示如何在VS Code中完成這個動作。

Azure Functions 是微軟所提供的雲端 Server-less 服務，可讓開發人員在 Azure 上撰寫簡短的程式碼（functions）。以便於來執行例行性的工作，例如： 固定時間執行特定動作。 每當OOO發生的時候，執行XXX動作。 Azure Functions 之所以稱為 server-less functions，意思是，可讓您在不需要額外建置、管理伺服器或底層架構的情況下，直接執行程式碼（functions）。您只需要專注於寫出正確的程式碼，Azure 會負責在背景中執行，同時讓您透過 azure portal 來管理和備份程式碼。 舉例來說 舉例來說，過去我曾幫用戶建立一個解決方案，每當用戶把圖檔或影片上傳到 azure blob(儲存體)之後，就自動呼叫Azure cognitive services，辨識影像圖片中的人臉，並且將結果紀錄在資料庫中，以便於後續可以關鍵字搜尋。 這整個機制，我們就可以透過 Azure Functions 來完成。 底下這個MS官方的影片，很清楚地介紹使用Azure function的好處: 你可以把 Azure Functions 想像成，有人幫你建立好了伺服器、網站、準備好了SDK、runtime，然後你只需要把執行特定功能的 WebAPI/Web Services程式碼寫好放上去，就可以開始運行了。 撰寫方式 具體 Azure Functions 支援的語言包含: C# Java/JavaScript Python TypeScript PowerShell Script …越來越多… 開發人員可以透過 Azure Portal來撰寫，或是透過開發工具(像是Visual Studio, VS Code)撰寫完之後，佈署上雲端來執行。 在雲端建立第一個Function 要使用 Azure Function，得先建立 Function App服務，中文版稱為"函數應用程式"。 您可參考底下影片建立一個 Function App: 接著，透過 azure portal ，你可以直接建立一個 Function 並且在其中撰寫程式碼。底下這段影片，展示如何建立一個Function App，並且監聽 azure storage中的 blob ...

寫程式很少沒有環境變數的，不知道你把環境變數儲存在哪裡? 怎樣的保存和使用，才是安全有效率的呢? 過去 .net 開發人員，大多把環境變屬保存在 web.config 中，以XML的形式存在: <?xml version="1.0" encoding="utf-8" ?> < appSettings > < add key = " MyCustomSetting " value = " MyCustomSettingValue " /> </ appSettings > 而 .net core之後的時代，則大多保存在 appSettings.json檔案中，以JSON形式存在: { "Logging" : { "LogLevel" : { "Default" : "Information" , "Microsoft" : "Warning" , "Microsoft.Hosting.Lifetime" : "Information" } } , "AllowedHosts" : "*" , "myConfig" : { "para1" : "value3" , "para2" : "value2" } } 在開發階段，我們的應用程式，可以直接consume(使用)位於local的XML/Json設定檔，也就是上述的web.config和appSettings.json，但這樣有一個小缺點，每次將應用程式佈署到不同環境後(QA/Staging/Production)，都要手動修改設定檔。 如今，將應用程式佈署到雲端上的Azure App Services之後，有一個更方便的配置管理後台...

Deployment Slot是Azure Web App超級好用的重要機制，你可以透過這個方式，輕易的實踐不停機更版的藍綠佈署，或是A/B測試，金絲雀佈署等進階佈署功能。 請先確定你的網站是S1以上的等級，如果不是，可透過Scale Up功能放大網站: 接著，我們就可以來建立Slot，你可以為slot取不同的名字。基本上，你可以把一個slot視為一個獨立的站台，但這個站台是依附於主站台之下，當需要時，我們可以把該站台和主站台對調(swap)。 建立與使用slot 例如，我們可以建立一個staging站台: 你會發現，建立好之後，你就有兩個獨立的網站，各自有獨立的網址： 在上面的例子中，主網站網址是: https://webappname2023.azurewebsites.net 建立出來的 slot 網站網址則是: https://webappname2023-staging.azurewebsites.net 這兩個網站的網址，都各自可以連入。 而你在佈署程式碼的時候，也是可以獨立佈署，基本上就可以視為是兩個獨立的網站。 而重點在於，你可以隨時交換(swap)這兩個網站的內容。 例如，我們可以把想要上線的新版，先佈署到 -sraging 這個站台，然後由測試人員測試無誤後，再透過 swap 功能交換網站，這樣 -staging 網站會瞬間跟原本的主網站交換。 而用戶所看到的則是，網站畫面(或功能)瞬間更新了，因為用戶是一直從主網站的網址連入，處理的好，完全不會有停機的需要。 後面我們會展示這個 zero-downtime的swap功能。而所謂的"處理的好"，有許多因素，包含網站設計的架構，應該盡量 遵循 stateless，並且不把資料存放在記憶體中。 流量百分比 除了實踐藍綠佈署的網站瞬間更版，另外slot還有導流的功能，wab app有內建的 traffic manager，你可以從後台設定你希望實現了流量導引比例: 設定完成之後，從網站主網址(沒有-staging的那個)，進入的流量，就會有80%流量被留在主網站，有20%的流量被導引到 -staging 網站，這個功能，可以幫助我們輕鬆實現 A/B testing 的網站佈署實作。

藍綠佈署是開發人員想實踐zero-downtime不停機更版的最佳實踐。底下這個例子，你會看到我們示範，當有新版的功能時，我們先將其佈署到 staging slot，然後交換 staging slot 與 production slot，在瞬間完成網站的更版。 優點在於: 不需要停機，沒有頓點，不像過去網站剛更新的時候，第一個使用的用戶會覺得卡卡的。 不會有任何用戶斷線或被登出。 有問題可以立即 rollback ，再swap回來就好，讓上新版變得安全可靠。 step: 15秒 --> 你會看到 staging slot，有獨立的網址 50秒 --> 將新版發佈到 staging slot 1’36秒 --> swap 正式機與staging slot 2’03秒 --> 正式機上出現新網站，由於已經在staging運行過，上版時瞬間可運行，不卡頓

大過年的，Azure VM上的C:槽空間不足。你知道的，C:槽空間不足會帶來很多奇奇怪怪的問題，且系統也無法更新了😥 在雲端，要把硬碟擴大很容易，但擴大了，我還是無法把C:槽放大，原因是C:槽後面卡了一個Recovery Partition，導致Extend Volume永遠灰色: 爬文爬了很久，不是無解，是很多解法。但各種方法試盡，最後只好嘗試最不想用的那個方法，沒想到20秒搞定花了我上午兩小時沒弄完的事情。 答案是: 使用工具。 (還是免費的) 工具在這裡: https://www.diskpart.com/ 誰說什麼工具不重要的? 知道再多的原理和指令，也沒法20秒搞定這個用工具其實20秒就可以搞定的事情，唉~ 那為何一開始我不用呢? 🙄 就…我不喜歡在電腦上裝任何不熟悉的東西。 那為何現在又裝了呢? 🤔 就…誰叫我搞不定呢!😪 ref: https://www.diskpart.com/windows-10/windows-10-move-recovery-partition-4348.html

最近幾年高併發流量的網站需求快要變成開發/維運人員的日常。在過去我們小時候的那個年代，大抵不會有網站需要面對瞬間高流量的存取要求，而是大部分的流量是可以預估的。 但近年來，由於服務全球化的趨勢，網站常常要面對從國內外全球而來的用戶，加上幾乎每一個用戶都有手機、平板、PC…等各種不同的連線設備，只消隨便舉辦一個網路活動，或是出現一個網路新聞事件，又或者類似搶票之類的需求，流量的瞬間高峰就很容易出現。 這時，該如何讓網站能夠瞬間達成負載平衡? 或是讓網站能夠不停機(zero-downtime)即刻升級，以因應瞬間出現的流量? 快速的Scale up與Scale out就是我們需要的解決方案。 什麼是 Scale up 與 Scale out Scale up指的是讓網站的伺服器本體的檔次升級，例如4G的RAM升級成8G的RAM，2核的CPU升級成4核的CPU… Scale out指的則是伺服器的水平擴展，在流量出現的時候，把原本的一台伺服器，擴展成兩台、四台、八台…等，如此一來，就可以分散流量，也可以實現fail-over(當某台伺服器發生問題時，由其他伺服器接手流量) : 進行 Scale up 在azure web app中，要實現 Scale Up/Down功能，只需要在管理後台設定即可，瞬間完成: 進行 Scale out S1以上等級的WebApp 就可以進行 Scale out，同樣是簡單的設定即可： 你可能會發現，才幾秒鐘的時間，五台伺服器就瞬間出現，Web App內建的負載平衡器，會幫我們自動導流的動作。 除了手動設定之外，其實還有Auto Scale功能，這讓我們可以透過建立設定檔，在高峰出現(例如CPU使用率、IO、流量增加…)的時候，自動化的進行Scale Out動作，在流量降低時，再自動還原，以降低成本。 請注意，Scale動作是以整個 App Service Plan為單位的。如果在相同的App Service Plan中有多個Web Site，將會被一起Scale唷

有一個字叫做 target fixation，這個字不常見。 我在整理舊書的時候，從書架上掉出了一本書，target fixation是我在這本書上看到的。 不知道你有沒有過一種經驗，一開始學習騎車或開車時，由於太專注在要前往的方向，結果卻直接一頭撞上你想抵達的目標。這個字，差不多就是這意思 --> 由於過於專注在目標上，導致於駕駛者不自覺的增加了撞上目標的風險。 一般來說，它用在飛行器具、車輛的駕駛上，是一個專有名詞。但這本書"飛機上的27A"，把這個字用在人生。 你曾有過，太過於專注一個目標，導致於你忘了身邊其他的事情? 如果你是程式設計師、工程師，你一定有過這樣的經驗 --> 專注解決一個棘手的問題，似乎才過沒多久，結果天都黑了(或是天都亮了)。 --> 這現象有個專有名詞，這叫心流(Flow) 心流不是很好嗎? 當我們想專注的時候，是的。 但一直心流會很好嗎? 不。 你若有機會看到沉溺於賭局中，專注在機台或牌局當中的人，那也是一種心流。但，就算贏了賭局，往往也輸了整個人生。時間過去了，就再也不會回來，有時候，路過的美景，過去了就是過去了，若是過於專注在目標上，往往會讓你錯過身邊的風景。 我記得，我把這本書送給了一個好友，因為那時候我看到他全心投入工作中，犧牲了非常多個人生活的時間。這我是過來人，過去專注在工作、寫書、做系統、上課…不知不覺，十幾年過去了，目標達成了，但想想好像也犧牲了些路上的風景。 專注於目標很棒，但千萬別忽略了身邊的人與美景。 農曆新年前的最後一天，再次給自己這個提醒。

有幾個基本的方式能夠快速地管理網站，如果想要檢視網站的內容，或是快速上傳或修改檔案，最好的方式是使用主控台與進階工具: 主控台 位於左方選單，開啟後，可直接在網頁站台上，對網站所在目錄下達指令: 這是一個快速的檢視網站實際內容的方式。 進階工具 另一個機制是管理後台中的進階工具，這個工具可以開啟管理後台，上傳或編輯檔案，也是一個古典的管理工具。 為何說是古典的管理工具呢? 其實，當你熟悉CI/CD之後，就會覺得，這樣以近乎硬幹的方式來hard code網站實在有點讓人擔憂，但不管怎麼說，它依舊是很方便的機制。 上圖的影片中，是從管理後台直接修改雲端的網站內容的方式。在沒有進行CI/CD或自動化佈署的狀況下，過去我們也常用上面這樣的方式來修改網站內容，但最近幾年，比較合理的做法是透過自動化佈署，但你依舊可以使用這些工具來檢視佈署狀況。

我喜歡用這個比喻跟同學解釋，為何 “容器化(Container)” 技術對於開發人員和維運工程師那麼重要。 過去，你一定碰到過，開發的程式 “在我的電腦上是好的” 但在客戶那邊就是不能用的情況。有時候是…在測試環境OK，在正式機就是不行，然後怎麼辦? 我們開始找差異(難不成把你的電腦出貨給客戶?)，有時候幾天幾夜你也找不出差別，乾脆重安裝一台比較快。 這是因為，我們所開發的軟體對於作業系統、runtime、套件…都有相依性，所以換了底層環境，或是有一點點的套件差異，就可能導致無法執行。 然而，當我們採用容器化技術後，可以把軟體運行所需要的一切，都封裝在一個影像檔(image)之中，未來，只要把這個 image 丟到任何支援容器化技術的環境，不管是甚麼平台，不管作業系統、不管runtime是甚麼版本、不管有沒有安裝什麼套件…我們的應用程式一定可以執行。 就好比貨櫃屋或是行動餐車，把營業所需要的家當全部都封裝在那個車廂(image)裡面了，不管開到哪，接上水電就可營業(執行)。 而且容器化技術可以把一個影像檔壓縮到幾百M以內，比起VM的 image 動輒幾G起跳，有著天生的複製方便、擴展容易的特性，使得你可以很輕鬆地實踐 scale out(動態生出伺服器) 或 fail-over(壞了立刻啟動備援)。 從此之後，我們的應用程式跟作業系統環境毫無相依性，且隨便也可以瞬間擴展出五台十台執行個體，再也不怕瞬間大流量，這不是突破性的革命，什麼是突破性的革命? 如果讓我票選，近代軟體開發最重要的幾個技術，除了網際網路之外，容器化和AI可能可以名列前三。

這種金字塔型的圖表，我只在兩張投影片上用過。 一張是 John Maxwell 的『領導力的五個層次』。另一張，就是它了 – 吳軍博士的『工程師的五個等級』。(五真是個奇幻數字) 幾年前，一場聚會中，有位長輩突然對我說：『別讓自已只顧著當下的忙碌，把人生的路給走小了。』當時，我聽不太懂，也不以為意，但幾年後卻發現，似乎自己真的容易迷失在日復一日的繁忙工作中，卻逐漸遺忘了對技術最初的熱愛，以及過去曾嚮往的遠方美景。 新的一年，剛好重新看到吳軍博士在矽谷來信一書(繁體中文版出自態度一書)中，對於工程師生涯的描述，拿來當作今年開年對自己的期許… 或許哪天，有機會上課時，我再跟大家分享對這張投影片的想法。以及，身為一個軟體工程師，我心裡所嚮往的遠方美景…