完成Docker EE for Windows在Swarm最後一哩Routing mesh(Ingress Mode)

完成 Docker EE for Windows 在 Swarm 最後一哩 Routing mesh(Ingress Mode)

在 Docker Enterprise Edition for Windows Server (簡稱 Docker EE for Windows) 架設與使用 Swarm Mode 時,一定會碰到一個問題,就是目前 Docker EE for Windows 還不支援 Swarm Mode 裡重要的 Routing mesh(又稱 Ingress mode) 功能。

在 Microsoft Docs 文件並沒有把話寫死,它寫著 "coming soon",讓我心裡一直有個希望的種子。

routing-mesh-coming-soon

釐清多 Windows Container 針對同一 Volume 運作時的權限身份

釐清多 Windows Container 針對同一 Volume 運作時的權限身份

專案有個需求,會同時有多個 Windows Container 對 Docker Host 同一資料夾進行操作,讀取、新增、刪除、修改都有,而且操作的量不小(秒級)。問題出在,A Container 建立資料夾與檔案,B Container 要操作時會出現 Access Denied。找了好久原因,終於釐清整個 Windows Container 在 Volume 運作時的身份與權限。

簡化的情境如下:

Docker Host --> A Container / B Container

在Server Core安裝Visual Studio Code

在Server Core安裝Visual Studio Code

雖然在 Server Core 以 PowerShell 為主,但還是有修改檔案內容的需求。當然,我實力超強,我可以用 PowerShell 來完成一切!(聽聽就好 XD)不然我也能使用 notepad.exe 來完成工作,不過當個現代化開發者,不使用個現代化編輯器的話,不就掉漆了。讓我呼叫你,超前鬼 Visual Studio Code。

Server Core 只是沒有 GUI 管理介面,但不代表不能安裝與使用 GUI 的應用程式。

在Server Core進行Python 3安裝

在Server Core進行Python 3安裝

同事想在 Server Core 上安裝 Python 3,但看到 Server Core 純 command-line 畫面嚇到,不知如何安裝軟體。其實我也不會,但我有變通的方式。哈哈。

如何掛載網路磁碟機至Windows Container Volume

如何掛載網路磁碟機至Windows Container Volume?

在 Server Core 1709/1803 - Windows Container,如果要掛載 Docker Host 的資料夾為 Volume,那麼最快速的方式是指定一個絕對路徑給 Windows Container。

例如:

docker run -v c:\ContainerData:c:\data:RO microsoft/windowsservercore:1709 cmd.exe
docker run -v c:\ContainerData:c:\data:RW microsoft/windowsservercore:1709 cmd.exe
docker run -v c:\ContainerData:c:\data microsoft/windowsservercore:1709 cmd.exe
  • :RO 為 Read Only,:RW 為 Read Write,未指定預設為 :RW

那麼如果想要掛載掛載網路磁碟機至 Windows Container 裡呢?

你或許會試試 -v \\HostNameOrIP\ShareFolder:C:\data 來直接掛載的方式。不用試,這行不通。

NGINX 基礎入門(Windows 版)

NGINX 基礎入門(Windows 版)

當我們啟用 nginx.exe 之後,需要透過 -s signal 來與 nginx.exe 溝通。

nginx.exe -s signal

signal 值可以是:

  • stop: fast shutdown
  • quit: graceful shutdown
  • reload:reloading the configuration file
  • reopen:reopening the log files

nginx.conf 組態

nginx.conf 是整個 NGINX 核心,管理者透過 nginx.conf 來調整 NGINX 運作行為。

在測試階段,最常用的是 nginx.exe -s reload 來重新載入 nginx.conf。

nginx.conf 最基本組成語法:

<section> {
    <directive> <parameters>;
}

注意,每一行指令都需要由分號(;)結束。例如:events 設置:

events {
    worker_connections  1024;
}

離線下載與安裝 Docker Enterprise Edition 任意版本

離線下載與安裝 Docker Enterprise Edition 任意版本

一般而言,要安裝 Docker Enterprise Edition (以下稱 Docker EE) (或 Preview) 版本都只需要執行二行 PowerShell 指令,例如:

