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
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 è AMIs possibile automatizzare la compilazione, creando ricette e aggiungendo componenti.
L'esempio seguente mostra **i componenti**, che possono essere preesistenti creati da AWS (gestiti da Amazon) e i componenti creati da te (di mia proprietà). Presta particolare attenzione al componente gestito da Amazon 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 Amazon AMIs Managed Public e personalizzarle per soddisfare i tuoi requisiti aziendali. Puoi quindi AMIs associarli a Launch Templates che ti 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
Amazon pubblica EKS ottimizzato AMIs che include 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 up-to-date offre un ambiente più sicuro a livello di nodo e contenitore.
Le dimensioni dell'immagine di un contenitore Windows influiscono push/pull sulle operazioni, il che può 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 del **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 vedrete la quantità di GBs nella colonna delle dimensioni, non preoccupatevi troppo, probabilmente più del 70% è già presente su disco come immagine del contenitore memorizzata nella cache.
## Documentazione di riferimento
[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/)