一個無法刪除的Windows同名資料夾
同事在一個意外之下,製造出了兩個同名資料夾:
好玩的事:一個可被刪除,另一個不管用什麼方式都無法被刪除。
在前面談到 PowerShell Core 的指令可能沒有 PowerShell 來的全面,預設 PowerShell Core 只提供最核心的模組功能,但放心,從 PowerShell 時期就能通過模組(Module)來擴充,我可以透過 https://www.powershellgallery.com 來查詢與安裝,或利用 Get-Module
來查詢:
PS C:\> Get-Module -ListAvailable
Directory: C:\program files\powershell\6\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Manifest 6.1.0.0 CimCmdlets Core {Get-CimAssociatedInstance, Get-CimClass, Get-CimInstance, Get-CimSession…}
Manifest 1.2.3.0 Microsoft.PowerShell.Archive Desk {Compress-Archive, Expand-Archive}
Manifest 6.1.0.0 Microsoft.PowerShell.Diagnostics Core {Get-WinEvent, New-WinEvent}
Manifest 6.1.0.0 Microsoft.PowerShell.Host Core {Start-Transcript, Stop-Transcript}
Manifest 6.1.0.0 Microsoft.PowerShell.Management Core {Add-Content, Clear-Content, Clear-ItemProperty, Join-Path…}
Manifest 6.1.0.0 Microsoft.PowerShell.Security Core {Get-Acl, Set-Acl, Get-PfxCertificate, Get-Credential…}
Manifest 6.1.0.0 Microsoft.PowerShell.Utility Core {Export-Alias, Get-Alias, Import-Alias, New-Alias…}
Manifest 6.1.0.0 Microsoft.WSMan.Management Core {Disable-WSManCredSSP, Enable-WSManCredSSP, Get-WSManCredSSP, Set-WSManQuickConfig…}
Script 1.3.2 PackageManagement Desk {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource…}
Script 2.1.3 PowerShellGet Desk {Find-Command, Find-DSCResource, Find-Module, Find-RoleCapability…}
Script 0.0 PSDesiredStateConfiguration Desk {ValidateNoCircleInNodeResources, StrongConnect, New-DscChecksum, Test-NodeResources…}
Script 6.1.0.0 PSDiagnostics Core {Disable-PSTrace, Disable-PSWSManCombinedTrace, Disable-WSManTrace, Enable-PSTrace…}
Script 2.0.0 PSReadLine Desk {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler, Get-PSReadLineOption…}
Binary 1.1.2 ThreadJob Desk Start-ThreadJob
因為教學與工作上的需求,經常使用到 Northwind 資料庫,但重覆性的建立工作,實在浪費不少時間。在容器化時代,當然用容器來解決這種工作內容最合適不過了。
在測試 .NET Core 註冊為 Windows Service 的過程中,發現 .NET Core 在離開 IIS 之後真的好好玩,連 ASP.NET Core 都可以不用理 IIS 也活的好好的。想把 ASP.NET Core 註冊為 Windows Service 來執行,最主要是想以得較高的身份驗證來執行一些之前在 IIS 裡不易處理的狀況。不過就在玩得正高興時,發現:
New-Service
Start-Service
Get-Service
Stop-Service
Remove-Service
最後一個 Remove-Service
怎麼試都會出錯,連看個說明文件也有事!
λ Get-Help Remove-Service
Get-Help : Get-Help 在此工作階段的說明檔中找不到 Remove-Service。若要下載更新的說明主題,請輸入: "Update-Help"。若要線上取得說明,請搜尋 TechN
et Library (網址為 https:/go.microsoft.com/fwlink/?LinkID=107116) 中的說明主題。
位於 線路:1 字元:1
+ Get-Help Remove-Service
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (:) [Get-Help], HelpNotFoundException
+ FullyQualifiedErrorId : HelpNotFound,Microsoft.PowerShell.Commands.GetHelpCommand
前篇說到,PowerShell Core(pwsh.exe) 目前使用上會有一個視窗跳動的問題,可以改用 cmder 或 Windows Terminal 等其他整合命令環境來解決。因為 cmder 需要其他組態,而 Windows Terminal 差不多是裝好即用,本篇說明 cmder 的相關組態。
日前接手一個 ASP.NET Core 的專案,在本機開發與測試一切正常。但在進行發行時會出現一個 TransformWebConfig 錯誤,造成發行錯誤:
Severity Code Description Project File Line Suppression State
Error The "TransformWebConfig" task failed unexpectedly.
System.Exception: In process hosting is not supported for AspNetCoreModule. Change the AspNetCoreModule to atleast AspNetCoreModuleV2.
at Microsoft.NET.Sdk.Publish.Tasks.WebConfigTransform.TransformAspNetCore(XElement aspNetCoreElement, String appName, Boolean configureForAzure, Boolean useAppHost, String extension, String aspNetCoreModuleName, String aspNetCoreHostingModel)
at Microsoft.NET.Sdk.Publish.Tasks.WebConfigTransform.Transform(XDocument webConfig, String appName, Boolean configureForAzure, Boolean useAppHost, String extension, String aspNetCoreModuleName, String aspNetCoreHostingModel, String environmentName)
at Microsoft.NET.Sdk.Publish.Tasks.TransformWebConfig.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
目前 PowerShell 有二個主要分支,一個 Windows 內建的 PowerShell,一個是開源的 PowerShell Core 版本。PowerShell 提供全面的系統與應用支援。PowerShell Core 提供重要的跨平台支援。PowerShell (Core) 兩者各有優缺點,PowerShell 由 Windows 10 預設內建與僅支援 Windows,為求系統最大相容與穩定,更新速度不快,而且某些 .NET Framework 的特色也被繼承下來!PowerShell Core 採用 .NET Core 重新開發的開源版本,更新速度快,而且會盡量採用優秀的開源套件來整合與開發。
Windows PowerShell 在早期的 Windows 7, 8 / Windows Server 2008, 2012, 2012 R2 版本可能需要透過安裝 WMF 來取得。
目前有換車的需求,88節又剛好有個不算壞的8/9號颱風假,所以做了一個瘋狂的決定,我們去看車,而且是把新竹中華路上所有車商的車子看一遍,目前家庭人數基本4位,偶爾也有長輩加入後為6位的需求,目標就放在 SUV 車型為主,其他就當賞車,有什麼看什麼,盡量以當天能試到的車為主。花了三天,總共看了13家車商,賞車25台,試乘11台車(以下有v的),價位約從80萬、100萬、120萬、150萬、170萬都有。
需求:
ACC(Adaptive Cruise Control,簡想說就是『自動跟車』)有分全速域與非全速域,全速域簡單想就是設定之後可以跟車到時速0,非全速域就是只能跟到一定的速度,一般是30。需不需要用到全速域看需求,像我經常要回宜蘭,有條世界級的塞車道,需求上我就會盡量選有全速域自動跟車的車型。
基本上,我們開著老丈人20年破老爺車去看車(我們叫它「破許」其實,開的也很開心,哈哈哈。),就算的高級車的接待人員也很客氣與盡力介紹,這點讓三天每天都是非常好的開始與結束。總體而言,接待業務人員服務品質落差很大,有些介紹詳細、試乘介紹也清楚,Audi 業務最專業,試乘還會放古典樂造製氣氛,有些就只是陪伴在旁,有問才有答,還有試乘說我們的音響很不錯,結果放FM 89.5,放出來還是台語歌,當場全家忍住不能笑,差點中傷。
Docker Swarm 的服務容器專案有個特別需求,再特定情況下需要對特定服務的複本(replicas)容器下達特定指令。這在單純的容器環境非常簡單,透過 docker exec CLI 就能簡單解決。
docker exec {container} ping localhost -n 1
docker exec -it {container} cmd
docker exec -it {container} powershell
目前專案維持舊專案 .NET Framework 與新專案 .NET Core 的關係,而 .NET Framework 專案從 4.5.x、4.6.x、4.7.x、4.8 都有,而伺服器需要安裝至對應版本 .NET Framework,例如,專案使用 .NET Framework 4.7.2,伺服器只安裝 4.7.1 則不行。在維護伺服器時需要確認目前已經安裝的 .NET Framework 版本,微軟官方:「判斷安裝的 .NET Framework 版本」是用 C# 方式去判斷。這在伺服器就是不方便,又不是開發機,我按文件邏輯改為 PowerShell 版本,PowerShell 方法在任何主機都能快速判斷已安裝 .NET Framework 4.5.x ~ 4.8 版本。
在將一個 ASP.NET Web API 應用程式進行容器化(Containerization)發現一個問題,原先的 Web API 部署至 IIS 應用程式之下,我們會區分開發區(Develop)、測試區(Staging)、正式區(Production),而原始的請求因為 IIS 應用程式的關係,路由都會被加上應用程式的前綴(Route Prefix),例如:
在前一篇解決 Symantec Endpoint Protection 與 Docker 相容性問題碰到一個問題,Docker for Windows 預設 NAT 網路無法重設,主要是想統一開發人員的 NAT 網路設定,這樣 IT 單位才方便統一套用防火牆規則。
我測試以下幾種方式:
fixed-cidr
docker network rm nat
移除,直接顯示「daemon: nat is a pre-defined network and cannot be removed」訊息Get-NetNat
沒有任何訊息,Get-ContainerNetwork | Remove-ContainerNetwork
更顯示沒有此指令。基本是都行不通。最後實在沒找到辦法才請開發人員統一自訂一條 NAT 網路。
不過就在不死心的狀態下,又在我個人的 Surface Pro 上又試了一次。
目前公司是採用 Symantec Endpoint Protection (簡稱 SEP) 方案與 Docker 一直有相容性問題,直到在追一個問題時發現 Running Docker containers in process isolation when Symantec Endpoint Protection is installed 才得以解決。但我碰到第二個問題,Container 啟動之後(例如,起一個 ASP.NET MVC 容器),請求網頁沒有問題了,但網頁如果連線至容器之外的資料庫進行存取時,那麼則會被 Symantec Endpoint Protection 內建的防火牆擋下,在 Symantec Endpoint Protection 進行防火牆設置得以解決。也就是將容器運作的 IP 網段進行排除。
由於專案需求多變,有時需要自行建置客製化 Windows 基礎映像檔(Base Image)來使用,就在是在微軟官方的基礎映像檔之上去安裝軟體、設定環境等,像之前的文章:WINDOWS CONTAINER之.NET CORE找不到GDIPLUS.DLL解決方案為例,我們就把 ASP.NET Core Runtime 安裝至 Server Core 基礎映像檔,微軟官方應用程式的映像檔除非特別理由,不然通常最終都會以 Nano Server 為基礎映像檔來提供。
一個有趣的Case。我們需要收集與分析機台日誌,一天資料量(Size)不大,約200 ~ 300MB,但資料量(Folders/Files)很多,目前觀測到每日約有60 ~ 70萬筆,而且還會不斷成長。資料夾與檔案數約1:2,也就是,如果當天資料夾10萬個那就有20萬筆檔案。我們需要定時去主機A把日誌同步至主機B去進行程式分析與處理,因為不是所有檔案都是我們需要的,在複製的過程會進行一些過濾動作,所以選擇下面三套來測試,但發現一個好玩的現像,主機B常常沒有多久就記憶體滿載(Memory 99%~)的情況,目前測試過:
當我們導入了 Azure Container Monitor 之後,取得另外一個好處,內建的 Log Analytics 提供強大的日誌分析功能。而且 Log Analytics 經過設計之後,這些數據分析的資料能輸出為儀表板(Dashboard)。我們製作了一個 Dashboard,然後放到團隊的電視上,圖中很明顯出現直線下滑的曲線,而那條線是 Memory 的可用率!連入主機查詢,又是可惡的 99% 記憶體。
前情提要:「我們透過 Container Monitoring 發現了一個 Portainer Agent 的錯誤。」最簡單的修正就是每次當 Portainer 發現 Portainer Agent 連不上時,去 Portainer 裡去設定 Portainer Agent 重啟後的新 IP Address。此 Portainer Agent 本身位於 Docker Swarm 的 Overlay 網路上,Overlay 網路預設會分配一個 10.x.x.x/24
,第一條通常是 10.0.0.0/24
,第二條 10.0.1.0/24
以此類推。
一般當 Docker Host 與 Container 的越來越多時就能發現,在管理與處理 Docker Host 與 Container 因為太分散的關係(Docker Swarm / Kubernetes 本身就分散式架構)反而費時費力,在內網可以採用 Portainer 來管理,Portainer 好用是好用,但 Portainre 本身還是比較是單一個 Docker 與 Container 服務來查詢與管理,要想整合多個 Docker 資訊時,它就比較使不上力了。在嘗試使用 Container Monitoring solution 之後,發現這真是個好服務,用個簡單實例來看看如何使 Container Monitoring 來快速進行問題定位與處理。
事件回顧:「同事反應,Docker 某個 Container 重新部署後,一直無法正常存取。而這群 Production Docker Host 我才剛剛在前一個週未進行 Docker Engine 升級與安裝作業系統 Service Pack 的維護。」
在評估一份Storage Spec發現一堆WISSD、RISSD、NLSAS、Tiering名稱已經看不懂,趕快補強儲存設備相關知識一下。
Kubernetes 是一套基於 Google Borg 的容器調度系統(Container Orchestration System),到目前為止,這些容器一直都是 Linux 容器,運行在 Linux 伺服器上。從開源的 GKE (Google Kubernetes Engine) 1.14 版本開始,支援在 Windows Server 上運行 Windows Container。Google 一直與 Microsoft 與 Kubernetes 社區保持密切合作,並且將結果上傳至開源專案中。GKE 將會在 2019 年提供 Windows 容器,這個場次會討論 Early Access Program(EAP)。這個場次會討論一些 Windows 容器使用者情境並展示產品的初期預覽功能。你也有機會聽到一個大客戶的意見,並且瞭解他們在 GKE 來調度 Windows 和 Linux 容器分析的範例。
Visual Studio 2019 最有感的改變之一就是一開始的「啟動畫面(startup)」不一樣。不過好景不常,這個啟動畫面在我公司舊筆電(比例非常高)與自用的 Surface Pro 6 上都會出現:
Windows Subsystem for Linux (WSL) 是讓我們在 Windows 裡使用非 VM 方式可以直接與 Linux 底層溝通。網路上關於 WSL 使用與配置有許多精彩文章。最近在重設新電腦,以下順手記錄整合 WSL + Ubuntu + zsh 的配置,並且整合至 Docker CLI、VS Code、wsltty 與 cmder,讓我們體驗一個完全不同檔次指令列模式。
使用者需求,當應用程式發現問題或錯誤時,希望主機能直接播放提示或警告音效,讓人員能快速到達主機位置進行問題排除。
在企業內,經常需要查詢 Active Directory(AD) 資訊,有幾種方式(方向)可以來執行。
我們使用 docker stack deploy
大量部署 Swarm services,在不斷部署新版本之後,偶爾發現新版本 services 部署成功但運作並不正常。也就是無法連線服務的狀態。目前查詢後的結論是 overlay 網路沒有正常運作了。
在導入 Docker for Windows 之後,使用 PowerShell 的比重越來越高,而且在 CD(持續發布)的過程,也相當依賴 PowerShell 來進行作業。平常,可以透過 Docker CLI 來直接對 Docker Host 來下達指令(docker -H host command
)。但今天如果是要直接對 Windows Server 下達 PowerShell 指令,也就是,我在 A 電腦直接透過指令視窗對 B 電腦下 PowerShell 指令,而非使用遠端桌面,那麼可以使用 PSRemoting。
在補測試程式的過程,有時需要提供假資料給測試程式以驗證正確性。因為是補的過程,在資料庫中已經有測試資料,所有我想借由這些測試資料快速產出一個假的含資料的類別。但有些類別中的欄位非常多,而且很多又有階層關係,一字一字輸入轉回 C# 的資料類別又慢又沒效率。
因為 Docker on Windows 的載入會影響到開機後的速度,所以習慣性會把開機啟動選項給關閉,需要時在啟動即可。
如果是在 Linux containers 模式之下,設定:
如果是在 Windows containers 模式之下,設定:
在使用外部倉庫(例如,Azure Container Registry)都需要先行在 Docker Host 進行 docker login
登入。登入後,使用 *.azurecr.io
進行 docker pull
或 docker push
就跟平常使用 Docker Hub 一樣自然。不過,在 Docker Engine 18.09 之後,提高了整個安全性檢查機制,如上圖,當我們執行登入 Azure ACR 的動作之後,它會給你一個明顯的大提示,你的密碼沒加密哦!
docker login <yourname>.azurecr.io
Username: <username>
Password: <password>
WARNING! Your password will be stored unencrypted in C:\Users\<user>\.docker\config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
跟著說明文件,很快就能找到解決方式,不過還是筆記小小注意事項。
通常在 Build Agnet 或 Docker Host 不斷部署之後,以 docker images
進行查詢,可以很明顯看到一堆 TAG 為 <none>
的 Images。一般而言,我們會定時清除為狀態為 dangling
的 Image,也就是上述 TAG 為 <none>
的 Images,以清除不必要(Unused
) Image 來簡省伺服器硬碟空間。