由於 Docker Desktop 的收費政策的關係，公司電腦不能裝 Docker Desktop 很久了，但某些需求，例如 Windows Container，還是用 Docker 來做比較方便。雖然就授權而言不能安裝 Docker Desktop，但授權沒限制單獨使用 Docker Engine。對於我們只下 Docker CLI 而言，Docker Engine on Windows 已經能完全滿足我們的需求了。
由於 Kubernetes 的導入，目前公司內的 Windows Container 已所剩無幾，並且 Docker Desktop 現有授權的關係，在公司使用 Docker Desktop 是需要每年採購授權的。因此想要嘗試改用 Podman，在轉換至 podman 過程有二件事：
docker CLI，要改成 podman CLI今天要測個MS SQL的東西時，啟動MS SQL容器時發生Ports are not available錯誤。
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<YourStrong@Passw0rd>" -p 1433:1433 --name sql1 --hostname sql1 -d mcr.microsoft.com/mssql/server:2022-latest
c71dce344559b7e9188144b69329bdeca50e85984742d0c97ea73d3b1a40c5cf
docker: Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:1433 -> 0.0.0.0:0: listen tcp 0.0.0.0:1433: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
我們某台Docker Host不斷發出CPU Alert，也就是CPU長時間不斷在高百分比情況。關於執行中的容器，我們可以使用docker stats觀察容器的CPU、RAM、I/O等整體狀態。雖然有幾秒會突然有某個容器衝高CPU的情況，但在某個AP容器被呼叫的情況，且只有短短幾秒，看起來合情合理。但如上圖，為何dockerd.exe的CPU一直持續在某個高點？而且不斷往上成長，雖然成長速度不快。所有容器服務在此台Docker Host都很正常執行，但就是想不到何為dockerd.exe為何持續佔用CPU。陷入苦思許久，苦思針對dockerd.exe我要如何偵錯；要針對某個處理程序（process）要偵錯，說起來不容易。
近期，我們有意將 Windows Container 升級至最新半年通道 Windows Server 2004，從 1709、1803、1809、1903、1909 一路被虐過來，總覺得會越走越輕鬆，結果沒有。前面，在解決了 VMTools 造成容器服務會被中斷的問題之後。馬上又碰到第二個問題。
公司新筆電，怎麼用不到半年整個 C: 就快滿了。當初 C: 給了約 220GB，雖然安裝一些開發工具會佔一些空間，但也不應該會把 C: 吃到快滿的狀態。
在某個時間點之後，我們的 Docker for Windows 服務測試區進入了非常不穩定期。一開始不容易發現的原因是，預設執行中的容器(Container)有下 --restart=always 而且又是在測試區，也就是說，當你部署新的容器服務時，會有10-15鐘很正常，然後中間會有個有個瞬斷。容器被中止後，因為 --restart=always 參數的關係， Docker 服務會用最快的時間重啟一個容器還給你用。所以總會覺得怎麼最近寫的容器應用程式怎麼過一段時間就卡卡的。在某次下 docker ps 時看到才發現到這些容器的啟動時間怪怪的。
近來，我們的 Docker Build 主機上經常過一段時間就會出現以下的錯誤造成 docker build 失敗。
我們先在本機進行 Redis for Windows 的 Master-Slave-Sentinel 架構測試。由於微軟官方已經不再繼續維護 Redis for Windows，目前還有一位 tporadowski fork 後持繼在更新與維護。讓我們謝謝他。
在某些時間，在進行 Docker 與 Container 偵錯時，真的已經查到完全沒有頭緒時，總會把問題定位「是否是 Docker 本身的蟲呢？」在導入 Docker 之後，真的碰過幾次 Docker 本身的問題，都是查了很久才在 Github Issue 上查詢到一些線索，最久等超過一年以上才放出修正。當我們想知道 Docker 本身狀態時，你會發現，就 Docker CLI 都是偏 Container 的操作，docker logs、docker events…好像沒有可以取得 Docker 本身偵錯資訊的 CLI。
如果要取得 Docker 本身的偵錯訊息，有兩種方式，一是使用指令進行 Debug Mode，一是使用 daemon.json 組態指定 Debug Mode。
在使用 multi-stage builds 進行建置 .NET / .NET Core 應用程式時發現一個有趣的事，在 docker build 內進行 nuget.org 還原時可正常還原套件。但如果是使用到 Private Nuget Service 時，例如，我們採用的是 Azure Artifacts - NuGet 服務，就會取得一堆紅色的錯誤訊息：
Errors in packages.config projects
Unable to find version '2018.8.2.3' of package 'KingXXXX.YYYYYYYYYYor'.
https://api.nuget.org/v3/index.json: Package 'KingXXXX.YYYYYYYYYYor.2018.8.2.3' is not found on source 'https://api.nuget.org/v3/index.json'.
Unable to find version '2017.10.17.1' of package 'KingXXXX.YYYYYYYYYYYYYYFramework'.
https://api.nuget.org/v3/index.json: Package 'KingXXXX.YYYYYYYYYYYYYYFramework.2017.10.17.1' is not found on source 'https://api.nuget.org/v3/index.json'.
Unable to find version '2018.7.24.2' of package 'KingXXXX.PPPPService'.
https://api.nuget.org/v3/index.json: Package 'KingXXXX.PPPPService.2018.7.24.2' is not found on source 'https://api.nuget.org/v3/index.json'.
NuGet Config files used:
C:\Users\ContainerAdministrator\AppData\Roaming\NuGet\NuGet.Config
Feeds used:
https://api.nuget.org/v3/index.json
在受管制的網路環境，需要在 Windows 容器內去安裝 MSBuild 工具，MSBuild 工具大約區分二個版本，Build Tools 2015 與 Build Tools for Visual Studio (2017, 2019)。
公司新開發機筆電明顯卡頓，而且時常出現螢幕閃黑數十秒後還原。原先不太在意，但頻率明顯增加的趨勢。一段時間過後發現，此現象在啟動 Docker for Windows 之後非常明顯。在啟動 Windows Container 失敗的錯誤訊息：The paging file is too small 引發我的好奇。
首先，這台開發機有 24 GB RAM，啟動 Docker for Windows 後整體使用率約 7 成(Windows Container 因為有機會開 SQL Server 容器，所以習慣設定 4096 MB)，也就是使用約 16 - 17 GB 左右，剩下也還有接近 7 GB 的記憶體空間。我知道 Paging 是指分頁檔，但通常分頁檔應該是實體憶體體不足才會產生與使用。怎麼會說不夠呢？
看過就好，請不要跟著做。
在處理一個 Docker 問題時，發現 Windows 系統日誌裡有非常大量的 disk 警告：
PS C:\> Get-EventLog -LogName System -EntryType Warning -Source disk -Newest 10 | fl
Index : 636983
EntryType : Warning
InstanceId : 2147745950
Message : Disk 19 has the same disk identifiers as one or more disks connected to the system. Go to Microsoft's support website (http://support.microsoft.com) and search for KB2983588 to resolve the issue.
Category : (0)
CategoryNumber : 0
ReplacementStrings : {\Device\Harddisk19\DR368, 19}
Source : disk
TimeGenerated : 11/29/2019 3:15:49 PM
TimeWritten : 11/29/2019 3:15:49 PM
UserName :
訊息說明，有大量的 disk 有著相同的 identifiers，請參考 KB2983588 來決解問題。
當我們採用含 IIS 功能的 Windows Container 後(例如，Windows IIS、ASP.NET等)，有時需要查詢或操作 IIS，未經組態的 IIS 容器並無法直接使用如 IIS 管理員等 GUI 工具來連線管理。還是可以透過內建 iisreset.exe 與 appcmd.exe 來進行查詢與管理。
某一批新 VM 主機在安裝了 Microsoft Monitoring Agent(MMA)之後，出現奇怪的現像，在 Log Analytics 裡，除了 Perf (效能計數器) 項目，其他查詢都很正常。本來方向一直在 MMA 打轉，查了許久，終於找出原因：
Get-Counter -ListSet * | Sort-Object -Property CounterSetName | Format-Table -AutoSize
Get-Counter -ListSet * | Where-Object -FilterScript {$_.CounterSetName -eq "Process" -or $_.CounterSetName -eq "Memory" -or $_.CounterSetName -eq "LogicalDisk"}
在公司 Windows 10 開發機上，當 Docker 採用 Process Isolation 執行時，畫面停止不動，無法繼續往下執行。
在公司 Windows 10 開發機上進行 Windows Container for GPU 測試時，在進行 docker build DirectX 範例時，不斷出現 timeout 的錯誤。連指定容器 DNS 都用上了，還是不行。
偵錯了好久才想到，公司網路環境特別，內部設備上網需包含一張特別的憑證。原本開發機已包含此憑證，上網正常，本以為容器只是透過本機 NAT 出去，應該只是借道而行，結果是不得其門而入。
因為教學與工作上的需求，經常使用到 Northwind 資料庫，但重覆性的建立工作，實在浪費不少時間。在容器化時代，當然用容器來解決這種工作內容最合適不過了。
Docker Swarm 的服務容器專案有個特別需求，再特定情況下需要對特定服務的複本(replicas)容器下達特定指令。這在單純的容器環境非常簡單，透過 docker exec CLI 就能簡單解決。
docker exec {container} ping localhost -n 1
docker exec -it {container} cmd
docker exec -it {container} powershell