Translate topic in IT language

docusaurus.config.js

@@ -49,7 +49,7 @@ const config = {
 
   i18n: {
     defaultLocale: "en",
-    locales: ["en", "de", "el", "es", "fr", "ja", "ko", "pt", "ru", "uk", "zh"],
+    locales: ["en", "de", "el", "es", "fr", "it", "ja", "ko", "pt", "ru", "uk", "zh"],
     localeConfigs: {
       en: {
         htmlLang: "en-us",
@@ -64,6 +64,9 @@ const config = {
       fr: {
         label: "Français (French)",
       },
+      it: {
+        label: "Italiano (Italian)",
+      },
       el: {
         label: "Ελληνικά (Greek)",
       },

i18n/it/docusaurus-plugin-content-blog/options.json

@@ -0,0 +1,14 @@
+{
+  "title": {
+    "message": "Blog",
+    "description": "The title for the blog used in SEO"
+  },
+  "description": {
+    "message": "Blog",
+    "description": "The description for the blog used in SEO"
+  },
+  "sidebar.title": {
+    "message": "Tutti i post",
+    "description": "The label for the left sidebar"
+  }
+}

i18n/it/docusaurus-plugin-content-docs/current.json

@@ -0,0 +1,6 @@
+{
+  "version.label": {
+    "message": "4.0.0-beta.1 🚧",
+    "description": "The label for version current"
+  }
+}

i18n/it/docusaurus-plugin-content-docs/version-2.json

@@ -0,0 +1,26 @@
+{
+  "version.label": {
+    "message": "2.17.0",
+    "description": "The label for version 2"
+  },
+  "sidebar.tutorialSidebar.category.Using Helm": {
+    "message": "Usa Helm",
+    "description": "The label for category Using Helm in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Helm Commands": {
+    "message": "Comandi Helm",
+    "description": "The label for category Helm Commands in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Charts": {
+    "message": "Charts",
+    "description": "The label for category Charts in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Developing Templates": {
+    "message": "Sviluppa Templates",
+    "description": "The label for category Developing Templates in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Best Practices": {
+    "message": "Best Practices",
+    "description": "The label for category Best Practices in sidebar tutorialSidebar"
+  }
+}

i18n/it/docusaurus-plugin-content-docs/version-3.json

@@ -0,0 +1,42 @@
+{
+  "version.label": {
+    "message": "3.19.0",
+    "description": "The label for version 3"
+  },
+  "sidebar.tutorialSidebar.category.Introduction": {
+    "message": "Introduzione",
+    "description": "The label for category Introduction in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.How-to": {
+    "message": "How-to",
+    "description": "The label for category How-to in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Topics": {
+    "message": "Topics",
+    "description": "The label for category Topics in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Best Practices": {
+    "message": "Best Practices",
+    "description": "The label for category Best Practices in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Chart Template Guide": {
+    "message": "Guida ai Chart Template",
+    "description": "The label for category Chart Template Guide in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Helm Commands": {
+    "message": "Comandi Helm",
+    "description": "The label for category Helm Commands in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Go SDK": {
+    "message": "Go SDK",
+    "description": "The label for category Go SDK in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Community": {
+    "message": "Community",
+    "description": "The label for category Community in sidebar tutorialSidebar"
+  },
+  "sidebar.tutorialSidebar.category.Frequently Asked Questions": {
+    "message": "Frequently Asked Questions",
+    "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar"
+  }
+}

i18n/it/docusaurus-plugin-content-docs/version-3/index.mdx

@@ -0,0 +1,31 @@
+---
+title: “Inizio della documentazione”
+description: “Tutto quello che c'è da sapere su come è organizzata questa documentazione.”
+---
+
+# Benvenuto
+
+Benvenuto nella documentazione di [Helm](https://helm.sh/). Helm è un gestore di
+pacchetti per Kubernetes. Per ulteriori informazioni sul contesto dettagliato, consulta il
+[rapporto sul percorso del progetto Helm
+alla CNCF](https://www.cncf.io/cncf-helm-project-journey/).
+
+# Come è organizzata questa documentazione?
+
+Helm ha una vasta documentazione. Una panoramica di alto livello su come è organizzata
+ti aiuterà a capire dove cercare determinate informazioni:
+
+- I [tutorial](/intro/index.mdx) ti guidano passo dopo passo nella creazione del
+  tuo primo Chart in Helm. Inizia da qui se sei nuovo in Helm.
+- [Guide tematiche](/topics/index.mdx) trattano gli argomenti e i concetti principali ad alto livello,
+  oltre a fornire contesto e spiegazioni utili su Helm.
+- Le [Guide della comunità](/community/index.mdx) trattano argomenti incentrati sulla
+  comunità Helm. Inizia da qui se desideri informarti sul
+  processo di sviluppo di Helm stesso e su come contribuire al progetto.
+- [Guide pratiche](/howto/index.mdx) sono ricette pronte all'uso. Ti guidano attraverso i passaggi
+  necessari per risolvere i principali problemi e casi d'uso. Sono più avanzate
+  dei tutorial e richiedono una conoscenza preliminare del funzionamento di Helm.
+
+import DocCardList from '@theme/DocCardList';
+
+<DocCardList />

i18n/it/docusaurus-plugin-content-docs/version-3/topics/advanced.md

@@ -0,0 +1,146 @@
+---
+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
+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.
+
+## Storage backends
+
+Helm 3 ha cambiato il default in cui memorizzare le informazioni sul rilascio in Secrets nel namespace della release. Helm 2 per impostazione predefinita memorizza le informazioni della release in
+ConfigMaps nel namespace dell'istanza di Tiller. Le sottosezioni che seguono
+mostrano come configurare i diversi backend. Questa configurazione si basa sulla 
+variabile d'ambiente `HELM_DRIVER`. Può essere impostata su uno dei valori:
+`[configmap, secret, sql]`.
+
+###  Storage backend ConfigMap
+
+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 dal backend predefinito a quello ConfigMap, si 
+dovrà fare la migrazione autonomamente. È possibile recuperare le informazioni sulla release
+con il seguente comando:
+
+```shell
+kubectl get secret --all-namespaces -l “owner=helm”
+```
+
+**NOTE DI PRODUZIONE**: Le informazioni sulla release includono il contenuto dei chart e dei values file, 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 Secret. Inoltre, i dati dei Secret
+possono essere configurati per [archiviazione criptata](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).
+Si tenga presente questo aspetto se si decide di passare al backend ConfigMap, perché potrebbe esporre i dati sensibili dell'applicazione.
+
+### Storage backend SQL
+
+Esiste uno storage backend SQL ***beta*** che memorizza le informazioni di rilascio in un database SQL.
+
+L'uso di uno storage backend di questo tipo è particolarmente utile se le informazioni sulla release
+pesano più di 1 MB (nel qual caso non possono essere memorizzate in ConfigMaps/Secrets).
+a causa dei limiti nello storage key-values di etcd in 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
+```
+
+> Nota: al momento è supportato solo PostgreSQL.
+
+**NOTE DI PRODUZIONE**: Si raccomanda 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](/topics/permissions_sql_storage_backend.md) per
+rispecchiare le RBAC di Kubernetes per le informazioni della release
+
+Se si vuole passare dal backend predefinito al backend SQL, si dovrà
+fare la migrazione in autonomia. È possibile recuperare le informazioni sulla release
+con il seguente comando:
+
+```shell
+kubectl get secret --all-namespaces -l “owner=helm”
+```

i18n/it/docusaurus-plugin-content-docs/version-3/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 file 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.