安裝 Docker EE 1

Install-Module DockerMsftProvider -Force
Install-Package Docker -ProviderName DockerMsftProvider -Force

安裝 Docker EE Preview:

Install-Module DockerProvider
Install-Package Docker -ProviderName DockerProvider -RequiredVersion preview

看似簡單無比的任務,搞得我就搞得我一個頭二個大。原本以為 Install-Module 加上 -Proxy 參數就能解決的問題,但不斷出現的紅字錯誤訊息,只有灰頭土臉可以形容。請管理網路同事幫忙,得到一個壞消息,這個 Install-Module 指令就算加了 -Proxy 結果還是往 Firewall 走,也有試著用 netsh 改更底層 Proxy 設定,但依然無用。動 Firewall 事態不小,非到不得以,實在不想走這一條。

使用 PowerShell 安裝、更新與刪除 Docker Enterprise Edition (含Preview)

使用 PowerShell 安裝、更新與刪除 Docker Enterprise Edition (含Preview)

在 Windows Server Core 1709 測試過程,經常需要安裝、更新或刪除 Docker Enterprise Edition 的動作。因為文件分散在 Docker Docs 與 Microsoft Docs ,整理為以下筆記,方便自己查詢。你能發現,使用 PowerShell 的安裝與更新非常簡單,刪除步驟比較多,你能從上而下跟著筆記把 Docker 給刪除,在重新安裝起來。

ASP.NET Web API GZip/Deflat 資料遺失迷航記

ASP.NET Web API GZip/Deflat 資料遺失迷航記

前情提要:參考(1)(2),之前測試發現 ASP.NET Web API 有個查詢資料量不小(1.92 MB),並且會有同等級的上傳行為,在 ASP.NET Web API 加入 GZIP/Deflate (解)壓縮來改善效能,資料由 1.92 MB → 50 KB 壓縮率約 40 倍,這是用一點 CPU 來改善效能的好範例。

同事回報,在測試區當資料量提升至 3.3 MB(3338506 bytes) 後,程式有機會(隨機)出錯(Exception)。

先來看 HTTP POST 流程:

RestSharp (RawData: Over 3.3 MB) → GZIP → GZIP ByteArray (79515 bytes) → HTTP POST → ASP.NET Web API

這是個 VSTO 的 Excel 應用程式,在讀取 Web API 資料之後,原封不同進行上傳(HTTP POST)動作,由側錄取得離線 RawData 約 3.3 MB,經過 GZIP 壓縮後得到約 78 KB 的 Byte Array 資料,最後使用參考(2)程式碼送出:

request.AddParameter("application/json", content.ToArray(), ParameterType.RequestBody);
檔案大小

接收流程:

ASP.NET Web API → DecompressionHandler → RawData → Web API life cycle

Web API 收到請求後安排一個 Message Handler 進行解壓縮後取得 RawData 之後,按 Web API 生命流程往下進行。

程式穩定運作,經過許多分析與測試後,在終於在 Web API 側錄到錯誤發生時的資訊:

lose data

在 DecompressionHandler 取得的 GZIP ByteArray 大小為 77889,很明顯小於原始的 79515,把解壓縮的 RawData 資料 Dump 出來後確實資料短少被截斷了,造成後續 Web API 在進行 ModelBinding 時的不正常 Exception。

NGINX Proxy 與 Windows Authentication 整合

NGINX Proxy 與 Windows Authentication 整合

最近在整合 NGINXReverse Proxy 時碰到一些 Windows Authentication 整合的問題,花費不少時間,特此筆記之。

一般的 Web App 在 NGINX Reverse Proxy 作用下都能正常運作,但內部網站有多許使用 Windows Authentication 功能來進行 SSO,例如,在 ASP.NET MVC 或 ASP.NET Core 的 View Page,只需透過一行 @User.Identity.Name 即可觸發瀏覽器進行身分驗證功能,在網域運作環境下,是不可多得好物。當然,你找網路可以找到許多教你設 proxy_set_header 的文章或討論:

