翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Windows サーバーとコンテナへのパッチ適用
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/ja_jp/eks/latest/best-practices/images/windows/associated-components.png)
EC2 Image Builder を使用すると、Amazon Managed Public AMI に基づいて AMIs、ビジネス要件を満たすようにカスタマイズできます。その後、これらの AMIs を起動テンプレートに関連付けることができます。これにより、新しい AMI を EKS ノードグループによって作成された Auto Scaling グループにリンクできます。これが完了したら、既存の Windows ノードの終了を開始できます。新しい Windows ノードは、新しく更新された AMI に基づいて起動されます。
## Windows イメージのプッシュとプル
Amazon は、キャッシュされた 2 つの Windows コンテナイメージを含む EKS 最適化 AMIs を公開します。
```
mcr.microsoft.com/windows/servercore
mcr.microsoft.com/windows/nanoserver
```
![\[画像\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/windows/images.png)
キャッシュされたイメージは、メイン OS の更新後に更新されます。Microsoft が Windows コンテナベースイメージに直接影響する新しい Windows 更新プログラムをリリースすると、その更新プログラムはメイン OS で通常の Windows 更新プログラムとして起動されます。環境を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.18 MB** のみであることを示しています。これは、プッシュオペレーション中に発生したアップロードの量です。
次の例は、Amazon ECR リポジトリにプッシュされた[流暢な Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) イメージを示しています。ECR に保存されるレイヤーのサイズは **533.05 MB** です。
![\[ECR イメージ\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/windows/ecr-image.png)
以下の からの出力では`docker image ls`、fluentd v1.14-windows-ltsc2019-1 のサイズはディスクで **6.96 GB** ですが、その量のデータをダウンロードして抽出したわけではありません。
実際には、プルオペレーション中に**圧縮された 533.05 MB** のみがダウンロードおよび抽出されます。
```
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.96 GB が表示されます。内訳:
+ Windows Server Core 2019 LTSC ベースイメージ = 5.74 GB
+ Fluentd 非圧縮ベースイメージ = 6.96 GB
+ ディスクの差 = 1.2 GB
+ Fluentd [圧縮最終イメージ ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html) = 533.05 MB
ベースイメージはローカルディスクに既に存在するため、ディスクの合計容量は 1.2 GB 増加します。次回サイズ列に GBs の量が表示されるときは、心配しすぎないでください。70% 以上がキャッシュされたコンテナイメージとしてディスクに既に存在する可能性があります。
## リファレンス
[EC2 Image Builder とイメージキャッシュ戦略を使用して Windows コンテナの起動時間を短縮する](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/)