

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Applicazione di patch a server e contenitori Windows
<a name="windows-patching"></a>

L'applicazione di patch a Windows Server è un'attività di gestione standard per gli amministratori di Windows. Ciò può essere ottenuto utilizzando diversi strumenti come Amazon System Manager - Patch Manager, WSUS, System Center Configuration Manager e molti altri. Tuttavia, i nodi Windows in un cluster Amazon EKS non devono essere trattati come normali server Windows. Devono essere trattati come server immutabili. In poche parole, evita di aggiornare un nodo esistente, basta avviarne uno nuovo basato su una nuova AMI aggiornata.

Utilizzando [EC2 Image](https://aws.amazon.com/image-builder/) Builder puoi automatizzare la creazione di AMI, creando ricette e aggiungendo componenti.

L'esempio seguente mostra **i componenti**, che possono essere preesistenti creati da AWS (Amazon-managed) e i componenti creati dall'utente (Owned by me). Presta molta attenzione al Amazon-managed componente chiamato **update-windows, che aggiorna Windows** Server prima di generare l'AMI tramite la pipeline EC2 Image Builder.

![componenti associati](http://docs.aws.amazon.com/it_it/eks/latest/best-practices/images/windows/associated-components.png)


EC2 Image Builder ti consente di creare AMI basate su AMI pubbliche gestite da Amazon e personalizzarle per soddisfare i tuoi requisiti aziendali. È quindi possibile associare tali AMI a Launch Templates che consentono di collegare una nuova AMI all'Auto Scaling Group creato da EKS Nodegroup. Al termine, puoi iniziare a terminare i nodi Windows esistenti e ne verranno lanciati di nuovi in base alla nuova AMI aggiornata.

## Spingere e tirare immagini Windows
<a name="_pushing_and_pulling_windows_images"></a>

Amazon pubblica AMI ottimizzate per EKS che includono due immagini di container Windows memorizzate nella cache.

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

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


Le immagini memorizzate nella cache vengono aggiornate in seguito agli aggiornamenti sul sistema operativo principale. Quando Microsoft rilascia un nuovo aggiornamento di Windows che influisce direttamente sull'immagine base del contenitore Windows, l'aggiornamento verrà avviato come un normale Windows Update sul sistema operativo principale. Mantenere l'ambiente aggiornato offre un ambiente più sicuro a livello di nodo e contenitore.

Le dimensioni dell'immagine di un contenitore Windows influiscono push/pull sulle operazioni e possono rallentare i tempi di avvio del contenitore. La [memorizzazione nella cache delle immagini dei contenitori Windows](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/) consente di I/O eseguire operazioni costose (estrazione dei file) sulla creazione della build AMI anziché sull'avvio del contenitore. Di conseguenza, tutti i livelli di immagine necessari verranno estratti dall'AMI e saranno pronti per essere utilizzati, accelerando il tempo di avvio di un contenitore Windows e la possibilità di iniziare ad accettare traffico. Durante un'operazione push, nel repository vengono caricati solo i livelli che compongono l'immagine.

**L'esempio seguente mostra che su Amazon ECR le immagini **fluentd-windows-sac2004** hanno solo 390,18 MB.** Questa è la quantità di upload avvenuta durante l'operazione push.

L'esempio seguente mostra un'immagine [fluentd Windows ltsc](https://github.com/fluent/fluentd-docker-image/blob/master/v1.14/windows-ltsc2019/Dockerfile) inviata a un repository Amazon ECR. **La dimensione del layer memorizzato in ECR è 533,05 MB.**

![immagine ecr](http://docs.aws.amazon.com/it_it/eks/latest/best-practices/images/windows/ecr-image.png)


L'output seguente di`docker image ls`, la dimensione del fluentd v1.14-windows-ltsc2019-1 è di **6,96 GB** su disco, ma ciò non significa che abbia scaricato ed estratto quella quantità di dati.

**In pratica, durante l'operazione pull verranno scaricati ed estratti solo i 533,05 MB compressi.**

```
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
```

La colonna delle dimensioni mostra la dimensione complessiva dell'immagine, 6,96 GB. Scomponendolo:
+ Immagine di base LTSC di Windows Server Core 2019 = 5,74 GB
+ Immagine di base non compressa Fluentd = 6,96 GB
+ Differenza su disco = 1,2 GB
+ Immagine finale [compressa Fluentd ECR = 533,05 MB](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-info.html)

L'immagine di base esiste già sul disco locale, per cui la quantità totale su disco è di 1,2 GB aggiuntivi. La prossima volta che vedrai la quantità di GB nella colonna delle dimensioni, non preoccuparti troppo, probabilmente più del 70% è già presente su disco come immagine del contenitore memorizzata nella cache.

## Documentazione di riferimento
<a name="_reference"></a>

 [Accelerazione dei tempi di avvio dei container Windows con EC2 Image Builder e la strategia Image Cache](https://aws.amazon.com/blogs/containers/speeding-up-windows-container-launch-times-with-ec2-image-builder-and-image-cache-strategy/) 