青菜SOAP與蘿蔔REST,請選擇?

青菜SOAP與蘿蔔REST,請選擇?

dzone.com 看到一篇比較 SOAPREST 的文章整理的覺得不錯,簡單翻譯做個筆記。

SOAPREST 都是 Web Service 通訊協定,在 REST 未風行之前,SOAP 長期以來都是 Web Service 服務介面的標準方法。不過,根據 Stormpath 的統計,目前已有超過 70% 的公開 API。

SOAPREST 主要差異

當你在 Internet 上公開一個 API,REST 通過獨立且一致的介面進行操作,用以訪問命名資源。而 SOAP 將應用程式邏輯的元件公開為服務,而不是資料,並且它通過不同的介面來操作。簡而言之,REST 訪問資料,SOAP 透過更標準化的訊息模式集來操作。在大多數情況下,可以使用 SOAPREST 來實現相同結果。

RESTful API, SPA, SEO 之三角關係

RESTful API, SPA, SEO 之三角關係

twMVC#28 的討論,有個學員問題一則有趣的問題:在導入 RESTful 架構後,純 JavaScript 執行環境(jQuery, AngularJs, React, ...)的前端要如何做 SEO?

Web資訊流:Database → Model → Server Render → HTML → Browser

SPA資訊流:Database → Model → RESTful API ⇆ JS Framework (Browser)

不論是傳統 ASP、ASP.NET (WebForms)、ASP.NET MVC 等都是以產出 HTML 為最終目標。但前端框架不斷爆發後,原本 Server Render 的角色不斷被 RESTful API 給取代,而前端則是各種框架(jQuery、React、Angular、Vue、...)來操作著 Browser 的 HTML 來進行畫面操作與互動。這類以 JavaScript 為核心的 SPA(Single Page Application) 頁面,對於 SEO(Search Engine Optimization) 而言是非常不友善的。

我本身專注在後端(Backend)且公司主要業務面向也非消費端,雖然知道一二,但回家深入瞭解一番之後,原來還有許多技術面向可以討論,以下就目前收集的到的資料討論。如果有更專精前端(Frontend)與前端 SEO 的朋友,也請不吝指教。

進行ASP.NET容器化-以ASP.NET MVC/Web API為例

進行ASP.NET容器化-以ASP.NET MVC/Web API為例

要將 ASP.NET MVC / ASP.NET Web API 轉移至 Docker Container 中運行,看似麻煩,但其實非常簡單。以下討論不使用工具與使用 Visual Studio for Docker 工具來達成轉移的工作。

整合VSTS Build/Release與Microsoft Azure服務完成ASP.NET Core容器化一條龍服務

整合VSTS Build/Release與Microsoft Azure服務完成ASP.NET Core容器化一條龍服務

你就是那條龍
來源:網路

ASP.NET Core 本身跨平台特性,使得他非常合適活在 Docker Container 裡。這裡試著把一個 github 專案先匯入 VSTS,然後在 VSTS Build 的 CI 服務進行 build image 和 pull image 的動作,pull image 我們採用 Microsoft Azure 的 Container Registry 服務來當私有庫。有了 image 之後,在使 VSTS Release 的 CD 服務將 image 送到 Web App for Container 去進行執行動作。

VS / VS Code <--> VSTS git <--> Build / Pull Image <--> ACR <--> Release <--> > Web App for Container <--> User

正常產生驗證用HTTP Cookie卻一直通不過Authorize驗證?

正常產生驗證用HTTP Cookie卻一直通不過Authorize驗證?

同事詢問一個靈異的狀況。美國同事的電腦,不論如何測試就是無法登入最近採用 ASP.NET Core + Razor Pages 開發的一個新服務網站。此網站使用預設 [Authorize] 來驗證,後端沒有什麼太深的程式碼,就是驗證帳密通過設定驗證 HTTP Cookie。

