From a71ba8d63b82fe93959a63661ac1bb20d6209efc Mon Sep 17 00:00:00 2001 From: alessandroargentieri Date: Thu, 8 Apr 2021 19:31:43 +0200 Subject: [PATCH] #20959 Localize Images page to Italian --- content/it/docs/concepts/containers/images.md | 316 ++++++++++++++++++ 1 file changed, 316 insertions(+) create mode 100644 content/it/docs/concepts/containers/images.md diff --git a/content/it/docs/concepts/containers/images.md b/content/it/docs/concepts/containers/images.md new file mode 100644 index 0000000000..43fe439ee0 --- /dev/null +++ b/content/it/docs/concepts/containers/images.md @@ -0,0 +1,316 @@ +--- +title: Immagini +content_type: concept +weight: 10 +--- + + + +L'immagine di un container rappresenta dati binari che incapsulano un'applicazione e +tutte le sue dipendenze software. Le immagini sono costituite da pacchetti software +eseguibili che possono essere avviati in modalità standalone e su cui si possono fare +ipotesi ben precise circa l'ambiente in cui vengono eseguiti. + +Tipicamente viene creata un'immagine di un'applicazione ed effettuato il _push_ +su un registry (un repository pubblico di immagini) prima di poterne fare riferimento esplicito in un +{{< glossary_tooltip text="Pod" term_id="pod" >}} + +Questa pagina va a delineare nello specifico il concetto di immagine di un container. + + + +## I nomi delle immagini + +Alle immagini dei container vengono normalmente attribuiti nomi come `pause`, `example/mycontainer`, o `kube-apiserver`. +Le immagini possono anche contenere l'hostname del registry in cui le immagini sono pubblicate; +ad esempio: `registro.fittizio.esempio/nomeimmagine`, +ed è possibile che sia incluso nel nome anche il numero della porta; ad esempio: `registro.fittizio.esempio:10443/nomeimmagine`. + +Se non si specifica l'hostname di un registry, Kubernetes assume che ci si riferisca al registry pubblico di Docker. + +Dopo la parte relativa al nome dell'immagine si può aggiungere un _tag_ (come comunemente avviene per comandi come `docker` e `podman`). +I tag permettono l'identificazione di differenti versioni della stessa serie di immagini. + +I tag delle immagini sono composti da lettere minuscole e maiuscole, numeri, underscore (`_`), +punti (`.`), e trattini (`-`). +Esistono regole aggiuntive relative a dove i caratteri separatori (`_`, `-`, and `.`) +possano essere inseriti nel tag di un'immagine. +Se non si specifica un tag, Kubernetes assume il tag `latest` che va a definire l'immagine disponibile più recente. + +{{< caution >}} +Evitate di utilizzare il tag `latest` quando si rilasciano dei container in produzione, +in quanto risulta difficile tracciare quale versione dell'immagine sia stata avviata e persino più difficile +effettuare un rollback ad una versione precente. + +Invece, meglio specificare un tag specifico come ad esempio `v1.42.0`. +{{< /caution >}} + +## Aggiornamento delle immagini + +Quando un {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod, o qualsiasi altro +oggetto che includa un Pod template viene creato per la prima volta, la policy di default per il pull di tutti i container nel Pod +è impostata su `IfNotPresent` (se non presente) se non specificato diversamente. +Questa policy permette al +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} di evitare di fare il pull +di un'immagine se questa è già presente. + +Se necessario, si può forzare il pull in ogni occasione in uno dei seguenti modi: + +- impostando `imagePullPolicy` (specifica per il pull delle immagini) del container su `Always` (sempre). +- omettendo `imagePullPolicy` ed usando il tag `:latest` (più recente) per l'immagine da utilizzare; + Kubernetes imposterà la policy su `Always` (sempre). +- omettendo `imagePullPolicy` ed il tag per l'immagine da utilizzare. +- abilitando l'admission controller [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages). + +{{< note >}} +Il valore dell'impostazione `imagePullPolicy` del container è sempre presente quando l'oggetto viene creato per la prima volta +e non viene aggiornato se il tag dell'immagine dovesse cambiare successivamente. + +Ad esempio, creando un Deployment con un'immagine il cui tag _non_ è +`:latest`, e successivamente aggiornando il tag di quell'immagine a `:latest`, il campo + `imagePullPolicy` _non_ cambierà su `Always`. +È necessario modificare manualmente la policy di pull di ogni oggetto dopo la sua creazione. +{{< /note >}} + +Quando `imagePullPolicy` è definito senza un valore specifico, esso è impostato su `Always`. + +## Multi-architecture support nelle immagini + +Oltre a fornire immagini binarie, un _container registry_ può fornire un [indice delle immagini disponibili per un container](https://github.com/opencontainers/image-spec/blob/master/image-index.md). +L'indice di un'immagine può puntare a più [file manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) ciascuno per una versione specifica dell'architettura di un container. +L'idea è che si può avere un unico nome per una stessa immagine (ad esempio: `pause`, `example/mycontainer`, `kube-apiserver`) e permettere a diversi sistemi di recuperare l'immagine binaria corretta a seconda dell'architettura della macchina che la sta utilizzando. + + +Kubernetes stesso tipicamente nomina le immagini dei container tramite il suffisso `-$(ARCH)`. +Per la garantire la retrocompatibilità è meglio generare le vecchie immagini con dei suffissi. +L'idea è quella di generare, ad esempio, l'immagine `pause` con un manifest che include tutte le architetture supportate, +affiancata, ad esempio, da `pause-amd64` che è retrocompatibile per le vecchie configurazioni o per quei file YAML +in cui sono specificate le immagini con i suffissi. + +## Utilizzare un private registry + +I private registry possono richiedere l'utilizzo di chiavi per accedere alle immagini in essi contenute. +Le credenziali possono essere fornite in molti modi: + - configurando i nodi in modo tale da autenticarsi al private registry + - tutti i pod possono acquisire informazioni da qualsiasi private registry configurato + - è necessario che l'amministratore del cluster configuri i nodi in tal senso + - tramite pre-pulled images (immagini pre-caricate sui nodi) + - tutti i pod possono accedere alle immagini salvate sulla cache del nodo a cui si riferiscono + - è necessario effettuare l'accesso come root di sistema su ogni nodo per inserire questa impostazione + - specificando _ImagePullSecrets_ su un determinato pod + - solo i pod che forniscono le proprie chiavi hanno la possibilità di accedere al private registry + - tramite estensioni locali o specifiche di un _Vendor_ + - se si sta utilizzando una configurazione personalizzata del nodo oppure se manualmente, o tramite il _cloud provider_, + si implementa un meccanismo di autenticazione del nodo presso il _container registry_. + +Di seguito la spiegazione dettagliata di queste opzioni. + +### Configurazione dei nodi per l'autenticazione ad un private registry + +Se si sta utilizzando Docker sui nodi, si può configurare il _Docker container runtime_ +per autenticare il nodo presso un private container registry. + +Questo è un approccio possibile se si ha il controllo sulle configurazioni del nodo. + +{{< note >}} +Kubernetes di default supporta solo le sezioni `auths` e `HttpHeaders` nelle configurazioni relative a Docker. +Eventuali _helper_ per le credenziali di Docker (`credHelpers` o `credsStore`) non sono supportati. +{{< /note >}} + + +Docker salva le chiavi per i registri privati in `$HOME/.dockercfg` oppure nel file `$HOME/.docker/config.json`. +Inserendo lo stesso file nella lista seguente, kubelet lo utilizzerà per recuperare le credenziali quando deve fare il _pull_ delle immagini. + +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` + +{{< note >}} +Potrebbe essere necessario impostare `HOME=/root` esplicitamente come variabile d'ambiente del processo _kubelet_. +{{< /note >}} + +Di seguito i passi consigliati per configurare l'utilizzo di un private registry da parte dei nodi del _cluster_. +In questo esempio, eseguire i seguenti comandi sul proprio desktop/laptop: + + 1. Esegui `docker login [server]` per ogni _set_ di credenziali che vuoi utilizzare. Questo comando aggiornerà `$HOME/.docker/config.json` sul tuo PC. + 1. Controlla il file `$HOME/.docker/config.json` in un editor di testo per assicurarti che contenga le credenziali che tu voglia utilizzare. + 1. Recupera la lista dei tuoi nodi; ad esempio: + - se vuoi utilizzare i nomi: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - se vuoi recuperare gli indirizzi IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` + 1. Copia il tuo file locale `.docker/config.json` in uno dei path sopra riportati nella lista di ricerca. + - ad esempio, per testare il tutto: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + +{{< note >}} +Per i cluster di produzione, utilizza un configuration management tool per poter applicare le impostazioni su tutti i nodi laddove necessario. +{{< /note >}} + +Puoi fare una verifica creando un Pod che faccia uso di un'immagine privata; ad esempio: + +```shell +kubectl apply -f - <}} +Questo approccio è possibile se si ha il controllo sulla configurazione del nodo. +Non funzionerà qualora il cloud provider gestisca i nodi e li sostituisca automaticamente. +{{< /note >}} + +Kubelet di default prova a fare il pull di ogni immagine dal registry specificato. +Tuttavia, qualora la proprietà `imagePullPolicy` (specifica di pull dell'immagine) del container sia impostata su `IfNotPresent` (vale a dire, se non è già presente) oppure su `Never` (mai), +allora l'immagine locale è utilizzata (in via preferenziale o esclusiva, rispettivamente). + +Se si vuole fare affidamento a immagini pre-scaricate per non dover incorrere in una fase di autenticazione presso il registry, +bisogna assicurarsi che tutti i nodi nel cluster abbiano scaricato le stesse versioni delle immagini. + +Questa procedura può essere utilizzata per accelerare il processo di creazione delle istanze o come alternativa all'autenticazione presso un private registry. + +Tutti i pod avranno accesso in lettura a qualsiasi immagine pre-scaricata. + +### Specificare la proprietà imagePullSecrets su un Pod + +{{< note >}} +Questo approccio è quello consigliato per l'avvio di container a partire da immagini presenti in registri privati. +{{< /note >}} + +Kubernetes da la possibilità di specificare le chiavi del _container registry_ su un Pod. + +#### Creare un Secret tramite Docker config + +Esegui il comando seguente, sostituendo i valori riportati in maiuscolo con quelli corretti: + +```shell +kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL +``` + +Se possiedi il file delle credenziali per Docker, anziché utilizzare il comando quì sopra +puoi importare il file di credenziali come un Kubernetes +{{< glossary_tooltip text="Secrets" term_id="secret" >}}. +[Creare un Secret a partire da credenziali Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) fornisce la spiegazione dettagliata su come fare. + +Ciò è particolarmente utile se si utilizzano più _container registry_ privati, +in quanto il comando `kubectl create secret docker-registry` genera un Secret che +funziona con un solo private registry. + +{{< note >}} +I Pod possono fare riferimento ai Secret per il pull delle immagini soltanto nel proprio _namespace_, +quindi questo procedimento deve essere svolto per ogni _namespace_. +{{< /note >}} + +#### Fare riferimento ad imagePullSecrets in un Pod + +È possibile creare pod che referenzino quel Secret aggiungendo la sezione `imagePullSecrets` alla definizione del Pod. + +Ad esempio: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Questo deve esser fatto per ogni Pod che utilizzi un private registry. + +Comunque, le impostazioni relative a questo campo possono essere automatizzate inserendo la sezione _imagePullSecrets_ +nella definizione della risorsa [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/). + +Visitare la pagina [Aggiungere ImagePullSecrets ad un Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) per istruzioni più dettagliate. + +Puoi utilizzarlo in congiunzione al file `.docker/config.json` configurato per ogni nodo. In questo caso, si applicherà un _merge_ delle credenziali. + +## Casi d'uso + +Ci sono varie soluzioni per configurare i private registry. Di seguito, alcuni casi d'uso comuni e le soluzioni suggerite. + +1. Cluster in cui sono utilizzate soltanto immagini non proprietarie (ovvero _open-source_). In questo caso non sussiste il bisogno di nascondere le immagini. + - Utilizza immagini pubbliche da Docker hub. + - Nessuna configurazione richiesta. + - Alcuni _cloud provider_ mettono in _cache_ o effettuano il _mirror_ di immagini pubbliche, il che migliora la disponibilità delle immagini e ne riduce il tempo di _pull_. +1. Cluster con container avviati a partire da immagini proprietarie che dovrebbero essere nascoste a chi è esterno all'organizzazione, ma + visibili a tutti gli utenti abilitati nel cluster. + - Utilizza un private [Docker registry](https://docs.docker.com/registry/). + - Esso può essere ospitato da [Docker Hub](https://hub.docker.com/signup), o da qualche altra piattaforma. + - Configura manualmente il file .docker/config.json su ogni nodo come descritto sopra. + - Oppure, avvia un private registry dietro il tuo firewall con accesso in lettura libero. + - Non è necessaria alcuna configurazione di Kubernetes. + - Utilizza un servizio di _container registry_ che controlli l'accesso alle immagini + - Esso funzionerà meglio con una configurazione del cluster basata su _autoscaling_ che con una configurazione manuale del nodo. + - Oppure, su un cluster dove la modifica delle configurazioni del nodo non è conveniente, utilizza `imagePullSecrets`. +1. Cluster con immagini proprietarie, alcune delle quali richiedono un controllo sugli accessi. + - Assicurati che l'_admission controller_ [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod potenzialmente possono avere accesso a tutte le immagini. + - Sposta i dati sensibili un un _Secret_, invece di inserirli in un'immagine. +1. Un cluster multi-tenant dove ogni tenant necessiti di un private registry. + - Assicurati che l'_admission controller_ [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod di tutti i tenant potrebbero potenzialmente avere accesso a tutte le immagini. + - Avvia un private registry che richieda un'autorizzazione all'accesso. + - Genera delle credenziali di registry per ogni tenant, inseriscile in dei _Secret_, e popola i _Secret_ per ogni _namespace_ relativo ad ognuno dei tenant. + - Il singolo tenant aggiunge così quel _Secret_ all'impostazione _imagePullSecrets_ di ogni _namespace_. + + +Se si ha la necessità di accedere a più registri, si può generare un _Secret_ per ognuno di essi. +Kubelet farà il _merge_ di ogni `imagePullSecrets` in un singolo file virtuale `.docker/config.json`. + +## {{% heading "whatsnext" %}} + +* Leggi [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) \ No newline at end of file