From 883b927bad663272bbab91cc63b4592264e3c10d Mon Sep 17 00:00:00 2001 From: Nicolas Fantoni Date: Tue, 9 Jul 2024 11:24:00 +0200 Subject: [PATCH 01/10] add it.toml Signed-off-by: Nicolas Fantoni --- i18n/it.toml | 223 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 223 insertions(+) create mode 100644 i18n/it.toml diff --git a/i18n/it.toml b/i18n/it.toml new file mode 100644 index 000000000..0007a6183 --- /dev/null +++ b/i18n/it.toml @@ -0,0 +1,223 @@ +# site-wide copy + +## actions and labels +[action_get_started] +other = "Inizia" + +[action_get_started_link] +other = "/docs/intro/quickstart" + +[action_translate] +other = "Traduci questa pagina" + +[action_translate_link] +other = "https://github.com/helm/helm-www#internationalization--translation" + +[action_copy] +other = "Copia" + +## site-wide banner about versioning +[banner_1] +other = "" + +## footer +[footer_support_title] +other = "Helm è supportato e sviluppato da una comunità di oltre 400 sviluppatori." + +[footer_support_subtitle] +other = "...e molti altri meravigliosi [helm](https://github.com/helm/helm/blob/main/OWNERS) manutentori principali." + +[footer_cncf_status] +other = "Noi siamo un progetto graduated della Cloud Native Computing Foundation." + +# homepage copy + +## homepage intro +[main_title] +other = "**Il** **package manager** **per Kubernetes**" + +[main_subtitle] +other = "Helm è il modo migliore per trovare, condividere e utilizzare il software realizzato per [Kubernetes](https://kubernetes.io)." + +## homepage about helm +[main_what_is_helm_title] +other = "Cos'è Helm?" + +[main_what_is_helm_description] +other = """ +Helm vi aiuta a gestire le applicazioni Kubernetes - I Charts di Helm vi aiutano a definire, installare e aggiornare anche le applicazioni Kubernetes più complesse. + +I Charts sono facili da creare, modificare, condividere e pubblicare — iniziate a usare Helm e smettete di fare copia-incolla. + +Helm è un graduated project nel [CNCF](https://cncf.io) ed è mantenuto dalla [Helm community](https://github.com/helm/community). + +### Learn more: + +* [Helm Architecture](./docs/topics/architecture/) +* [Quick Start Guide](/docs/intro/quickstart/) +* [Video: Un introduzione a Helm](https://www.youtube.com/watch?v=Zzwq9FmZdsU&t=2s) +""" + +[main_why_teams_love] +other = 'Perchè Teams Helm' + +[feature_01_title] +other = "Gestire la Complessità" + +[feature_01_desc] +other = "I Charts descrivono anche le applicazioni più complesse, consentono di ripetere l'installazione delle applicazioni e fungono da unico punto di riferimento." + +[feature_02_title] +other = "Aggiornamenti facili" + +[feature_02_desc] +other = "Eliminate il fastidio degli aggiornamenti con gli upgrade in-place e gli hooks personalizzati." + +[feature_03_title] +other = "Condivisione semplice" + +[feature_03_desc] +other = "I Charts sono facili da versionare, condividere e ospitare su server pubblici o privati." + +[feature_04_title] +other = "Rollbacks" + +[feature_04_desc] +other = "Usate `helm rollback` per tornare facilmente a una versione precedente di una release." + +## homepage get helm +[get_helm_title] +other = "Prendete Helm!" + +[get_helm_desc] +other = "Installate Helm con un gestore pacchetti o [scaricate un binario].(https://github.com/helm/helm/releases/latest)." + +[get_helm_next] +other = "Una volta installato, scompattate il binario di helm e aggiungetelo al vostro PATH e sarete pronti a partire! Consultate la [documentazione](/docs/intro/install/) per ulteriori informazioni e [istruzioni d'uso](/docs/intro/using_helm/)." + +[get_charts_title] +other = "Prendete i Charts" + +[get_charts_desc] +other = "Visita [Artifact Hub](https://artifacthub.io) per esplorare i [charts Helm](https://artifacthub.io/packages/search?kind=0) da numerosi repositories pubblici." + +[get_upgrade_title] +other = "[Aggiornamento da versione v2 a v3?](https://helm.sh/docs/topics/v2_v3_migration/)" + +[get_upgrade_desc] +other = "[Per maggiori dettagli, leggete il documento sulla migrazione.](https://helm.sh/docs/topics/v2_v3_migration/)" + +## homepage community +[community_title] +other = "Unisciti alla community" + +[community_desc] +other = "Ulteriori informazioni sul progetto Helm e su come contribuire." + +[community_next_release] +other = "Prossimo rilascio" + +[community_next_release_version] +other = "__Versione:__ " + +[community_next_release_date] +other = "__Data:__ " + +[community_release_calendar] +other = "[Calendario rilasci](https://helm.sh/calendar/release)" + +[community_events_title] +other = "Eventi" + +[community_upcoming_events_title] +other = "Prossimi eventi" + +[community_upcoming_events_desc] +other = "Guarda questo spazio..." + +[community_past_events_title] +other = "Eventi Passati" + +[community_past_event_01] +other = "_25 Febbraio 2020_ - [Helm Security Webinar](https://www.cncf.io/webinars/helm-security-a-look-below-deck/)" + +[community_past_event_02] +other = "_18 Novembre 2019_ - [KubeCon North America](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/)" + +[community_past_event_03] +other = "_11 Settembre 2019_ - [Helm Summit 2019](https://events19.linuxfoundation.org/events/helm-summit-2019/)" + +[community_sig_title] +other = "SIG Apps" + +[community_sig_subtitle] +other = "Uno Special Interest Group per la distribuzione e il funzionamento delle applicazioni in Kubernetes." + +[community_sig_desc] +other = """ +[SIG-Apps](https://github.com/kubernetes/community/blob/master/sig-apps/README.md) è uno Special Interest Group per la distribuzione e il funzionamento delle applicazioni in Kubernetes. + +[si incontrano ogni settimana](https://github.com/kubernetes/community/blob/master/sig-apps/README.md) per dimostrare e discutere strumenti e progetti. Gli incontri della comunità vengono registrati e [condivisi su YouTube](https://www.youtube.com/results?search_query=kubernetes+sig+apps). +""" + +[community_standup_title] +other = "Standup per sviluppatori" + +[community_standup_time] +other = "Giovedì 9:30-10 (PT)" + +[community_standup_desc] +other = "Questi incontri sono aperti a tutti. Controllare la [community repository](https://github.com/helm/community/blob/main/communication.md#meetings) per le note e i dettagli." + +[community_slack_title] +other = "Slack" + +[community_slack_group_01_title] +other = "Utenti Helm" + +[community_slack_group_01_desc] +other = "Discussione sull'uso di Helm, sul lavoro con i Charts e sulla risoluzione degli errori più comuni." + +[community_slack_group_02_title] +other = "Sviluppo di Helm" + +[community_slack_group_02_desc] +other = "Argomenti riguardanti lo sviluppo di Helm, le PR in corso, i comunicati, ecc." + +[community_slack_group_03_title] +other = "Charts" + +[community_slack_group_03_desc] +other = "Discussione per utenti e collaboratori di Charts Helm ." + +[community_slack_join] +other = "[Richiedi accesso qui](https://slack.k8s.io/) per unirti al team Slack di Kubernetes." + +[community_contrib_title] +other = "Contribuire" + +[community_contrib_subtitle] +other = "Helm accoglie sempre nuovi apporti al progetto!" + + +[community_contrib_desc] +other = """ +### Dove iniziare? + +Helm è un grande progetto con molti utenti e collaboratori. Può essere un'esperienza da non perdere! + +Abbiamo un elenco di [buone prime issues](https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22) se volete aiutare ma non sapete da dove cominciare. + +### Cosa devo fare? + +Prima di contribuire con del codice, leggete la nostra [Guida al contributo] (https://github.com/helm/helm/blob/main/CONTRIBUTING.md). Essa illustra i processi di creazione e revisione delle pull requests. + +Una volta scritto del codice, si prega di [firmare i propri commit](https://helm.sh/blog/helm-dco/index.html) per garantire che Helm aderisca all'accordo [DCO](https://developercertificate.org/) utilizzato dal [CNCF](https://www.cncf.io/). +""" + +# 404 page +[404_title] +other = "**404** **Pagina non trovata.**" + +[404_subtitle] +other = "Mi spiace per questo. Se qualcosa non funziona, per favore [segnalalo qui](https://github.com/helm/helm-www/issues/new)" From 7a49b67db567f8a07343f1dd199c410e4bc08fe4 Mon Sep 17 00:00:00 2001 From: Nicolas Fantoni Date: Tue, 9 Jul 2024 11:24:47 +0200 Subject: [PATCH 02/10] add topic it Signed-off-by: Nicolas Fantoni --- content/it/docs/_index.md | 21 + content/it/docs/topics/_index.md | 8 + content/it/docs/topics/advanced.md | 188 +++ content/it/docs/topics/architecture.md | 59 + content/it/docs/topics/chart_repository.md | 301 +++++ content/it/docs/topics/chart_tests.md | 93 ++ content/it/docs/topics/charts.md | 1048 +++++++++++++++++ content/it/docs/topics/charts_hooks.md | 191 +++ content/it/docs/topics/kubernetes_apis.md | 147 +++ content/it/docs/topics/kubernetes_distros.md | 100 ++ content/it/docs/topics/library_charts.md | 399 +++++++ .../topics/permissions_sql_storage_backend.md | 60 + content/it/docs/topics/plugins.md | 375 ++++++ content/it/docs/topics/provenance.md | 267 +++++ content/it/docs/topics/rbac.md | 178 +++ content/it/docs/topics/registries.md | 252 ++++ content/it/docs/topics/release_policy.md | 45 + content/it/docs/topics/v2_v3_migration.md | 110 ++ content/it/docs/topics/version_skew.md | 74 ++ 19 files changed, 3916 insertions(+) create mode 100644 content/it/docs/_index.md create mode 100644 content/it/docs/topics/_index.md create mode 100644 content/it/docs/topics/advanced.md create mode 100644 content/it/docs/topics/architecture.md create mode 100644 content/it/docs/topics/chart_repository.md create mode 100644 content/it/docs/topics/chart_tests.md create mode 100644 content/it/docs/topics/charts.md create mode 100644 content/it/docs/topics/charts_hooks.md create mode 100644 content/it/docs/topics/kubernetes_apis.md create mode 100644 content/it/docs/topics/kubernetes_distros.md create mode 100644 content/it/docs/topics/library_charts.md create mode 100644 content/it/docs/topics/permissions_sql_storage_backend.md create mode 100644 content/it/docs/topics/plugins.md create mode 100644 content/it/docs/topics/provenance.md create mode 100644 content/it/docs/topics/rbac.md create mode 100644 content/it/docs/topics/registries.md create mode 100644 content/it/docs/topics/release_policy.md create mode 100644 content/it/docs/topics/v2_v3_migration.md create mode 100644 content/it/docs/topics/version_skew.md diff --git a/content/it/docs/_index.md b/content/it/docs/_index.md new file mode 100644 index 000000000..7563d1a97 --- /dev/null +++ b/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. diff --git a/content/it/docs/topics/_index.md b/content/it/docs/topics/_index.md new file mode 100644 index 000000000..19de990b4 --- /dev/null +++ b/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. diff --git a/content/it/docs/topics/advanced.md b/content/it/docs/topics/advanced.md new file mode 100644 index 000000000..e5c277a1a --- /dev/null +++ b/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" +``` diff --git a/content/it/docs/topics/architecture.md b/content/it/docs/topics/architecture.md new file mode 100644 index 000000000..28d3fbe4a --- /dev/null +++ b/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. \ No newline at end of file diff --git a/content/it/docs/topics/chart_repository.md b/content/it/docs/topics/chart_repository.md new file mode 100644 index 000000000..9bc317900 --- /dev/null +++ b/content/it/docs/topics/chart_repository.md @@ -0,0 +1,301 @@ +--- +title: "Guida ai Chart Repository" +description: "Come creare e lavorare coi repository per Helm chart." +aliases: ["/docs/chart_repository/"] +weight: 6 +--- + +Questa sezione spiega come creare e lavorare con i repository dei chart Helm. Ad alto livello +un repository di chart è una posizione in cui i chart confezionati possono essere archiviati e condivisi. + +Il repository distribuito della comunità di Helm si trova all'indirizzo +[Artifact Hub](https://artifacthub.io/packages/search?kind=0) e accoglie con favore la +partecipazione. Ma Helm permette anche di creare e gestire un proprio repository di chart. Questa guida spiega come farlo. + +## Prerequisiti + +* Leggere la guida [Quickstart]({{< relref path="quickstart.md" lang="en">}}) +* Leggere il documento [Charts]({{< ref "/docs/topics/charts.md" >}}) + +## Creare un chart repository + +Un _chart repository_ è un server HTTP che ospita un file `index.yaml` e +opzionalmente alcuni chart confezionati. Quando si è pronti a condividere i propri chart, il modo + modo preferibile è caricarli in un archivio di grafici. + +A partire da Helm 2.2.0, è supportata l'autenticazione SSL lato client a un repository. Altri +protocolli di autenticazione possono essere disponibili come plugin. + +Poiché un chart repository può essere un qualsiasi server HTTP in grado di servire file YAML e tar +e può rispondere a richieste GET, si ha una pletora di opzioni quando si tratta di ospitare il proprio chart repository. +Ad esempio, è possibile utilizzare un bucket di Google +Cloud Storage (GCS), Amazon S3, GitHub Pages o addirittura creare il proprio server web. + +### The chart repository structure +### La struttura del chart repository + +Un chart repository è composto da chart pacchettizzati e da un file speciale chiamato`index.yaml` che contiene un indice di tutti i chart presenti nel repository. +Spesso, i chart che `index.yaml` descrive sono ospitati sullo stesso server, così come i [file di provenienza] ({{< ref "provenance.md" >}}).Per esempio, il layout del repository `https://example.com/charts` potrebbe essere così: + +``` +charts/ + | + |- index.yaml + | + |- alpine-0.1.2.tgz + | + |- alpine-0.1.2.tgz.prov +``` + +In questo caso, il file di indice conterrebbe informazioni su un chart, il chart Alpine, e fornirebbe l'URL per il download`https://example.com/charts/alpine-0.1.2.tgz` per quel chart. + +Non è necessario che un pacchetto di chart si trovi sullo stesso server del file`index.yaml`. Tuttavia, spesso è la soluzione più semplice. + +### Il file indice + +Il file indice è un file yaml chiamato `index.yaml`. Contiene alcuni metadati +del pacchetto, compreso il contenuto del file `Chart.yaml` di un chart. A +chart repository valido deve avere un file di indice. Il file indice contiene +informazioni su ogni chart presente nel repository. Il comando `helm repo index` +genera un file di indice basato su una determinata directory locale che +contenente i chart pacchettizzati. + +Questo è un esempio di file di indice: + +```yaml +apiVersion: v1 +entries: + alpine: + - created: 2016-10-06T16:23:20.499814565-06:00 + description: Deploy a basic Alpine Linux pod + digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd + home: https://helm.sh/helm + name: alpine + sources: + - https://github.com/helm/helm + urls: + - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz + version: 0.2.0 + - created: 2016-10-06T16:23:20.499543808-06:00 + description: Deploy a basic Alpine Linux pod + digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 + home: https://helm.sh/helm + name: alpine + sources: + - https://github.com/helm/helm + urls: + - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz + version: 0.1.0 + nginx: + - created: 2016-10-06T16:23:20.499543808-06:00 + description: Create a basic nginx HTTP server + digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff + home: https://helm.sh/helm + name: nginx + sources: + - https://github.com/helm/charts + urls: + - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz + version: 1.1.0 +generated: 2016-10-06T16:23:20.499029981-06:00 +``` + +## Ospitare i Chart Repositories + +Questa parte mostra diversi modi per servire un chart repository.. + +### Google Cloud Storage + +Il primo passo è quello di **creare il proprio bucket GCS**. Chiameremo il nostro +`fantastic-charts`. + +![Creare un bucket GCS](https://helm.sh/img/create-a-bucket.png) + +Quindi, rendete il vostro bucket pubblico **modificando i permessi del bucket**. + +![Modifica permessi](https://helm.sh/img/edit-permissions.png) + +Inserire questa voce per **rendere pubblico il bucket**: + +![Rendi pubblico il bucket](https://helm.sh/img/make-bucket-public.png) + +Congratulazioni, ora avete un bucket GCS vuoto pronto per servire i chart! + +È possibile caricare il chart repository utilizzando lo strumento a riga di comando Google Cloud Storage +o utilizzando l'interfaccia web di GCS. È possibile accedere a un bucket GCS pubblico tramite +semplice HTTPS a questo indirizzo: `https://bucket-name.storage.googleapis.com/`. + +### Cloudsmith + +È anche possibile impostare chart repositories utilizzando Cloudsmith. Per saperne di più +chart repositories con Cloudsmith +[qui](https://help.cloudsmith.io/docs/helm-chart-repository) + +### JFrog Artifactory + +Allo stesso modo, è possibile impostare chart repositories utilizzando JFrog Artifactory. Per saperne di più +su chart repositories con JFrog Artifactory +[qui](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repository) + +### Esempio con GitHub Pages + +In modo simile è possibile creare charts repository utilizzando GitHub Pages. + +GitHub consente di servire pagine web statiche in due modi diversi: + +- Configurando un progetto per servire il contenuto della sua cartella `docs/`. +- Configurando un progetto per servire un particolare branch. + +Noi adotteremo il secondo approccio, anche se il primo è altrettanto semplice. + +Il primo passo sarà quello di **creare il branch gh-pages**. È possibile farlo +localmente come. + +```console +$ git checkout -b gh-pages +``` + +Oppure tramite browser web usando il pulsante **Branch** sul repository GitHub: + +![Crea branch GitHub Pages](https://helm.sh/img/create-a-gh-page-button.png) + +Successivamente, ci si deve assicurare che il branch **gh-pages** sia impostato come GitHub Pages, +cliccare sulle **Impostazioni** del proprio repository e scorrere fino alla sezione **Pagine GitHub** e +e impostare come indicato di seguito: + +![Crea branch GitHub Pages](https://helm.sh/img/set-a-gh-page.png) + +Per impostazione predefinita, **Source** viene solitamente impostato su **gh-pages branch**. Se questo non è +impostato per impostazione predefinita, selezionarlo. + +È possibile utilizzare un **dominio personalizzato** se lo si desidera. + +Verificare che **Enforce HTTPS** sia spuntato, in modo che **HTTPS** venga utilizzato quando vengono serviti i chart. + +In questa configurazione si può usare il branch predefinito per memorizzare il codice dei chart e il branch **gh-pages** come repository dei chart. Ad esempio: +`https://USERNAME.github.io/REPONAME`. La dimostrazione [TS +Charts](https://github.com/technosophos/tscharts) è accessibile all'indirizzo +`https://technosophos.github.io/tscharts/`. + +If you have decided to use GitHub pages to host the chart repository, check out +[Chart Releaser Action]({{< relref path="/docs/howto/chart_releaser_action.md" lang="en" >}}). +Chart Releaser Action is a GitHub Action workflow to turn a GitHub project into +a self-hosted Helm chart repo, using +[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool. + +### Ordinary web servers + +To configure an ordinary web server to serve Helm charts, you merely need to do +the following: + +- Put your index and charts in a directory that the server can serve +- Make sure the `index.yaml` file can be accessed with no authentication + requirement +- Make sure `yaml` files are served with the correct content type (`text/yaml` + or `text/x-yaml`) + +Per esempio, se si vogliono servire i chart da `$WEBROOT/charts`, assicurarsi che ci sia una cartella `charts/` nella propria radice web e inserire il file indice e i chart +all'interno di quella cartella. + +### ChartMuseum Repository Server + +ChartMuseum è un server di repository Helm Chart open-source scritto in Go +(Golang), con supporto per backend di cloud storage, tra cui [Google Cloud +Storage](https://cloud.google.com/storage/), [Amazon +S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob +Microsoft Azure](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba +Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object +Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud +Oracle Cloud](https://cloud.oracle.com/storage), [Baidu Cloud +BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object +Tencent](https://intl.cloud.tencent.com/product/cos), [DigitalOcean +Spaces](https://www.digitalocean.com/products/spaces/), +[Minio](https://min.io/) e [etcd](https://etcd.io/). + +È inoltre possibile utilizzare il servizio +[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) +per ospitare un archivio di chart da un file system locale. + +### Registro dei pacchetti GitLab + +Con GitLab è possibile pubblicare i chart Helm nel Package Registry del progetto. +Per saperne di più sull'impostazione di un helm package repository con GitLab [qui](https://docs.gitlab.com/ee/user/packages/helm_repository/). + +## Gestione dei repository dei grafici + +Ora che si dispone di un chart repository, l'ultima parte di questa guida spiega come +come gestire i chart in quel repository. + + +### Memorizzare i chart nel chart repository + +Ora che si dispone di un chart repository, carichiamo un chart e un file di indice nel repository. +I chart in un chart repository devono essere impacchettati (`helm package +nome-della-cartella/`) e correttamente versionati (seguendo le linee guida di [SemVer 2](https://semver.org/)). + +I passi successivi compongono un flusso di lavoro di esempio, ma si può usare +qualsiasi flusso di lavoro per memorizzare e aggiornare i chart nel proprio repository. + +Una volta pronto un chart pacchettizzato, creare una nuova directory e spostare il chart pacchettizzato in quella directory. + +```console +$ helm package docs/examples/alpine/ +$ mkdir fantastic-charts +$ mv alpine-0.1.0.tgz fantastic-charts/ +$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com +``` + +L'ultimo comando prende il percorso della cartella locale appena creata e l'URL del repository grafico remoto. +l'URL del chart repository remoto e compone un file `index.yaml` all'interno della cartella indicata. + +Ora è possibile caricare il chart e il file di indice nel chart repository, utilizzando uno strumento di sincronizzazione o manualmente. +Se si utilizza Google Cloud Storage, si può dare un'occhiata a questo [esempio di flusso di lavoro]({{< relref path="/docs/howto/chart_repository_sync_example.md" lang="en" >}}) utilizzando il client gsutil. Per GitHub, è sufficiente inserire i chart nel branch di destinazione appropriato. + +### Aggiungere nuovi chart a un repository esistente + +Ogni volta che si desidera aggiungere un nuovo chart al repository, è necessario rigenerare l'indice. + +Il comando `helm repo index` ricostruisce completamente il file +`index.yaml` da zero, includendo solo i chart trovati localmente. + +Tuttavia, è possibile utilizzare il flag `--merge` per aggiungere in modo incrementale nuovi chart a un file `index.yaml + esistente (un'ottima opzione quando si lavora con un repository remoto come GCS). + Eseguire `helm repo index --help` per saperne di più, + +Assicurarsi di caricare sia il file `index.yaml` rivisto che il chart. E +se si è generato un file di provenienza, caricare anche quello. + +### Condividere i chart con altri + +Quando si è pronti a condividere i chart, è sufficiente comunicare a qualcuno l'URL del vostro repository. + +Da lì, aggiungeranno il repository al loro client helm tramite il comando `helm repo +add [NAME] [URL]` con il nome che si desidera utilizzare per fare riferimento al repository. + + ``console +$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com +$ helm repo list +fantastic-charts https://fantastic-charts.storage.googleapis.com +``` + +Se i chart sono supportati dall'autenticazione di base HTTP, si possono fornire anche il nome utente e la password: + +```console +$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password +$ helm repo list +fantastic-charts https://fantastic-charts.storage.googleapis.com +``` + +**Nota:** Un repository non verrà aggiunto se non contiene un valido file +`index.yaml`. + +**Nota:** Se il proprio repository helm utilizza ad esempio un certificato autofirmato, si può usare `helm repo add --insecure-skip-tls-verify ...` per saltare la verifica della CA. + +Dopodiché, i vostri utenti saranno in grado di cercare nei vostri chart. Dopo aver +aggiornato il repository, possono usare il comando `helm repo update` per ottenere le ultime +informazioni più recenti sui chart. + +*Sotto il cofano, i comandi `helm repo add` e `helm repo update` +recuperano il file index.yaml e lo memorizzano nella cartella +`$XDG_CACHE_HOME/helm/repository/cache/`. È qui che la funzione `helm +search` trova le informazioni sui chart. diff --git a/content/it/docs/topics/chart_tests.md b/content/it/docs/topics/chart_tests.md new file mode 100644 index 000000000..5e1e5d997 --- /dev/null +++ b/content/it/docs/topics/chart_tests.md @@ -0,0 +1,93 @@ +--- +title: "Testare i Chart" +description: "Descrive come eseguire e testare i chart." +aliases: ["/docs/chart_tests/"] +weight: 3 +--- + +Un chart contiene una serie di risorse e componenti Kubernetes che lavorano +insieme. Come autore di un chart, si potrebbe voler scrivere alcuni test per convalidare che funzioni come previsto quando viene installato. Questi test aiutano anche il +consumatore del chart a capire cosa dovrebbe fare. + +Un **test** in un chart helm si trova nella cartella `templates/` ed è una definizione di lavoro che specifica un container con un determinato comando da eseguire. Il container +deve terminare con successo (exit 0) perché il test sia considerato superato. La definizione del job deve contenere l'annotazione helm test hook: `helm.sh/hook: test`. + +Si noti che fino a Helm v3, la definizione del job doveva contenere una di queste annotazioni helm test hook: `helm.sh/hook: test-success` o `helm.sh/hook: test-failure`. +`helm.sh/hook: test-success` è ancora accettato come alternativa retro-compatibile a `helm.sh/hook: test`. + +Test di esempio: + +- Validare che la configurazione del file values.yaml sia stata iniettata correttamente. + - Verificare che il nome utente e la password funzionino correttamente + - Assicurarsi che un nome utente e una password non corretti non funzionino. +- Verificare che i servizi siano attivi e che il bilanciamento del carico sia corretto +- ecc. + +È possibile eseguire i test predefiniti in Helm su una release utilizzando il comando `helm +test `. Per un utente del chart, questo è un ottimo modo per verificare che la propria release di un chart (o di un'applicazione) funzioni come previsto. + +## Esempio di test + +Il comando [helm create](/docs/helm/helm_create) creerà automaticamente una serie di cartelle e file. Per provare la funzionalità di test di helm, creare prima un chart demo. + +```console +$ helm create demo +``` + +Ora sarà possibile vedere la seguente struttura nel chart demo. + +``` +demo/ + Chart.yaml + values.yaml + charts/ + templates/ + templates/tests/test-connection.yaml +``` + +In `demo/templates/tests/test-connection.yaml` si trova un test che si può provare. È possibile vedere la definizione del pod di test di helm qui: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: "{{ include "demo.fullname" . }}-test-connection" + labels: + {{- include "demo.labels" . | nindent 4 }} + annotations: + "helm.sh/hook": test +spec: + containers: + - name: wget + image: busybox + command: ['wget'] + args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] + restartPolicy: Never + +``` + +## Passi per eseguire una suite di test su una release + +Per prima cosa, installare il chart sul cluster per creare una release. Potrebbe essere necessario +attendere che tutti i pod siano attivi; se si esegue il test subito dopo l'installazione, è probabile che si verifichi un errore transitivo e che si debba ripetere il test. + +```console +$ helm install demo demo --namespace default +$ helm test demo +NAME: demo +LAST DEPLOYED: Mon Feb 14 20:03:16 2022 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: demo-test-connection +Last Started: Mon Feb 14 20:35:19 2022 +Last Completed: Mon Feb 14 20:35:23 2022 +Phase: Succeeded +[...] +``` + +## Note + +- È possibile definire tutti i test che si desidera in un singolo file yaml o distribuirli in diversi file yaml nella cartella `templates/`. +- È possibile annidare la propria suite di test sotto una cartella `tests/`, come ad esempio `/templates/tests/` per un maggiore isolamento. +- Un test è un [hook] di Helm (/docs/charts_hooks/), quindi annotazioni come `helm.sh/hook-weight` e `helm.sh/hook-delete-policy` possono essere usate con le risorse dei test. diff --git a/content/it/docs/topics/charts.md b/content/it/docs/topics/charts.md new file mode 100644 index 000000000..36a5035a1 --- /dev/null +++ b/content/it/docs/topics/charts.md @@ -0,0 +1,1048 @@ +--- +title: "Charts" +description: "Spiega il formato dei chart e fornisce indicazioni di base per la creazione di chart con Helm." +aliases: [ + "docs/developing_charts/", + "developing_charts" +] +weight: 1 +--- + +Helm utilizza un formato di packaging chiamato _charts_. Un chart è un insieme di file +che descrivono un insieme correlato di risorse Kubernetes. Un singolo chart potrebbe essere usato per distribuire qualcosa di semplice, come un pod memcached, o qualcosa di complesso, +come uno stack completo di app web con server HTTP, database, cache e così via. + +I chart vengono creati come file disposti in un particolare albero di directory. Possono essere +in archivi versionati per essere distribuiti. + +Se si desidera scaricare e consultare i file di un chart pubblicato, senza installarlo, è possibile farlo con `helm pull chartrepo/nome del chart`. + +Questo documento spiega il formato del chart e fornisce una guida di base per +costruire chart con Helm. + +## La struttura dei file del chart + +Un chart è organizzato come una raccolta di file all'interno di una directory. Il nome della directory +è il nome del chart (senza informazioni sulla versione). Quindi, +un chart che descrive WordPress verrebbe memorizzato in una directory `wordpress/`. + +All'interno di questa directory, Helm si aspetta una struttura che corrisponde a questa: + +```text +wordpress/ + Chart.yaml # Un file YAML contenente informazioni sul chartt + LICENSE # OPZIONALE: un file di testo semplice contenente la licenza per il chart. + README.md # OPZIONALE: un file README human-readable + values.yaml # I valori di configurazione predefiniti per questo chart + values.schema.json # OPZIONALE: Uno schema JSON per imporre una struttura al file values.yaml + charts/ # Una directory contenente i chart da cui dipende questo chart. + crds/ # Custom Resource Definitions + templates/ # Una directory di template che, se combinati con i values, + # genereranno file manifest Kubernetes validi. + templates/NOTES.txt # OPZIONALE: un file di testo semplice contenente brevi note d'uso. +``` + +Helm si riserva l'uso delle directory `charts/`, `crds/` e `templates/` e dei nomi dei file elencati. +Gli altri file saranno lasciati così come sono. + +## Il file Chart.yaml + +Il file `Chart.yaml` è necessario per un chart. Contiene i seguenti campi: + +```yaml +apiVersion: La versione dell'API del chart (obbligatorio) +name: il nome del chart (obbligatorio) +version: Una versione di SemVer 2 (obbligatorio) +kubeVersion: Un intervallo SemVer di versioni Kubernetes compatibili (opzionale) +description: Una descrizione di una sola frase di questo progetto (opzionale) +type: Il tipo di chart (opzionale) +keywords: + - Un elenco di parole chiave relative a questo progetto (opzionale) +home: L'URL della pagina iniziale di questo progetto (facoltativo) +sources: + - Un elenco di URL al codice sorgente di questo progetto (facoltativo) +dependencies: # Un elenco dei requisiti del chart (opzionale) + - name: il nome del chart (nginx) + version: La versione del chart ("1.2.3") + repository: (opzionale) L'URL del repository ("https://example.com/charts") o l'alias ("@repo-name") + condition: (facoltativo) Un percorso yaml che si risolve in un booleano, usato per abilitare/disabilitare i chart (ad esempio, subchart1.enabled). + tag: # (opzionale) + - I tag possono essere usati per raggruppare i chart da abilitare/disabilitare insieme + import-values: # (opzionale) + - ImportValues contiene la mappatura dei valori di origine con la chiave padre da importare. Ogni elemento può essere una stringa o una coppia di elementi di sottoelenco padre/figlio. + alias: (opzionale) Alias da usare per il chart. Utile quando si deve aggiungere lo stesso chart più volte. +maintainer: # (opzionale) + - name: il nome del maintainer (obbligatorio per ogni maintainer) + email: L'email del maintainer (opzionale per ogni maintainer) + url: Un URL per il maintainer ( opzionale per ogni maintainer) +icon: Un URL a un'immagine SVG o PNG da usare come icona (opzionale). +appVersion: La versione dell'applicazione che contiene (opzionale). Non è necessario che sia SemVer. Si consigliano le citazioni. +deprecated: Se questo chart è deprecato (opzionale, booleano). +annotations: + example: Un elenco di annotazioni con chiave per nome (opzionale). +``` + +A partire da [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), non sono consentiti campi aggiuntivi. +L'approccio consigliato è quello di aggiungere metadati personalizzati in `annotations`. + +### Chart e versioni + +Ogni chart deve avere un numero di versione. Una versione deve seguire lo standard [SemVer 2](https://semver.org/spec/v2.0.0.html). A differenza di Helm Classic, Helm v2 +e successivi utilizza i numeri di versione come marcatori di release. I pacchetti nei repository sono +identificati dal nome più versione. + +Per esempio, un chart `nginx` il cui campo versione è impostato a `version: 1.2.3` +si chiamerà: + +```testo +nginx-1.2.3.tgz +``` + +Sono supportati anche nomi SemVer 2 più complessi, come `version: +1.2.3-alpha.1+ef365`. Ma i nomi non SemVer sono esplicitamente rifiutati dal sistema. + +**NOTA:** Mentre Helm Classic e Deployment Manager erano entrambi molto orientati a GitHub +quando si trattava di chart, Helm v2 e successivi non si basano su GitHub e nemmeno su Git. +Di conseguenza, non utilizza gli SHA di Git per il versioning. + +Il campo `version` all'interno di `Chart.yaml` è usato da molti strumenti di Helm, compresa la CLI. Quando si genera un pacchetto, il comando `helm package` +utilizzerà la versione trovata in `Chart.yaml` come token nel nome del pacchetto. +Il sistema presume che il numero di versione nel nome del pacchetto del chart +corrisponda al numero di versione presente in `Chart.yaml`. Il mancato rispetto di questa ipotesi +causerà un errore. + +### Il campo `apiVersion` + +Il campo `apiVersion` dovrebbe essere `v2` per i chart Helm che richiedono almeno Helm +3. I chart che supportano versioni precedenti di Helm hanno una `apiVersion` impostata a `v1` e sono ancora installabili con Helm 3. + +Cambiamenti dalla `v1` alla `v2`: + +- Un campo `dependencies` che definisce le dipendenze del chart, che erano situate in un file `requirements.yaml` separato per i chart della `v1` (vedere [Dipendenze dei Chart](#dipendenze-dei-chart)). +- Il campo `type`, che discrimina i chart di applicazione da quelli di libreria (vedere [Tipi di chart](#tipi-di-chart)). + +### Il campo `appVersion` + +Si noti che il campo `appVersion` non è correlato al campo `version`. È un +modo di specificare la versione dell'applicazione. Per esempio, la tabella `drupal` +può avere una `appVersion: "8.2.1"`, che indica che la versione di Drupal inclusa nel chart (per impostazione predefinita) è `8.2.1`. Questo campo è informativo e non ha alcun impatto sul calcolo della versione del chart. Si consiglia di racchiudere la versione tra virgolette. Questo costringe il parser YAML a trattare il numero di versione come una stringa. Lasciarlo senza virgolette può causare problemi di parsing in alcuni casi. Per esempio, YAML interpreta `1.0` come un valore in virgola mobile e un SHA di git commit come `1234e10` come notazione scientifica. + +A partire da Helm v3.5.0, `helm create` avvolge il campo predefinito `appVersion` tra virgolette. + +### Il campo `kubeVersion` + +Il campo opzionale `kubeVersion` può definire i vincoli di semver sulle versioni supportate di Kubernetes. Helm convaliderà i vincoli di versione al momento dell'installazione del chart e fallirà se il cluster esegue una versione di Kubernetes non supportata. + +I vincoli di versione possono comprendere confronti AND separati da spazi, come ad esempio + +``` +>= 1.13.0 < 1.15.0 +``` +che possono essere combinati con l'operatore OR `||` come nel seguente esempio + +``` +>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 +``` + +In questo esempio la versione `1.14.0` viene esclusa, il che può avere senso se è noto un bug +in certe versioni che impediscono il corretto funzionamento del chart. + +Oltre ai vincoli di versione che impiegano gli operatori `=` `!=` `>` `<` `>=` `<=`, sono supportate le seguenti notazioni stenografiche + + * intervalli di trattini per intervalli chiusi, dove `1.1 - 2.3.4` è equivalente a `>= + 1.1 <= 2.3.4`. + * caratteri jolly `x`, `X` e `*`, dove `1.2.x` equivale a `>= 1.2.0 <= 1.3.0`. + 1.3.0`. + * intervalli di tilde (sono consentite modifiche alla versione della patch), dove `~1.2.3` equivale a + `>= 1.2.3 < 1.3.0`. + * intervalli di caret (sono ammessi cambiamenti di versione minori), dove `^1.2.3` equivale a + `>= 1.2.3 < 2.0.0`. + +Per una spiegazione dettagliata dei vincoli di semver supportati, vedere +[Masterminds/semver](https://github.com/Masterminds/semver). + +### Deprecazione dei chart + +Quando si gestiscono i chart in un Chart Repository, a volte è necessario deprecare un chart. +Il campo opzionale `deprecated` in `Chart.yaml` può essere utilizzato +per contrassegnare un chart come deprecato. Se la versione **più recente** di un chart nel repository +è contrassegnata come deprecata, allora il chart nel suo insieme è considerato +deprecato. Il nome del chart può essere riutilizzato in seguito pubblicando una versione più recente +che non sia contrassegnata come deprecata. Il flusso di lavoro per la deprecazione dei chart è il seguente: + +1. Aggiornare il file `Chart.yaml` del grafico per contrassegnarlo come deprecato, eliminando la versione +2. Rilasciare la nuova versione del chart nel Chart Repository. +3. Rimuovere il chart dal repository dei sorgenti (p.e. git) + +### Tipi di chart + +Il campo `type` definisce il tipo di chart. Esistono due tipi:`application` +e `library`. Application è il tipo predefinito e rappresenta il chart standard +che può essere utilizzato completamente. Il [Chart di tipo Library]({{< ref +"/docs/topics/library_charts.md" >}}) fornisce utilità o funzioni per il costruttore di chart. +Un chart library si differenzia da un chart applicativo perché non è +installabile e di solito non contiene oggetti risorsa. + +**Nota:** Un chart di tipo application può essere usato come chart di tipo library. Questo viene abilitato impostando il tipo a `library`. +Il chart sarà quindi reso come un chart di libreria +dove si possono sfruttare tutte le utilità e le funzioni. Tutti gli oggetti risorsa +del chart non saranno renderizzati. + +## LICENZA, README e NOTE + +I chart possono contenere anche file che descrivono l'installazione, la configurazione, +e la licenza d'uso di un chart. + +La LICENZA è un file di testo semplice che contiene il codice di[licenza](https://en.wikipedia.org/wiki/Software_license) per il chart.Il chart può contenere una licenza perché può contenere logica di programmazione nei modelli e quindi non sarebbe solo di configurazione. Ci possono essere anche licenze separate per l'applicazione installata dal chart, se necessario. + +Un README per un chart dovrebbe essere formattato in Markdown (README.md) e dovrebbe contenere genealmente: +- una descrizione dell'applicazione o del servizio che il chart fornisce +- Eventuali prerequisiti o requisiti per eseguire il chart +- Descrizioni delle opzioni in `values.yaml` e dei valori predefiniti +- Qualsiasi altra informazione che possa essere rilevante per l'installazione o la configurazione del chart. + +Quando gli hub e le altre interfacce utente visualizzano i dettagli di un chart, tali dettagli vengono +dal contenuto del file `README.md`. + +Il chart può anche contenere un breve file di testo semplice `templates/NOTES.txt` che verrà stampato dopo l'installazione e quando si visualizza lo stato di una release. +Questo file viene valutato come un [template](#templates-e-values) e può essere +usato per visualizzare le note d'uso, i passi successivi o qualsiasi altra informazione relativa a una +un rilascio del chart. Ad esempio, si possono fornire istruzioni per connessione a un database o l'accesso a un'interfaccia web. Poiché questo file viene stampato su STDOUT quando si esegue `helm install` o `helm status`, è consigliabile mantenere il contenuto breve e rimandare al README per maggiori dettagli. + +## Dipendenze dei chart + +In Helm, un chart può dipendere da un numero qualsiasi di altri chart. Queste dipendenze +possono essere collegate dinamicamente utilizzando il campo `dependencies` in `Chart.yaml` o +nella cartella `charts/` e gestite manualmente. + +### Gestione delle dipendenze con il campo `dipendenze + +I chart richiesti dal chart corrente sono definiti come un elenco nel campo +`dipendenze`. + +```yaml +dependencies: + - name: apache + version: 1.2.3 + repository: https://example.com/charts + - name: mysql + version: 3.2.1 + repository: https://another.example.com/charts +``` + +- Il campo `name` è il nome del chart desiderato. +- Il campo `version` è la versione del chart desiderata. +- Il campo `repository` è l'URL completo del repository del chart. Si noti che + deve essere usato anche `helm repo add` per aggiungere quel repo localmente. +- Si può usare il nome del repo invece dell'URL + +```console +$ helm repo add fantastic-charts https://charts.helm.sh/incubator +``` + +```yaml +dependencies: + - name: awesomeness + version: 1.0.0 + repository: "@fantastic-charts" +``` +Una volta definite le dipendenze, è possibile eseguire `helm dependency update` e il programma utilizzerà il file delle dipendenze per scaricare tutti i chart specificati nel file delle dipendenze per scaricare tutti i chart specificati nella cartella +`charts/`. + +```console +$ helm dep up foochart +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "local" chart repository +...Successfully got an update from the "stable" chart repository +...Successfully got an update from the "example" chart repository +...Successfully got an update from the "another" chart repository +Update Complete. Happy Helming! +Saving 2 charts +Downloading apache from repo https://example.com/charts +Downloading mysql from repo https://another.example.com/charts +``` + +Quando `helm dependency update` recupera i chart, li memorizza come archivi di chart nella directory `charts/`. Quindi, per l'esempio precedente, ci si aspetterebbe +di vedere i seguenti file nella cartella charts: + +```text +charts/ + apache-1.2.3.tgz + mysql-3.2.1.tgz +``` + +#### Campo Alias nelle dipendenze + +Oltre agli altri campi sopra citati, ogni voce relativa alle dipendenze può contenere il campo opzionale`alias`. + +L'aggiunta di un alias per un dependency chart inserisce un chart nelle dipendenze usando +alias come nome della nuova dipendenza. + +Si può usare `alias` nel caso in cui si debba accedere a un chart con altri nomi. + +```yaml +# parentchart/Chart.yaml + +dependencies: + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + alias: new-subchart-1 + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + alias: new-subchart-2 + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 +``` + +Nell'esempio precedente, avremo 3 dipendenze in tutto per `parentchart`: + +```text +subchart +new-subchart-1 +new-subchart-2 +``` + +Il modo manuale per ottenere questo risultato è copiare/incollare lo stesso chart nella directory +`charts/` più volte con nomi diversi. + +#### Tag e Condition fields nelle dipendenze + +Oltre agli altri campi sopra citati, ogni voce di requisiti può contenere i campi opzionali +`tags` e `condition`. + +Tutti i campi sono caricati per impostazione predefinita. Se i campi `tags` o `condition` sono presenti, +vengono valutati e utilizzati per controllare il caricamento dei chart a cui sono applicati. + +Condition - Il campo condition contiene uno o più percorsi YAML (delimitati da virgole). +Se questo percorso esiste nei valori del genitore superiore e si risolve in un valore +valore booleano, il grafico verrà attivato o disattivato in base a quel valore booleano. +Viene valutato solo il primo percorso valido trovato nell'elenco; se non esistono percorsi, la condizione non ha effetto. + +Tags - Il campo tags è un elenco YAML di etichette da associare a questo chart. In +valori del parent superiore, tutti i chart con tag possono essere attivati o disattivati +specificando il tag e un valore booleano. + +```yaml +# parentchart/Chart.yaml + +dependencies: + - name: subchart1 + repository: http://localhost:10191 + version: 0.1.0 + condition: subchart1.enabled,global.subchart1.enabled + tags: + - front-end + - subchart1 + - name: subchart2 + repository: http://localhost:10191 + version: 0.1.0 + condition: subchart2.enabled,global.subchart2.enabled + tags: + - back-end + - subchart2 +``` + +```yaml +# parentchart/values.yaml + +subchart1: + enabled: true +tags: + front-end: false + back-end: true +``` + +Nell'esempio precedente, tutti i chart con il tag `front-end` sarebbero disabilitati ma +poiché il percorso `subchart1.enabled` valuta 'true' nei valori del parent, +la condizione sovrascrive il tag `front-end` e `subchart1` viene abilitato. + +Poiché `subchart2` è etichettato con `back-end` e tale tag valuta a `true`, +`subchart2` sarà abilitato. Si noti anche che, sebbene `subchart2` abbia una condizione + +specificata, non c'è alcun percorso e valore corrispondente nei valori del parent, per cui questa +condizione non ha alcun effetto. + +##### Uso della CLI con tag e condizioni + +Il parametro `--set' può essere usato come di consueto per modificare i valori dei tag e delle condizioni. + +```console +helm install --set tags.front-end=true --set subchart2.enabled=false +``` + +##### Risoluzione di tag e condizioni + +- **Le conditions (se impostate in valori) sovrascrivono sempre i tag.** La prima condition path + che esiste vince e le successive per quel chart vengono ignorate. +- I tag vengono valutati come "se uno qualsiasi dei tag del chart è vero, allora abilita il chart". +- I valori dei tag e delle condition devono essere impostati nei value del chart superiore. +- La chiave `tags:` nei value deve essere una chiave di livello superiore. I globals e le tabelle `tags:` annidate non sono attualmente supportati. + +#### Importare i Values dei figli tramite le dipendenze + +In alcuni casi è auspicabile che i valori di un chart figlio si propaghino al chart padre e siano condivisi come values predefiniti comuni. +Un ulteriore vantaggio di +utilizzare il formato `exports` è che consentirà ai futuri strumenti di introspezione dei values impostabili dall'utente. + +Le chiavi che contengono i valori da importare possono essere specificate nel chart +padre, nel campo `import-values`, utilizzando un elenco YAML. Ogni elemento +dell'elenco è una chiave che viene importata dal campo `exports` del chart figlio. + +Per importare valori non contenuti nella chiave `exports`, utilizzare il metodo +[child-parent](#usare-il-formato-child-parent). Esempi di entrambi i formati +sono descritti di seguito. + +##### Usare il formato exports + +Se il file `values.yaml` di un chart figlio contiene un campo `exports` nella root, +il suo contenuto può essere importato direttamente nei valori del parent, specificando le chiavi da importare, come nell'esempio seguente: + +```yaml +# parent's Chart.yaml file + +dependencies: + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + import-values: + - data +``` + +```yaml +# child's values.yaml file + +exports: + data: + myint: 99 +``` + +Dal momento che stiamo specificando la chiave `data` nella nostra lista di importazione, Helm cerca nel campo `exports` del chart figlio la chiave `data` e importa il suo contenuto. + +I valori finali del parent conterranno il nostro campo esportato: + +```yaml +# parent's values + +myint: 99 +``` + +Si noti che la chiave del parent `data' non è contenuta nei values finali del parent. + +Se è necessario specificare la chiave del parent, utilizzare il formato 'child-parent'. + +##### Usare il formato child-parent + +Per accedere ai values che non sono contenuti nella chiave `exports` dei values del chart figlio, sarà necessario specificare la chiave di origine dei valori da +da importare (`child`) e il percorso di destinazione nei valori del chart padre +(`parent`). + +L'opzione `import-values` nell'esempio seguente indica a Helm di prendere tutti i valori trovati nel percorso `child:` e di copiarli nei valori del parent nel percorso specificato in +`parent:` + +```yaml +# parent's Chart.yaml file + +dependencies: + - name: subchart1 + repository: http://localhost:10191 + version: 0.1.0 + ... + import-values: + - child: default.data + parent: myimports +``` + +Nell'esempio precedente, i valori trovati in `default.data` nei valori del subchart1 +saranno importati nella chiave `myimports` nei valori del chart padre, come descritto di seguito: + +```yaml +# parent's values.yaml file + +myimports: + myint: 0 + mybool: false + mystring: "helm rocks!" +``` + +```yaml +# subchart1's values.yaml file + +default: + data: + myint: 999 + mybool: true +``` + +I valori risultanti del chart padre saranno: + +```yaml +# parent's final values + +myimports: + myint: 999 + mybool: true + mystring: "helm rocks!" +``` + +I valori finali del parent contengono ora i campi `myint` e `mybool` importati da subchart1. + +### Gestione manuale delle dipendenze tramite la directory `charts/` + +Se si desidera un maggiore controllo sulle dipendenze, queste possono essere +esplicitate copiando i chart delle dipendenze nella cartella `charts/`. + +Una dipendenza deve essere una cartella di chart scompattati, ma il suo nome non può iniziare con +con `_` o `.`. Tali file vengono ignorati dal caricatore del chart. + +Per esempio, se il chart di WordPress dipende dal grafico di Apache, il chart di Apache +(della versione corretta) viene fornito nella cartella `charts/` del chart WordPress: + +```yaml +wordpress: + Chart.yaml + # ... + charts/ + apache/ + Chart.yaml + # ... + mysql/ + Chart.yaml + # ... +``` + +L'esempio precedente mostra come il chart di WordPress esprima la sua dipendenza da +Apache e MySQL includendo questi chart all'interno della cartella `charts/`. + +**TIP:** _Per inserire una dipendenza nella cartella `charts/`, usare il comando `helm pull". + +### Aspetti operativi dell'uso delle dipendenze + +Le sezioni precedenti spiegano come specificare le dipendenze dei chart, ma come influiscono sull'installazione dei chart con `helm install` e `helm upgrade`? + +Supponiamo che un chart chiamato "A" crei i seguenti oggetti Kubernetes + +- namespace "A-Namespace" +- statefulset "A-StatefulSet" +- service "A-Service" + +Inoltre, A dipende dal chart B, che crea gli oggetti + +- namespace "B-Namespace" +- replicaset "B-ReplicaSet" +- service "B-Service" + +Dopo l'installazione/aggiornamento del chart A viene creata/modificata una singola release di Helm. +Il rilascio creerà/aggiornerà tutti gli oggetti Kubernetes di cui sopra nel seguente ordine: + +- A-Namespace +- B-Namespace +- A-Service +- B-Service +- B-ReplicaSet +- A-StatefulSet + +Questo perché quando Helm installa/aggiorna i chart, gli oggetti Kubernetes del +chart e tutte le sue dipendenze sono + +- aggregati in un unico insieme; quindi +- ordinati per tipo seguito dal nome; e poi +- creati/aggiornati in questo ordine. + +Quindi viene creata una singola release con tutti gli oggetti per il chart e le sue dipendenze. + +L'ordine di installazione dei tipi di Kubernetes è dato dall'enumerazione InstallOrder +in kind_sorter.go (si veda [il file sorgente di Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). + +## Templates e Values + +I template di Helm Chart sono scritti nel linguaggio [Go template](https://golang.org/pkg/text/template/), con l'aggiunta di una cinquantina di +funzioni template [dalla libreria Sprig](https://github.com/Masterminds/sprig) e alcune altre [funzioni specializzate]({{< relref path="/docs/howto/charts_tips_and_tricks.md" lang="en" >}}). + +Tutti i file dei template sono memorizzati nella cartella `templates/` di un chart. Quando Helm +esegue il rendering dei chart, passerà ogni file in quella cartella attraverso il motore dei + template. + +I values dei template possono essere forniti in due modi: +- Gli sviluppatori dei chart possono fornire un file chiamato `values.yaml` all'interno di un chartrafico. + Questo file p + +### File Template + +I file template seguono le convenzioni standard per la scrittura dei template di Go (vedi +[il pacchetto Go text/templatedocumentazione](https://golang.org/pkg/text/template/) per i dettagli). +Un esempio dipotrebbe essere simile a questo: + +```yaml +apiVersion: v1 +kind: ReplicationController +metadata: + name: deis-database + namespace: deis + labels: + app.kubernetes.io/managed-by: deis +spec: + replicas: 1 + selector: + app.kubernetes.io/name: deis-database + template: + metadata: + labels: + app.kubernetes.io/name: deis-database + spec: + serviceAccount: deis-database + containers: + - name: deis-database + image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} + imagePullPolicy: {{ .Values.pullPolicy }} + ports: + - containerPort: 5432 + env: + - name: DATABASE_STORAGE + value: {{ default "minio" .Values.storage }} +``` + +L'esempio precedente, basato vagamente su +[https://github.com/deis/charts](https://github.com/deis/charts), è un template +per un replica controller Kubernetes. Può utilizzare i seguenti quattro valori +(solitamente definiti in un file `values.yaml`): + +- `imageRegistry`: Il registry di origine dell'immagine Docker. +- `dockerTag`: Il tag per l'immagine Docker. +- `pullPolicy`: La politica di pull di Kubernetes. +- `storage`: Il backend dello storage, il cui valore predefinito è impostato su `"minio"`. + +Tutti questi valori sono definiti dall'autore del template. Helm non richiede o deficita di +parametri. + +Per vedere chart funzionanti, consultare il CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). + +### Valori predefiniti + +I valori forniti tramite un file `values.yaml` (o tramite il flag `--set`) sono +accessibili dall'oggetto `.Values` di un template. Ma ci sono altri +dati predefiniti a cui si può accedere nei template. + +I seguenti valori sono predefiniti, sono disponibili per ogni template e non possono essere sovrascritti. Come per tutti i valori, i nomi sono _sensibili alle maiuscole_. + +- `Release.Name`: Il nome della release (non il chart). +- `Release.Namespace`: il namespace dove sarà rilasciato il chart +- `Release.Service`: Il servizio che ha effettuato il rilascio. +- `Release.IsUpgrade`: Viene impostato a true se l'operazione corrente è un + aggiornamento o rollback. +- `Release.IsInstall`: È impostato su true se l'operazione corrente è un'installazione. +- `Chart`: Il contenuto di `Chart.yaml`. Pertanto, la versione del chart è + ottenibile come `Chart.Version` e i manutentori sono in `Chart.Maintainers`. +- `Files`: Un oggetto simile a una mappa che contiene tutti i file non speciali del chart. Questo oggetto + non darà accesso ai template, ma darà accesso ai file aggiuntivi presenti (a meno che non siano esclusi usando `.helmignore`). Ai file + si può accedere utilizzando `{{ index .Files "file.name" }}` o utilizzando il comando + `{{.Files.Get name }}` Si può anche accedere al contenuto del file + come `[]byte` usando `{{ .Files.GetBytes }}`. +- `Capabilities`: Un oggetto simile a una mappa che contiene informazioni sulle versioni + di Kubernetes (`{{ .Capabilities.KubeVersion }}`) e le versioni di Kubernetes + API supportate (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`). + +**NOTA:** Qualsiasi campo `Chart.yaml` sconosciuto verrà eliminato.Non saranno +accessibili all'interno dell'oggetto `Chart`. Pertanto, `Chart.yaml` non può essere usato per +passare dati strutturati in modo arbitrario nel template. Il file values può essere usato +per questo, però. + +### Files Values + +Considerando il modello della sezione precedente, un file `values.yaml` che fornisce i valori necessari +avrebbe il seguente aspetto: + +```yaml +imageRegistry: "quay.io/deis" +dockerTag: "latest" +pullPolicy: "Always" +storage: "s3" +``` + +Un file di valori è formattato in YAML. Un chart può includere un file `values.yaml` predefinito. Il comando di installazione di Helm permette all'utente di sovrascrivere i valori fornendo +values YAML aggiuntivi: + +```console +$ helm install --generate-name --values=myvals.yaml wordpress +``` + +Quando i valori vengono passati in questo modo, verranno uniti nel file dei valori +di default. Per esempio, si consideri un file `myvals.yaml` che assomiglia a questo: + +```yaml +storage: "gcs" +``` + +Quando questo viene unito con il file `values.yaml` nel chart, il contenuto generato risultante sarà: + +```yaml +imageRegistry: "quay.io/deis" +dockerTag: "latest" +pullPolicy: "Always" +storage: "gcs" +``` + +Si noti che solo l'ultimo campo è stato sovrascritto. + +**NOTA:** Il file dei valori predefiniti incluso in un chart _deve_ essere chiamato +`values.yaml`. Ma i file specificati sulla riga di comando possono avere qualsiasi nome. + +**NOTA:** Se il flag `--set` è usato in `helm install` o `helm upgrade`, quei valori sono semplicemente convertiti in YAML. + +**NOTA:** Se esistono voci richieste nel file dei valori, queste possono essere dichiarate +come richieste nel template del chart, utilizzando la funzione ['required']({{< relref path="/docs/howto/charts_tips_and_tricks.md" lang="en" >}}) + +Tutti questi valori sono poi accessibili all'interno dei template utilizzando l'oggetto `.Values`: + +```yaml +apiVersion: v1 +kind: ReplicationController +metadata: + name: deis-database + namespace: deis + labels: + app.kubernetes.io/managed-by: deis +spec: + replicas: 1 + selector: + app.kubernetes.io/name: deis-database + template: + metadata: + labels: + app.kubernetes.io/name: deis-database + spec: + serviceAccount: deis-database + containers: + - name: deis-database + image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} + imagePullPolicy: {{ .Values.pullPolicy }} + ports: + - containerPort: 5432 + env: + - name: DATABASE_STORAGE + value: {{ default "minio" .Values.storage }} +``` + +### Ambito, dipendenze e valori + +I file Values possono dichiarare valori per il chart di primo livello e per tutti i chart inclusi nella cartella `charts/` di quel chart. Oppure, per dirla +in modo diverso, un file di values può fornire valori al chart così come a qualsiasi +delle sue dipendenze. Per esempio, il chart dimostrativo di WordPress qui sopra ha sia `mysql` che `apache` come dipendenze. Il file dei valori potrebbe fornire i valori +a tutti questi componenti: + +```yaml +title: "My WordPress Site" # Sent to the WordPress template + +mysql: + max_connections: 100 # Sent to MySQL + password: "secret" + +apache: + port: 8080 # Passed to Apache +``` + +I chart di livello superiore hanno accesso a tutte le variabili definite sotto. Quindi il chart di WordPress può accedere alla password di MySQL come `.Values.mysql.password`. +Ma i chart di livello inferiore non possono accedere alle variabili dei chart padre, quindi MySQL non sarà in grado di accedere alla proprietà `title`. Né, a questo proposito, può accedere a +`apache.port`. + +I valori sono inseriti in namespace, ma i namespace vengono eliminati. Quindi, per il chart di WordPress, +può accedere al campo della password di MySQL come `.Values.mysql.password`. Ma per il chart +MySQL, l'ambito dei valori è stato ridotto e il prefisso dello spazio dei nomi è stato +rimosso, per cui il campo password viene visualizzato semplicemente come `.Values.password`. + +#### Valori globali + +A partire dalla versione 2.0.0-Alpha.2, Helm supporta valori speciali "globali". Si consideri questa +versione modificata dell'esempio precedente: + +```yaml +title: "My WordPress Site" # Sent to the WordPress template + +global: + app: MyWordPress + +mysql: + max_connections: 100 # Sent to MySQL + password: "secret" + +apache: + port: 8080 # Passed to Apache +``` + +Quanto sopra aggiunge una sezione `global` con il valore `app: MyWordPress`. Questo valore +è disponibile per _tutti_ i chart come `.Values.global.app`. + +Per esempio, i template `mysql` possono accedere a `app` come `{{.Values.global.app}}`, così come il chart `apache`. In effetti, il file values +di cui sopra viene rigenerato in questo modo: + +```yaml +title: "My WordPress Site" # Sent to the WordPress template + +global: + app: MyWordPress + +mysql: + global: + app: MyWordPress + max_connections: 100 # Sent to MySQL + password: "secret" + +apache: + global: + app: MyWordPress + port: 8080 # Passed to Apache +``` + +Questo permette di condividere una variabile di primo livello con tutti i chart secondari che +è utile per impostare proprietà di `metadati` come le etichette. + +Se un subchart dichiara una variabile globale, questa sarà passata _verso il basso_ (ai subchart del subchart), ma non _verso l'alto_ al chart padre. Non c'è +modo che un subchart possa influenzare i valori del chart padre. + +Inoltre, le variabili globali del chart padre hanno la precedenza sulle variabili globali dei subchart. + +### Schema Files + +A volte, il maintainer di un chart potrebbe voler definire una struttura per i suoi values. +Questo può essere fatto definendo uno schema nel file `values.schema.json`. Uno schema +è rappresentato come un [JSON Schema] (https://json-schema.org/). Potrebbe assomigliare a +qualcosa del genere: + +```json +{ + "$schema": "https://json-schema.org/draft-07/schema#", + "properties": { + "image": { + "description": "Container Image", + "properties": { + "repo": { + "type": "string" + }, + "tag": { + "type": "string" + } + }, + "type": "object" + }, + "name": { + "description": "Service name", + "type": "string" + }, + "port": { + "description": "Port", + "minimum": 0, + "type": "integer" + }, + "protocol": { + "type": "string" + } + }, + "required": [ + "protocol", + "port" + ], + "title": "Values", + "type": "object" +} +``` + +Questo schema verrà applicato ai valori per convalidarli. La convalida avviene quando +uno dei seguenti comandi: + +- `helm install` +- `helm upgrade` +- `helm lint` +- `helm template` + +Un esempio di file `values.yaml` che soddisfa i requisiti di questo schema +potrebbe assomigliare a questo: + +```yaml +name: frontend +protocol: https +port: 443 +``` + +Si noti che lo schema viene applicato all'oggetto finale `.Values` e non solo al file `values.yaml`. Questo significa che il seguente file `yaml` è valido, +dato che lo schema è stato installato con l'appropriata opzione `--set` mostrata +sotto. + +```yaml +name: frontend +protocol: https +``` + +```console +helm install --set port=443 +``` + +Inoltre, l'oggetto finale `.Values` viene controllato rispetto a *tutti* gli schemi dei subchart.Questo significa che le restrizioni di un subchart non possono essere aggirate da un chart padre. Questo funziona anche al contrario: se un subchart ha un requisito che +non è soddisfatto nel file `values.yaml` del subchart, il chart padre *deve* soddisfare +tali restrizioni per essere valido. + +### Riferimenti + +Quando si tratta di scrivere template, values e schema, esistono diversi +riferimenti standard che vi aiuteranno. + +- [Go templates](https://godoc.org/text/template) +- [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) +- [The YAML format](https://yaml.org/spec/) +- [JSON Schema](https://json-schema.org/) +## Definizioni di risorse personalizzate (CRD) + +Kubernetes fornisce un meccanismo per dichiarare nuovi tipi di oggetti Kubernetes. +Utilizzando le CustomResourceDefinitions (CRD), gli sviluppatori Kubernetes possono dichiarare tipi di risorse personalizzate. + +In Helm 3, i CRD sono trattati come un tipo speciale di oggetto. Vengono installati +prima del resto del chart e sono soggetti ad alcune limitazioni. + +I file YAML dei CRD devono essere collocati nella cartella `crds/` all'interno di un chart. +Più CRD (separati da marcatori YAML di inizio e fine) possono essere inseriti nello stesso file. +Helm tenterà di caricare _tutti_ i file nella directory CRD +in Kubernetes. + +I file CRD _non possono essere "templetizzati"_. Devono essere semplici documenti YAML. + +Quando Helm installa un nuovo chart, caricherà i CRD, si fermerà fino a quando i CRD +sono resi disponibili dal server API, quindi avvia il motore dei template, esegue il rendering del resto del chart e lo carica su Kubernetes. A causa di questo ordine, +le informazioni sui CRD sono disponibili nell'oggetto `.Capabilities` nei template Helm, +e i template di Helm possono creare nuove istanze di oggetti che sono stati dichiarati in +CRD. + +Ad esempio, se il chart ha una CRD per `CronTab` nella cartella `crds/`, +si possono creare istanze del tipo `CronTab` nella cartella `templates/`: + +```text +crontabs/ + Chart.yaml + crds/ + crontab.yaml + templates/ + mycrontab.yaml +``` + +Il file `crontab.yaml` deve contenere la CRD senza direttive di template: + +```yaml +kind: CustomResourceDefinition +metadata: + name: crontabs.stable.example.com +spec: + group: stable.example.com + versions: + - name: v1 + served: true + storage: true + scope: Namespaced + names: + plural: crontabs + singular: crontab + kind: CronTab +``` + +Quindi il template `mycrontab.yaml` può creare una nuova `CronTab` (usando i template +come di consueto): + +```yaml +apiVersion: stable.example.com +kind: CronTab +metadata: + name: {{ .Values.name }} +spec: + # ... +``` + +Helm si assicurerà che il tipo `CronTab` sia stato installato e che sia disponibile +dal server API di Kubernetes prima di procedere all'installazione degli elementi in +`templates/`. + +### Limitazioni dei CRD + +A differenza della maggior parte degli oggetti in Kubernetes, i CRD sono installati globalmente. Per questo motivo, +Helm adotta un approccio molto cauto nella gestione dei CRD. I CRD sono soggetti alle +seguenti limitazioni: + +- I CRD non vengono mai reinstallati. Se Helm determina che i CRD presenti nella directory `crds/` + sono già presenti (indipendentemente dalla versione), Helm non tenterà di installarli o aggiornarli. +- I CRD non vengono mai installati in caso di aggiornamento o rollback. Helm creerà i CRD solo durante le + operazioni di installazione. +- I CRD non vengono mai eliminati. L'eliminazione di un CRD cancella automaticamente tutti i contenuti del CRD in tutti i namespace del cluster. + +Di conseguenza, Helm non + eliminerà i CRD. + +Gli operatori che desiderano aggiornare o eliminare i CRD sono invitati a farlo manualmente e con molta attenzione. + +## Usare Helm per gestire i chart + +Lo strumento `helm` ha diversi comandi per lavorare con i chart. + +Può creare un nuovo chart: + +```console +$ helm create mychart +Created mychart/ +``` + +Una volta modificato un chart, `helm` può impacchettarlo in un archivio di chart +per l'utente: + +```console +$ helm package mychart +Archived mychart-0.1.-.tgz +``` + +Si può anche usare `helm` per trovare problemi con la formattazione o le informazioni del chart. + +```console +$ helm lint mychart +No issues found +``` + +## Chart Repositories + +Un _chart repository_ è un server HTTP che ospita uno o più chart confezionati. +Mentre `helm` può essere utilizzato per gestire le directory locali di chart, quando si tratta di +condividere i chart, il meccanismo preferito è un chart repository. + +Qualsiasi server HTTP in grado di servire file YAML e file tar e di rispondere alle richieste GET +può essere utilizzato come server di repository. Il team di Helm ha testato alcuni +server, tra cui Google Cloud Storage con modalità website abilitata e S3 con modalità website abilitata. + +Un repository è caratterizzato principalmente dalla presenza di un file speciale chiamato +`index.yaml` che contiene un elenco di tutti i pacchetti forniti dal repository, +insieme ai metadati che permettono di recuperare e verificare tali pacchetti. + +Sul lato client, i repository sono gestiti con i comandi `helm repo`. +Tuttavia, Helm non fornisce strumenti per il caricamento di grafici su server di repository remoti. + Questo perché ciò comporterebbe l'aggiunta di requisiti sostanziali per un server +server e quindi aumenterebbe la barriera per la creazione di un repository. + +## Chart Starter Packs + +Il comando `helm create` accetta un'opzione `--starter` che permette di +specificare un "chart iniziale". Inoltre, l'opzione starter ha un alias breve `-p`. + +Esempi di utilizzo: + +``console +helm create my-chart --starter starter-name +helm create my-chart -p starter-name +helm create my-chart -p /absolute/path/to/starter-name +``` + +Gli starter sono dei normali chart, ma si trovano in +`$XDG_DATA_HOME/helm/starters`. Come sviluppatore di chart, si possono creare chart +che sono specificamente progettati per essere usati come starter. Tali chart devono essere progettati +con le seguenti considerazioni: + +- Il file `Chart.yaml` sarà sovrascritto dal generatore. +- Gli utenti si aspetteranno di poter modificare i contenuti di un chart di questo tipo, quindi la documentazione dovrebbe + indicare come gli utenti possono farlo. +- Tutte le occorrenze di `` saranno sostituite con il nome del chart specificato, in modo che i chart di partenza possano essere usati come modelli, tranne che per alcuni file variabili. Ad esempio, se si utilizzano file personalizzati nella cartella `vars` o alcuni file `README.md`, `` NON verrà sovrascritto al loro interno. Inoltre, la descrizione del chart non viene ereditata. + +Attualmente l'unico modo per aggiungere un chart a `$XDG_DATA_HOME/helm/starters` è copiarlo manualmente. Nella documentazione del chart, si potrebbe spiegare +questo processo. diff --git a/content/it/docs/topics/charts_hooks.md b/content/it/docs/topics/charts_hooks.md new file mode 100644 index 000000000..28ff04ee7 --- /dev/null +++ b/content/it/docs/topics/charts_hooks.md @@ -0,0 +1,191 @@ +--- +title: "Chart Hooks" +description: "Descrive come lavorare con i chart hooks." +aliases: ["/docs/charts_hooks/"] +weight: 2 +--- + +Helm fornisce un meccanismo di _hook_ per consentire agli sviluppatori di chart di intervenire in determinati punti del ciclo di vita di una release. Ad esempio, è possibile utilizzare gli hook per: + +- Caricare una ConfigMap o un Segreto durante l'installazione prima che vengano caricati altri chart. +- Eseguire un Job per eseguire il backup di un database prima dell'installazione di un nuovo chart e poi eseguire un secondo Job dopo l'aggiornamento per ripristinare i dati. +- Eseguire un Job prima di eliminare una release per togliere in modod gracefully un service dalla rotation prima di rimuoverlo. + +Gli hook funzionano come i normali templates, ma hanno annotazioni speciali che fanno sì che Helm li utilizzi in modo diverso. +In questa sezione si illustra il modello d'uso di base degli hook. + +## Gli Hook disponibili + +Sono definiti i seguenti hook: + +| Valore Annotation | Descrizione | +| ---------------- | ----------------------------------------------------------------------------------------------------- | +| `pre-install` | Viene eseguito dopo il rendering dei modelli, ma prima che vengano create le risorse in Kubernetes | +| `post-install` | Viene eseguita dopo che tutte le risorse sono state caricate in Kubernetes | +| `pre-delete` | Viene eseguito su una richiesta di cancellazione prima che qualsiasi risorsa venga eliminata da Kubernetes | +| `post-delete` | Viene eseguita su una richiesta di cancellazione dopo che tutte le risorse della release sono state cancellate | +| `pre-upgrade` | Viene eseguita una richiesta di aggiornamento dopo che i template sono stati renderizzati, ma prima che le risorse siano aggiornate | +|`post-upgrade` | Viene eseguita una richiesta di aggiornamento dopo che tutte le risorse sono state aggiornate | +| `pre-rollback` | Viene eseguita una richiesta di rollback dopo che i template sono stati renderizzati, ma prima che le risorse siano state rollbackate | +| `post-rollback` | Viene eseguita una richiesta di rollback dopo che tutte le risorse sono state modificate | +| `test` | Viene eseguita quando viene invocato il sottocomando Helm test ([view test docs](/docs/chart_tests/)) | + +Si noti che l'hook `crd-install` è stato rimosso a favore della directory `crds/`. +in Helm 3._ + +## Hooks e Release Lifecycle + +Gli hook consentono allo sviluppatore del chart di eseguire operazioni in punti strategici del ciclo di vita della release. +Ad esempio, si consideri il ciclo di vita di +un'installazione di `helm`. Per impostazione predefinita, il ciclo di vita appare come segue: + +1. L'utente esegue `helm install foo` +2. Viene richiamata l'API di installazione della libreria Helm3. +Dopo alcune verifiche, la libreria restituisce i manifest `foo`. +4. La libreria carica le risorse risultanti in Kubernetes +5. La libreria restituisce l'oggetto di rilascio (e altri dati) al client. +6. Il client esce + +Helm definisce due hook per il ciclo di vita di `install`: `pre-install` e `post-install`. + Se lo sviluppatore della chart `foo` implementa entrambi gli hook, il ciclo di vita +viene modificato in questo modo: + +1. L'utente esegue `helm install foo` +2. Viene richiamata l'API di installazione della libreria Helm +3. Vengono installati i CRD nella directory `crds/`. +4. Dopo alcune verifiche, la libreria esegue il rendering dei template `foo`. +5. La libreria si prepara a eseguire gli hook `pre-install` (caricamento delle risorse hook + in Kubernetes) +6. La libreria ordina gli hook per peso (assegnando un peso pari a 0 per impostazione predefinita), + per tipo di risorsa e infine per nome in ordine crescente. +7. La libreria carica quindi per primo hook con il peso più basso (da negativo a positivo). +8. La libreria attende finché l'hook non è "pronto" (tranne che per i CRD). + +9. La libreria carica le risorse risultanti in Kubernetes. Si noti che se il flag + `--wait` è impostato, la libreria aspetterà che tutte le risorse siano in uno stato di + ready e non eseguirà l'hook `post-install` finché non saranno pronte. +10. La libreria esegue l'hook `post-install` (caricando le risorse dell'hook). +11. La libreria attende finché l'hook non è "pronto". +12. La libreria restituisce l'oggetto release (e altri dati) al client. +13. Il client esce + +Cosa significa aspettare che un hook sia pronto? Dipende dalla risorsa +dichiarata nell'hook. Se la risorsa è del tipo `Job` o `Pod`, Helm attenderà +finché non viene eseguita con successo fino al completamento. Se l'hook fallisce, il rilascio +fallirà. Si tratta di un'operazione _bloccante_, quindi il client Helm si metterà in pausa durante l'esecuzione del Job. + +Per tutti gli altri tipi, non appena Kubernetes contrassegna la risorsa come caricata (aggiunta o aggiornata), la risorsa è considerata come caricata. +o aggiornata), la risorsa è considerata "pronta". Quando molte risorse sono +dichiarate in un hook, le risorse vengono eseguite in serie. Se hanno un peso +(vedere sotto), vengono eseguite in ordine ponderato. +A partire da Helm 3.2.0 le risorse hook con lo stesso peso vengono installate nello stesso delle normali risorse non hook. Altrimenti, l'ordine non è +garantito. (In Helm 2.3.0 e successivi, sono ordinate alfabeticamente. Questo +comportamento, tuttavia, non è considerato vincolante e potrebbe cambiare in futuro). È considerata una buona pratica aggiungere un peso all'hook e impostarlo a `0` se il peso non è importante. + +### Le risorse degli hook non sono gestite con i rilasci corrispondenti + +Le risorse create da un hook non sono attualmente tracciate o gestite come parte del rilascio. +Una volta che Helm ha verificato che l'hook ha raggiunto lo stato di ready, lascerà la risorsa hook da sola. Il garbage collection delle risorse hook quando +il rilascio corrispondente viene cancellato, potrebbe essere aggiunto a Helm 3 in futuro, per cui +le risorse hook che non devono mai essere cancellate dovrebbero essere annotate con +`helm.sh/resource-policy: keep`. + +In pratica, ciò significa che se si creano delle risorse in un hook, non si può fare affidamento su `helm uninstall` per rimuovere le risorse. Per distruggere tali +risorse, è necessario o [aggiungere un'annotazione personalizzata `helm.sh/hook-delete-policy +personalizzata](#politiche-di-cancellazione-degli-hook) al file template dell'hook, oppure [impostare il campo time +to live (TTL) di una risorsa Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). + +## Scrivere un hook + +Gli hook sono semplicemente file manifest di Kubernetes con annotazioni speciali nella sezione +`metadati`.Essendo file di template, si possono usare tutte le normali funzionalità dei template, tra cui la lettura di `.Values`, `.Release` e +`.Template`. + +Per esempio, questo modello, memorizzato in `templates/post-install-job.yaml`, +dichiara un job da eseguire su `post-install`: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: "{{ .Release.Name }}" + labels: + app.kubernetes.io/managed-by: {{ .Release.Service | quote }} + app.kubernetes.io/instance: {{ .Release.Name | quote }} + app.kubernetes.io/version: {{ .Chart.AppVersion }} + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" + annotations: + # This is what defines this resource as a hook. Without this line, the + # job is considered part of the release. + "helm.sh/hook": post-install + "helm.sh/hook-weight": "-5" + "helm.sh/hook-delete-policy": hook-succeeded +spec: + template: + metadata: + name: "{{ .Release.Name }}" + labels: + app.kubernetes.io/managed-by: {{ .Release.Service | quote }} + app.kubernetes.io/instance: {{ .Release.Name | quote }} + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" + spec: + restartPolicy: Never + containers: + - name: post-install-job + image: "alpine:3.3" + command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] + +``` + +Ciò che rende questo template un hook è l'annotazione: + +```yaml +annotations: + "helm.sh/hook": post-install +``` + +Una risorsa può implementare più hook: + +```yaml +annotations: + "helm.sh/hook": post-install,post-upgrade +``` + +Allo stesso modo, non c'è limite al numero di risorse diverse che possono +implementare un determinato hook. Per esempio, si potrebbero dichiarare sia un segreto che una config map +come pre-install hook. + +Quando i chart secondari dichiarano degli hook, anche questi vengono valutati. Non c'è modo per un chart di +di livello superiore di disabilitare gli hook dichiarati dai sottochart. + +È possibile definire un peso per un hook, che aiuterà a costruire un ordine di esecuzione deterministico. I pesi si definiscono utilizzando la seguente +annotazione: + +```yaml +annotations: + "helm.sh/hook-weight": "5" +``` + +I pesi degli hook possono essere numeri positivi o negativi, ma devono essere rappresentati come +stringhe. Quando Helm avvia il ciclo di esecuzione degli hook di un particolare tipo, li ordina modo crescente. + +### Politiche di cancellazione degli hook + +È possibile definire delle politiche che determinano quando eliminare le +risorse degli hook corrispondenti. Le politiche di cancellazione degli hook sono definite usando la seguente +annotazione: + +```yaml +annotations: + "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded +``` + +È possibile scegliere uno o più valori di annotazione definiti: + +| Annotation Value | Description | +| ---------------------- | -------------------------------------------------------------------- | +| `before-hook-creation` | Elimina la risorsa precedente prima che venga lanciato un nuovo hook (impostazione predefinita) | +| `hook-succeeded` | Eliminare la risorsa dopo che l' hook è stato eseguito con successo | +| `hook-failed` | Elimina la risorsa se l'hook fallisce durante l'esecuzione | + +Se non è specificata alcuna annotazione relativa alla politica di cancellazione degli hook, si applica il comportamento `before-hook-creation` per impostazione predefinita. diff --git a/content/it/docs/topics/kubernetes_apis.md b/content/it/docs/topics/kubernetes_apis.md new file mode 100644 index 000000000..cff8255aa --- /dev/null +++ b/content/it/docs/topics/kubernetes_apis.md @@ -0,0 +1,147 @@ +--- +title: "API Kubernetes Deprecate" +description: "Spiega le API Kubernetes deprecate in Helm" +aliases: ["docs/k8s_apis/"] +--- + +Kubernetes è un sistema basato su API e l'API si evolve nel tempo per riflettere l'evoluzione della +comprensione dello spazio problematico. Questa è una pratica comune a tutti i +sistemi e le loro API. Una parte importante dell'evoluzione delle API è una buona politica e un processo di deprecazione +e un processo che informi gli utenti sulle modalità di implementazione delle modifiche alle API. In altre parole, i consumatori della vostra API devono sapere in anticipo e in quale release +un'API sarà rimossa o modificata. +In questo modo si elimina l'elemento sorpresa e +di cambiamenti che possono causare interruzioni per i consumatori. + +Il [Kubernetes deprecation +policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) +documenta come Kubernetes gestisce le modifiche alle versioni delle sue API. La politica di +deprecazione indica l'arco di tempo in cui le versioni delle API saranno supportate in seguito a un +annuncio di deprecazione. È quindi importante essere a conoscenza degli annunci di deprecazione e sapere quando le versioni delle API +e verranno rimosse, per ridurre al minimo l'effetto. + +Questo è un esempio di annuncio [per la rimozione di versioni API deprecate +deprecate in Kubernetes +1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) ed è stato +pubblicizzato alcuni mesi prima del rilascio. Queste API sarebbero state +annunciate per la deprecazione prima di questo rilascio. Questo dimostra che esiste una buona +politica che informa i consumatori sul supporto delle versioni delle API. + +I template di Helm specificano un [Kubernetes API +group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) +quando si definisce un oggetto Kubernetes, simile a un file manifest Kubernetes. Viene +specificato nel campo `apiVersion` del template e identifica la versione dell'API +dell'oggetto Kubernetes. Questo significa che gli utenti di Helm e i manteiner dei chart +Helm devono sapere quando le versioni delle API di Kubernetes sono state deprecate e in quale versione di Kubernetes saranno rimosse. + +## Maintainers dei chart + +È necessario controllare i chart per verificare la presenza di versioni dell'API Kubernetes che siano +deprecate o rimosse in una versione di Kubernetes. Le versioni dell'API trovate come deprecate +o che non sono più supportate, dovrebbero essere aggiornate alla versione supportata e rilasciata una nuova versione del chart. La versione dell'API è definita dai parametri +`kind` e `apiVersion`. Ad esempio, un oggetto `Deployment` rimosso +nella versione API di Kubernetes 1.16: + +```yaml +apiVersion: apps/v1beta1 +kind: Deployment +``` + +## Utenti Helm + +È necessario verificare i chart che si utilizzano (in modo simile a [chart +maintainers](#maintainers-dei-chart)) e identificare tutti i chart in cui le versioni delle API sono +deprecate o rimosse in una versione di Kubernetes. Per i chart identificati, è necessario verificare l'ultima versione del chart (che ha versioni API supportate) o aggiornare il chart da soli. + +Inoltre, è necessario verificare tutti i chart distribuiti (ad esempio, i rilasci di Helm). +verificando nuovamente la presenza di versioni API deprecate o rimosse. Questo può essere fatto +ottenendo i dettagli di una release con il comando `helm get manifest`. + +I mezzi per aggiornare una release di Helm alle API supportate dipendono dalle vostre scoperte +come segue: + +1. Se si trovano versioni API deprecate solo allora: + - Eseguire un `aggiornamento` con una versione del chart con versioni API di Kubernetes supportate. + +- Aggiungere una descrizione nell'aggiornamento, qualcosa del tipo di non eseguire un rollback a una versione di Helm precedente a quella attuale. + +2. Se si trova una o più versioni di API che sono state rimosse in una versione di Kubernetes + allora: + - Se si sta eseguendo una versione di Kubernetes in cui la versione o le versioni API sono ancora + disponibili (ad esempio, si è su Kubernetes 1.15 e si è scoperto di utilizzare API + che saranno rimosse in Kubernetes 1.16): + - Seguire la procedura del passo 1 + - In caso contrario (ad esempio, si sta già utilizzando una versione di Kubernetes dove + alcune versioni di API segnalate da `helm get manifest` non sono più disponibili): + - È necessario modificare il manifest di rilascio memorizzato nel cluster per + aggiornare le versioni delle API a quelle supportate. Vedere [Aggiornamento delle versioni API di un Release Manifest](#aggiornamento-delle-versioni-api-di-un-release-manifest) per maggiori dettagli. + +> Nota: in tutti i casi di aggiornamento di una release di Helm con API supportate, non si dovrebbe +mai eseguire il rollback della release a una versione precedente a quella con le API supportate. + +> Raccomandazione: La pratica migliore è quella di aggiornare le release che utilizzano API deprecate alle versioni API supportate, prima di eseguire l'aggiornamento a un cluster kubernetes che rimuove tali versioni API. + +Se non si aggiorna una release come suggerito in precedenza, si verificherà un errore +simile al seguente quando si tenta di aggiornare una release in una versione Kubernetes +in cui la versione o le versioni API sono state rimosse: + +``` +Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) +for this kubernetes version and it is therefore unable to build the kubernetes +objects for performing the diff. error from kubernetes: unable to recognize "": +no matches for kind "Deployment" in version "apps/v1beta1" +``` + +Helm fallisce in questo scenario perché tenta di creare una patch diff tra la release correntemente distribuita (che contiene le API di Kubernetes che vengono + +rimosse in questa versione di Kubernetes) rispetto al chart che si sta passando con le +versioni aggiornate/supportate delle API. Il motivo del fallimento è che quando Kubernetes rimuove una versione dell'API, la libreria client di Kubernetes Go non è più in grado di analizzare gli oggetti deprecati e quindi Helm fallisce quando chiama la libreria. + Helm purtroppo non è in grado di riprendersi da questa situazione e non è più in grado di gestire un simile rilascio. + Vedere [Aggiornamento delle versioni API di un Release Manifest](#aggiornamento-delle-versioni-api-di-un-release-manifest) per maggiori dettagli su come recuperare da questo scenario. + +## Aggiornamento delle versioni API di un Release Manifest + +Il manifest è una proprietà dell'oggetto Helm release che viene memorizzata nel campo dati di un Secret (predefinito) o di ConfigMap nel cluster. Il campo dati +contiene un oggetto gzipped codificato in base 64 (c'è un'ulteriore codifica in base 64 per un Secret). +Esiste un Secret/ConfigMap per release nel namespace della release. + +È possibile utilizzare il plugin Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) +per eseguire l'aggiornamento di una release alle API supportate. Consultare il readme +per maggiori dettagli. + +In alternativa, si possono seguire i seguenti passaggi manuali per eseguire l'aggiornamento delle versioni APIdi un manifest di rilascio. +A seconda della configurazione, si seguiranno +i passi per il Secret o la ConfigMap. + +- Ottenere il nome del Segreto o della Configmap associata all'ultima release distribuita : + - backend Secrets: `kubectl get secret -l + owner=helm,status=deployed,name= --namespace + | awk '{print $1}' | grep -v NAME` +- ConfigMap backend: `kubectl get configmap -l + owner=helm,status=deployed,name= --namespace + | awk '{print $1}' | grep -v NAME` +- Ottenere i dettagli dell'ultimo rilascio distribuito: + - Secrets backend: `kubectl get secret -n + -o yaml > release.yaml` + - ConfigMap Backend: `kubectl get configmap -n + -o yaml > release.yaml` +- Eseguire il backup del rilascio, nel caso sia necessario ripristinarlo se qualcosa va storto: + - `cp release.yaml release.bak` + - In caso di emergenza, ripristinare: `kubectl apply -f release.bak -n + ` +- Decodificare l'oggetto release: + - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d + | base64 -d | gzip -d > release.data.decoded` + - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 + -d | gzip -d > release.data.decoded` +- Cambia le versioni API dei manifest. Si può usare qualsiasi strumento (per esempio un editor) per apportare le modifiche. +Questo si trova nel campo `manifest` dell'oggetto release decodificato (`release.data.decoded`) +- Codifica l'oggetto release: + - Secrets backend: `cat release.data.decoded | gzip | base64 | base64` + - ConfigMap backend: `cat release.data.decoded | gzip | base64` +- Sostituire il valore della proprietà `data.release` nel file di rilascio distribuito +(`release.yaml`) con il nuovo oggetto di rilascio codificato +- Applicare il file allo nel namespace: `kubectl apply -f release.yaml -n + ` +- Eseguire un `helm upgrade` con una versione del chart con le versioni supportate di API Kubernetes +- Aggiungere una descrizione nell'aggiornamento, qualcosa del tipo di non eseguire un + rollback a una versione di Helm precedente a questa versione attuale diff --git a/content/it/docs/topics/kubernetes_distros.md b/content/it/docs/topics/kubernetes_distros.md new file mode 100644 index 000000000..f23a7a549 --- /dev/null +++ b/content/it/docs/topics/kubernetes_distros.md @@ -0,0 +1,100 @@ +--- +title: "Guida alle distribuzioni di Kubernetes" +description: "Raccoglie informazioni sull'utilizzo di Helm in ambienti Kubernetes specifici." +aliases: ["/docs/kubernetes_distros/"] +weight: 10 +--- + +Helm dovrebbe funzionare con qualsiasi [versione conforme di +Kubernetes](https://github.com/cncf/k8s-conformance) (che sia +[certificato](https://www.cncf.io/certification/software-conformance/) o meno). + +Questo documento raccoglie informazioni sull'uso di Helm in specifici ambienti Kubernetes. +Si prega di contribuire con ulteriori dettagli su qualsiasi distro (ordinata +in ordine alfabetico) se lo si desidera. + +## AKS + +Helm funziona con [Azure Kubernetes +Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). + +## DC/OS + +Helm è stato testato e funziona sulla piattaforma Mesospheres DC/OS 1.11 Kubernetes, +e non richiede alcuna configurazione aggiuntiva. + +## EKS + +Helm funziona con Amazon Elastic Kubernetes Service (Amazon EKS): +[Utilizzo di Helm con Amazon +EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). + +## GKE + +La piattaforma Kubernetes in hosting GKE di Google è nota per funzionare con Helm e non richiede +nessuna configurazione aggiuntiva. + +## `scripts/local-cluster` e Hyperkube + +È noto che Hyperkube configurato tramite `scripts/local-cluster.sh` funziona. Per +Hyperkube raw potrebbe essere necessario eseguire una configurazione manuale. + +## IKS + +Helm funziona con [IBM Cloud Kubernetes +Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). + +## KIND (Kubernetes IN Docker) + +Helm è regolarmente testato su [KIND](https://github.com/kubernetes-sigs/kind). + +## KubeOne + +Helm funziona senza problemi nei cluster impostati da KubeOne. + +## Kubermatic + +Helm funziona senza problemi nei cluster utente creati da Kubermatic. +Poiché i seed cluster possono essere impostati in modi diversi, il supporto di Helm dipende dalla loro configurazione. + +## MicroK8s + +Helm può essere abilitato in [MicroK8s](https://microk8s.io) usando il comando: +`microk8s.enable helm3` + +## Minikube + +Helm è testato e noto per funzionare con +[Minikube](https://github.com/kubernetes/minikube). Non richiede alcuna +configurazione aggiuntiva. + +## Openshift + +Helm funziona direttamente su OpenShift Online, OpenShift Dedicated, OpenShift +Container Platform (versione >= 3.6) o OpenShift Origin (versione >= 3.6). Per +saperne di più leggete [questo +blog](https://blog.openshift.com/getting-started-helm-openshift/) post. + +## Platform9 + +Helm è preinstallato con [Platform9 Managed +Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). +Platform9 fornisce l'accesso a tutti i chart ufficiali di Helm attraverso l'interfaccia utente dell'App Catalog +e la CLI nativa di Kubernetes. È possibile aggiungere manualmente altri repository. +Ulteriori dettagli sono disponibili in questo [articolo Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). + +## Ubuntu con `kubeadm` + +Kubernetes avviato con `kubeadm` è noto per funzionare sulle seguenti distribuzioni Linux: + +- Ubuntu 16.04 +- Fedora release 25 + +Alcune versioni di Helm (v2.0.0-beta2) richiedono di `esportare +KUBECONFIG=/etc/kubernetes/admin.conf` o creare un `~/.kube/config`. + +## VMware Tanzu Kubernetes Grid + +Helm funziona su VMware Tanzu Kubernetes Grid, TKG, senza bisogno di modifiche alla configurazione. +La Tanzu CLI può gestire l'installazione di pacchetti per [helm-controller](https://fluxcd.io/flux/components/helm/), consentendo di gestire in modo dichiarativo i rilasci dei chart Helm. +Ulteriori dettagli sono disponibili nella documentazione di TKG per [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). diff --git a/content/it/docs/topics/library_charts.md b/content/it/docs/topics/library_charts.md new file mode 100644 index 000000000..ded75bc00 --- /dev/null +++ b/content/it/docs/topics/library_charts.md @@ -0,0 +1,399 @@ +--- +title: "Library Charts" +description: "Spiega i library charts e gli esempi di utilizzo" +aliases: ["docs/library_charts/"] +weight: 4 +--- + +Un library chart è un tipo di [[Helm chart]] ({{< ref "/docs/topics/charts.md" >}}) +che definisce primitive o definizioni di chart che possono essere condivise dai template di Helm in altri chart. +Questo permette agli utenti di condividere frammenti di codice che possono essere +riutilizzabili tra i vari chart, evitando ripetizioni e mantenendo i chart +[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). + +Il library chart è stato introdotto in Helm 3 per riconoscere formalmente i chart comuni o + di aiuto che sono stati utilizzati dai manutentori dei chart a partire da Helm 2. Includendolo come + tipo di chartrafico, fornisce: +- un mezzo per distinguere esplicitamente tra chart comuni e chart applicativi +- Una logica per impedire l'installazione di un chart comune +- Nessun rendering di template in un chart comune, che potrebbe contenere artefatti di rilascio. +- Permettere ai chart dipendenti di utilizzare il contesto dell'importatore. + +Un manutentore di chart può definire un chart comune come un library chart ed essere sicuro che Helm gestirà il chart in modo standard e coerente. Ciò significa anche che + che le definizioni in un chart applicativo possono essere condivise cambiando +il tipo di chart. + +## Creare un Simple Library Chart + + Come accennato in precedenza, un library chart è un tipo di [Helm chart]({{< ref "/docs/topics/charts.md" >}}). +Ciò significa che si può iniziare creando un chart: + +```console +$ helm create mylibchart +Creating mylibchart +``` + +Si rimuoveranno prima tutti i file nella cartella `templates`, poiché in questo esempio si creeranno le + le nostre definizioni di template. + +```console +$ rm -rf mylibchart/templates/* +``` + +Anche il file values non sarà necessario. + +```console +$ rm -f mylibchart/values.yaml +``` + +Prima di lanciarci nella creazione di codice comune, facciamo un rapido ripasso di alcuni concetti rilevanti di Helm. Un [named template]({{< relref path="/docs/chart_template_guide/named_templates.md" lang="en" >}}) (talvolta chiamato partial +o un subtemplate) è semplicemente un template definito all'interno di un file e a cui viene dato un nome. +Nella cartella `templates/`, qualsiasi file che inizia con un trattino basso(_) +non è previsto come output di un file manifest di Kubernetes. Quindi, per convenzione, i template +e partials sono inseriti in un file `_*.tpl` o `_*.yaml`. + +In questo esempio, si codificherà un ConfigMap comune che crea una risorsa +ConfigMap vuota. Si definirà il ConfigMap comune nel file +`mylibchart/templates/_configmap.yaml` come segue: + +```yaml +{{- define "mylibchart.configmap.tpl" -}} +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} +data: {} +{{- end -}} +{{- define "mylibchart.configmap" -}} +{{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} +{{- end -}} +``` + +Il costrutto ConfigMap è definito nel template `mylibchart.configmap.tpl`. Si tratta di un semplice ConfigMap con una risorsa vuota, `data`.All'interno di questo file c'è +un altro modello denominato `mylibchart.configmap`. Questo named template +include un altro template chiamato `mylibchart.util.merge` che prenderà come argomenti due named template + il template che chiama `mylibchart.configmap` e +`mylibchart.configmap.tpl`. + +La helper function `mylibchart.util.merge` è un named template in +`mylibchart/templates/_util.yaml`. Si tratta di un pratico utility di [The Common Helm +Helper Chart](#the-common-helm-helper-chart) perché fonde i due template +e sovrascrive qualsiasi parte comune in entrambi: + +```yaml +{{- /* +mylibchart.util.merge will merge two YAML templates and output the result. +This takes an array of three values: +- the top context +- the template name of the overrides (destination) +- the template name of the base (source) +*/}} +{{- define "mylibchart.util.merge" -}} +{{- $top := first . -}} +{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} +{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} +{{- toYaml (merge $overrides $tpl) -}} +{{- end -}} +``` + +Questo è importante quando un chart vuole utilizzare codice comune che deve essere personalizzato con la sua configurazione. + +Infine, cambiamo il tipo di grafico in `library`. Questo richiede la modifica di +`mylibchart/Chart.yaml` come segue: + +```yaml +apiVersion: v2 +name: mylibchart +description: A Helm chart for Kubernetes + +# A chart can be either an 'application' or a 'library' chart. +# +# Application charts are a collection of templates that can be packaged into versioned archives +# to be deployed. +# +# Library charts provide useful utilities or functions for the chart developer. They're included as +# a dependency of application charts to inject those utilities and functions into the rendering +# pipeline. Library charts do not define any templates and therefore cannot be deployed. +# type: application +type: library + +# This is the chart version. This version number should be incremented each time you make changes +# to the chart and its templates, including the app version. +version: 0.1.0 + +# This is the version number of the application being deployed. This version number should be +# incremented each time you make changes to the application and it is recommended to use it with quotes. +appVersion: "1.16.0" +``` + +Il library chart è ora pronto per essere condiviso e la sua definizione di ConfigMap può essere riutilizzata. + +Prima di andare avanti, vale la pena di verificare se Helm riconosce il chart come un library chart: + +```console +$ helm install mylibchart mylibchart/ +Error: library charts are not installable +``` + +## Utilizzare il Simple Library Chart + +È il momento di utilizzare il library chart. Ciò significa creare nuovamente un chart: + +```console +$ helm create mychart +Creating mychart +``` + +Ripuliamo di nuovo i file dei template, perché vogliamo creare solo una ConfigMap: + +```console +$ rm -rf mychart/templates/* +``` + +Quando si vuole creare una semplice ConfigMap in un template di Helm, si potrebbe avere un aspetto +simile al seguente: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} +data: + myvalue: "Hello World" +``` + +Tuttavia, riutilizzeremo il codice comune già creato in `mylibchart`. +La ConfigMap può essere creata nel file `mychart/templates/configmap.yaml` +come segue: + +```yaml +{{- include "mylibchart.configmap" (list . "mychart.configmap") -}} +{{- define "mychart.configmap" -}} +data: + myvalue: "Hello World" +{{- end -}} +``` + +Si può notare che si semplifica il lavoro da fare, ereditando la definizione comune di +ConfigMap, che aggiunge proprietà standard per ConfigMap. Nel nostro +aggiungiamo la configurazione, in questo caso la chiave dati `myvalue` e il suo valore. +valore. La configurazione sovrascrive la risorsa vuota del ConfigMap comune. +Questo è possibile grazie alla funzione helper `mylibchart.util.merge` di cui abbiamo parlato nella sezione precedente. + +Per poter utilizzare il codice comune, è necessario aggiungere `mylibchart` come dipendenza. +Aggiungere quanto segue alla fine del file `mychart/Chart.yaml`: + +```yaml +# My common code in my library chart +dependencies: +- name: mylibchart + version: 0.1.0 + repository: file://../mylibchart +``` + +Questo include il library chart come dipendenza dinamica dal filesystem +che si trova nello stesso percorso padre del nostro chart dell'applicazione. Poiché stiamo includendo +il library chart come dipendenza dinamica, è necessario eseguire `helm dependency update`. +Questo copierà il library chart nella cartella `charts/`. + +```console +$ helm dependency update mychart/ +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "stable" chart repository +Update Complete. ⎈Happy Helming!⎈ +Saving 1 charts +Deleting outdated charts +``` + +Ora siamo pronti a distribuire il nostro chart. Prima dell'installazione, vale la pena di controllare +il template renderizzato. + +```console +$ helm install mydemo mychart/ --debug --dry-run +install.go:159: [debug] Original chart version: "" +install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart + +NAME: mydemo +LAST DEPLOYED: Tue Mar 3 17:48:47 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +affinity: {} +fullnameOverride: "" +image: + pullPolicy: IfNotPresent + repository: nginx +imagePullSecrets: [] +ingress: + annotations: {} + enabled: false + hosts: + - host: chart-example.local + paths: [] + tls: [] +mylibchart: + global: {} +nameOverride: "" +nodeSelector: {} +podSecurityContext: {} +replicaCount: 1 +resources: {} +securityContext: {} +service: + port: 80 + type: ClusterIP +serviceAccount: + annotations: {} + create: true + name: null +tolerations: [] + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +data: + myvalue: Hello World +kind: ConfigMap +metadata: + labels: + app: mychart + chart: mychart-0.1.0 + release: mydemo + name: mychart-mydemo +``` + +Questa sembra la ConfigMap che vogliamo, con la sovrascrittura dei dati di `myvalue: Hello +World`. Installiamolo: + +```console +$ helm install mydemo mychart/ +NAME: mydemo +LAST DEPLOYED: Tue Mar 3 17:52:40 2020 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: None +``` + +Possiamo recuperare il rilascio e vedere che il template effettivo è stato caricato. + +```console +$ helm get manifest mydemo +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +data: + myvalue: Hello World +kind: ConfigMap +metadata: + labels: + app: mychart + chart: mychart-0.1.0 + release: mydemo + name: mychart-mydemo + ``` + +## Vantaggi dei Library Chart + +A causa della loro incapacità di agire come chart autonomi, i library charts possono sfruttare le seguenti funzionalità: +- L'oggetto `.Files` fa riferimento ai percorsi dei file del chart padre, anziché al percorso locale del library charts. +- L'oggetto `.Values` è lo stesso del chart padre, a differenza dei +[subcharts]({{< relref path="/docs/chart_template_guide/subcharts_and_globals.md" lang="en" >}}) dell'applicazione che ricevono la sezione di valori configurata sotto la loro intestazione nel chart padre. + + +## The Common Helm Helper Chart + +```markdown +Note: Il repo Common Helm Helper Chart su Github non è più mantenuto attivamente e il repo è stato deprecato e archiviato. +``` + +Questo [chart] (https://github.com/helm/charts/tree/master/incubator/common) era +il pattern originale per i chart comuni. Fornisce utilità che riflettono le best practice + di sviluppo dei chart Kubernetes. Soprattutto, può essere utilizzato +quando si sviluppano i chart, in modo da avere a disposizione un pratico codice condiviso. + +Ecco un modo rapido per usarlo. Per maggiori dettagli, consultare il file +[README](https://github.com/helm/charts/blob/master/incubator/common/README.md). + +Creare di nuovo un chart: + +```console +$ helm create demo +Creating demo +``` + +Utilizziamo il codice comune della tabella degli helper. Per prima cosa, modificare il file di deployment +`demo/templates/deployment.yaml` come segue: + +```yaml +{{- template "common.deployment" (list . "demo.deployment") -}} +{{- define "demo.deployment" -}} +## Define overrides for your Deployment resource here, e.g. +apiVersion: apps/v1 +spec: + replicas: {{ .Values.replicaCount }} + selector: + matchLabels: + {{- include "demo.selectorLabels" . | nindent 6 }} + template: + metadata: + labels: + {{- include "demo.selectorLabels" . | nindent 8 }} + +{{- end -}} +``` + +E ora il file del service, `demo/templates/service.yaml`, come segue: + +```yaml +{{- template "common.service" (list . "demo.service") -}} +{{- define "demo.service" -}} +## Define overrides for your Service resource here, e.g. +# metadata: +# labels: +# custom: label +# spec: +# ports: +# - port: 8080 +{{- end -}} +``` + +Questi template mostrano come l'ereditarietà del codice comune dal helper chart +semplifica la codifica fino alla configurazione o alla personalizzazione delle risorse. + +Per poter utilizzare il codice comune, occorre aggiungere `common` come dipendenza. Aggiungere +quanto segue alla fine del file `demo/Chart.yaml`: + +```yaml +dependencies: +- name: common + version: "^0.0.5" + repository: "https://charts.helm.sh/incubator/" +``` + +Nota: è necessario aggiungere il repo `incubator` all'elenco dei repository Helm +(`helm repo add`). + +Poiché stiamo includendo il chart come dipendenza dinamica, dobbiamo eseguire +`helm dependency update`. Questo copierà il chart helper nella cartella `charts/`. + +Poiché l'helper chart utilizza alcuni costrutti di Helm 2, è necessario aggiungere il file +a `demo/values.yaml` per consentire il caricamento dell'immagine `nginx`, che +è stata aggiornata nello scaffold chart di Helm 3: + +```yaml +image: + tag: 1.16.0 +``` + +Si può verificare che i chart template siano corretti prima di distribuirli usando i comandi `helm lint` e `helm template`. + +Se è tutto a posto, si può procedere al deploy con `helm install`! + diff --git a/content/it/docs/topics/permissions_sql_storage_backend.md b/content/it/docs/topics/permissions_sql_storage_backend.md new file mode 100644 index 000000000..c971a678f --- /dev/null +++ b/content/it/docs/topics/permissions_sql_storage_backend.md @@ -0,0 +1,60 @@ +--- +title: "Gestione delle autorizzazioni per SQL storage backend" +description: "Scoprite come impostare le autorizzazioni quando si utilizza SQL storage backend." +aliases: ["/docs/permissions_sql_storage_backend/"] +--- + +Questo documento ha lo scopo di fornire agli utenti una guida per l'impostazione e la gestione dei permessi nell'utilizzo del SQL storage backend. + +## Introduzione + +Per gestire i permessi, Helm sfrutta la funzione RBAC di Kubernetes. Quando si utilizza +SQL storage backend, i ruoli di Kubernetes non possono essere utilizzati per determinare se un utente può accedere o meno a una determinata risorsa. +Questo documento mostra come creare e +gestire questi permessi. + +## Inizializzazione + +La prima volta che la CLI di Helm si connetterà al database, il client si accerterà che sia stato +precedentemente inizializzato. Se così non fosse, si occuperà automaticamente dell'impostazione necessaria. +Questa inizializzazione richiede i privilegi di amministratore +sullo schema pubblico, o almeno per essere in grado di: + +* creare una tabella +* concedere i privilegi sullo schema pubblico + +Dopo l'esecuzione della migrazione sul database, tutti gli altri ruoli possono utilizzare il client. + +## Concedere i privilegi a un utente non amministratore in PostgreSQL + +Per gestire i permessi, il driver del backend SQL sfrutta l'opzione +[RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security +Security Level) di PostgreSQL. RLS consente a tutti gli utenti di poter leggere/scrivere +dalla/alla stessa tabella, senza poter manipolare le stesse righe se non ne sono esplicitamente autorizzati a farlo. Per impostazione predefinita, qualsiasi ruolo che non sia stato +concesso esplicitamente con i giusti privilegi restituirà sempre un elenco vuoto +quando si esegue `helm list` e non sarà in grado di recuperare o modificare alcuna risorsa nel cluster. + +Vediamo come concedere a un determinato ruolo l'accesso a specifici spazi dei nomi: + +```sql +CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); +``` + +Questo comando concederà i permessi di lettura e scrittura a tutte le risorse che +soddisfano la condizione `namespace = 'default'' al ruolo `role'. Dopo aver creato +questa politica, l'utente che si connette al database per conto del ruolo +`role` sarà quindi in grado di vedere tutti i rilasci che risiedono nel namespace`default`. +quando si esegue `helm list`, e di modificarle e cancellarle. + +I privilegi possono essere gestiti in modo granulare con RLS, e si potrebbe essere interessati a +limitare l'accesso alle diverse colonne della tabella: +* key +* type +* body +* name +* namespace +* version +* status +* owner +* createdAt +* modifiedAt diff --git a/content/it/docs/topics/plugins.md b/content/it/docs/topics/plugins.md new file mode 100644 index 000000000..243be5407 --- /dev/null +++ b/content/it/docs/topics/plugins.md @@ -0,0 +1,375 @@ +--- +title: "Guida ai plugin di Helm" +description: "Introduce all'uso e alla creazione di plugin per estendere le funzionalità di Helm." +aliases: ["/docs/plugins/"] +weight: 12 +--- + +Un plugin di Helm è uno strumento a cui si può accedere tramite la CLI `helm`, ma che +non fa parte della base di codice di Helm. + +I plugin esistenti possono essere trovati nella sezione +[related]({{< relref path="related.md#helm-plugins" lang="en" >}}) o cercando su +[GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). + +Questa guida spiega come usare e creare i plugin. + +## Una panoramica + +I plugin di Helm sono strumenti aggiuntivi che si integrano perfettamente con Helm. Forniscono +un modo per estendere il set di funzionalità principali di Helm, senza però richiedere che ogni nuova +funzionalità sia scritta in in Go e di aggiungerle al core dello strumento. + +I plugin di Helm hanno le seguenti caratteristiche: + +- Possono essere aggiunti e rimossi da un'installazione di Helm senza impattare lo + strumento principale. +- Possono essere scritti in qualsiasi linguaggio di programmazione. +- Si integrano con Helm e vengono visualizzati in `helm help` e in altri luoghi. + +I plugin di Helm si trovano in `$HELM_PLUGINS`. È possibile trovarne il valore corrente, +compreso il valore predefinito quando non è impostato nell'ambiente, usando il comando +`helm env`. + +Il modello a plugin di Helm è parzialmente basato sul modello a plugin di Git. A tal fine, +a volte si sente parlare di `helm` come il _porcelain_ layer, mentre i plugin sono il _plumbing_. Questo è un modo abbreviato per suggerire che Helm fornisce +l'esperienza dell'utente e la logica di elaborazione di primo livello, mentre i plugin svolgono il +"lavoro di dettaglio" per eseguire un'azione desiderata. + +## Installazione di un plugin + +I plugin vengono installati con il comando `$ helm plugin install `. È possibile + inserire il percorso di un plugin sul file system locale o l'url di un repo VCS remoto. +Il comando `helm plugin install` clona o copia il plugin nel +percorso/url indicato in `$HELM_PLUGINS` + +```console +$ helm plugin install https://github.com/adamreese/helm-env +``` + +Se si dispone di una distribuzione tar del plugin, è sufficiente decomprimere il plugin nella cartella +`$HELM_PLUGINS`. È anche possibile installare i plugin in formato tar + direttamente da url, lanciando `helm plugin install +https://domain/path/to/plugin.tar.gz` + +## Building Plugins + +Per molti versi, un plugin è simile a un chart. Ogni plugin ha una cartella di primo livello + e un file `plugin.yaml`. + +``` +$HELM_PLUGINS/ + |- last/ + | + |- plugin.yaml + |- last.sh + +``` + +Nell'esempio precedente, il plugin `last` è contenuto in una cartella +chiamata `last`. Ha due file: `plugin.yaml` (obbligatorio) e uno script eseguibile, `last.sh` (opzionale). + +Il core di un plugin è un semplice file YAML chiamato `plugin.yaml`. Ecco un file YAML per un plugin che aiuta a ottenere il nome dell'ultimo rilascio: + +```yaml +name: "last" +version: "0.1.0" +usage: "get the last release name" +description: "get the last release name" +ignoreFlags: false +command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r" +platformCommand: + - os: linux + arch: i386 + command: "$HELM_BIN list --short --max 1 --date -r" + - os: linux + arch: amd64 + command: "$HELM_BIN list --short --max 1 --date -r" + - os: windows + arch: amd64 + command: "$HELM_BIN list --short --max 1 --date -r" +``` + +Il `name` è il nome del plugin. Quando Helm esegue questo plugin, questo è il nome che che utilizzerà (ad esempio, `helm NAME` invocherà questo plugin). + +_`name` deve corrispondere al nome della cartella._ Nell'esempio precedente, ciò significa che il plugin +con `name: last` dovrebbe essere contenuto in una cartella chiamata `last`. + +Restrizioni su `name`: + +- `name` non può duplicare uno dei comandi di primo livello esistenti `helm`. +- `name` deve essere limitato ai caratteri ASCII a-z, A-Z, 0-9, `_` e `-`. + +`version` è la versione SemVer 2 del plugin. `usage` e `description` sono +utilizzati per generare il testo di aiuto di un comando. + +Lo switch `ignoreFlags` indica a Helm di non passare flag al plugin. Quindi, se un plugin viene chiamato con `helm myplugin --foo` e `ignoreFlags: true`, allora +`--foo` viene silenziosamente scartato. + +Infine, cosa più importante, `platformCommand` o `command` è il comando +che questo plugin eseguirà quando viene chiamato. La sezione `platformCommand` +definisce le varianti di un comando specifiche per sistema operativo/architettura. Le seguenti +regole per decidere quale comando utilizzare: + +- Se `platformCommand` è presente, verrà cercato per primo. +- Se sia `os` che `arch` corrispondono alla piattaforma corrente, la ricerca si interrompe e viene utilizzato il comando. +- Se `os` corrisponde e non c'è una corrispondenza più specifica con `arch`, il comando verrà utilizzato. +- Se non viene trovata alcuna corrispondenza con `platformCommand`, verrà utilizzato il comando predefinito `command`. +- Se non vengono trovate corrispondenze in `platformCommand` e non è presente alcun `comando`, Helm uscirà con un errore. + +Le variabili d'ambiente vengono interpolate prima dell'esecuzione del plugin. Il modello +illustra la via preferenziale per indicare dove risiede il programma del plugin. + +Esistono alcune strategie per lavorare con i comandi dei plugin: + +- Se un plugin include un eseguibile, l'eseguibile per un `platformCommand:` o un `command:` deve essere impacchettato nella directory del plugin. +- La linea `platformCommand:` o `command:` avrà le variabili d'ambiente espanse prima dell'esecuzione. +`$HELM_PLUGIN_DIR` punterà alla cartella dei plugin. +- Il comando stesso non viene eseguito in una shell. Quindi non è possibile eseguire uno script. +- Helm inietta molte configurazioni nelle variabili d'ambiente. +Date un occhiata per vedere quali informazioni sono disponibili. +- Helm non fa alcuna ipotesi sul linguaggio del plugin. È possibile scriverlo + in qualsiasi linguaggio si preferisca. +- I comandi sono responsabili dell'implementazione di testi di aiuto specifici per `-h` e + `--help`. Helm userà `usage` e `description` per `helm help` e `helm + help myplugin`, ma non gestirà `helm myplugin --help`. + +## Downloader Plugins +Per impostazione predefinita, Helm è in grado di estrarre i chart tramite HTTP/S. A partire da Helm 2.4.0, i plugin +possono avere una capacità speciale di scaricare chart da fonti arbitrarie. + +I plugin devono dichiarare questa capacità speciale nel file `plugin.yaml` (livello superiore): + +```yaml +downloaders: +- command: "bin/mydownloader" + protocols: + - "myprotocol" + - "myprotocols" +``` + +Se tale plugin è installato, Helm può interagire con il repository usando lo schema di protocollo specificato invocando il `comand`. + Il repository speciale +deve essere aggiunto in modo simile a quelli normali: `helm repo add favoritemyprotocol://example.com/` Le regole per i repository speciali sono le stesse di quelli regolari: Helm deve essere in grado di scaricare il file `index.yaml` per poter +scoprire e memorizzare nella cache l'elenco dei chart disponibili. + +Il comando definito sarà invocato con il seguente schema: `command certFile +keyFile caFile full-URL`. Le credenziali SSL provengono dalla definizione del repo +memorizzate in `$HELM_REPOSITORY_CONFIG`. +(cioè, `$HELM_CONFIG_HOME/repositories.yaml`). Un downloader plugin +dovrebbe scaricare il contenuto grezzo su stdout e segnalare gli errori su stderr. + +Il comando downloader supporta anche subcommands o argomenti, consentendo di +specificare ad esempio il subcommand `bin/mydownloader -d` nel file `plugin.yaml`. Questo +è utile se si vuole usare lo stesso eseguibile per il comando principale del plugin e per +il comando downloader, ma con un subcommand diverso per ciascuno. + +## Variabili d'ambiente + +Quando Helm esegue un plugin, passa l'environment esterno al plugin e inietta alcune variabili d'ambiente aggiuntive. + +Variabili come `KUBECONFIG` sono impostate per il plugin se sono impostate nell'ambiente esterno. + +Viene garantito che le seguenti variabili siano impostate: + +- `HELM_PLUGINS`:Il percorso della cartella dei plugin. +- `HELM_PLUGIN_NAME`: Il nome del plugin, come invocato da `helm`. Quindi `helm + myplug` avrà il nome breve `myplug`. +- `HELM_PLUGIN_DIR`: La directory che contiene il plugin. +- `HELM_BIN`: Il percorso del comando `helm` (come eseguito dall'utente). +- `HELM_DEBUG`: Indica se il flag di debug è stato impostato da helm. +- `HELM_REGISTRY_CONFIG`: Il percorso della configurazione del registry (se + se si usa). Si noti che l'uso di Helm con i registry è una funzione sperimentale. +- `HELM_REPOSITORY_CACHE`: Il percorso dei file della cache del repository. +- `HELM_REPOSITORY_CONFIG`: Il percorso del file di configurazione del repository. +- `HELM_NAMESPACE`: Il namespace dato al comando `helm` (generalmente usando il flag + il flag `-n`). +- `HELM_KUBECONTEXT`: Il nome del contesto di configurazione di Kubernetes dato al comando + `helm`. + +Inoltre, se è stato specificato esplicitamente un file di configurazione di Kubernetes, esso verrà +sarà impostato come variabile `KUBECONFIG`. + +## Una nota sul flag parsing + +Quando si esegue un plugin, Helm analizza i flag globali per il proprio uso. Nessuno di questi + flag viene passato al plugin. + +- `--debug`: Se viene specificato, `$HELM_DEBUG` viene impostato a `1`. +- `--registry-config`: Viene convertito in `$HELM_REGISTRY_CONFIG`. +- `--repository-cache`: Viene convertito in `$HELM_REPOSITORY_CACHE`. +- `--repository-config`: Viene convertito in `$HELM_REPOSITORY_CONFIG`. +- `--namespace` e `-n`: Viene convertito in `$HELM_NAMESPACE`. +- `--kube-context`: Viene convertito in `$HELM_KUBECONTEXT`. +- `--kubeconfig`: Viene convertito in `$KUBECONFIG`. + +I plugin dovrebbero mostrare un testo di aiuto e poi uscire per `-h` e `--help`. In tutti gli +altri casi, i plugin possono usare i flag come meglio credono. + +## Supporto per l'autocompletamento della shell + +A partire da Helm 3.2, un plugin può opzionalmente fornire il supporto per il completamento automatico della shell come parte del meccanismo di autocompletamento di Helm. + +### Autocompletamento statico + +Se un plugin fornisce i propri flag e/o sotto-comandi, può informare Helm di questi, disponendo di un file `completion.yaml` che si trova nella cartella principale del plugin. +Il file `completion.yaml` ha la forma: + +```yaml +name: +flags: +- +- +validArgs: +- +- +commands: + name: + flags: + - + - + validArgs: + - + - + commands: + +``` + +Note: +1. Tutte le sezioni sono facoltative ma devono essere fornite se applicabili. +1. I flag non devono includere il prefisso `-` o `--`. +1. Possono e devono essere specificati flag sia brevi che lunghi. Un flag breve non deve necessariamente + essere associato alla corrispondente forma lunga, ma entrambe le forme devono essere + elencate. +1. I flag non devono essere ordinati in alcun modo, ma devono essere elencati nel punto corretto della gerarchia dei sottocomandi del file. +1. I flag globali esistenti di Helm sono già gestiti dal meccanismo di autocompletamento di Helm, quindi i plugin non devono specificare i seguenti flag `--debug`, +`--namespace` o `-n`, `--kube-context` e `--kubeconfig`, o qualsiasi altro flag globale. + +1. L'elenco `validArgs` fornisce un elenco statico di possibili completamenti del + primo parametro di un sottocomando. Non è sempre possibile + fornire tale elenco in anticipo (vedere la sezione [Completamento dinamico](#completamento-dinamico)), nel qual caso la sezione +`validArgs` può essere omessa. + +Il file `completion.yaml` è del tutto opzionale. Se non viene fornito, Helm +non fornirà semplicemente il completamento automatico della shell per il plugin (a meno che [Completamento dinamico](#completamento-dinamico) sia supportato dal plugin). Inoltre, aggiungendo un file +`completion.yaml` è compatibile con le versioni precedenti e non avrà alcun impatto sul comportamento del plugin quando si utilizzano versioni precedenti di helm. + +A titolo di esempio, per il [`fullstatus +](https://github.com/marckhouzam/helm-fullstatus) che non ha sottocomandi, ma accetta gli stessi flag del comando `helm status`, il file +file `completion.yaml` è: + +```yaml +name: fullstatus +flags: +- o +- output +- revision +``` + +Un esempio più complesso per il +[`2to3`](https://github.com/helm/helm-2to3), ha un file `completion.yaml` del tipo: + +```yaml +name: 2to3 +commands: +- name: cleanup + flags: + - config-cleanup + - dry-run + - l + - label + - release-cleanup + - s + - release-storage + - tiller-cleanup + - t + - tiller-ns + - tiller-out-cluster +- name: convert + flags: + - delete-v2-releases + - dry-run + - l + - label + - s + - release-storage + - release-versions-max + - t + - tiller-ns + - tiller-out-cluster +- name: move + commands: + - name: config + flags: + - dry-run +``` + +### Completamento dinamico + +Sempre a partire da Helm 3.2, i plugin possono fornire il proprio completamento automatico della shell. +L'autocompletamento dinamico della shell è il completamento dei valori dei parametri o dei flag che non possono essere +definiti in anticipo. Ad esempio, +il completamento dei nomi delle release di helm attualmente disponibili sul cluster. + +Affinché il plugin supporti l'autocompletamento dinamico, deve fornire un file + **eseguibile** chiamato `plugin.complete` nella sua directory principale. Quando lo script di completamento di +Helm richiede un completamento dinamico per il plugin, eseguirà il file `plugin.complete`., passandogli la riga di comando che deve essere completata. L'eseguibile `plugin.complete` dovrà avere la logica per +determinare quali siano le scelte corrette per il completamento e inviarle allo standard +per essere utilizzato dallo script di completamento di Helm. + +Il file `plugin.complete` è del tutto opzionale. Se non viene fornito, Helm +non fornirà il completamento automatico dinamico per il plugin. Inoltre, l'aggiunta di un file `plugin.complete` è compatibile con le versioni precedenti e non avrà alcun impatto sul comportamento del plugin quando si utilizza +con versioni precedenti di Helm. + +L'output dello script `plugin.complete` dovrebbe essere un elenco separato da new-line char +come ad esempio: + +``` +rel1 +rel2 +rel3 +``` + +Quando viene richiamato `plugin.complete`, l'ambiente del plugin viene impostato come quando viene richiamato lo script principale del plugin. +Pertanto, le variabili `$HELM_NAMESPACE`, +`$HELM_KUBECONTEXT` e tutte le altre variabili del plugin saranno già impostate e i corrispondenti flag globali saranno rimossi. + +Il file `plugin.complete` può essere in qualsiasi forma eseguibile; può essere uno script di shell, un programma Go o qualsiasi altro tipo di programma che Helm può eseguire. Il file + `plugin.complete` ***deve*** avere i permessi di esecuzione per l'utente. Il file + `plugin.complete` ***deve*** terminare con codice di successo (valore 0). + +In alcuni casi, il completamento dinamico richiederà di ottenere informazioni dal cluster Kubernetes.Ad esempio, il plugin `helm fullstatus` richiede come input il nome di una release. +Nel plugin `fullstatus`, per il suo script `plugin.complete` +fornisce il completamento per i nomi dei rilasci correnti, può semplicemente eseguire `helm list -q` e produrre il risultato. + +Se si vuole usare lo stesso eseguibile per l'esecuzione del plugin e per il suo completamento, lo script +`plugin.complete` deve richiamare l'eseguibile del plugin principale con qualche parametro o flag speciale; quando l'eseguibile principale del plugin +rileva il parametro o il flag speciale, saprà di dover eseguire il completamento. Nel nostro + esempio, `plugin.complete` potrebbe essere implementato in questo modo: + +```sh +#!/usr/bin/env sh + +# "$@" is the entire command-line that requires completion. +# It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. +$HELM_PLUGIN_DIR/status.sh --complete "$@" +``` + +Il vero script del plugin `fullstatus` (`status.sh`) deve quindi cercare il flag `--complete` +e, se lo trova, stampare il completamento corretto. + +### Suggerimenti e trucchi + +1. La shell filtra automaticamente le scelte di completamento che non corrispondono all'input dell'utente. Un plugin può quindi restituire tutti i completamenti rilevanti senza + rimuovere quelli che non corrispondono all'input dell'utente. Ad esempio, se la riga di comando è `helm fullstatus ngin`, lo script `plugin.complete` può + stampare *tutti* i nomi dei rilasci (dello spazio dei nomi `default`), non solo quelli che iniziano con `ngin`. +; la shell manterrà solo quelli che iniziano con + `ngin`. +1. Per semplificare il supporto al completamento dinamico, specialmente se si ha un plugin complesso, + si può fare in modo che lo script `plugin.complete` chiami lo script principale del plugin e richieda le scelte di completamento. + Si veda la sezione [Completamento dinamico](#completamento-dinamico) per un esempio. +1. Per eseguire il debug del completamento dinamico e del file `plugin.complete`, si può eseguire il comando + seguente per vedere i risultati del completamento: + - `helm __complete `. Per esempio: + - `helm __complete fullstatus --output js`, + - `helm __complete fullstatus -o json ""`. diff --git a/content/it/docs/topics/provenance.md b/content/it/docs/topics/provenance.md new file mode 100644 index 000000000..e8842ff19 --- /dev/null +++ b/content/it/docs/topics/provenance.md @@ -0,0 +1,267 @@ +--- +title: "Provenienza e integrità di Helm" +description: "Descrive come verificare l'integrità e l'origine di un chart." +aliases: ["/docs/provenance/"] +weight: 5 +--- + +Helm dispone di strumenti di provenienza che aiutano gli utenti dei chart a verificare l'integrità e l'origine di un pacchetto. +Utilizzando strumenti standard del settore basati su PKI, GnuPG e gestori di pacchetti ben noti, Helm è in grado di generare e verificare i file di firma. + +## Panoramica + +L'integrità viene stabilita confrontando un chart con un record di provenienza. I record di provenienza +sono memorizzati in _file di provenienza_, che vengono memorizzati insieme a un chart impacchettato. Per esempio, se un chart è chiamato `myapp-1.2.3.tgz`, il suo file di provenienza +sarà `myapp-1.2.3.tgz.prov`. + +I file di provenienza sono generati al momento dell'impacchettamento (`helm package --sign ...`), +e possono essere controllati da più comandi, in particolare `helm install --verify`. + +## Il flusso di lavoro + +Questa sezione descrive un potenziale flusso di lavoro per utilizzare i dati di provenienza in modo efficace. + +Prerequisiti: + +- Una coppia di chiavi PGP valida in un formato binario (non in formato ASCII) +- Lo strumento a riga di comando `helm` +- Strumenti a riga di comando GnuPG (opzionale) +- Strumenti a riga di comando Keybase (opzionale) + +**NOTA:** Se la vostra chiave privata PGP ha una passphrase, vi sarà richiesto di + inserire tale passphrase per tutti i comandi che supportano l'opzione `--sign'. + +La creazione di un nuovo chart è identica a quella precedente: + +```console +$ helm create mychart +Creating mychart +``` + +Una volta pronti per l'impacchettamento, aggiungere il flag `-sign' a `helm package'. Inoltre, specificare il nome con cui è conosciuta la chiave di firma e il portachiavi che contiene la +corrispondente chiave privata: + +```console +$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart +``` + +**Nota:** Il valore dell'argomento `--key` deve essere una sottostringa del `uid` +della chiave desiderata (nell'output di `gpg --list-keys`), ad esempio il nome o l'email. **L'impronta digitale non può essere usata.** + +**TIP:** per gli utenti di GnuPG, il portachiavi segreto si trova in `~/.gnupg/secring.gpg`. È possibile +usare `gpg --list-secret-keys` per elencare le chiavi in proprio possesso. + +**Attenzione:** GnuPG v2 memorizza il portachiavi segreto usando un nuovo formato `kbx`nel percorso predefinito `~/.gnupg/pubring.kbx`. Utilizzare il seguente comando +per convertire il portachiavi nel formato gpg tradizionale: + +```console +$ gpg --export >~/.gnupg/pubring.gpg +$ gpg --export-secret-keys >~/.gnupg/secring.gpg +``` + +A questo punto, si dovrebbero vedere sia `mychart-0.1.0.tgz` che +`mychart-0.1.0.tgz.prov`. Entrambi i file dovrebbero essere caricati nel repository desiderato. + +È possibile verificare un chart usando `helm verify`: + +```console +$ helm verify mychart-0.1.0.tgz +``` + +Una verifica fallita si presenta così: + +```console +$ helm verify topchart-0.1.0.tgz +Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" +``` + +Per verificare durante un'installazione, usare il flag `--verify`. + +```console +$ helm install --generate-name --verify mychart-0.1.0.tgz +``` + +Se il portachiavi contenente la chiave pubblica associata al grafico firmato non si trova nella posizione predefinita, potrebbe essere necessario indicare il portachiavi con `--keyring PATH` come nell'esempio del pacchetto `helm`. + +Se la verifica fallisce, l'installazione verrà interrotta prima che il chart venga +renderizzato. + +### Utilizzo delle credenziali di Keybase.io + +Il servizio [Keybase.io](https://keybase.io) semplifica la creazione di una catena di fiducia per un'identità crittografica. Le credenziali di Keybase possono essere usate per firmare +chart. + +Prerequisiti: + +- Un account Keybase.io configurato +- GnuPG installato localmente +- La CLI `keybase` installata localmente + +#### Firmare i pacchetti + +Il primo passo è importare le chiavi del keybase nel portachiavi GnuPG locale: + +```console +$ keybase pgp export -s | gpg --import +``` + +Questo convertirà la vostra chiave Keybase nel formato OpenPGP, e poi la importerà +localmente nel file `~/.gnupg/secring.gpg`. + +Si può verificare eseguendo `gpg --list-secret-keys`. + +```console +$ gpg --list-secret-keys +/Users/mattbutcher/.gnupg/secring.gpg +------------------------------------- +sec 2048R/1FC18762 2016-07-25 +uid technosophos (keybase.io/technosophos) +ssb 2048R/D125E546 2016-07-25 +``` + +Si noti che la chiave segreta avrà una stringa identificativa: + +``` +technosophos (keybase.io/technosophos) +``` + +Questo è il nome completo della chiave. + +Successivamente, si può impacchettare e firmare un chart con `helm package`. Assicuratevi di usare almeno + una parte di questi nomi in `--key`. + +```console +$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart +``` + +Di conseguenza, il comando `package` dovrebbe produrre sia un file `.tgz` che un file `.tgz.prov`. + +#### Verifica dei pacchetti + +È possibile utilizzare una tecnica simile anche per verificare un chart firmato con la chiave +Keybase di qualcun altro. Supponiamo di voler verificare un pacchetto firmato da +`keybase.io/technosophos`. Per farlo, utilizzate lo strumento `keybase`: + +```console +$ keybase follow technosophos +$ keybase pgp pull +``` + +Il primo comando qui sopra traccia l'utente `technosophos`. Successivamente `keybase pgp pull` +scarica le chiavi OpenPGP di tutti gli account che si seguono, inserendole nel proprio portachiavi GnuPG (`~/.gnupg/pubring.gpg`). + +A questo punto, è possibile utilizzare `helm verify` o uno qualsiasi dei comandi con il flag +`--verify`: + +```console +$ helm verify somechart-1.2.3.tgz +``` + +### Motivi per cui un chart non può essere verificato + +Queste sono le ragioni più comuni del fallimento. + +- Il file `.prov' è mancante o corrotto. Questo indica che qualcosa è + configurato male o che il manteiner originale non ha creato un file di provenienza. +- La chiave usata per firmare il file non è presente nel portachiavi. Questo indica che l'entità che ha firmato il chart non è qualcuno di cui avete già segnalato la fiducia. +- La verifica del file `.prov` non è riuscita. Questo indica che c'è qualcosa di + sbagliato nel chart o nei dati di provenienza. +- Gli hash dei file nel file di provenienza non corrispondono all'hash del file + dell'archivio. Ciò indica che l'archivio è stato manomesso. + +Se la verifica fallisce, c'è motivo di diffidare del pacchetto. + +## Il file di provenienza + +Il file di provenienza contiene il file YAML di un chart e diverse informazioni di verifica. I file di provenienza sono progettati per essere +generati automaticamente. + +Vengono aggiunti i seguenti dati di provenienza: + +* Il file del chart (`Chart.yaml`) è incluso per dare sia all'uomo che agli strumenti una facile visione del contenuto del chart. +* La firma (SHA256, proprio come Docker) del pacchetto del chart (il file `.tgz`) è inclusa e può essere usata per verificare l'integrità del pacchetto chart. +* L'intero corpo del file è firmato con l'algoritmo usato da OpenPGP (vedi + [Keybase.io](https://keybase.io) per un modo emergente di rendere semplice la firma crittografica e la verifica). + +La combinazione di questi elementi fornisce agli utenti le seguenti garanzie: + +* Il pacchetto stesso non è stato manomesso (checksum del pacchetto `.tgz`). +* L'entità che ha rilasciato il pacchetto è nota (tramite la firma GnuPG/PGP). + +Il formato del file è simile a questo: + +``` +Hash: SHA512 + +apiVersion: v2 +appVersion: "1.16.0" +description: Sample chart +name: mychart +type: application +version: 0.1.0 + +... +files: + mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 +-----BEGIN PGP SIGNATURE----- + +wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd +nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI +mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 +cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi +hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D +qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= +=aHfz +-----END PGP SIGNATURE----- +``` + +Si noti che la sezione YAML contiene due documenti (separati da `...\n`). Il primo file è il contenuto di `Chart.yaml`.Il secondo è il checksum, una mappa di +nomi di file e digest SHA-256 del contenuto di quel file al momento del packaging. + +Il blocco della firma è una firma PGP standard, che fornisce [resistenza alla manomissione](https://www.rossde.com/PGP/pgp_signatures.html). + +## Chart Repositories + +I chart repository servono come raccolta centralizzata dei chart Helm. + +I chart repository devono consentire di fornire i file di provenienza via HTTP tramite una +una richiesta specifica e devono renderli disponibili nello stesso percorso URI del chart. + +Ad esempio, se l'URL di base di un pacchetto è`https://example.com/charts/mychart-1.2.3.tgz`, il file di provenienza, se esiste, DEVE essere accessibile all'indirizzo +`https://example.com/charts/mychart-1.2.3.tgz.prov`. + +Dal punto di vista dell'utente finale, `helm install --verify myrepo/mychart-1.2.3` +dovrebbe portare al download sia del chart che del file di provenienza, senza alcuna +configurazione o azione aggiuntiva da parte dell'utente. + +### Firme nei registri basati su OCI + +Se si pubblicano charts in un [registro basato su OCI]({{< ref "registries.md" >}}), si può usare il +[plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) +per pubblicare la provenienza su [sigstore](https://sigstore.dev/). +[Come descritto nella documentazione](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), il processo di creazione della provenienza e di firma con una chiave GPG sono comuni, ma il comando `helm sigstore upload` può essere usato per pubblicare la provenienza in un registro di trasparenza immutabile. + +## Stabilire autorità e autenticità + +Quando si ha a che fare con i sistemi a catena di fiducia, è importante essere in grado di +stabilire l'autorità di un firmatario. O, per dirla in parole povere, il sistema di cui sopra +si basa sul fatto che ci si fida della persona che ha firmato il chart. Questo, a sua volta significa che bisogna fidarsi della chiave pubblica del firmatario. + +Una delle decisioni progettuali di Helm è stata quella di non inserirsi nella catena di fiducia come una parte necessaria. +Non vogliamo essere +"l'autorità di certificazione" per tutti i firmatari di chart. Al contrario, siamo decisamente favorevoli a un modello decentralizzato, e questo è uno dei motivi per cui abbiamo scelto OpenPGP come +tecnologia di base. Quindi, quando si tratta di stabilire l'autorità, abbiamo + lasciato questo passo più o meno indefinito in Helm 2 (una decisione portata avanti in +Helm 3). + +Tuttavia, abbiamo alcune indicazioni e raccomandazioni per coloro che sono interessati a utilizzare +il sistema di provenienza: + +- La piattaforma [Keybase](https://keybase.io) fornisce un archivio pubblico centralizzato per le informazioni sulla fiducia. + +- È possibile utilizzare Keybase per memorizzare le proprie chiavi o per ottenere le chiavi pubbliche di altri. +- Keybase ha anche una favolosa documentazione disponibile +- Anche se non l'abbiamo testata, la funzione "sito web sicuro" di Keybase potrebbe essere usata + per fornire i chart di Helm. +- L'idea di base è che un "revisore di chart" ufficiale firmi i chart con la sua chiave e il file di provenienza risultante venga caricato nel chart repository. +- Si è lavorato sull'idea che un elenco di chiavi di firma valide possa essere incluso nel file `index.yaml` di un repository. \ No newline at end of file diff --git a/content/it/docs/topics/rbac.md b/content/it/docs/topics/rbac.md new file mode 100644 index 000000000..1fc3e3611 --- /dev/null +++ b/content/it/docs/topics/rbac.md @@ -0,0 +1,178 @@ +--- +title: "Role-based Access Control" +description: "Spiega come Helm interagisce con il Role-Based Access Control di Kubernetes." +aliases: ["/docs/rbac/"] +weight: 11 +--- + +In Kubernetes, l'assegnazione di ruoli a un utente o a un account di servizio specifico per un'applicazione +è una pratica ottimale per garantire che l'applicazione operi nell'ambito + specificato. Per saperne di più sui permessi dei service account leggere la [ +documentazione ufficiale di Kubernetes] (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). + +A partire da Kubernetes 1.6, il Role-based Access Control è abilitato per impostazione predefinita. +RBAC consente di specificare quali tipi di azioni sono consentite a seconda dell'utente e del suo ruolo nell'organizzazione. + +Con RBAC, è possibile + +- concedere operazioni privilegiate (creazione di risorse a livello di cluster, come nuovi ruoli) + agli amministratori +- limitare la capacità di un utente di creare risorse (pod, volumi persistenti, + deployment) a specifici namespace o in ambiti a livello di cluster (quote di risorse, ruoli, definizioni di risorse personalizzate). +- limitare la capacità di un utente di visualizzare le risorse in namespace specifici o a livello di cluster. + +Questa guida è destinata agli amministratori che desiderano limitare l'ambito di interazione di un utente con l'API Kubernetes. + +## Gestione degli account utente + +Tutti i cluster Kubernetes hanno due categorie di utenti: i service accounts gestiti da Kubernetes e gli utenti normali. + +Si presume che gli utenti normali siano gestiti da un servizio esterno e indipendente. Un amministratore che distribuisce le chiavi private, uno user store come Keystone o Google +Accounts, persino un file con un elenco di nomi utente e password. A questo proposito, Kubernetes non dispone di oggetti che rappresentano i normali account utente. +Gli utenti normali non possono essere aggiunti a un cluster tramite una chiamata API. + +Al contrario, i service account sono utenti gestiti dall'API di Kubernetes. Sono + vincolati a specifici namespace e creati automaticamente dal server API o +manualmente tramite chiamate API. I service account sono legati a un insieme di credenziali memorizzate come Secrets, che vengono montate nei pod e che consentono ai processi in cluster di +interagire con l'API di Kubernetes. + +Le richieste API sono legate a un utente normale o a un service account, oppure sono trattate come richieste anonime. + Questo significa che ogni processo all'interno o all'esterno del +cluster, dall'utente umano che digita `kubectl` su una workstation, alle kubelets sui nodi, ai membri del sistema di controllo devono autenticarsi quando effettuano richieste +al server API, o essere trattato come un utente anonimo. + +## Ruoli, ClusterRoles, RoleBindings e ClusterRoleBindings + +In Kubernetes, gli account utente e i service account possono visualizzare e modificare solo le risorse a cui è stato concesso l'accesso. Questo accesso viene concesso attraverso l'uso di Ruoli e RoleBindings. I ruoli e i RoleBindings sono vincolati a un particolare +namespace, che concedono agli utenti la possibilità di visualizzare e/o modificare le risorse all'interno di quel namespace a cui il ruolo fornisce l'accesso. + +A livello di cluster, questi sono chiamati ClusterRoles e ClusterRoleBindings. +La concessione di un ClusterRole a un utente garantisce l'accesso alla visualizzazione e/o alla modifica di risorse nell'intero cluster. È inoltre necessario per visualizzare e/o modificare le risorse a livello del cluster (namespace, quote di risorse, nodi). + + I ClusterRole possono essere vincolati a un particolare namespace attraverso un riferimento in un +RoleBinding. I ClusterRoles predefiniti `admin`, `edit` e `view` sono comunemente utilizzati in questo modo. + +Questi sono alcuni ClusterRoles disponibili di default in Kubernetes. Sono + intesi come ruoli rivolti all'utente. Includono i ruoli di super-utente +(`cluster-admin`) e ruoli con accesso più granulare (`admin`, `edit`, +`view`). + +| Default ClusterRole | Default ClusterRoleBinding | Description +|---------------------|----------------------------|------------- +| `cluster-admin` | `system:masters` group | Consente l'accesso al superutente per eseguire qualsiasi azione su qualsiasi risorsa. Se usato in un ClusterRoleBinding, dà il pieno controllo su ogni risorsa del cluster e su tutti i namespace. Se usato in un RoleBinding, dà il pieno controllo su ogni risorsa nel namespace del rolebinding, compreso namespace stesso. +| `admin` | Nessuno | Consente l'accesso come amministratore, da concedere all'interno di un namespace utilizzando un RoleBinding. Se usato in un RoleBinding, consente l'accesso in lettura/scrittura alla maggior parte delle risorse di un namespace, compresa la possibilità di creare ruoli e rolebindings all'interno del namespace. Non consente l'accesso in scrittura alla quota di risorse o al namespace stesso. +| `edit` | Nessuno | Consente l'accesso in lettura/scrittura alla maggior parte degli oggetti di un namespace. Non consente di visualizzare o modificare i ruoli o i rolebindings. +| `view` | Nesuno | Consente l'accesso in sola lettura alla maggior parte degli oggetti di un namespace. Non consente di visualizzare i ruoli o i rolebindings. Non consente di visualizzare i secret, poiché questi sono a valore elevato. + +## Limitare l'accesso di un account utente utilizzando RBAC + +Ora che abbiamo compreso le basi del controllo degli accessi basato sui ruoli, discutiamo di come un amministratore può limitare l'accesso di un utente. + +### Esempio: Concedere a un utente l'accesso in lettura/scrittura a un particolare namespace + +Per limitare l'accesso di un utente a un particolare namespace, si può usare il ruolo +`edit` o il ruolo `admin`. Se i vostri chart creano o interagiscono con i Ruoli e i +Rolebindings, si vorrà utilizzare il ClusterRole `admin`. + +Inoltre, è possibile creare un RoleBinding con accesso `cluster-admin`. +Concedere a un utente l'accesso `cluster-admin` all'ambito del namespace fornisce il pieno controllo su tutte le risorse del namespace, compreso il namespace stesso. + +In questo esempio, creeremo un utente con il ruolo `edit`. Per prima cosa, creare il namespace: + +```console +$ kubectl create namespace foo +``` + +Ora, creare un RoleBinding in questo namespace, assegnando all'utente il ruolo `edit`. + +```console +$ kubectl create rolebinding sam-edit + --clusterrole edit \​ + --user sam \​ + --namespace foo +``` + +### Esempio: Concedere a un utente l'accesso in lettura/scrittura all'ambito del cluster + +Se un utente desidera installare un chart che installa risorse di ambito cluster (namespace, ruoli, definizioni di risorse personalizzate, ecc.) necessita di +accesso in scrittura all'ambito del cluster. + +Per farlo, si deve concedere all'utente l'accesso `admin` o `cluster-admin`. + +Concedere a un utente l'accesso `cluster-admin` garantisce l'accesso a tutte le +risorse disponibili in Kubernetes, compreso l'accesso ai nodi con `kubectl drain` e altri compiti amministrativi. Si raccomanda vivamente di considerare di fornire all'utente l'accesso `admin` o di creare un ClusterRole personalizzato per le sue esigenze. + +```console +$ kubectl create clusterrolebinding sam-view + --clusterrole view \​ + --user sam + +$ kubectl create clusterrolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam +``` + +### Esempio: Concedere a un utente l'accesso in sola lettura a un particolare spazio dei nomi + +Si sarà notato che non c'è un ClusterRole disponibile per visualizzare i secret. Il ClusterRole `view` non concede a un utente l'accesso in lettura ai secret, per motivi di escalation. Helm memorizza i metadati di rilascio come secret per impostazione predefinita. + +Per poter eseguire `helm list`, un utente deve essere in grado di leggere i secret. Per questo, si creerà uno speciale ClusterRole `secret-reader`. + +Creare il file `cluster-role-secret-reader.yaml` e scrivervi il seguentecontenuto nel file: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1​ +kind: ClusterRole​ +metadata:​ + name: secret-reader​ +rules:​ +- apiGroups: [""]​ + resources: ["secrets"]​ + verbs: ["get", "watch", "list"] +``` + +Quindi, creare il ClusterRole usando + +```console +$ kubectl create -f clusterrole-secret-reader.yaml​ +``` + +Una volta fatto questo, possiamo concedere a un utente l'accesso in lettura alla maggior parte delle risorse, e poi l'accesso in lettura ai secrets: + +```console +$ kubectl create namespace foo + +$ kubectl create rolebinding sam-view + --clusterrole view \​ + --user sam \​ + --namespace foo + +$ kubectl create rolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam \​ + --namespace foo +``` + +### Esempio: Concedere a un utente l'accesso in sola lettura all'ambito del cluster + +In alcuni scenari, può essere utile concedere a un utente l'accesso all'ambito del cluster. +Ad esempio, se un utente vuole eseguire il comando `helm list --all-namespaces`, +l'API richiede che l'utente abbia accesso in lettura all'ambito del cluster. + +Per farlo, si deve concedere all'utente l'accesso `view` e `secret-reader` come descritto sopra, ma con un ClusterRoleBinding. + +```console +$ kubectl create clusterrolebinding sam-view + --clusterrole view \​ + --user sam + +$ kubectl create clusterrolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam +``` + +## Riflessioni aggiuntive + +Gli esempi mostrati sopra utilizzano i ClusterRoles predefiniti forniti con +Kubernetes. Per un controllo più dettagliato sulle risorse a cui gli utenti hanno accesso, si può consultare [la documentazione di Kubernetes +https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sulla creazione di Roles e ClusterRoles personalizzati. diff --git a/content/it/docs/topics/registries.md b/content/it/docs/topics/registries.md new file mode 100644 index 000000000..cfba02ecd --- /dev/null +++ b/content/it/docs/topics/registries.md @@ -0,0 +1,252 @@ +--- +title: "Utilizzare registry OCI-based" +description: "Descrive come utilizzare OCI per la distribuzione dei chart." +aliases: ["/docs/registries/"] +weight: 7 +--- + +A partire da Helm 3, è possibile utilizzare i registry dei container con supporto [OCI](https://www.opencontainers.org/) per memorizzare e condividere i pacchetti di chart. A partire da Helm v3.8.0, il supporto OCI è abilitato per impostazione predefinita. + +## Supporto OCI prima della v3.8.0 + +Con Helm v3.8.0 il supporto OCI è passato da sperimentale a disponibile in generale. Nelle versioni precedenti di Helm, il supporto OCI si comportava in modo diverso. Se si utilizzava il supporto OCI prima di Helm v3.8.0, è importante capire cosa è cambiato con le diverse versioni di Helm. + +### Abilitazione del supporto OCI prima della v3.8.0 + +Prima di Helm v3.8.0, il supporto OCI è *sperimentale* e deve essere abilitato. + +Per abilitare il supporto sperimentale di OCI per le versioni di Helm precedenti alla v3.8.0, impostare la variabile d'ambiente `HELM_EXPERIMENTAL_OCI`. Ad esempio: + +```console +export HELM_EXPERIMENTAL_OCI=1 +``` + +### Deprecazione di funzioni OCI e cambiamenti di comportamento con la versione 3.8.0 + +Con il rilascio di [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), le seguenti caratteristiche e comportamenti sono diversi dalle versioni precedenti di Helm: + +- Quando si imposta un chart nelle dipendenze come OCI, la versione può essere impostata su un intervallo come le altre dipendenze. +- I tag SemVer che includono informazioni sulla compilazione possono essere pushed e utilizzati. I registries OCI non supportano il carattere `+` come tag. Helm traduce il `+` in `_` quando viene memorizzato come tag. +- Il comando `helm registry login` segue ora la stessa struttura della Docker CLI per la memorizzazione delle credenziali. Lo stesso path per la configurazione del registry può essere passato sia a Helm che alla Docker CLI. + +### Deprecazione di funzioni OCI e cambiamenti di comportamento con la v3.7.0 + +Il rilascio di [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) ha incluso l'implementazione di [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) per il supporto di OCI. Di conseguenza, le seguenti caratteristiche e comportamenti sono diversi dalle versioni precedenti di Helm: + +- Il sottocomando `helm chart` è stato rimosso. +- La cache dei chart è stata rimossa (niente `helm chart list` ecc.). +- I riferimenti al registry OCI sono ora sempre preceduti da `oci://`. +- Il nome di base del riferimento al registry deve *sempre* corrispondere al nome del chart. +- Il tag del riferimento al registry deve *sempre* corrispondere alla versione semantica del chart (quindi nessun tag `latest`). +- Il tipo di supporto del chart è stato cambiato da `application/tar+gzip` a `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. + + +## Utilizzo di un registry OCI-based + +### Helm repositories in registry OCI-based + +Un [repository Helm] ({{< ref "chart_repository.md" >}}) è un modo per ospitare e distribuire i chart Helm pacchettizzati. Un registry basato su OCI può contenere zero o più repository Helm e ognuno di questi repository può contenere zero o più chart Helm pacchettizzati. + +### Use hosted registries + +Esistono diversi registri di container ospitati con supporto OCI che si possono usare per i chart di Helm. Ad esempio: + +- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) +- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) +- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) +- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) +- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) +- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) +- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) + + +Seguire la documentazione del fornitore del container registry ospitati per creare e configurare un registry con supporto OCI. + +**Nota:** È possibile eseguire [Docker Registry](https://docs.docker.com/registry/deploying/) o [`zot`](https://github.com/project-zot/zot), che sono registries basati su OCI, sul computer di sviluppo. L'esecuzione di un registry basato su OCI sul computer di sviluppo deve essere utilizzata solo a scopo di test. + +### Usare sigstore per firmare i chart basati su OCI + +Il plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) permette di usare [Sigstore](https://sigstore.dev/) per firmare i chart Helm con gli stessi strumenti usati per firmare le immagini dei container. Questo fornisce un'alternativa alla [Provenienza basata su GPG]({{< ref "provenance.md" >}}) supportata dai classici [chart repository]({{< ref "chart_repository.md" >}}). + +Per maggiori dettagli sull'uso del plugin `helm sigstore`, vedere [la documentazione del progetto](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). + +## Comandi per lavorare con i registries + +### il sottocomando `registry` + +#### `login` + +accesso a un registry (con inserimento manuale della password) + +```console +$ helm registry login -u myuser localhost:5000 +Password: +Login succeeded +``` + +#### `logout` + +logout da un registry + +```console +$ helm registry logout localhost:5000 +Logout succeeded +``` + +### Il sottocomando `push + +Carica un chart in un registry basato su OCI: + +```console +$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts +Pushed: localhost:5000/helm-charts/mychart:0.1.0 +Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 +``` + +Il sottocomando `push` può essere utilizzato solo per i file `.tgz +creati in anticipo con `helm package`. + +Quando si usa `helm push` per caricare un chart in un registro OCI, il riferimento +deve essere preceduto da `oci://` e non deve contenere il nome di base o il tag. + +Il nome di base del registry viene dedotto dal nome del chart, +e il tag viene dedotto dalla versione semantica del chart. Questo è +attualmente un requisito rigoroso. + +Alcuni registry richiedono che il repository e/o lo spazio dei nomi (se specificato). +siano stati creati in precedenza. In caso contrario, verrà prodotto un errore durante l'operazione `helm push`. + +Se è stato creato un [file di provenienza] ({{< ref "provenance.md" >}}) (`.prov`), ed è presente accanto al file `.tgz` del chart, esso sarà + automaticamente caricato nel registry al momento del `push`. Questo comporta +un livello in più nel [Helm chart manifest] (#helm-chart-manifest). + +Gli utenti del plugin [helm-push](https://github.com/chartmuseum/helm-push) (per caricare i chart su [ChartMuseum]({{< ref "chart_repository.md" >}}#chartmuseum-repository-server)) +potrebbe avere dei problemi, poiché il plugin va in conflitto con il nuovo `push` integrato. +A partire dalla versione v0.10.0, il plugin è stato rinominato in `cm-push`. + +### Altri sottocomandi + +Il supporto per il protocollo `oci://` è disponibile anche in vari altri sottocomandi. +Ecco un elenco completo: + +- `helm pull` +- `helm show ` +- `helm template` +- `helm install` +- `helm upgrade` + +Il nome di base (nome del chart) del riferimento al registry *è* incluso in ogni tipo di azione che comporta il download di un chart +(rispetto a `helm push` dove viene omesso). + +Ecco alcuni esempi di utilizzo dei sottocomandi sopra elencati contro +grafici basati su OCI: + +``` +$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 +Pulled: localhost:5000/helm-charts/mychart:0.1.0 +Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff + +$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 +apiVersion: v2 +appVersion: 1.16.0 +description: A Helm chart for Kubernetes +name: mychart +... + +$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 +--- +# Source: mychart/templates/serviceaccount.yaml +apiVersion: v1 +kind: ServiceAccount +... + +$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 +NAME: myrelease +LAST DEPLOYED: Wed Oct 27 15:11:40 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +... + +$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 +Release "myrelease" has been upgraded. Happy Helming! +NAME: myrelease +LAST DEPLOYED: Wed Oct 27 15:12:05 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 2 +NOTES: +... +``` + +## Specificare le dipendenze + +Le dipendenze di un chart possono essere recuperate da un registry usando il sottocomando `dependency update`. + +Il `repository` per una data voce in `Chart.yaml` è specificato come riferimento al registry senza il nome di base: + +``` +dependencies: + - name: mychart + version: "2.7.0" + repository: "oci://localhost:5000/myrepo" +``` +Questo recupererà `oci://localhost:5000/myrepo/mychart:2.7.0` quando viene eseguito `dependency update`. + +## Helm chart manifest + +Esempio di manifest del chart Helm rappresentato in un registry +(notare i campi `mediaType`): + +```json +{ + "schemaVersion": 2, + "config": { + "mediaType": "application/vnd.cncf.helm.config.v1+json", + "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", + "size": 117 + }, + "layers": [ + { + "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", + "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", + "size": 2487 + } + ] +} +``` + +Il seguente esempio contiene un +[provenance file]({{< ref "provenance.md" >}}) +(notare il layer extra): + +```json +{ + "schemaVersion": 2, + "config": { + "mediaType": "application/vnd.cncf.helm.config.v1+json", + "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", + "size": 117 + }, + "layers": [ + { + "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", + "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", + "size": 2487 + }, + { + "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", + "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", + "size": 643 + } + ] +} +``` + +## Migrazione da un chart repo + +La migrazione dai classici [chart repository]({{< ref "chart_repository.md" >}}) +(repository basati su index.yaml) è semplice usando `helm pull`, poi `helm push` per caricare i file `.tgz` in un registry. + + diff --git a/content/it/docs/topics/release_policy.md b/content/it/docs/topics/release_policy.md new file mode 100644 index 000000000..9f678b3fb --- /dev/null +++ b/content/it/docs/topics/release_policy.md @@ -0,0 +1,45 @@ +--- +title: "Politica sui rilasci pianificati" +description: "Descrive la politica dei programmi di rilascio di Helm." +--- + +A beneficio dei suoi utenti, Helm definisce e annuncia in anticipo le date di rilascio. +Questo documento descrive la politica che regola il programma di rilascio di Helm. + +## Calendario dei rilasci + +Il calendario pubblico dei prossimi rilasci di Helm è disponibile [qui] (https://helm.sh/calendar/release). + +## Versioni semantiche + +Le versioni di Helm sono espresse come `x.y.z`, dove `x` è la versione maggiore, `y` è la versione minore e `z` è la versione della patch, secondo [Semantic +Versioning](https://semver.org/spec/v2.0.0.html). + +## Rilasci di patch + +Le patch release forniscono agli utenti correzioni di bug e di sicurezza. Non +contengono nuove funzionalità. + +Il rilascio di una nuova patch relativa all'ultima minor/major release avverrà di norma una volta al mese, il secondo mercoledì di ogni mese. + +Un rilascio di patch per correggere una regressione ad alta priorità o un problema di sicurezza può essere effettuato ogni volta che è necessario. + +Il rilascio di una patch sarà annullato per uno dei seguenti motivi: +- se non ci sono nuovi contenuti dal rilascio precedente +- se la data di rilascio della patch cade una settimana prima della release candidate (RC1) di una prossima release minore +- se la data di rilascio della patch cade entro le quattro settimane successive a una release minore + +## Rilasci minori + +I rilasci minori contengono correzioni di sicurezza e bug, oltre a nuove funzionalità. Sono retrocompatibili per quanto riguarda l'API e l'uso della CLI. + +Per allinearsi con i rilasci di Kubernetes, verrà rilasciata una minor release di helm ogni 4 mesi (3 release all'anno).Se necessario, è possibile effettuare ulteriori rilasci minori, che non influenzeranno la tempistica di un rilascio futuro annunciato, a meno che la release annunciata non sia a meno di 7 giorni di distanza. + +In concomitanza con la pubblicazione di una release, la data della prossima release minore +sarà annunciata e pubblicata sulla pagina web principale di Helm. + +## Rilasci maggiori + +Le versioni maggiori contengono cambiamenti radicali. Tali rilasci sono rari, ma a volte sono necessarie per consentire a helm di continuare a evolversi in nuove e importanti direzioni. + +Le major release possono essere difficili da pianificare. Per questo motivo, la data di rilascio finale definitiva sarà scelta e annunciata solo dopo che sarà disponibile la prima versione beta di tale release. \ No newline at end of file diff --git a/content/it/docs/topics/v2_v3_migration.md b/content/it/docs/topics/v2_v3_migration.md new file mode 100644 index 000000000..57da1a5b7 --- /dev/null +++ b/content/it/docs/topics/v2_v3_migration.md @@ -0,0 +1,110 @@ +--- +title: "Migrazione Helm da v2 a v3" +description: "Scoprite come migrare Helm da v2 a v3." +weight: 13 +--- + +Questa guida mostra come migrare Helm da v2 a v3. Helm v2 deve essere installato e gestire le release in uno o più cluster. + +## Panoramica dei cambiamenti di Helm 3 + +L'elenco completo dei cambiamenti da Helm 2 a 3 è documentato nella sezione [FAQ +(https://v3.helm.sh/docs/faq/#changes-since-helm-2). Di seguito è riportato un estratto +di alcuni di questi cambiamenti che l'utente dovrebbe conoscere prima e durante la migrazione: + +1. Rimozione di Tiller: + - Sostituisce l'architettura client/server con quella client/library (solo binary `helm`). + - La sicurezza è ora basata sull'utente (delegata al cluster di utenti Kubernetes). + - I rilasci sono ora memorizzati come secrets all'interno del cluster e i metadati dell'oggetto release sono cambiati. + - I rilasci sono persistiti in base al namespace della release e non più nel Tiller namespace. +2. Aggiornamento del repository dei chart: + - `helm search` ora supporta sia la ricerca nel repository locale che l'esecuzione di query di ricerca + nell'Hub degli artefatti +3. Chart apiVersion spostato a "v2" per le modifiche alle specifiche: + - Dipendenze del chart collegate dinamicamente spostate in `Chart.yaml`. + (`requirements.yaml` rimosso e requisiti --> dipendenze) + - I library chart (chart helper/comuni) possono ora essere aggiunti come dipendenze di chart collegati dinamicamente + - I chart hanno un campo di metadati `type` per definire che il chart è di tipo + "applicazione" o "libreria". È un'applicazione per impostazione predefinita, il che significa che + è renderizzabile e installabile + - I chart di Helm 2 (apiVersion=v1) sono ancora installabili. +4. Aggiunta della specifica di directory XDG: + - La home di Helm è stata rimossa e sostituita con una specifica di directory XDG per la memorizzazione dei file di configurazione. + - Non è più necessario inizializzare Helm + - Rimossi `helm init` e `helm home`. +5. Ulteriori modifiche: + - L'installazione/set-up di Helm è semplificata: + - Solo client Helm (helm binary) (senza Tiller). + - Paradigma Run-as-is + - i repository `local` o `stable` non sono impostati di default + - L'hook `crd-install` è stato rimosso e sostituito con la directory `crds` in chart +dove tutti i CRD in essa definiti saranno installati prima di qualsiasi rendering del chart. + - il valore dell'annotazione del hook `test-failure` è stato rimosso e `test-success` è stato deprecato. + Usare invece `test` + - Comandi rimossi/sostituiti/aggiunti: + - delete --> uninstall : rimuove tutta la cronologia dei rilasci per impostazione predefinita + (in precedenza era necessario `--purge`) + - fetch --> pull + - home (rimosso) + - init (rimosso) + - install: richiede il nome dela release o l'argomento `--generate-name`. + - inspect --> show + - reset (rimosso) + - serve (rimosso) + - template: l'argomento `-x`/`--execute` è stato rinominato in `-s`/`--show-only`. + - upgrade: Aggiunto l'argomento `--history-max` che limita il numero massimo di revisioni salvate per rilascio (0 per nessun limite) + - La libreria Go di Helm 3 ha subito molte modifiche ed è incompatibile con + la libreria Helm 2 + - I binari di rilascio sono ora ospitati su `get.helm.sh`. + +## Casi d'uso per migrazione + +I casi d'uso della migrazione sono i seguenti: + +1. Helm v2 e v3 gestiscono lo stesso cluster: + - Questo caso d'uso è consigliato solo se si intende eliminare gradualmente Helm v2 e non si richiede a v3 di gestire le release distribuite da v2. Tutte le nuove release in fase di distribuzione dovrebbero essere eseguite dalla v3 e le release esistenti distribuite dalla v2 + esistenti sono aggiornate/rimosse solo dalla v2. + - Helm v2 e v3 possono tranquillamente gestire lo stesso cluster. Le versioni di Helm + possono essere installate sullo stesso sistema o su sistemi separati + - Se si installa Helm v3 sullo stesso sistema, è necessario eseguire un passaggio aggiuntivo + per garantire che entrambe le versioni del client possano coesistere fino alla rimozione del client Helm v2.Rinominare o collocare il binario di Helm v3 in una cartella diversa per evitare conflitti. + + - Altrimenti non ci sono conflitti tra le due versioni grazie alle + seguenti distinzioni: + - I file di archiviazione delle release (cronologia) v2 e v3 sono indipendenti l'uno dall'altro. Le + modifiche includono la risorsa Kubernetes per la memorizzazione e i metadati dell'oggetto + contenuti nella risorsa. I rilasci saranno anche su un namespace per + utente invece di utilizzare namespace di Tiller (ad esempio, v2 + namespace predefinito di Tiller kube-system). v2 utilizza "ConfigMaps" o "Secrets" + sotto namespace Tiller e la ownership `TILLER`. v3 usa "Secrets" nel namespace utente e ownership `helm`. I rilasci sono incrementali sia in + v2 e v3 + - L'unico problema potrebbe esserci se le risorse Kubernetes con scope di cluster (ad es. + `clusterroles.rbac`) sono definite in un chart. La distribuzione v3 fallirebbe + anche se unico nel namespace, perché le risorse si scontrerebbero. + - La configurazione della v3 non usa più `$HELM_HOME` e utilizza invece le specifiche delle directory XDG Viene anche creata al volo, se necessario. È + quindi indipendente dalla configurazione v2. Questo è applicabile solo quando + entrambe le versioni sono installate sullo stesso sistema + +2. Migrazione di Helm v2 a Helm v3: + - Questo caso d'uso si applica quando si desidera che Helm v3 gestisca le release Helm v2 esistenti. + - Va notato che un client Helm v2: + - può gestire da 1 a molti cluster Kubernetes + - può connettersi a 1 o più istanze di Tiller per un cluster. + - Questo significa che bisogna essere consapevoli di questo quando si esegue la migrazione, in quanto le release + vengono distribuite nei cluster da Tiller e dal suo namespace. È necessario + quindi essere consapevoli della migrazione per ogni cluster e ogni istanza Tiller + gestita dall'istanza del client Helm v2. + - Il percorso di migrazione dei dati consigliato è il seguente: + 1. Backup dei dati v2 + 2. Migrare la configurazione di Helm v2 + 3. Migrare le release di Helm v2 + 4. Quando si è certi che Helm v3 stia gestendo tutti i dati di Helm v2 (per tutti i cluster e le istanze Tiller dell'istanza client di Helm v2) come + ci si aspetta, si procede alla pulizia dei dati di Helm v2. + - Il processo di migrazione è automatizzato da Helm v3 + [2to3](https://github.com/helm/helm-2to3). + +## Riferimenti + + - Plugin Helm v3 [2to3](https://github.com/helm/helm-2to3) + - Blog [post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) +che spiega l'uso del plugin `2to3` con degli esempi diff --git a/content/it/docs/topics/version_skew.md b/content/it/docs/topics/version_skew.md new file mode 100644 index 000000000..a525491af --- /dev/null +++ b/content/it/docs/topics/version_skew.md @@ -0,0 +1,74 @@ +--- +title: "Helm Version Support Policy" +description: "Descrive la politica di rilascio delle patch di Helm e lo scostamento massimo di versione supportato tra Helm e Kubernetes." +--- + +Questo documento descrive il massimo scarto di versione supportato tra Helm e +Kubernetes. + +## Versioni supportate + +Le versioni di Helm sono espresse come `x.y.z`, dove `x` è la versione maggiore, `y` è la versione minore e `z` è la versione della patch, secondo la terminologia di [Semantic +Versioning](https://semver.org/spec/v2.0.0.html). + +Il progetto Helm mantiene un branch di rilascio per la versione minore più recente. +Le correzioni applicabili, comprese quelle per la sicurezza, vengono raccolte nel ramo di rilascio, +a seconda della gravità e della fattibilità. Maggiori dettagli si trovano in +[Politica di rilascio di Helm](release_policy.md). + +## Sfasamento della versione supportata + +Quando viene rilasciata una nuova versione di Helm, questa viene compilata per una particolare +versione minore di Kubernetes. Ad esempio, Helm 3.0.0 interagisce con Kubernetes +utilizzando il client Kubernetes 1.16.2, quindi è compatibile con Kubernetes 1.16. + +A partire da Helm 3, si presume che Helm sia compatibile con `n-3` versioni di Kubernetes con cui è stato compilato.A causa dei cambiamenti di Kubernetes tra le versioni minori, la politica di supporto di Helm +2 è leggermente più restrittiva, in quanto si presume che sia compatibile con `n-1` versioni di Kubernetes. + +Ad esempio, se si utilizza una versione di Helm 3 compilata con la versione client di +API Kubernetes 1.17, allora dovrebbe essere sicuro l'utilizzo con Kubernetes 1.17, +1.16, 1.15 e 1.14. Se si sta utilizzando una versione di Helm 2 compilata +con le API client di Kubernetes 1.16, dovrebbe essere sicuro l'uso con +Kubernetes 1.16 e 1.15. + +Non è consigliabile utilizzare Helm con una versione di Kubernetes più recente di quella con cui è stato compilato in quanto Helm non fornisce alcuna garanzia di compatibilità. + +Se si sceglie di utilizzare Helm con una versione di Kubernetes non supportata, +l'utilizzo avviene a proprio rischio e pericolo. + +Per determinare quale versione di Helm è compatibile con il vostro cluster, consultate la tabella seguente. + +| Helm Version | Supported Kubernetes Versions | +|--------------|-------------------------------| +| 3.14.x | 1.29.x - 1.26.x | +| 3.13.x | 1.28.x - 1.25.x | +| 3.12.x | 1.27.x - 1.24.x | +| 3.11.x | 1.26.x - 1.23.x | +| 3.10.x | 1.25.x - 1.22.x | +| 3.9.x | 1.24.x - 1.21.x | +| 3.8.x | 1.23.x - 1.20.x | +| 3.7.x | 1.22.x - 1.19.x | +| 3.6.x | 1.21.x - 1.18.x | +| 3.5.x | 1.20.x - 1.17.x | +| 3.4.x | 1.19.x - 1.16.x | +| 3.3.x | 1.18.x - 1.15.x | +| 3.2.x | 1.18.x - 1.15.x | +| 3.1.x | 1.17.x - 1.14.x | +| 3.0.x | 1.16.x - 1.13.x | +| 2.16.x | 1.16.x - 1.15.x | +| 2.15.x | 1.15.x - 1.14.x | +| 2.14.x | 1.14.x - 1.13.x | +| 2.13.x | 1.13.x - 1.12.x | +| 2.12.x | 1.12.x - 1.11.x | +| 2.11.x | 1.11.x - 1.10.x | +| 2.10.x | 1.10.x - 1.9.x | +| 2.9.x | 1.10.x - 1.9.x | +| 2.8.x | 1.9.x - 1.8.x | +| 2.7.x | 1.8.x - 1.7.x | +| 2.6.x | 1.7.x - 1.6.x | +| 2.5.x | 1.6.x - 1.5.x | +| 2.4.x | 1.6.x - 1.5.x | +| 2.3.x | 1.5.x - 1.4.x | +| 2.2.x | 1.5.x - 1.4.x | +| 2.1.x | 1.5.x - 1.4.x | +| 2.0.x | 1.4.x - 1.3.x | From 6970e8b0455153ad3ae0cd81d3b6324724b86586 Mon Sep 17 00:00:00 2001 From: Nicolas Fantoni Date: Tue, 9 Jul 2024 11:25:45 +0200 Subject: [PATCH 03/10] add config.toml Signed-off-by: Nicolas Fantoni --- config.toml | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/config.toml b/config.toml index e2e2c0f11..9c1f2ee67 100644 --- a/config.toml +++ b/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"] From e283ba562980afe54d5c4d7a5b561ed4aa48605f Mon Sep 17 00:00:00 2001 From: Andrew Block Date: Wed, 26 Jun 2024 08:19:35 -0500 Subject: [PATCH 04/10] Road to Helm 4 Blog Signed-off-by: Andrew Block Signed-off-by: Nicolas Fantoni --- .../en/blog/2024-06-26-the-road-to-helm-4.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 content/en/blog/2024-06-26-the-road-to-helm-4.md diff --git a/content/en/blog/2024-06-26-the-road-to-helm-4.md b/content/en/blog/2024-06-26-the-road-to-helm-4.md new file mode 100644 index 000000000..b808c451b --- /dev/null +++ b/content/en/blog/2024-06-26-the-road-to-helm-4.md @@ -0,0 +1,33 @@ +--- +title: "The Road to Helm 4" +slug: "the-road-to-helm-4" +authorname: "Helm Maintainers" +author: "@HelmPack" +authorlink: "https://helm.sh" +date: "2024-06-26" +--- + +We have been saying it for a while now – Helm is "stable software". That should not come as a surprise to anyone familiar with Kubernetes and the surrounding ecosystem as many within the Kubernetes community consider Helm to be the de-facto package manager. The use of Helm is far reaching: from open source community projects, to startups, to Fortune 500 organizations. Helm has become an essential component of build and deployment workflows that handle mission critical workloads. + +One of the primary tenants that the Helm project takes very seriously is its policy related to [backwards compatibility](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#semantic-versioning). This strict adherence towards limiting impacts that could adversely affect end consumers is one of the primary reasons why Helm has become such a stable project that the community can count on. Unfortunately, Helm’s backwards compatibility policy does impose limitations to the types of changes or features that can be introduced. It is important to note that Helm is not just a CLI tool, but it is also an SDK. The Helm SDK supports an entire ecosystem of solutions that have been developed to manage Helm content. Any breaking change could negatively impact one of those integrations. + +However, even with strong adherence to the types of changes that the project can make, Helm has been able to introduce new features over time since Helm 3 was released back in 2019. The first such feature, included in Helm 3.1.0, was [post rendering functionality](https://helm.sh/docs/topics/advanced), which allows end users to customize rendered manifests before being installed or upgraded by Helm. Allowing a post rendering step in the Helm release lifecycle was a game changer for both end users and chart maintainers alike. Users no longer have to patch, fork, or manually render chart templates locally to make their custom adjustments. As a result, chart maintainers no longer need to make their charts overly complicated to fit every possible use case under the sun. Since then, minor (new feature) versions of Helm have been released on a quarterly schedule, and continue to bring ever more functionality to end users. Another important new feature introduced during Helm 3 was the support for [OCI registries as a distribution method](https://helm.sh/docs/topics/registries/#using-an-oci-based-registry) for charts. Functionality for this experimental feature shipped with Helm 3.0.0 and became a fully functional feature in 3.8.0. Users of the CLI as well as the SDK could now confidently store charts using the same tried and true method as they store the container images. And, because charts stored in container registries follow OCI standards, Helm users and chart maintainers can use many of the same tools made for container images – which continue to be improved every day – to accomplish those tasks with their Helm charts too. Helm helped bring greater standardization to the wider Cloud Native ecosystem as it was one of the first projects that made use of OCI as a storage mechanism, which has helped popularize the use of OCI artifacts by other projects. A complete list of new Helm features can be found in the release notes of each minor version [here](https://github.com/helm/helm/releases). + +The success of Helm is partially related to the architectural changes that were introduced in Helm 3. Gone are the days of the server side component, Tiller (which limited the use of Helm within multi-tenant), and security conscious environments. Countless other enhancements were also introduced that set Helm version 3 apart from its predecessors. + +Businessman Marcus Lemonis said it best: “If you don’t evolve, you will die”. This sentiment is very much a fact, especially in the technology industry where new tools, approaches, and architectures are introduced with each passing day. It has been 5 years since the release of Helm version 3 and it has become clear, thanks to input from the community, that more impactful changes need to be made to the project so that Helm can continue to serve as an efficient package manager for Kubernetes. That being said, the Helm community is excited to announce the initial kickoff to pave a path toward Helm version 4. + +## Helm 4 ContribFest at KubeCon EU 2024 + +It’s often asked: “Is Helm Popular?”. Based on responses from attendees at events, like KubeCon, who fill sessions relating to the project to maximum capacity, the answer continues to remain a resounding “YES”. At the 2024 KubeCon EU in Paris, the first steps towards soliciting feedback from the Open Source community regarding the next version of Helm occurred during the ContribFest in a session titled, “Building the Helm 4 Highway”. Clearly, there is an interest in evolving the capabilities that are part of the Helm project. Not only was the session full, but a number of compelling ideas were shared including adding support for additional templating languages other than golang, expanding the use of plugins, and increasing the level of support surrounding the secure software supply chain, such as additional methods of signing charts. The full list of ideas and topics from the ContribFest session can be found [here](https://docs.google.com/document/d/1WJ3K96fJeldKHoKhejWHDvCOTddEvY-RCtQBUaZ57FM/edit#heading=h.2xqu5w422ice). + +## Getting Involved + +For those interested in playing a role in the next version of Helm (we’d love to have you), there are several different ways to participate! + +1. Join the weekly Helm 4 Roadmap meeting Fridays at 19:00 UTC where members of the community share ideas, develop solutions, and collaborate surrounding the next version of Helm. + 1. [Zoom Meeting](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09). +2. Participate in discussions in the [#helm-dev](https://kubernetes.slack.com/archives/C51E88VDG) channel on the Kubernetes Slack, where members of the Helm community collaborate on Helm development efforts, including those focused on Helm version 4. +3. Submit an [issue](https://github.com/helm/helm/issues) within the Helm [GitHub repository](https://github.com/helm/helm). + +Helm helped define how to package and manage software for Kubernetes. But let’s not stop there - as we update and develop new features and capabilities in Helm 4, Helm will continue to be a tool that the community can continue to leverage confidently to find, share, and run software on Kubernetes. From f1bb2131577bc7c74f63a132d2fa93d0fe807c48 Mon Sep 17 00:00:00 2001 From: Andrew Block Date: Wed, 26 Jun 2024 22:27:33 -0500 Subject: [PATCH 05/10] Additional contact method to Helm 4 blog Signed-off-by: Andrew Block Signed-off-by: Nicolas Fantoni --- content/en/blog/2024-06-26-the-road-to-helm-4.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/blog/2024-06-26-the-road-to-helm-4.md b/content/en/blog/2024-06-26-the-road-to-helm-4.md index b808c451b..b0e30ef4e 100644 --- a/content/en/blog/2024-06-26-the-road-to-helm-4.md +++ b/content/en/blog/2024-06-26-the-road-to-helm-4.md @@ -29,5 +29,6 @@ For those interested in playing a role in the next version of Helm (we’d love 1. [Zoom Meeting](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09). 2. Participate in discussions in the [#helm-dev](https://kubernetes.slack.com/archives/C51E88VDG) channel on the Kubernetes Slack, where members of the Helm community collaborate on Helm development efforts, including those focused on Helm version 4. 3. Submit an [issue](https://github.com/helm/helm/issues) within the Helm [GitHub repository](https://github.com/helm/helm). +4. Follow [@HelmPack](https://x.com/HelmPack) on Twitter/X for project updates. Helm helped define how to package and manage software for Kubernetes. But let’s not stop there - as we update and develop new features and capabilities in Helm 4, Helm will continue to be a tool that the community can continue to leverage confidently to find, share, and run software on Kubernetes. From f3e508692e28f09436c2f543c7937d6c0382eef3 Mon Sep 17 00:00:00 2001 From: Karen Chu Date: Thu, 11 Jul 2024 18:14:29 +0100 Subject: [PATCH 06/10] Update 2024-06-26-the-road-to-helm-4.md updating publishing date Signed-off-by: Karen Chu Signed-off-by: Nicolas Fantoni --- content/en/blog/2024-06-26-the-road-to-helm-4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/2024-06-26-the-road-to-helm-4.md b/content/en/blog/2024-06-26-the-road-to-helm-4.md index b0e30ef4e..9c008da04 100644 --- a/content/en/blog/2024-06-26-the-road-to-helm-4.md +++ b/content/en/blog/2024-06-26-the-road-to-helm-4.md @@ -4,7 +4,7 @@ slug: "the-road-to-helm-4" authorname: "Helm Maintainers" author: "@HelmPack" authorlink: "https://helm.sh" -date: "2024-06-26" +date: "2024-07-10" --- We have been saying it for a while now – Helm is "stable software". That should not come as a surprise to anyone familiar with Kubernetes and the surrounding ecosystem as many within the Kubernetes community consider Helm to be the de-facto package manager. The use of Helm is far reaching: from open source community projects, to startups, to Fortune 500 organizations. Helm has become an essential component of build and deployment workflows that handle mission critical workloads. From 6989e34e4e19a670c2c7c0a6a5257cc1d2ab3924 Mon Sep 17 00:00:00 2001 From: Paul Muriel Biya-Bi Date: Fri, 12 Jul 2024 18:59:25 -0400 Subject: [PATCH 07/10] Docs: Fix typo on the values files page (#1596) * Docs: Fix typo on the values files page Signed-off-by: Paul Muriel Biya-Bi * Docs: Add omitted word on the values files page Signed-off-by: Paul Muriel Biya-Bi --------- Signed-off-by: Paul Muriel Biya-Bi Signed-off-by: Nicolas Fantoni --- content/en/docs/chart_template_guide/values_files.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/chart_template_guide/values_files.md b/content/en/docs/chart_template_guide/values_files.md index f8e6fc54e..6c66b793c 100644 --- a/content/en/docs/chart_template_guide/values_files.md +++ b/content/en/docs/chart_template_guide/values_files.md @@ -10,9 +10,9 @@ values passed into the chart. Its contents come from multiple sources: - The `values.yaml` file in the chart - If this is a subchart, the `values.yaml` file of a parent chart -- A values file if passed into `helm install` or `helm upgrade` with the `-f` +- A values file is passed into `helm install` or `helm upgrade` with the `-f` flag (`helm install -f myvals.yaml ./mychart`) -- Individual parameters passed with `--set` (such as `helm install --set foo=bar +- Individual parameters are passed with `--set` (such as `helm install --set foo=bar ./mychart`) The list above is in order of specificity: `values.yaml` is the default, which From 25e9259c7e7156dcd71019654c18d8bc7950cbd9 Mon Sep 17 00:00:00 2001 From: Martin Hickey Date: Wed, 10 Jul 2024 14:37:11 +0100 Subject: [PATCH 08/10] Add blog to announce end of support for Helm 2to3 tool Signed-off-by: Martin Hickey Signed-off-by: Nicolas Fantoni --- ...2024-07-16-helm2to3-becomes-unsupported.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md diff --git a/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md b/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md new file mode 100644 index 000000000..65cd819c4 --- /dev/null +++ b/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md @@ -0,0 +1,20 @@ +--- +title: "Helm 2to3 is Now Unsupported" +slug: "helm2to3-becomes-unsupported" +authorname: "Martin Hickey" +author: "@hickeyma" +authorlink: "https://helm.sh" +date: "2024-07-16" +--- + +Over four years ago, we [introduced Helm 3](https://helm.sh/blog/helm-3-released/), a major evolution in Helm's development. And we [announced](https://helm.sh/blog/2019-10-22-helm-2150-released/) at that time that Helm 2 would receive patches and security updates for a year. We also provided a [migration path to Helm 3 from Helm 2](https://helm.sh/docs/topics/v2_v3_migration/) and a tool [helm-2to3](https://github.com/helm/helm-2to3) to automate migration. + +One year later, [Helm 2 became unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). + +Here we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated by now. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the [helm-2to3](https://github.com/helm/helm-2to3) tool. + +In practice, this means the following: + +- **Helm 2to3** will receive no more updates (not even security patches). + +We strongly discourage use of Helm 2to3, as it will be receiving no future security updates or patches. From cbf24407b6cd44f15761621c138d63040c1725f5 Mon Sep 17 00:00:00 2001 From: Martin Hickey Date: Mon, 15 Jul 2024 17:38:52 +0100 Subject: [PATCH 09/10] Update after reviews Signed-off-by: Martin Hickey Signed-off-by: Nicolas Fantoni --- .../en/blog/2024-07-16-helm2to3-becomes-unsupported.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md b/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md index 65cd819c4..179b43a9c 100644 --- a/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md +++ b/content/en/blog/2024-07-16-helm2to3-becomes-unsupported.md @@ -11,10 +11,8 @@ Over four years ago, we [introduced Helm 3](https://helm.sh/blog/helm-3-released One year later, [Helm 2 became unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). -Here we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated by now. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the [helm-2to3](https://github.com/helm/helm-2to3) tool. +Here we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated to Helm 3 by this time. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the [helm-2to3](https://github.com/helm/helm-2to3) tool. -In practice, this means the following: +In practice, this means that **Helm 2to3** will receive no more updates (not even security patches). -- **Helm 2to3** will receive no more updates (not even security patches). - -We strongly discourage use of Helm 2to3, as it will be receiving no future security updates or patches. +We strongly discourage the use of the [helm-2to3](https://github.com/helm/helm-2to3) tool moving forward, as it will be receiving no future security updates or patches. We hope that it has been a useful tool to aid in the migration from Helm 2 to 3. From a83b12ff2a723a9107ee8da95df5f251b21d987e Mon Sep 17 00:00:00 2001 From: Nicolas Fantoni Date: Wed, 31 Jul 2024 11:26:35 +0200 Subject: [PATCH 10/10] fix phrase Signed-off-by: Nicolas Fantoni --- i18n/it.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i18n/it.toml b/i18n/it.toml index 0007a6183..7592c2c22 100644 --- a/i18n/it.toml +++ b/i18n/it.toml @@ -37,7 +37,7 @@ other = "Noi siamo un progetto graduated della Cloud Native Computing Foundation other = "**Il** **package manager** **per Kubernetes**" [main_subtitle] -other = "Helm è il modo migliore per trovare, condividere e utilizzare il software realizzato per [Kubernetes](https://kubernetes.io)." +other = "Helm è il modo migliore per trovare, condividere e utilizzare applicazioni realizzate per [Kubernetes](https://kubernetes.io)." ## homepage about helm [main_what_is_helm_title]