一開始的方向還在通想會不會是 ASP.NET Core 本身有雷,這個技術還很新,不敢說我們的掌握度還很好,可是想想可能性非常的低,這個 [Authorize] 的發展從 ASP.NET MVC 到 ASP.NET Core 應該算成熟的應用。反覆測試,發現一奇特現像。

  • US同事電腦:
    • Chrome 無法登入,一直導回登入頁面。
    • 登入過程需產生的驗證 Cookie ,經 F12 開發工具確認,有正確產生。
  • TW同事電腦:
    • Chrome 正常。
    • Firefox 重現無法登入,一直導回登入頁面。

Server Core 1709 with Docker EE Preview LCOW 絕對運作筆記

Server Core 1709 with Docker EE Preview LCOW 絕對運作筆記

LCOW

Linux Containers on Windows (以下稱 LCOW) 對於 Windows Server 上的容器化提供非常重要的戰略位置。先不論 Windows Server 上的 Docker EE 僅能執行 Windows Container,講個笑話,用 Docker EE 連架個私有 Registry 都困難重重。而 Windows 10 上的 Docker CE 好一些,可以直接進行 Linux Container / Windows Container 切換與操作,但兩者並無法同時使用(不過,也快可以了)。也就是說,在使用 LCOW 技術之後,不用在特別區分這是 Linux Container 或 Windows Container,不用在特別去切換執行環境,即可在一個 Docker EE 執行環境下同時執行 Linux / Windows Container。

使用SQL Server Schema Comparion新增NOT NULL欄位

使用SQL Server Schema Comparion新增NOT NULL欄位

我們的資料庫除了正式區之外都是使用 Visual Studio 資料庫專案來進行版控與管理。在測試區碰到一個簡單需求,新增表格欄位,例如定義 LocationType NVARCHAR (50) NOT NULL,透過 New Schema Comparion 原本以為快速就能解決的表格更新,結果立刻得到如下錯誤:

一個Windows 10小設定加速docker的container建立與執行速度

一個Windows 10小設定加速docker的container建立與執行速度

在學習 docker 過程中,會一直不斷重覆且大量建立與消滅 container 的過程。但每次在執行如 docker run 的指令,總是會覺得卡卡的,瞬間 CPU 都會飆高。查詢後得知,在 docker 建立 container 的過程會觸發 Antimalware Service Executable 程序,這是 Windows Defender 保護程序。

以下教各位把 docker 加入 Antimalware Service Executable 排除範圍:

管理Windows Server的殺手級火奴魯魯(Honolulu)-Server篇

管理Windows Server的殺手級火奴魯魯(Honolulu)-Server篇

前一篇,是本機 Windows 安裝 Project Hololulu,我們有介紹一下下面的架構圖:

Honolulu deployment

左邊算來第二、第三種是在 Server 上安裝 Project Hololulu。在 Server 上安裝 Project Hololulu 好處是,由於是 Web-based,如果是團隊有另一個人也要管理 Windows Server 的需求,那麼透過一個入口點(EndPoint)即可管理所有個人擁有權限的伺服器,而且如果前一篇有注意看 Add 連線那張圖,可以發現,除一般 Server 外,PC、Failover Cluster、Hyper-Converged Cluster 都是 Project Hololulu 的能力範圍。

管理 Windows Server Core/Nano 的殺手級火奴魯魯(Hanolulu) - Windows 10 篇

管理 Windows Server Core/Nano 的殺手級火奴魯魯(Hanolulu) - Windows 10 篇

Server Core/Server Nano 安裝模式有兩種:含 GUI (桌面體驗)與無 GUI。就安全性與安裝大小而言,會建議採用無 GUI 的模式。而我們正在測試的 Windows Server 1709 版本,目前還沒有 GUI 版,從 GUI 版本升級至 1709 版本之後會得到 Server Core 無 GUI 版本。也就是前一篇提到,一個純 command line 的畫面版本。PowerShell 對於不熟悉的人是個不小的挑戰,尤其是我們這種半路出家的只是一些 cmd.exe 指令的人員,管 Server 不是下下 dir 就能解決的事。Server Core/Server Nano 的無 GUI 模式,其實微軟有準備幾個 GUI 配套措施。