

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 修補 Windows 伺服器和容器
<a name="windows-patching"></a>

修補 Windows Server 是 Windows 管理員的標準管理任務。這可以使用 Amazon System Manager - Patch Manager、WSUS、System Center Configuration Manager 等不同工具來完成。不過，Amazon EKS 叢集中的 Windows 節點不應視為一般 Windows 伺服器。它們應被視為不可變伺服器。簡單來說，避免更新現有的節點，只要根據新的更新 AMI 啟動新的節點即可。

使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/)，您可以透過建立配方和新增元件來自動化 AMIs 建置。

下列範例顯示**元件**，這些元件可以是由 AWS (Amazon 受管） 建置的預先存在元件，以及您建立的元件 （由我擁有）。請密切注意稱為 **update-windows** 的 Amazon 受管元件，這會在透過 EC2 Image Builder 管道產生 AMI 之前更新 Windows Server。

![\[相關聯的元件\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/associated-components.png)


EC2 Image Builder 可讓您根據 Amazon Managed Public AMI 建置 AMIs，並自訂它們以符合您的業務需求。然後，您可以將這些 AMIs 與啟動範本建立關聯，以便將新的 AMI 連結至 EKS 節點群組建立的 Auto Scaling 群組。完成後，您可以開始終止現有的 Windows 節點，並根據新的更新 AMI 啟動新的節點。

## 推送和提取 Windows 映像
<a name="_pushing_and_pulling_windows_images"></a>

Amazon 發佈 EKS 最佳化 AMIs，其中包含兩個快取的 Windows 容器映像。

```
mcr.microsoft.com/windows/servercore
mcr.microsoft.com/windows/nanoserver
```

![\[images\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/images.png)


快取映像會在主要作業系統的更新之後更新。當 Microsoft 發行直接影響 Windows 容器基礎映像的新 Windows 更新時，更新將作為主要作業系統上的一般 Windows Update 啟動。讓環境保持在up-to-date可在節點和容器層級提供更安全的環境。

Windows 容器映像的大小會影響推送/提取操作，這可能會導致容器啟動時間變慢。[快取 Windows 容器映像](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)允許在 AMI 建置建立時執行昂貴的 I/O 操作 （檔案擷取），而非容器啟動。因此，AMI 上將擷取所有必要的影像層，並準備好可供使用，以加快 Windows 容器啟動的時間，並可以開始接受流量。在推送操作期間，只會將構成映像的圖層上傳到儲存庫。

下列範例顯示 Amazon ECR 上的 **fluentd-windows-sac2004** 映像只有 **390.18MB**。這是推送操作期間發生的上傳量。

下列範例顯示推送到 Amazon ECR 儲存庫[的流暢 Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) 映像。存放在 ECR 中的 layer 大小為 **533.05MB。**

![\[ecr 映像\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/windows/ecr-image.png)


以下來自 的輸出`docker image ls`，磁碟上 Fluentd v1.14-windows-ltsc2019-1 的大小為 **6.96GB**，但這並不表示它下載並擷取了該數量的資料。

實際上，在提取操作期間，只會下載和擷取**壓縮的 533.05MB。**

```
REPOSITORY                                                              TAG                        IMAGE ID       CREATED         SIZE
111122223333.dkr.ecr.us-east-1.amazonaws.com/fluentd-windows-coreltsc   latest                     721afca2c725   7 weeks ago     6.96GB
fluent/fluentd                                                          v1.14-windows-ltsc2019-1   721afca2c725   7 weeks ago     6.96GB
amazonaws.com/eks/pause-windows                                         latest                     6392f69ae6e7   10 months ago   255MB
```

大小欄顯示影像的整體大小，6.96GB。將其分解：
+ Windows Server Core 2019 LTSC 基礎映像 = 5.74GB
+ Fluentd 未壓縮的基礎映像 = 6.96GB
+ 磁碟差異 = 1.2GB
+ Fluentd [壓縮最終映像 ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html) = 533.05MB

本機磁碟上已存在基礎映像，導致磁碟上的總量為額外 1.2GB。下次在大小欄中看到 GBs 的數量時，請不要太擔心，可能超過 70% 的 GB 已經在磁碟上做為快取的容器映像。

## 參考資料
<a name="_reference"></a>

 [使用 EC2 映像建置器和映像快取策略加速 Windows 容器啟動時間](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/) 