Translate topic section in italian language

config.toml

@@ -436,3 +436,39 @@ weight = 5
 
 [languages.zh.params]
 language_alternatives = ["en"]
+
+# Italian
+[languages.it]
+title = "Helm"
+description = "Helm - Il gestore di pacchetti Kubernetes."
+contentDir = "content/it"
+languageName = "Italiano"
+weight = 2
+
+[[languages.it.menus.main]]
+name = "Start"
+url = "/"
+weight = 1
+
+[[languages.it.menus.main]]
+name = "Documentazione"
+url = "/docs"
+weight = 2
+
+[[languages.it.menus.main]]
+name = "Charts"
+url = "https://artifacthub.io/"
+weight = 3
+
+[[languages.it.menus.main]]
+name = "Blog"
+url = "https://helm.sh/blog"
+weight = 4
+
+[[languages.it.menus.main]]
+name = "Community"
+url = "https://github.com/helm/community"
+weight = 5
+
+[languages.it.params]
+language_alternatives = ["en"]

content/it/docs/_index.md

@@ -0,0 +1,21 @@
+---
+title: "Docs Home"
+description: "Tutto quello che c'è da sapere su come è organizzata la documentazione."
+---
+
+# Benvenuto
+
+Benvenuti nella documentazione di [Helm](https://helm.sh/). Helm è il gestore di pacchetti
+per Kubernetes e si possono avere informazioni di base dettagliate nel
+[report CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/).
+
+# Come è organizzata la documentazione
+
+Helm ha molta documentazione. Una panoramica di alto livello su come è organizzata la documentazione vi aiuterà a capire dove cercare determinate cose:
+
+- I [Tutorial]({{< relref path="/docs/chart_template_guide/getting_started" lang="en" >}}) vi accompagnano attraverso una serie di passi per creare il vostro primo Chart Helm.
+  Iniziate da qui se siete alle prime armi con Helm.
+- Le [guide agli argomenti](topics) trattano gli argomenti e i concetti chiave a un livello piuttosto alto e forniscono informazioni di base e spiegazioni utili.
+- Le [Guide alla comunità]({{< relref path="/docs/community" lang="en" >}}) trattano argomenti incentrati sulla comunità di Helm.
+  Iniziate da qui se volete saperne di più sul processo di sviluppo di Helm e su come potete contribuire.
+- Le [guide how-to]({{< relref path="/docs/howto" lang="en" >}}) sono ricette. Vi guidano attraverso i passi necessari per affrontare problemi e casi d'uso chiave. Sono più avanzate dei tutorial e presuppongono una certa conoscenza del funzionamento di Helm.

content/it/docs/topics/_index.md

@@ -0,0 +1,8 @@
+---
+title: "Topics"
+weight: 3
+---
+
+# Topic Guides
+
+Qui troverete le introduzioni a tutte le parti principali di Helm che dovrete o vorrete conoscere.

content/it/docs/topics/advanced.md

@@ -0,0 +1,188 @@
+---
+title: "Tecniche Avanzate di Helm"
+description: "Spiega varie funzioni avanzate per i power user di Helm"
+aliases: ["/docs/advanced_helm_techniques"]
+weight: 9
+---
+
+Questa sezione illustra varie funzioni e tecniche avanzate di utilizzo di Helm.
+Le informazioni contenute in questa sezione sono destinate ai "power user" di Helm che desiderano
+personalizzare e manipolare in modo avanzato i Charts e le Release. Ognuna di queste funzioni avanzate comporta dei compromessi e degli avvertimenti, per cui
+ognuna di esse deve essere utilizzata con attenzione e con una conoscenza approfondita di Helm. O in altre parole,
+ricordate il [principio di Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)
+
+## Post Rendering
+Il post rendering offre agli installatori di Charts la possibilità di manipolare manualmente,
+configurare e/o convalidare i manifesti renderizzati prima che vengano installati da Helm.
+Questo permette agli utenti con esigenze di configurazione avanzate di poter usare strumenti come [`kustomize`](https://kustomize.io) per applicare le modifiche alla configurazione senza la necessità di dover fare il fork di un Chart pubblico o senza richiedere ai manutentori del Chart di specificare ogni singola opzione di
+di configurazione per un pezzo di software. Esistono anche casi d'uso per iniettare strumenti comuni e macchine secondarie in ambienti aziendali o l'analisi dei manifesi prima della distribuzione.
+
+### Prerequisiti
+- Helm 3.1+
+
+### Utilizzo
+Un post-renderer può essere un qualsiasi eseguibile che accetta manifest Kubernetes renderizzati
+su STDIN e restituisce manifest Kubernetes validi su STDOUT. Dovrebbe restituire
+un codice di uscita non-0 in caso di fallimento. Questa è l'unica "API" tra i
+due componenti. Permette una grande flessibilità in ciò che si può fare con il processo di
+post-rendering.
+
+Un post renderer può essere usato con `install`, `upgrade` e `template`. Per usare un
+post-renderer, usare il flag `--post-renderer` con il percorso del renderer
+che si desidera utilizzare:
+
+```shell
+$ helm install mychart stable/wordpress --post-renderer ./path/to/executable
+```
+
+Se il percorso non contiene separatori, la ricerca verrà effettuata in $PATH, altrimenti
+risolverà qualsiasi percorso relativo in un percorso completamente qualificato.
+
+Se si desidera utilizzare più post-renderizzatori, richiamateli tutti in uno script o
+insieme in un qualsiasi strumento binario con cui è stato implementato. In bash, questo potrebbe essere
+semplice come `renderer1 | renderer2 | renderer3`.
+
+Si può vedere un esempio di utilizzo di `kustomize` come renderizzatore di post
+[qui](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render).
+
+### Avvertenze
+Quando si usano i postrenderer, ci sono diverse cose importanti da tenere a mente.
+La più importante è che quando si usa un post renderer, tutte le persone che modificano quella release **DOVREBBERO** usare lo stesso renderizzatore per poter essere
+ripetibili. Questa caratteristica è stata costruita appositamente per consentire a qualsiasi utente di
+cambiare il renderer che sta utilizzando o di smettere di usare un renderer, ma questo
+dovrebbe essere fatto deliberatamente per evitare modifiche accidentali o perdite di dati.
+
+Un'altra nota importante riguarda la sicurezza. Se si usa un post-renderer, bisogna assicurarsi che provenga da una fonte affidabile (come nel caso di qualsiasi altro eseguibile arbitrario
+). L'uso di renderizzatori non affidabili o non verificati NON è raccomandato, in quanto hanno pieno accesso ai modelli renderizzati, che spesso contengono dati
+dati segreti.
+
+### Post renderer personalizzati
+La fase di post renderer offre una flessibilità ancora maggiore se utilizzata con l'SDK Go. Ogni post renderer deve solo implementare la seguente interfaccia di Go:
+
+```go
+type PostRenderer interface {
+    // Run expects a single buffer filled with Helm rendered manifests. It
+    // expects the modified results to be returned on a separate buffer or an
+    // error if there was an issue or failure while running the post render step
+    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
+}
+```
+
+Per ulteriori informazioni sull'uso di Go SDK, vedere la sezione [Go SDK](#go-sdk).
+
+## Go SDK
+Helm 3 ha presentato un SDK per Go completamente ristrutturato per una migliore esperienza nella
+di creazione di software e strumenti che sfruttano Helm. La documentazione completa è disponibile
+all'indirizzo [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), ma
+una breve panoramica di alcuni dei pacchetti più comuni e di un semplice esempio qui di seguito.
+
+### Package overview
+Questo è un elenco dei pacchetti più comunemente utilizzati, con una semplice spiegazione di ciascuno di essi: 
+
+- `pkg/action`: Contiene il "client" principale per eseguire le azioni di Helm. Questo è lo stesso pacchetto che la CLI utilizza sotto il cofano. Se si ha solo bisogno di eseguire comandi di Helm base da un altro programma Go, questo pacchetto fa al caso vostro.
+- `pkg/{chart,chartutil}`: Metodi e helper utilizzati per caricare e manipolare i chart.
+- `pkg/cli` e i suoi sottopacchetti: Contiene tutti i gestori per le variabili d'ambiente standard di Helm e i suoi sottopacchetti contenenti file di output e di values
+- `pkg/release`: Definisce l'oggetto `Release` e i suoi stati.
+
+Ovviamente ci sono molti altri pacchetti oltre a questi, quindi date un'occhiata alla documentazione per maggiori informazioni!
+### Simple example
+Questo è un semplice esempio di come fare `helm list` usando l'SDK di Go:
+
+```go
+package main
+
+import (
+    "log"
+    "os"
+
+    "helm.sh/helm/v3/pkg/action"
+    "helm.sh/helm/v3/pkg/cli"
+)
+
+func main() {
+    settings := cli.New()
+
+    actionConfig := new(action.Configuration)
+    // You can pass an empty string instead of settings.Namespace() to list
+    // all namespaces
+    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil {
+        log.Printf("%+v", err)
+        os.Exit(1)
+    }
+
+    client := action.NewList(actionConfig)
+    // Only list deployed
+    client.Deployed = true
+    results, err := client.Run()
+    if err != nil {
+        log.Printf("%+v", err)
+        os.Exit(1)
+    }
+
+    for _, rel := range results {
+        log.Printf("%+v", rel)
+    }
+}
+
+```
+
+## Supporti di archiviazione
+
+Helm 3 ha cambiato la memorizzazione predefinita delle informazioni sul rilascio in Segreti nello spazio dei nomi della release.
+Helm 2 per impostazione predefinita memorizza le informazioni di rilascio come ConfigMaps nello spazio dei nomi dell'istanza di Tiller. Le sottosezioni che seguono
+mostrano come configurare i diversi backend. Questa configurazione si basa sul parametro
+variabile d'ambiente `HELM_DRIVER`. Può essere impostata su uno dei valori:
+`[configmap, secret, sql]`.
+
+### ConfigMap storage backend
+
+Per abilitare il backend ConfigMap, è necessario impostare la variabile d'ambiente
+`HELM_DRIVER` a `configmap`.
+
+Si può impostare in una shell come segue:
+
+```shell
+export HELM_DRIVER=configmap
+```
+
+Se si vuole passare dallo storage predefinito a quello di ConfigMap, si dovrà fare la migrazione per conto proprio. È possibile recuperare le informazioni sul rilascio con il seguente comando:
+
+```shell
+kubectl get secret --all-namespaces -l "owner=helm"
+```
+
+**NOTE DI PRODUZIONE**: Le informazioni di rilascio includono i contenuti dei charts e dei file di values, e quindi potrebbero contenere dati sensibili (come password, chiavi private e altre credenziali) che devono essere protetti dall'accesso non autorizzato. Quando si gestisce l'autorizzazione di Kubernetes, ad esempio con
+[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), è possibile concedere un accesso più ampio alle risorse ConfigMap, mentre si limita l'accesso alle risorse Secret.
+Ad esempio, il ruolo predefinito [user-facing
+utente](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
+"view" garantisce l'accesso alla maggior parte delle risorse, ma non ai segreti. Inoltre, i dati dei segreti
+possono essere configurati per [archiviazione criptata](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).
+Tenere presente questo aspetto se si decide di passare al backend ConfigMap, perché potrebbe esporre i dati sensibili dell'applicazione.
+
+### SQL storage backend
+
+Esiste un backend di archiviazione SQL in ***beta*** che memorizza le informazioni di rilascio in un database SQL.
+
+L'uso di un backend di memorizzazione di questo tipo è particolarmente utile se le informazioni sul rilascio pesano più di 1 MB (in tal caso, non possono essere memorizzate in ConfigMaps/Secrets a causa dei limiti interni dell'archivio di valori chiave etcd di Kubernetes).
+
+Per abilitare il backend SQL, è necessario distribuire un database SQL e impostare la variabile d'ambiente `HELM_DRIVER` a `sql`. I dettagli del DB sono impostati con la variabile d'ambiente `HELM_DRIVER_SQL_CONNECTION_STRING`.
+
+È possibile impostarla in una shell come segue:
+
+```shell
+export HELM_DRIVER=sql
+export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme
+```
+
+> Note: Solo PostgreSQL è supportato al momento.
+
+**NOTE DI PRODUZIONE**: Si consiglia di:
+- Preparare il database alla produzione. Per PostgreSQL, consultare i documenti di [Server Administration](https://www.postgresql.org/docs/12/admin.html) per maggiori dettagli. 
+- Abilitare la [gestione dei permessi](/docs/permissions_sql_storage_backend/) per
+rispecchiare Kubernetes RBAC per le informazioni di rilascio
+
+Se si vuole passare dal backend predefinito al backend SQL, si dovrà fare la migrazione per conto proprio. È possibile recuperare le informazioni sul rilascio con il seguente comando:
+
+```shell
+kubectl get secret --all-namespaces -l "owner=helm"
+```

content/it/docs/topics/architecture.md

@@ -0,0 +1,59 @@
+---
+title: "Architettura di Helm"
+description: "Descrive l'architettura di Helm ad alto livello."
+aliases: ["/docs/architecture/"]
+weight: 8
+---
+
+# Architettura di Helm
+
+Questo documento descrive l'architettura di Helm ad alto livello.
+
+## Lo scopo di Helm
+
+Helm è uno strumento per la gestione dei pacchetti Kubernetes chiamati _charts_. Helm può fare quanto segue:
+
+- Creare nuovi chart da zero
+- pacchettizzare i chart in archivi (tgz)
+- Interagire con i repository dei chart, dove questi sono memorizzati
+- installare e disinstallare chart in un cluster Kubernetes esistente
+- Gestire il ciclo di rilascio dei chart installati con Helm.
+
+Per Helm, ci sono tre concetti importanti:
+
+1. Il _chart_ è un insieme di informazioni necessarie per creare un'istanza di un'applicazione Kubernetes.
+2. Il _config_ contiene informazioni di configurazione che possono essere unite in un chart impacchettato per creare un oggetto rilasciabile.
+3. Una _release_ è un'istanza in esecuzione di un _chart_, combinato con una specifica
+   _config_.
+
+## Componenti
+
+Helm è un eseguibile implementato in due parti distinte:
+
+Il **Client Helm** è un client a riga di comando per gli utenti finali. Il client è
+responsabile di quanto segue:
+
+- Sviluppo del chart locale
+- Gestione dei repository
+- Gestione dei rilasci
+- Interfacciamento con la libreria Helm
+  - Invio di chart da installare
+  - Richiedere l'aggiornamento o la disinstallazione di release esistenti.
+
+La **Libreria Helm** fornisce la logica per l'esecuzione di tutte le operazioni di Helm. Si
+si interfaccia con il server API di Kubernetes e fornisce le seguenti funzionalità:
+
+- Combinazione di un chart e di una configurazione per costruire un rilascio.
+- Installazione dei chart in Kubernetes e fornitura del successivo oggetto di rilascio.
+- Aggiornamento e disinstallazione dei chart interagendo con Kubernetes.
+
+La libreria Helm standalone incapsula la logica Helm in modo che possa essere sfruttata da diversi client.
+
+## Implementazione
+
+Il client e la libreria Helm sono scritti nel linguaggio di programmazione Go.
+
+La libreria utilizza il client Kubernetes per comunicare con Kubernetes.
+Attualmente, questa libreria utilizza REST+JSON. Memorizza le informazioni in Secrets situatiall'interno di Kubernetes. Non ha bisogno di un proprio database.
+
+I file di configurazione sono, quando possibile, scritti in YAML.